CCAMP Working Group P. Doolan Internet-Draft Coriant Intended status: Informational October 27, 2014 Expires: April 30, 2015 Concerns with the use of Proprietary Application Codes draft-doolan-ccamp-proprietary-ac-00 Abstract This document explains the terms Application Code and Application Identifier and points out a danger that exists when proprietary application codes are used. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 30, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Doolan Expires April 30, 2015 [Page 1] Internet-DraftProblems with proprietary Application CodesC October 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Description and definition of AC and AI . . . . . . . . . . . 2 3.1. AC . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2. AI . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. AC and AI axioms . . . . . . . . . . . . . . . . . . . . 4 4. Using AIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Using AI containing a STANDARD AC . . . . . . . . . . . . 5 4.2. Using AI containing a PROPRIETARY AC . . . . . . . . . . 5 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Application Code (AC) and Application Identifier (AI) are concepts and terms defined in the ITU-T. They have been used in at least two drafts in the IETF [SNMP][LMP] and it is quite possible they will be used in others. While the definitions of these concepts are not overly complicated it is important to understand them and to be aware of some subtleties in using them. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Description and definition of AC and AI This section provides and discusses some descriptive and definitional material realted to AC and AI from ITU-T Recommendations. 3.1. AC ACs have been used in ITU-T Recommendations that specify optical interface parameters since at least the early 1990s. They are used in many of the ITU-T Recommendations referenced in CCAMP work e.g. G.957 [ITU-T_G.957], G.695 [ITU-T_G.695], G.698.1 [ITU-T_G.698.1] and G.698.2 [ITU-T_G.698.2]. Doolan Expires April 30, 2015 [Page 2] Internet-DraftProblems with proprietary Application CodesC October 2014 ACs are explained in the ITU-T handbook 'Optical fibres, cables and systems' [ITU-T_OFCS]. ACs take into account 'the many possible combinations of channel counts, optical tributary signal types, span distances, fibre types and system configurations. The structure of these codes varies from one Recommendation to another, depending on the characteristics required to distinguish one application from another'. An indication of the bit rate and of the type of fibre employed is common to all ACs specified in ITU-T Recommendations. ACs are perhaps best illustrated by example, in the handbook we find two examples: From G.957 the AC 'L-16.2' wherein: o L indicates a target distance of ~ 80kn (long reach) o 16 indicates bit rate is STM-16 (2.48832 Gbits/s) o 2 indicates G.652 fibre (in the 1550nm region) And a more complicated example 'DN100C-2A(L)F' from G.698.2 wherein: o D indicates DWDM o N indicates narrow spectral excursion o 100 indicates minimum channel spacing of 100GHz o C indicates chromatic dispersion limits appropriate to a compensated link o 2 indicates highest class of bit rate supported is NRZ 10G o A indicates that the link may contain optical amplifiers o 3 indicates G.653 fibre o L indicates operating wavelength in the L band o F indicates that FEC must be transmitted 3.2. AI In contrast to venerable history of AC, which first appears in Recommendations under the responsiblity of Q6/15 in the 1990s, AI is a more modern creation of Q12/15 and appears first in G.872 [ITU-T_G.872] the 'Architecture of optical transport networks' in 2012. Doolan Expires April 30, 2015 [Page 3] Internet-DraftProblems with proprietary Application CodesC October 2014 In G.872 we find that 'the characteristic information of the OCh layer network (is) an optical signal defined by a set of parameters. The central frequency, required bandwidth and other analogue parameters such as signal-to-noise ratio associated with the network media channel are of particular interest. The parameters are captured in an application identifier, which covers both standardized as well as proprietary applications'. These parameters defining the characteristic information of an optical signal are the same parameters as were heretofore encoded in ACs; the difference is that AI covers 'standard and proprietary applications'. In a footnote we find the important qualification that 'an application identifier applies to the transmitter, the network media channel and receiver combination. It does not apply to a single interface'. In G.874 [ITU-T_G.874], which is a management specification under the responsibility of Q14/15 entitled 'Management aspects of optical transport network elements', there is a clause describing management of AIs. It states that G.872 has 'generalised Application Code to Application Identifier so that proprietary (i.e. non standard) applications can be handled'. There is still no definition of AI here; for that we have to consult G.874.1 [ITU-T_G.874.1] the 'Optical transport network (OTN): Protocol-neutral management information model for the network element view' where, in the UML model supplied with that Recommendation we find: The syntax of ApplicationIdentifier is a pair{ApplicationIdentifierType, PrintableString}. The value of ApplicationIdentifierType is either STANDARD or PROPRIETARY. The value of PrintableString represents the standard application code as defined in the ITU-T Recommendations or a vendor-specific proprietary code. This is the Holy Grail; from it we can draw some axioms which we list below. 3.3. AC and AI axioms Note that we also discuss proprietary codes (PC) in this section. o An AI may contain an AC OR a PC. o An AC is NOT the same as an AI. o An AI is NOT the same as an AC. o A PC is NOT the same as an AI. o An AI is not the same as a PC. Doolan Expires April 30, 2015 [Page 4] Internet-DraftProblems with proprietary Application CodesC October 2014 o ACs are defined in ITU-T standards and the corresponding AI would be {STANDARD, AC value} o By definition PCs are proprietary and not defined in standards but, the vendor specific values would be given as printable strings in an AI as {PROPRIETARY, PC value}. 4. Using AIs The IETF specifies protocols; CCAMP in particular specifies protocols that are used to configure and control equipment containing optical interfaces that conform to ITU-T specifications. It is quite natural to imagine that routing, signaling or link management protocols, or extensions to such protocols, developed in CCAMP might need to encode parameters describing those optical interfaces. In the past using an AC would have been a natural choice to do that, now, with the specificaton of AI, using AI would seem to be a best practice. Indeed we see existence proof in some work in progress in CCAMP [SNMP][LMP] that AI is already being used. The IETF's work is used throughout the industry. Other bodies 'profile' protocol specifications developed in IETF and use those profiles as building blocks for specification of implementation agreements designed to enable the development of multivendor interoperable systems. It is vital therefore that we consider the use of AI as currently specified from that perspective. In the following sections we consider the use of Standard and Proprietary ACs in AIs. 4.1. Using AI containing a STANDARD AC When a protocol component receives or sends an AI containing the ApplicationIdentifierType set to STANDARD there is no ambiguity about the meaning or provenance of the PrintAble string the AI contains: It MUST be an AC defined in an ITU-T Recommendation. We note that, unfortunately, there is no single registry of ITU-T ACs, but there are a relatively small number of Recommendations that need to be examined to determine whether an AC identified in this way, i.e as standard, really is what it claims to be. The situation is not so clear cut for proprietary ACs which we consider next. 4.2. Using AI containing a PROPRIETARY AC When a protocol component receives an AI containing the ApplicationIdentifierType set to PROPRIETARY there are two possibilities: it either recognizes the AC or it does not. We can Doolan Expires April 30, 2015 [Page 5] Internet-DraftProblems with proprietary Application CodesC October 2014 dismiss the second of these trivially; robust specifications of protocols contain instructions for handling unrecognised or incorectly formatted information elements. The first case, wherein the AC is recognised, might also seem straightforward - after all the AC has been 'recognised' - but it is not. Because there is, beyond the fact that it is represented by a printable string, no definition of a proprietary code it is impossible for a protocol entity to distinguish between a PROPRIETARY AC that it believes to be one of its own (i.e sent by a protocol peer using the same proprietary list of PROPRIETARY ACs) and one sent from an implementation using a different proprietary list of ACs one of which is, unfortunately, identical. Proprietary ACs are not uniquely self identifying and a risk of collision exists. This means that they may not be used in a manner that requires them to be unique. 5. Discussion AI is a relatively new concept that allows for representation of standard (ITU-T specified) and proprietary ACs. This is valuable and we believe that protocol specifications that need to communicate optical interface parameters should use AI henceforth. This memo identifies a potential problem with the use of proprietary ACs wherein a 'collision' between ACs may occur. We believe such collisions to be dangerous and that they should be eliminated. How that is done is FFS but we note that the definition of AI is the responsibility of ITU-T SG15 and it is important that a solution be developed. Until such time as a resolution to this problem has been achieved we believe that proprietary application codes should be considered dangerous and not used in a way that requires them to be unique i.e. not used at all. Standard ACs are not afflicted by this problem and may be used. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations TBD Doolan Expires April 30, 2015 [Page 6] Internet-DraftProblems with proprietary Application CodesC October 2014 8. References 8.1. Normative References [ITU-T_G.695] ITU-T, "ITU-T G.695 Optical interfaces for coarse wavelength division multiplexing applications; 10/2010", 2010, . [ITU-T_G.698.1] ITU-T, "ITU-T G.698.1 Multichannel DWDM applications with single-channel optical interfaces; 11/2009", 2009, . [ITU-T_G.698.2] ITU-T, "ITU-T G.698.2 Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces ; 11/2009", 2009, . [ITU-T_G.872] ITU-T, "ITU-T G.872 - Architecture of optical transport networks; 10/2012", 2012, . [ITU-T_G.874] ITU-T, "ITU-T G.874 - Management aspects of optical transport network elements; 08/2013", 2013, . [ITU-T_G.874.1] ITU-T, "ITU-T G.874.1 - Optical transport network: Protocol-neutral management information model for the network element view; 10/2012", 2012, . [ITU-T_G.957] ITU-T, "ITU-T G.957 Optical interfaces for equipments and systems relating to the synchronous digital hierarchy; 03/2006", 2006, . [LMP] IETF, "(work in progress) Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application draft-dharinigert-ccamp-g-698-2-lmp-08", 2014, . Doolan Expires April 30, 2015 [Page 7] Internet-DraftProblems with proprietary Application CodesC October 2014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SNMP] IETF, "(work in progress) An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications", 2014, . 8.2. Informative References [ITU-T_OFCS] ITU-T, "ITU-T Handbook - Optical fibres, cables and systems, ITU-T Manual 2009", 2009. Author's Address Paul Doolan Coriant USA Phone: +1 972 357 5822 Email: paul.doolan@coriant.com Doolan Expires April 30, 2015 [Page 8]