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, <http://www.itu.int/rec/T-REC-G.695/en>.

   [ITU-T_G.698.1]
              ITU-T, "ITU-T G.698.1 Multichannel DWDM applications with
              single-channel optical interfaces; 11/2009", 2009,
              <http://www.itu.int/rec/T-REC-G.698.1/en>.

   [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,
              <http://www.itu.int/rec/T-REC-G.698.2/en>.

   [ITU-T_G.872]
              ITU-T, "ITU-T G.872 - Architecture of optical transport
              networks; 10/2012", 2012,
              <http://www.itu.int/rec/T-REC-G.872/en>.

   [ITU-T_G.874]
              ITU-T, "ITU-T G.874 - Management aspects of optical
              transport network elements; 08/2013", 2013,
              <http://www.itu.int/rec/T-REC-G.874/en>.

   [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,
              <http://www.itu.int/rec/T-REC-G.874.1/en>.

   [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, <http://www.itu.int/rec/T-REC-G.957/en>.

   [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,
              <https://tools.ietf.org/id/draft-dharinigert-ccamp-
              g-698-2-lmp-08.txt>.



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, <http://tools.ietf.org/html/
              draft-galikunze-ccamp-g-698-2-snmp-mib-02>.

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]