Internet DRAFT - draft-doolan-ccamp-proprietary-ac
draft-doolan-ccamp-proprietary-ac
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]
