Network Working Group G. BernsteinInternetDraftEngineering Task Force (IETF) G. Bernstein, Ed. Request for Comments: 7579 Grotto NetworkingIntended status:Category: Standards Track Y.Lee Expires: June 2015Lee, Ed. ISSN: 2070-1721 D. Li Huawei W. Imajuku NTTFebruary 23,J. Han Huawei June 2015 General Network Element Constraint Encoding forGMPLS ControlledGMPLS-Controlled Networksdraft-ietf-ccamp-general-constraint-encode-20.txtAbstract Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Status ofthisThis Memo ThisInternet-Draftissubmitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force(IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum(IETF). It represents the consensus ofsix monthsthe IETF community. It has received public review andmay be updated, replaced, or obsoletedhas been approved for publication byother documents at any time. Itthe Internet Engineering Steering Group (IESG). Further information on Internet Standards isinappropriate to use Internet-Drafts as reference material or to cite them other than as "workavailable inprogress." Internet-Draft General Network Element Constraint Encoding February 2015 The listSection 2 of RFC 5741. Information about the currentInternet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The liststatus ofInternet-Draft Shadow Directories canthis document, any errata, and how to provide feedback on it may beaccessedobtained athttp://www.ietf.org/shadow.html This Internet-Draft will expire on June 23, 2015.http://www.rfc-editor.org/info/rfc7579. Copyright Notice Copyright (c) 2015 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.Conventions used in this document 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].Table of Contents 1.Introduction...................................................3Introduction ....................................................4 1.1. Node Switching AsymmetryConstraints......................4Constraints .......................4 1.2.Non-LocalNon-local Label AssignmentConstraints....................4Constraints .....................5 1.3. Conventions Used in This Document ..........................5 2.Encoding.......................................................5Encoding ........................................................5 2.1. Connectivity MatrixField.................................5Field ..................................6 2.2. Port LabelRestriction Field..............................7Restrictions Field ..............................7 2.2.1.SIMPLE_LABEL.........................................8SIMPLE_LABEL ........................................9 2.2.2.CHANNEL_COUNT........................................9CHANNEL_COUNT .......................................9 2.2.3.LABEL_RANGE..........................................9 Internet-Draft General Network Element Constraint Encoding February 2015LABEL_RANGE ........................................10 2.2.4. SIMPLE_LABEL &CHANNEL_COUNT........................10CHANNEL_COUNT .......................10 2.2.5.Link Label Exclusivity..............................10LINK_LABEL_EXCLUSIVITY .............................11 2.3. Link SetField...........................................11Field ............................................11 2.4. Available LabelsField...................................13Field ....................................13 2.5. Shared Backup LabelsField...............................14Field ................................14 2.6. Label SetField..........................................14 2.6.1. Inclusive/Exclusive Label Lists.....................15 2.6.2. Inclusive/Exclusive Label Ranges....................16 2.6.3. Bitmap Label Set....................................17Field ...........................................15 3. SecurityConsiderations.......................................17Considerations ........................................17 4. IANAConsiderations...........................................18Considerations ............................................18 5.Acknowledgments...............................................18 APPENDIX A:References .....................................................18 5.1. Normative References ......................................18 5.2. Informative References ....................................19 Appendix A. EncodingExamples....................................19Examples .....................................20 A.1. Link SetField...........................................19Field ............................................20 A.2. Label SetField..........................................19Field ...........................................20 A.3. ConnectivityMatrix......................................20Matrix .......................................21 A.4. Connectivity Matrix withBi-directional Symmetry.........23Bidirectional Symmetry ...........25 A.5. Priority Flags in Available/Shared BackupLabels.........25 6. References....................................................27 6.1. Normative References.....................................27 6.2. Informative References...................................28 7. Contributors..................................................29Labels ..........27 Contributors ......................................................27 Authors'Addresses...............................................30Addresses ................................................29 1. Introduction Somedata planedata-plane technologies that wish to make use of a GMPLS control plane contain additional constraints on switching capability and label assignment. In addition, some of these technologies must perform non-local label assignment based on the nature of the technology, e.g., wavelength continuity constraint in Wavelength Switched Optical Networks(WSON)(WSONs) [RFC6163]. Such constraints can lead to the requirement forlink by linklink-by-link label availability in path computation and label assignment. This document provides efficient encodings of information needed by the routing and label assignment process in technologies such as WSON and are potentially applicable to a wider range of technologies. Such encodings can be used to extend GMPLS signaling and routing protocols. Inadditionaddition, these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE).Internet-Draft General Network Element Constraint Encoding February 20151.1. Node Switching Asymmetry Constraints For some network elements, the ability of a signal or packet on a particular input port to reach a particular output port may be limited.In addition,Additionally, in some network elements (e.g., a simple multiplexer), the connectivity between some inputportsand output ports may befixed, e.g., a simple multiplexer.fixed. To take into account such constraints during path computation, we model this aspect of a network element via a connectivity matrix. The connectivity matrix (ConnectivityMatrix) represents either the potential connectivity matrix for asymmetric switches or fixed connectivity for an asymmetric device such as a multiplexer. Note that this matrix does not represent any particular internal blocking behavior but indicates which input ports and labels (e.g., wavelengths) could possibly be connected to a particular output port and label pair. Representing internalstate dependentstate-dependent blocking for a node is beyond the scope of this document and, due to its highly implementation-dependent nature, would most likely not be subject to standardization in the future. The connectivity matrix is a conceptual M*m by N*n matrix where M represents the number of input portseach(each with mlabelslabels) and N the number of output portseach(each with nlabels.labels). 1.2.Non-LocalNon-local Label Assignment Constraints If the nature of the equipment involved in a network results in a requirement for non-local label assignment, we can have constraints based on limits imposed by the ports themselves and those that are implied by the current label usage. Note that constraints such as these only become important when label assignment has a non-local character. For example, inMPLSMPLS, an LSR may have a limited range of labels available for use on an outputport,port and a set of labels already in use on thatport, and henceport; these are therefore unavailable for use. This information, however, does not need to be shared unless there is some limitation on the LSR's label swapping ability. For example, if aTDMTime Division Multiplexer (TDM) node lacks the ability to perform time-slotinterchange,interchange or a WSON lacks the ability to perform wavelength conversion, then the label assignment process is not local to a single node. In this case, it may be advantageous to share the label assignment constraint information for use in path computation. Port label restrictions (PortLabelRestriction) model the label restrictions that the network element (node) and link may impose on a port. These restrictions tell us what labels may or may not beInternet-Draft General Network Element Constraint Encoding February 2015used on a link and are intended to be relatively static. More dynamic information is contained in the information on available labels. Port label restrictions are specified relative to the port in general or to a specific connectivity matrix for increased modeling flexibility.Reference[Switch] gives an example where both switch and fixed connectivity matrices are used and both types of constraints occur on the same port. 1.3. Conventions Used in This Document 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]. 2. Encoding This section provides encodings for the information elements defined in[RWA-Info][RFC7446] that have applicability to WSON. The encodings are designed to be suitable for use in the GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in the PCEprotocolCommunication Protocol (PCEP) [RFC5440]. Note that the information distributed in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs withinTLVs andTLVs; this document defines elements to be used within such constructs. Specific constructs of sub-TLVs and the nesting of sub-TLVs of the information element defined by this document will be defined in the respective protocol enhancement documents. 2.1. Connectivity Matrix Field The Connectivity Matrix Field represents how input ports are connected to output ports for network elements. The switch and fixed connectivity matrices can be compactly represented in terms of a minimal list of input and output port set pairs that have mutual connectivity. As described in [Switch], such a minimal list representation leads naturally to a graph representation for path computationpurposes thatpurposes; this representation involves the fewest additional nodes and links. The Connectivity Matrix Field is uniquely identified only by the advertising node. There may be more than one Connectivity Matrix Field associated with a node as a node can partition the switch matrix into severalsub- matrices.sub-matrices. This partitioning is primarily to limit the size of any individual information element used to represent the matrix and to enable incremental updates. When the matrix is partitioned intosub- matrices,sub-matrices, each sub-matrix will be mutually exclusive to one another in representing which ports/labels are associated with eachsub- matrix.sub-matrix. This implies that two matrices will not have the same {src port, src label, dst port, dst label}.Internet-Draft General Network Element Constraint Encoding February 2015Each sub-matrix is identified via a different Matrix IDwhichthat MUST represent a unique combination of {src port, src label, dst port, dst label}. A TLV encoding of this list of link set pairs is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conn | MatrixID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Set A #1 | : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Set B #1 : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Linkset pairsSet Pairs asneededNeeded | : tospecify connectivitySpecify Connectivity : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+WhereWhere: Connectivity (Conn) (4bit)bits) is the device type. 0--- the device is fixed 1--- the device is switched (e.g.,ROADM/OXC)Reconfigurable Optical Add/Drop Multiplexer / Optical Cross-Connect (ROADM/OXC)) MatrixID represents the ID of the connectivity matrix and is an8 bit8-bit integer. The value of 0xFF is reserved for use with port label constraints and should not be used to identify a connectivity matrix. Link Set A #1 and Link Set B #1 together represent a pair of link sets. See Section2.3.2.3 for adetaildetailed description of thelink set field.Link Set Field. There are two permitted combinations for thelink set fieldLink Set Field parameter "dir" forLink Setlink set A and B pairs: o Link Set A dir=input, Link Set B dir=output In this case, the meaning of the pair of link sets A and Bin this caseis that any signal that inputs a link in set A can be potentially switched out of an output link in set B.Internet-Draft General Network Element Constraint Encoding February 2015o Link Set A dir=bidirectional, Link Set B dir=bidirectionalTheIn this case, the meaning of the pair of link sets A and Bin this caseis that any signal that inputs on the links in set A can potentially output on a link in setB,B and any input signal on the links in set B can potentially output on a link in set A. If link set A is an input and link set B is an output for a signal, then it implies that link set A is an output and link set B is an input for that signal. See Appendix A for both types of encodings as applied to a ROADM example. 2.2. Port LabelRestrictionRestrictions Field The Port LabelRestrictionRestrictions Field tells us what labels may or may not be used on a link. The port labelrestrictionrestrictions can be encoded asfollows:follows. More than one of these fields may be needed to fully specify a complex port constraint. When more than one of these fieldsareis present, the resulting restriction is the union of the restrictions expressed in each field. The use of the reserved value of 0xFF for the MatrixID indicates that a restriction applies to theport,port and not to a specific connectivity matrix. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MatrixID | RstType |SwitchingCapSwitching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Restriction Parameters per Restriction Type | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: MatrixID: either is the value in the corresponding Connectivity MatrixfieldField or takes the value 0xFF to indicate the restriction applies to the port regardless of anyConnectivity Matrix.connectivity matrix. RstType (Restriction Type) can take the following values and meanings:Internet-Draft General Network Element Constraint Encoding February 20150: SIMPLE_LABEL (Simple label selectiverestriction;restriction). See Section 2.2.1 fordetails)details. 1: CHANNEL_COUNT (Channel countrestriction;restriction). See Section 2.2.2 fordetails)details. 2: LABEL_RANGE (Label range device with a movable center label andwidth;width). See Section 2.2.3 fordetails)details. 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL and CHANNEL_COUNT restriction. The accompanying label set and channel count indicate labels permitted on the port and the maximum number of channels that can be simultaneously used on theport;port). See Section 2.2.4 fordetails)details. 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once amongst a set of specifiedports;ports). See Section 2.2.5 fordetails) SwitchingCapdetails. Switching Cap (Switching Capability) is defined in[RFC4203][RFC4203], and LSP Encoding Type is defined in [RFC3471]. The combination of these fields defines the type of labels used in specifying the port label restrictions as well as the interface type to which these restrictions apply. The Additional Restriction Parameters per RestrictionType field is an optional field that describes additional restriction parameters for each RestrictionType pertaining to specific protocols. 2.2.1. SIMPLE_LABEL In the case oftheSIMPLE_LABEL,Thethe formatis given by:is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MatrixID | RstType = 0 |SwitchingCapSwitching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In thiscasecase, the accompanying label set indicates the labels permitted on the port/matrix. See Section 2.6 for the definition of label set.Internet-Draft General Network Element Constraint Encoding February 20152.2.2. CHANNEL_COUNT In the case oftheCHANNEL_COUNT, the formatis given by:is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MatrixID | RstType = 1| SwitchingCap|Switching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxNumChannels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In thiscasecase, the accompanying MaxNumChannels indicates the maximum number of channels (labels) that can be simultaneously used on the port/matrix. MaxNumChannels is a 32-bit integer. 2.2.3. LABEL_RANGE In the case oftheLABEL_RANGE, the formatis given by:is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MatrixID | RstType = 2 | Switching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxLabelRange | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is a generalization of the waveband device. The MaxLabelRange indicates the maximum width of the waveband in terms of the channels spacing given in the Label Set Field. The corresponding label set is used to indicate the overall tuning range. MaxLabelRange is a 32-bit integer. See Section 2.6.2 forthean explanation of label range.Internet-Draft General Network Element Constraint Encoding February 20152.2.4. SIMPLE_LABEL & CHANNEL_COUNT In the case oftheSIMPLE_LABEL &CHANNEL_COUNTCHANNEL_COUNT, the formatis given by:is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MatrixID | RstType = 3 |SwitchingCapSwitching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxNumChannels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In thiscasecase, the accompanying label set and MaxNumChannels indicate labels permitted on the port and the maximum number of labels that can be simultaneously used on the port. See Section 2.6 for the definition of label set. 2.2.5.Link Label ExclusivityLINK_LABEL_EXCLUSIVITY In the case oftheLink LabelExclusivityExclusivity, the formatis given by:is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MatrixID | RstType = 4 |SwitchingCapSwitching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Set Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In thiscasecase, the accompanying link set indicates that a label may be used at most once among the ports in thelink set field.Link Set Field. See Section 2.3 for the definition of link set.Internet-Draft General Network Element Constraint Encoding February 20152.3. Link Set Field We will frequently need to describe properties of groups of links. To do soefficientlyefficiently, we can make use of a link set concept similar to the label set concept of [RFC3471].ThisThe Link Set Field is used in the <ConnectivityMatrix>, which is defined in Section 2.1. The information carried in aLink Setlink set is definedby:as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action |Dir| Format | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action: 8 bits 0 - Inclusive List Indicates that one or more link identifiers are included in theLink Set.link set. Each identifies a separate link that is part of the set. 1 - Inclusive Range Indicates that theLink Setlink set defines a range of links. It contains two link identifiers. The first identifier indicates the start of the range. The second identifier indicates the end of the range. All links with numeric values between the bounds are considered to be part of the set. A value of zero in either position indicates that there is no bound on the corresponding portion of the range. Note that the Action field can be set to 0x01 (Inclusive Range) only when the identifier for unnumbered link is used. Dir: Directionality of theLink Setlink set (2 bits) 0--- bidirectional 1--- inputInternet-Draft General Network Element Constraint Encoding February 20152--- outputFor example, inIn opticalnetworksnetworks, we think in terms of unidirectionalas well asand bidirectional links. For example, label restrictions or connectivity may be different for an inputport,port than for its "companion" outputportport, if one exists. Note that "interfaces" such as those discussed in the Interfaces MIB [RFC2863] are assumed to be bidirectional. This also applies to the links advertised in various link state routing protocols. Format: The format of the link identifier (6 bits) 0--- Link Local Identifier Indicates that the links in theLink Setlink set are identified by link local identifiers. All link local identifiers are supplied in the context of the advertising node. 1--- Local Interface IPv4 Address Indicates that the links in the link set are identified by Local Interface IPv4 Address. 2--- Local Interface IPv6 Address Indicates that the links in theLink Setlink set are identified by Local InterfaceIPIPv6 Address. Others--- Reserved for futureuse.use Note that all link identifiers in the same list must be of the same type. Length: 16 bits This field indicates the total length in bytes of the Link Setfield.Field. Link Identifier: length is dependent on the link format The link identifier represents the portwhichthat is being described either for connectivity or for label restrictions. This can be the link local identifier of[RFC4202],GMPLSrouting, [RFC4203]routing [RFC4202], GMPLS OSPFrouting,routing [RFC4203], and[RFC5307]IS-IS GMPLSrouting.routing [RFC5307]. The use of the link local identifier format can result in more compact encodings when the assignments are done in a reasonable fashion.Internet-Draft General Network Element Constraint Encoding February 20152.4. Available Labels Field The Available Labels Field consists of priorityflags,flags and a singlevariable length label set fieldvariable-length Label Set Field as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRI | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+WhereWhere: PRI (Priority Flags, 8 bits): A bitmap used to indicate which priorities are being advertised. The bitmap is in ascending order, with the leftmost bit representing priority level 0 (i.e., the highest) and the rightmost bit representing priority level 7 (i.e., the lowest). A bit MUST be set (1) corresponding to each priority represented in thesub-TLV,sub-TLV and MUST NOT be set (0) when the corresponding priority is not represented. If a label is available at priorityMM, it MUST be advertised available at each priority N < M. At least one priority level MUST be advertised. The PRI field indicates the availability of the labels for use inLSP set upLabel Switched Path (LSP) setup andpre-emptionpreemption as described in [RFC3209]. When a label is advertised as available for priorities 0, 1, ...MM, it may be used by any LSP of priority N <= M. When a label is in use by an LSP of priorityMM, it may be used by an LSP of priority N < M if LSP preemption is supported. When a label was initially advertised as available forpriorities,priorities 0, 1, ... M and once a label is used for an LSP at a priority, say N (N<=M), then this label is advertised as available for 0, ... N-1. Note that the Label Set Field is defined in Section 2.6. See AppendixA.5.A.5 for illustrative examples.Internet-Draft General Network Element Constraint Encoding February 20152.5. Shared Backup Labels Field The Shared Backup Labels Field consists of priorityflags,flags and a singlevariable length label set fieldvariable-length Label Set Field as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRI | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+WhereWhere: PRI (Priority Flags, 8 bits): A bitmap used to indicate which priorities are being advertised. The bitmap is in ascending order, with the leftmost bit representing priority level 0 (i.e., the highest) and the rightmost bit representing priority level 7 (i.e., the lowest). A bit MUST be set (1) corresponding to each priority represented in thesub-TLV,sub-TLV and MUST NOT be set (0) when the corresponding priority is not represented. If a label is available at priorityMM, it MUST be advertised available at each priority N < M. At least one priority level MUST be advertised. The same LSPset upsetup andpre-emptionpreemption rules specified in Section 2.4 apply here. Note that Label Set Field is defined in Section 2.6. See AppendixA.5.A.5 for illustrative examples. 2.6. Label Set Field The Label Set Field is used within the<AvailableLabels>Available Labels Field or the<SharedBackupLabels>, which isShared Backup Labels Field, defined in Sections2.4.2.4 and2.5.,2.5, respectively. It is also used withinthe <SIMPLE_LABEL>, <LABEL_RANGE>, <SIMPLE_LABEL>SIMPLE_LABEL, LABEL_RANGE, or<CHANNEL_COUNT>, which isSIMPLE_LABEL & CHANNEL_COUNT, defined in Sections2.1.1. - 2.1.4.,2.2.1, 2.2.3, and 2.2.4, respectively. The general format for a label set is given below. This format uses the Action concept from [RFC3471] with an additional Action to define a"bit map""bitmap" type of label set. Labels are variable in length.Action specificAction-specific fields are definedbelow. Internet-Draft General Network Element Constraint Encoding February 2015in Sections 2.6.1, 2.6.2, and 2.6.3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action| Num Labels = N | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Base Label | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(Action specific(Action-specific fields) | | . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action: 0 - Inclusive List 1 - Exclusive List 2 - Inclusive Range 3 - Exclusive Range 4 - Bitmap Set Num Labels is generally the number of labels. It has a specific meaning depending on theactionAction value. See Sections2.6.1 -2.6.1, 2.6.2, and 2.6.3 for details. Num Labels is a12 bit12-bit integer. Length is the length in bytes of the entirelabel set field.Label Set Field. 2.6.1. Inclusive/Exclusive Label ListsIn the case of theFor inclusive/exclusive lists (Action = 0 or 1), the wavelength set formatis given by: Internet-Draft General Network Element Constraint Encoding February 2015is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 or 1 | Num Labels = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label #1 | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label #N | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Where:Label #1 is the firstLabellabel to beincluded/excludedincluded/excluded, and Label #N is the lastLabellabel to be included/excluded. Num Labels MUST match with N. 2.6.2. Inclusive/Exclusive Label RangesIn the case ofFor inclusive/exclusive ranges (Action = 2 or 3), the label set formatis given by:is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2 or 3 | Num Labels | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Label | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Label | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that Start Label is the firstLabellabel in the range to beincluded/excludedincluded/excluded, and End Label is the last label in the same range. Num Labels MUST be two.Internet-Draft General Network Element Constraint Encoding February 20152.6.3. Bitmap Label SetIn the case of Action = 4, theFor bitmap sets (Action = 4), the label set formatis given by:is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Num Labels | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Base Label | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Bit MapBitmap Word #1 (Lowest numerical labels) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Bit MapBitmap Word #N (Highest numerical labels) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+WhereIn this case, Num Labelsin this casetells us the number of labels represented by thebit map.bitmap. Each bit in thebit mapbitmap represents a particular label with a value of 1/0 indicating whether or not the label is in theset or not.set. Bit position zero represents the lowest label and corresponds to the base label, while each succeeding bit position represents the next label logically above the previous. The size of thebit mapbitmap is Num Labels bits, but thebit mapbitmap is padded out to a full multiple of 32 bits so that the field is a multiple of four bytes. Bits that do not represent labels(i.e., those in positions (Num Labels) and beyond)SHOULD be set to zero and MUST be ignored. 3. Security Considerations This document defines protocol-independent encodings for WSON information and does not introduce any security issues. However, other documents that make use of these encodings within protocol extensions need to consider the issues and risks associatedInternet-Draft General Network Element Constraint Encoding February 2015with inspection, interception, modification, or spoofing of any of this information. It is expected that any such documents will describe the necessary security measures to provide adequate protection. A general discussion on security in GMPLS networks can be found in [RFC5920]. 4. IANA Considerations This document provides generalprotocol independentprotocol-independent information encodings. There is no IANA allocation request for the information elements defined in this document. IANA allocation requests will be addressed inprotocol specificprotocol-specific documents based on the encodings defined here. 5.Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Internet-Draft General Network Element Constraint EncodingReferences 5.1. Normative References [G.694.1] ITU-T, "Spectral grids for WDM applications: DWDM frequency grid", ITU-T Recommendation G.694.1, February2015 APPENDIX A: Encoding Examples Here we give examples of the general encoding extensions applied2012. [RFC2119] Bradner, S., "Key words for use in RFCs tosome simple ROADM network elementsIndicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2863] McCloghrie, K. andlinks. A.1. Link Set Field Suppose that we wishF. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, <http://www.rfc-editor.org/info/rfc2863>. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions todescribe a setRSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>. [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>. [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support ofinput ports that are have link local identifiers number 3 through 42. In the link set field we set the Action = 1 to denote an inclusive range; the Dir = 1 to denote input links; and, the Format = 0 to denote link local identifiers. In particular we have: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.2.Generalized Multi-Protocol LabelSet Field Example: A 40 channel C-Band DWDM system with 100GHz spacing with lowest frequency 192.0THz (1561.4nm)Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>. [RFC4203] Kompella, K., Ed., andhighest frequency 195.9THz (1530.3nm). These frequencies correspond to n = -11,Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>. [RFC5307] Kompella, K., Ed., andn = 28 respectively. Now suppose the following channels are available: Frequency (THz) n Value bit map position -------------------------------------------------- 192.0 -11 0 192.5 -6 5 193.1 0 11 193.9 8 19 194.0 9 20 195.2 21 32 195.8 27 38 Using the label format definedY. Rekhter, Ed., "IS-IS Extensions in[RFC6205], withSupport of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>. [RFC6205] Otani, T., Ed., and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, DOI 10.17487/RFC6205, March 2011, <http://www.rfc-editor.org/info/rfc6205>. 5.2. Informative References [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>. [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011, <http://www.rfc-editor.org/info/rfc6163>. [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, DOI 10.17487/RFC7446, February 2015, <http://www.rfc-editor.org/info/rfc7446>. [Switch] Bernstein, G., Lee, Y., Gavler, A., and J. Martensson, "Modeling WDM Wavelength Switching Systems for Use in GMPLS and Automated Path Computation", Journal of Optical Communications and Networking, Volume 1, Issue 1, pp. 187-195, June 2009. Appendix A. Encoding Examples This appendix contains examples of theGrid value setgeneral encoding extensions applied toindicate an ITU-T A/2 [G.694.1] DWDM grid, C.S. setsome simple ROADM network elements and links. A.1. Link Set Field Suppose that we wish toindicate 100GHz this lambda bit mapdescribe a setwould then be encoded as follows: Internet-Draft General Network Element Constraint Encoding February 2015 0 1 2 3 0 1 2of input ports that have link local identifiers numbered 34through 42. In the Link Set Field, we set Action = 1 to denote an inclusive range, Dir = 1 to denote input links, and Format = 0 to denote link local identifiers. Thus, we have: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.2. Label Set Field In this example, we use a 40-channel C-Band Dense Wavelength Division Multiplexing (DWDM) system with 100 GHz spacing with lowest frequency 192.0 THz (1561.4 nm) and highest frequency 195.9 THz (1530.3 nm). These frequencies correspond to n = -11 and n = 28, respectively. Now suppose the following channels are available: Frequency (THz) n Value bitmap position -------------------------------------------------- 192.0 -11 0 192.5 -6 5 193.1 0 11 193.9 8 19 194.0 9 20 195.2 21 32 195.8 27 38 Using the label format defined in [RFC6205], with the Grid value set to indicate an ITU-T A/2 [G.694.1] DWDM grid and C.S. set to indicate 100 GHz, this lambda bitmap set would then be encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Num Labels = 40 | Length = 16 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency = -11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To encode this same set as an inclusivelistlist, we would have: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Num Labels = 7 | Length = 32 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency = -11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency = -6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency = -0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency = 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Reserved | n for lowest frequency = 27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.3. Connectivity MatrixExample:Suppose we have a typical 2-degree40 channel40-channel ROADM. In addition to its two line sideportsports, it has 80 add and 80 drop ports. Thepicture Internet-Draft General Network Element Constraint Encoding February 2015figure below illustrates how a typical 2-degree ROADM system that works withbi-directionalbidirectional fiber pairs is a highly asymmetrical system composed of two unidirectional ROADM subsystems. (Tributary) Ports #3-#42 Input added to Output dropped from West Line Output East Line Input vvvvv ^^^^^ | |||.| | |||.| +-----| |||.|--------| |||.|------+ | +----------------------+ | | | | | Output | | Unidirectional ROADM | | Input -----------------+ | | +-------------- <=====================| |===================< -----------------+ +----------------------+ +-------------- | | Port #1 | | Port #2 (West Line Side) | |(East Line Side) -----------------+ +----------------------+ +-------------- >=====================| |===================> -----------------+ | Unidirectional ROADM | +-------------- Input | | | | Output | | _ | | | +----------------------+ | +-----| |||.|--------| |||.|------+ | |||.| | |||.| vvvvv ^^^^^ (Tributary) Ports #43-#82 Output dropped from Input added to West Line Input East Line Output Referring to the figure above, we see that the Input direction of ports#3- #42#3-#42 (add ports) can only connect to the output on port#1. While#1 while the Input side of port #2 (line side) can only connect to the output on ports #3-#42 (drop) and to the output on port #1 (pass through). Similarly, the input direction of ports #43-#82 can only connect to the output on port #2(line). While(line) while the input direction of port #1 can only connect to the output on ports #43-#82 (drop) or port #2 (pass through). We can now represent this potential connectivity matrix as follows. This representation uses only 29 32-bit words.Internet-Draft General Network Element Constraint Encoding February 20150 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conn = 1 | MatrixID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: adds to line +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: line to drops +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: line to line +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: adds to line +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #43 |Internet-Draft General Network Element Constraint Encoding February 2015+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #82 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: line to drops +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #43 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #82 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: line to line +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.4. Connectivity Matrix withBi-directionalBidirectional Symmetry If one has the ability to renumber the ports of the previous example as shown in the nextfigurefigure, then we can take advantage of thebi- directionalbidirectional symmetry and usebi-directionalbidirectional encoding of the connectivity matrix. Note that we set dir=bidirectional in thelink set fields. Internet-Draft General Network Element Constraint Encoding February 2015Link Set Fields. (Tributary) Ports #3-42 Ports #43-82 West Line Output East Line Input vvvvv ^^^^^ | |||.| | |||.| +-----| |||.|--------| |||.|------+ | +----------------------+ | | | | | Output | | Unidirectional ROADM | | Input -----------------+ | | +-------------- <=====================| |===================< -----------------+ +----------------------+ +-------------- | | Port #1 | | Port #2 (West Line Side) | |(East Line Side) -----------------+ +----------------------+ +-------------- >=====================| |===================> -----------------+ | Unidirectional ROADM | +-------------- Input | | | | Output | | _ | | | +----------------------+ | +-----| |||.|--------| |||.|------+ | |||.| | |||.| vvvvv ^^^^^ Ports #3-#42 Ports #43-82 Output dropped from Input added to West Line Input East Line OutputInternet-Draft General Network Element Constraint Encoding February 20150 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conn = 1 | MatrixID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Add/DropsNote: Add/Drop #3-42 to Line side #1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: line #2 to add/drops #43-82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=1 |0 0|0 0 0 0 0 0|Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #43 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #82 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: line to line +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.5. Priority Flags in Available/Shared Backup Labels If one wants to make a set of labels (indicated by Label Set Field #1) available only for the highest priority level (Priority Level 0) Internet-Draft General Network Element Constraint Encoding February 2015 while allowing a set of labels (indicated by Label Set Field #2) available to all priority levels, the following encoding will express such need. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Internet-Draft General Network Element Constraint Encoding February 2015 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3209] Awduche, D., et al. "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", June, 2002. [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [RFC6205] T. Otani, Ed. and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, March 2011. Internet-Draft General Network Element Constraint Encoding February 2015 6.2. Informative References [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", RFC5440. [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, April 2011. [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, "Modeling WDM Wavelength Switching Systems for UseLength = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #43 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #82 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: line to line +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier = #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.5. Priority Flags inGMPLS and Automated Path Computation", JournalAvailable/Shared Backup Labels If one wants to make a set ofOptical Communications and Networking, vol. 1, June, 2009, pp. 187-195. [RWA-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and Wavelength Assignment Information Modellabels (indicated by Label Set Field #1) available only forWavelength Switched Optical Networks", work in progress: draft-ietf- ccamp-rwa-info. Internet-Draft General Network Element Constraint Encoding February 2015 7.the highest priority level (Priority Level 0) while allowing a set of labels (indicated by Label Set Field #2) to be available to all priority levels, the following encoding will express such need. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Contributors Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy Phone: +39 010 600 3736Email:EMail: diego.caviglia@ericsson.com Anders Gavler Acreo AB Electrum 236 SE - 164 40 Kista SwedenEmail:EMail: Anders.Gavler@acreo.se Jonas Martensson Acreo AB Electrum 236 SE - 164 40Kista,Kista SwedenEmail:EMail: Jonas.Martensson@acreo.se Itaru Nishioka NEC Corp. 1753Simonumabe,Simonumabe Nakahara-ku, Kawasaki, Kanagawa 211-8666 Japan Phone: +81 44 396 3287Email:EMail: i-nishioka@cb.jp.nec.com Rao Rajan InfineraEmail:EMail: rrao@infinera.com Giovanni MartinelliCISCO Email:Cisco EMail: giomarti@cisco.com Remi TheillaudInternet-Draft General Network Element Constraint Encoding February 2015Marben EMail: remi.theillaud@marben-products.com Authors' Addresses Greg M. Bernstein(ed.)(editor) Grotto NetworkingFremont California, USAFremont, California United States Phone: (510) 573-2237Email:EMail: gregb@grotto-networking.com Young Lee(ed.)(editor) Huawei Technologies 1700 Alma Drive, Suite 100 Plano, TX 75075USAUnited States Phone: (972) 509-5599 (x2240)Email:EMail: ylee@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129P.R.ChinaChina Phone: +86-755-28973237Email:EMail: danli@huawei.com Wataru Imajuku NTT Network Innovation Labs 1-1 Hikari-no-oka, Yokosuka, Kanagawa Japan Phone: +81-(46) 859-4315Email:EMail: imajuku.wataru@lab.ntt.co.jpInternet-Draft General Network Element Constraint Encoding February 2015Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129P.R.ChinaChina Phone: +86-755-28972916Email:EMail: hanjianrui@huawei.com