Network Working Group G. Bernstein Internet Draft Grotto Networking Intended status: Standards Track Y. Lee Expires: August 2014 D. Li Huawei W. Imajuku NTT August 7, 2014 General Network Element Constraint Encoding for GMPLS Controlled Networks draft-ietf-ccamp-general-constraint-encode-15.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents 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 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 7, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Bernstein and Lee Expires February 7, 2015 [Page 1] Internet-Draft General Network Element Constraint Encoding February 2014 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. Abstract Generalized Multiprotocol Label Switching 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. 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...................................................3 1.1. Node Switching Asymmetry Constraints......................3 1.2. Non-Local Label Assignment Constraints....................4 2. Encoding.......................................................5 2.1. Connectivity Matrix Field.................................5 2.2. Port Label Restriction Field..............................7 2.2.1. SIMPLE_LAB...........................................8 2.2.2. CHANNEL_COUNT........................................8 2.2.3. LABEL_RANGE1.........................................9 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT.........................9 Bernstein and Lee Expires February 7, 2015 [Page 2] Internet-Draft General Network Element Constraint Encoding February 2014 2.2.5. Link Label Exclusivity..............................10 2.3. Link Set Field...........................................10 2.4. Available Labels Field...................................12 2.5. Shared Backup Labels Field...............................13 2.6. Label Set Field..........................................13 2.6.1. Inclusive/Exclusive Label Lists.....................14 2.6.2. Inclusive/Exclusive Label Ranges....................15 2.6.3. Bitmap Label Set....................................16 3. Security Considerations.......................................16 4. IANA Considerations...........................................17 5. Acknowledgments...............................................17 APPENDIX A: Encoding Examples....................................18 A.1. Link Set Field...........................................18 A.2. Label Set Field..........................................18 A.3. Connectivity Matrix......................................19 A.4. Connectivity Matrix with Bi-directional Symmetry.........22 A.5. Priority Flags in Available/Shared Backup Labels.........24 6. References....................................................26 6.1. Normative References.....................................26 6.2. Informative References...................................26 7. Contributors..................................................28 Authors' Addresses...............................................29 Intellectual Property Statement..................................30 Disclaimer of Validity...........................................30 1. Introduction Some data 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 WSON [WSON- Frame]. Such constraints can lead to the requirement for link 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. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). Bernstein and Lee Expires February 7, 2015 [Page 3] Internet-Draft General Network Element Constraint Encoding February 2014 1.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, in some network elements the connectivity between some input ports and output ports may be fixed, e.g., a simple multiplexer. 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. Representing internal state dependent blocking for a node is beyond the scope of this document and due to it's highly implementation dependent nature would most likely not be subject to standardization in the future. The connectivity matrix is a conceptual M by N matrix representing the potential switched or fixed connectivity, where M represents the number of input ports and N the number of output ports. 1.2. Non-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 in MPLS an LSR may have a limited range of labels available for use on an output port and a set of labels already in use on that port and hence 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 a TDM node lacks the ability to perform time-slot interchange or a WSON lacks the ability to perform wavelength conversion then the label assignment process is not local to a single node and it may be advantageous to share the label assignment constraint information for use in path computation. Bernstein and Lee Expires February 7, 2015 [Page 4] Internet-Draft General Network Element Constraint Encoding February 2014 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 be used 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. 2. Encoding This section provides encodings for the information elements defined in [RWA-Info] 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 PCE protocol (PCEP) [RFC5440]. Note that the information distributed in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and 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 computation purposes that involves the fewest additional nodes and links. A TLV encoding of this list of link set pairs is: Bernstein and Lee Expires February 7, 2015 [Page 5] Internet-Draft General Network Element Constraint Encoding February 2014 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connectivity | MatrixID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Set A #1 | : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Set B #1 : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Link set pairs as needed | : to specify connectivity : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Connectivity is the device type. 0 -- the device is fixed 1 -- the device is switched(e.g., ROADM/OXC) MatrixID represents the ID of the connectivity matrix and is an 8 bit integer. The value of 0xFF is reserved for use with port wavelength 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 Section 2.3. for a detail description of the link set field. There are two permitted combinations for the link set field parameter "dir" for Link Set A and B pairs: o Link Set A dir=input, Link Set B dir=output The meaning of the pair of link sets A and B in this case is that any signal that inputs a link in set A can be potentially switched out of an output link in set B. o Link Set A dir=bidirectional, Link Set B dir=bidirectional Bernstein and Lee Expires February 7, 2015 [Page 6] Internet-Draft General Network Element Constraint Encoding February 2014 The meaning of the pair of link sets A and B in this case is that any signal that inputs on the links in set A can potentially output on a link in set B, and any input signal on the links in set B can potentially output on a link in set A. See Appendix A for both types of encodings as applied to a ROADM example. 2.2. Port Label Restriction Field Port Label Restriction Field tells us what labels may or may not be used on a link. The port label restriction can be encoded as follows: More than one of these fields may be needed to fully specify a complex port constraint. When more than one of these fields are present the resulting restriction is the intersection of the restrictions expressed in each field. To indicate that a restriction applies to the port in general and not to a specific connectivity matrix use the reserved value of 0xFF for the MatrixID. 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 |RestrictionType| Switching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Restriction Parameters per RestrictionType | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: MatrixID: either is the value in the corresponding Connectivity Matrix field or takes the value OxFF to indicate the restriction applies to the port regardless of any Connectivity Matrix. RestrictionType can take the following values and meanings: 0: SIMPLE_LABEL (Simple label selective restriction) 1: CHANNEL_COUNT (Channel count restriction) Bernstein and Lee Expires February 7, 2015 [Page 7] Internet-Draft General Network Element Constraint Encoding February 2014 2: LABEL_RANGE (Label range device with a movable center label and width) 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 the port) 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once amongst a set of specified ports) Switching Capability is defined in [RFC4203] and Encoding 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. 2.2.1. SIMPLE_LABEL In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or MatrixSpecificRestrictions) format is given by: 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 | Switching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this case the accompanying label set indicates the labels permitted on the port. 2.2.2. CHANNEL_COUNT In the case of the CHANNEL_COUNT the format is given by: Bernstein and Lee Expires February 7, 2015 [Page 8] Internet-Draft General Network Element Constraint Encoding February 2014 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 | Switching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxNumChannels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this case the accompanying MaxNumChannels indicates the maximum number of channels (labels) that can be simultaneously used on the port/matrix. 2.2.3. LABEL_RANGE In the case of the LABEL_RANGE the GeneralPortRestrictions (or MatrixSpecificRestrictions) format is given by: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this case the accompanying MaxLabelRange indicates the maximum range of the labels. The corresponding label set is used to indicate the overall label range. Specific center label information can be obtained from dynamic label in use information. It is assumed that both center label and range tuning can be done without causing faults to existing signals. 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given by: Bernstein and Lee Expires February 7, 2015 [Page 9] Internet-Draft General Network Element Constraint Encoding February 2014 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 | Switching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxNumChannels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this case 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. 2.2.5. Link Label Exclusivity In the case of the Link Label Exclusivity the format is given by: 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 | Switching Cap | Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Set Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this case the accompanying port set indicate that a label may be used at most once among the ports in the link set field. 2.3. Link Set Field We will frequently need to describe properties of groups of links. To do so efficiently we can make use of a link set concept similar to the label set concept of [RFC3471]. This Link Set Field is used in the , which is defined in Section 2.1. The information carried in a Link Set is defined by: Bernstein and Lee Expires February 7, 2015 [Page 10] Internet-Draft General Network Element Constraint Encoding February 2014 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 the Link Set. Each identifies a separate link that is part of the set. 1 - Inclusive Range Indicates that the Link Set defines a range of links. It contains two link identifiers. The first identifier indicates the start of the range (inclusive). The second identifier indicates the end of the range (inclusive). 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 unnumbered link identifier is used. Dir: Directionality of the Link Set (2 bits) 0 -- bidirectional 1 -- input 2 -- output For example in optical networks we think in terms of unidirectional as well as bidirectional links. For example, label restrictions or connectivity may be different for an input port, than for its "companion" output port if one exists. Note that "interfaces" such Bernstein and Lee Expires February 7, 2015 [Page 11] Internet-Draft General Network Element Constraint Encoding February 2014 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 the Link 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 2 -- Local Interface IPv6 Address Indicates that the links in the Link Set are identified by Local Interface IP Address. All Local Interface IP Address are supplied in the context of the advertising node. Others -- Reserved for future 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 Set field. Link Identifier: length is dependent on the link format The link identifier represents the port which is being described either for connectivity or label restrictions. This can be the link local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF routing, and [RFC5307] IS-IS GMPLS routing. The use of the link local identifier format can result in more compact encodings when the assignments are done in a reasonable fashion. 2.4. Available Labels Field The Available Labels Field consists of priority flags, and a single variable length label set field as follows: Bernstein and Lee Expires February 7, 2015 [Page 12] Internet-Draft General Network Element Constraint Encoding February 2014 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 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where 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 the sub-TLV, and MUST NOT be set (0) when the corresponding priority is not represented. At least one priority level MUST be advertised that, unless overridden by local policy, SHALL be at priority level 0. Note that Label Set Field is defined in Section 2.6. See Appendix A.5. for illustrative examples. 2.5. Shared Backup Labels Field The Shared Backup Labels Field consists of priority flags, and single variable 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 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where 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 Bernstein and Lee Expires February 7, 2015 [Page 13] Internet-Draft General Network Element Constraint Encoding February 2014 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 the sub-TLV, and MUST NOT be set (0) when the corresponding priority is not represented. At least one priority level MUST be advertised that, unless overridden by local policy, SHALL be at priority level 0. Note that Label Set Field is defined in Section 2.6. See Appendix A.5. for illustrative examples. 2.6. Label Set Field Label Set Field is used within the or the , which is defined in Section 2.4. and 2.5., 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" type of label set. Labels are variable in length. Action specific fields are defined below. 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Base Label | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Action specific fields) | | . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action: Bernstein and Lee Expires February 7, 2015 [Page 14] Internet-Draft General Network Element Constraint Encoding February 2014 0 - Inclusive List 1 - Exclusive List 2 - Inclusive Range 3 - Exclusive Range 4 - Bitmap Set Length is the length in bytes of the entire field. 2.6.1. Inclusive/Exclusive Label Lists In the case of the inclusive/exclusive lists the wavelength set format is given by: 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label #1 | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label #N | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Label #1 is the first Label to be included/excluded and Label #N is the last Label to be included/excluded. Num Labels MUST match with N. 2.6.2. Inclusive/Exclusive Label Ranges In the case of inclusive/exclusive ranges the label set format is given by: Bernstein and Lee Expires February 7, 2015 [Page 15] Internet-Draft General Network Element Constraint Encoding February 2014 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 that Start Label is the first Label in the range to be included/excluded and End Label is the last label in the same range. Num Labels MUST be two. 2.6.3. Bitmap Label Set In the case of Action = 4, the bitmap the label set format is given by: 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 Map Word #1 (Lowest numerical labels) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bit Map Word #N (Highest numerical labels) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Num Labels in this case tells us the number of labels represented by the bit map. Each bit in the bit map represents a particular label with a value of 1/0 indicating whether the label is in the set or not. 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. Bernstein and Lee Expires February 7, 2015 [Page 16] Internet-Draft General Network Element Constraint Encoding February 2014 The size of the bit map is Num Label bits, but the bit map 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 associated with, 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 general protocol independent information encodings. There is no IANA allocation request for the information elements defined in this document. IANA allocation requests will be addressed in protocol specific documents based on the encodings defined here. 5. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Bernstein and Lee Expires February 7, 2015 [Page 17] Internet-Draft General Network Element Constraint Encoding February 2014 APPENDIX A: Encoding Examples Here we give examples of the general encoding extensions applied to some simple ROADM network elements and links. A.1. Link Set Field Suppose that we wish to describe a set of input 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. Label Set Field Example: A 40 channel C-Band DWDM system with 100GHz spacing with lowest frequency 192.0THz (1561.4nm) and highest frequency 195.9THz (1530.3nm). These frequencies correspond to n = -11, and n = 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 defined in [RFC6205], with the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. set to indicate 100GHz this lambda bit map set would then be encoded as follows: Bernstein and Lee Expires February 7, 2015 [Page 18] Internet-Draft General Network Element Constraint Encoding February 2014 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 inclusive list 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 = 20 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 Matrix Example: Suppose we have a typical 2-degree 40 channel ROADM. In addition to its two line side ports it has 80 add and 80 drop ports. The picture Bernstein and Lee Expires February 7, 2015 [Page 19] Internet-Draft General Network Element Constraint Encoding February 2014 below illustrates how a typical 2-degree ROADM system that works with bi-directional 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 we see that the Input direction of ports #3- #42 (add ports) can only connect to the output on port #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 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 30 32-bit words. Bernstein and Lee Expires February 7, 2015 [Page 20] Internet-Draft General Network Element Constraint Encoding February 2014 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 = 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 | Bernstein and Lee Expires February 7, 2015 [Page 21] Internet-Draft General Network Element Constraint Encoding February 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 with Bi-directional Symmetry If one has the ability to renumber the ports of the previous example as shown in the next figure then we can take advantage of the bi- directional symmetry and use bi-directional encoding of the connectivity matrix. Note that we set dir=bidirectional in the link set fields. Bernstein and Lee Expires February 7, 2015 [Page 22] Internet-Draft General Network Element Constraint Encoding February 2014 (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 Output Bernstein and Lee Expires February 7, 2015 [Page 23] Internet-Draft General Network Element Constraint Encoding February 2014 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 = 1 | MatrixID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Add/Drops #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) Bernstein and Lee Expires February 7, 2015 [Page 24] Internet-Draft General Network Element Constraint Encoding February 2014 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 0 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 0 0 0 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bernstein and Lee Expires February 7, 2015 [Page 25] Internet-Draft General Network Element Constraint Encoding February 2014 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. [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. [RFC6205] T. Otani, Ed. and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, March 2011. 6.2. Informative References [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM applications: DWDM frequency grid, June 2002. [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM applications: CWDM wavelength grid, December 2003. Bernstein and Lee Expires February 7, 2015 [Page 26] Internet-Draft General Network Element Constraint Encoding February 2014 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [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. [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling WDM Wavelength Switching Systems for Use in GMPLS and Automated Path Computation", Journal of Optical 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 Model for Wavelength Switched Optical Networks", work in progress: draft-ietf- ccamp-rwa-info. Bernstein and Lee Expires February 7, 2015 [Page 27] Internet-Draft General Network Element Constraint Encoding February 2014 7. Contributors Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy Phone: +39 010 600 3736 Email: diego.caviglia@ericsson.com Anders Gavler Acreo AB Electrum 236 SE - 164 40 Kista Sweden Email: Anders.Gavler@acreo.se Jonas Martensson Acreo AB Electrum 236 SE - 164 40 Kista, Sweden Email: Jonas.Martensson@acreo.se Itaru Nishioka NEC Corp. 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 Japan Phone: +81 44 396 3287 Email: i-nishioka@cb.jp.nec.com Rao Rajan Infinera Email: rrao@infinera.com Giovanni Martinelli CISCO Email: giomarti@cisco.com Remi Theillaud Bernstein and Lee Expires February 7, 2015 [Page 28] Internet-Draft General Network Element Constraint Encoding February 2014 Marben remi.theillaud@marben-products.com Authors' Addresses Greg M. Bernstein (ed.) Grotto Networking Fremont California, USA Phone: (510) 573-2237 Email: gregb@grotto-networking.com Young Lee (ed.) Huawei Technologies 1700 Alma Drive, Suite 100 Plano, TX 75075 USA Phone: (972) 509-5599 (x2240) Email: ylee@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28973237 Email: danli@huawei.com Wataru Imajuku NTT Network Innovation Labs 1-1 Hikari-no-oka, Yokosuka, Kanagawa Japan Phone: +81-(46) 859-4315 Email: imajuku.wataru@lab.ntt.co.jp Bernstein and Lee Expires February 7, 2015 [Page 29] Internet-Draft General Network Element Constraint Encoding February 2014 Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972916 Email: hanjianrui@huawei.com Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bernstein and Lee Expires February 7, 2015 [Page 30] Internet-Draft General Network Element Constraint Encoding February 2014 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bernstein and Lee Expires February 7, 2015 [Page 31]