idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 29, 2014) is 3405 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein 2 Internet Draft Grotto Networking 3 Intended status: Standards Track Y. Lee 4 Expires: June 2015 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 December 29, 2014 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-16.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on June 29, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 Internet-Draft General Network Element Constraint Encoding December 45 2014 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Abstract 59 Generalized Multiprotocol Label Switching can be used to control a 60 wide variety of technologies. In some of these technologies network 61 elements and links may impose additional routing constraints such as 62 asymmetric switch connectivity, non-local label assignment, and 63 label range limitations on links. 65 This document provides efficient, protocol-agnostic encodings for 66 general information elements representing connectivity and label 67 constraints as well as label availability. It is intended that 68 protocol-specific documents will reference this memo to describe how 69 information is carried for specific uses. 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC-2119 [RFC2119]. 77 Table of Contents 79 1. Introduction...................................................3 80 1.1. Node Switching Asymmetry Constraints......................4 81 1.2. Non-Local Label Assignment Constraints....................4 82 2. Encoding.......................................................5 83 2.1. Connectivity Matrix Field.................................5 84 2.2. Port Label Restriction Field..............................7 85 2.2.1. SIMPLE_LABEL.........................................8 86 2.2.2. CHANNEL_COUNT........................................8 87 2.2.3. LABEL_RANGE..........................................9 88 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT.........................9 90 Internet-Draft General Network Element Constraint Encoding December 91 2014 93 2.2.5. Link Label Exclusivity..............................10 94 2.3. Link Set Field...........................................10 95 2.4. Available Labels Field...................................12 96 2.5. Shared Backup Labels Field...............................13 97 2.6. Label Set Field..........................................14 98 2.6.1. Inclusive/Exclusive Label Lists.....................15 99 2.6.2. Inclusive/Exclusive Label Ranges....................16 100 2.6.3. Bitmap Label Set....................................17 101 3. Security Considerations.......................................17 102 4. IANA Considerations...........................................18 103 5. Acknowledgments...............................................18 104 APPENDIX A: Encoding Examples....................................19 105 A.1. Link Set Field...........................................19 106 A.2. Label Set Field..........................................19 107 A.3. Connectivity Matrix......................................20 108 A.4. Connectivity Matrix with Bi-directional Symmetry.........23 109 A.5. Priority Flags in Available/Shared Backup Labels.........25 110 6. References....................................................27 111 6.1. Normative References.....................................27 112 6.2. Informative References...................................28 113 7. Contributors..................................................29 114 Authors' Addresses...............................................30 115 Intellectual Property Statement..................................31 116 Disclaimer of Validity...........................................31 118 1. Introduction 120 Some data plane technologies that wish to make use of a GMPLS 121 control plane contain additional constraints on switching capability 122 and label assignment. In addition, some of these technologies must 123 perform non-local label assignment based on the nature of the 124 technology, e.g., wavelength continuity constraint in WSON 125 [RFC6163]. Such constraints can lead to the requirement for link by 126 link label availability in path computation and label assignment. 128 This document provides efficient encodings of information needed by 129 the routing and label assignment process in technologies such as 130 WSON and are potentially applicable to a wider range of 131 technologies. Such encodings can be used to extend GMPLS signaling 132 and routing protocols. In addition these encodings could be used by 133 other mechanisms to convey this same information to a path 134 computation element (PCE). 136 Internet-Draft General Network Element Constraint Encoding December 137 2014 139 1.1. Node Switching Asymmetry Constraints 141 For some network elements the ability of a signal or packet on a 142 particular input port to reach a particular output port may be 143 limited. In addition, in some network elements the connectivity 144 between some input ports and output ports may be fixed, e.g., a 145 simple multiplexer. To take into account such constraints during 146 path computation we model this aspect of a network element via a 147 connectivity matrix. 149 The connectivity matrix (ConnectivityMatrix) represents either the 150 potential connectivity matrix for asymmetric switches or fixed 151 connectivity for an asymmetric device such as a multiplexer. Note 152 that this matrix does not represent any particular internal blocking 153 behavior but indicates which input ports and labels (e.g., 154 wavelengths) could possibly be connected to a particular output port 155 and label pair. Representing internal state dependent blocking for a 156 node is beyond the scope of this document and due to it's highly 157 implementation dependent nature would most likely not be subject to 158 standardization in the future. The connectivity matrix is a 159 conceptual M*m by N*n matrix where M represents the number of input 160 ports each with m labels and N the number of output ports each with 161 n labels. 163 1.2. Non-Local Label Assignment Constraints 165 If the nature of the equipment involved in a network results in a 166 requirement for non-local label assignment we can have constraints 167 based on limits imposed by the ports themselves and those that are 168 implied by the current label usage. Note that constraints such as 169 these only become important when label assignment has a non-local 170 character. For example in MPLS an LSR may have a limited range of 171 labels available for use on an output port and a set of labels 172 already in use on that port and hence unavailable for use. This 173 information, however, does not need to be shared unless there is 174 some limitation on the LSR's label swapping ability. For example if 175 a TDM node lacks the ability to perform time-slot interchange or a 176 WSON lacks the ability to perform wavelength conversion then the 177 label assignment process is not local to a single node and it may be 178 advantageous to share the label assignment constraint information 179 for use in path computation. 181 Port label restrictions (PortLabelRestriction) model the label 182 restrictions that the network element (node) and link may impose on 183 a port. These restrictions tell us what labels may or may not be 185 Internet-Draft General Network Element Constraint Encoding December 186 2014 188 used on a link and are intended to be relatively static. More 189 dynamic information is contained in the information on available 190 labels. Port label restrictions are specified relative to the port 191 in general or to a specific connectivity matrix for increased 192 modeling flexibility. Reference [Switch] gives an example where both 193 switch and fixed connectivity matrices are used and both types of 194 constraints occur on the same port. 196 2. Encoding 198 This section provides encodings for the information elements defined 199 in [RWA-Info] that have applicability to WSON. The encodings are 200 designed to be suitable for use in the GMPLS routing protocols OSPF 201 [RFC4203] and IS-IS [RFC5307] and in the PCE protocol (PCEP) 202 [RFC5440]. Note that the information distributed in [RFC4203] and 203 [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and 204 this document defines elements to be used within such constructs. 205 Specific constructs of sub-TLVs and the nesting of sub-TLVs of the 206 information element defined by this document will be defined in the 207 respective protocol enhancement documents. 209 2.1. Connectivity Matrix Field 211 The Connectivity Matrix Field represents how input ports are 212 connected to output ports for network elements. The switch and fixed 213 connectivity matrices can be compactly represented in terms of a 214 minimal list of input and output port set pairs that have mutual 215 connectivity. As described in [Switch] such a minimal list 216 representation leads naturally to a graph representation for path 217 computation purposes that involves the fewest additional nodes and 218 links. 220 The Connectivity Matrix is uniquely identified only by the 221 advertising node. There may be more than one matrix associated with 222 a node as the node can partition the switch matrix into several sub- 223 matrices for various reasons such as incremental updates, etc. When 224 the matrix is partitioned into sub-matrices, it is envisioned that 225 they are mutually exclusive to one another in representing which 226 ports/labels are associated with each sub-matrix. This implies that 227 two matrices will not have the same {src port, src label, dst port, 228 dst label}. 230 Internet-Draft General Network Element Constraint Encoding December 231 2014 233 A TLV encoding of this list of link set pairs is: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Conn | MatrixID | Reserved | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Link Set A #1 | 241 : : : 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Link Set B #1 : 244 : : : 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Additional Link set pairs as needed | 247 : to specify connectivity : 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Where 252 Connectivity (Conn) (4 bit) is the device type. 254 0 -- the device is fixed 256 1 -- the device is switched(e.g., ROADM/OXC) 258 MatrixID represents the ID of the connectivity matrix and is an 8 259 bit integer. The value of 0xFF is reserved for use with port 260 wavelength constraints and should not be used to identify a 261 connectivity matrix. 263 Link Set A #1 and Link Set B #1 together represent a pair of link 264 sets. See Section 2.3. for a detail description of the link set 265 field. There are two permitted combinations for the link set field 266 parameter "dir" for Link Set A and B pairs: 268 o Link Set A dir=input, Link Set B dir=output 270 The meaning of the pair of link sets A and B in this case is that 271 any signal that inputs a link in set A can be potentially switched 272 out of an output link in set B. 274 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 276 Internet-Draft General Network Element Constraint Encoding December 277 2014 279 The meaning of the pair of link sets A and B in this case is that 280 any signal that inputs on the links in set A can potentially 281 output on a link in set B, and any input signal on the links in 282 set B can potentially output on a link in set A. 284 See Appendix A for both types of encodings as applied to a ROADM 285 example. 287 2.2. Port Label Restriction Field 289 Port Label Restriction Field tells us what labels may or may not be 290 used on a link. 292 The port label restriction can be encoded as follows: More than one 293 of these fields may be needed to fully specify a complex port 294 constraint. When more than one of these fields are present the 295 resulting restriction is the union of the restrictions expressed in 296 each field. To indicate that a restriction applies to the port in 297 general and not to a specific connectivity matrix use the reserved 298 value of 0xFF for the MatrixID. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | MatrixID |RestrictionType| Switching Cap | Encoding | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Additional Restriction Parameters per RestrictionType | 306 : : 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Where: 311 MatrixID: either is the value in the corresponding Connectivity 312 Matrix field or takes the value OxFF to indicate the restriction 313 applies to the port regardless of any Connectivity Matrix. 315 RestrictionType can take the following values and meanings: 317 0: SIMPLE_LABEL (Simple label selective restriction; See 318 Section 2.2.1 for details) 320 1: CHANNEL_COUNT (Channel count restriction; See Section 2.2.2 321 for details) 323 Internet-Draft General Network Element Constraint Encoding December 324 2014 326 2: LABEL_RANGE (Label range device with a movable center label 327 and width; See Section 2.2.3 for details) 329 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 330 and CHANNEL_COUNT restriction. The accompanying label set and 331 channel count indicate labels permitted on the port and the 332 maximum number of channels that can be simultaneously used on 333 the port; See Section 2.2.4 for details) 335 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once 336 amongst a set of specified ports; See Section 2.2.5 for 337 details) 339 Switching Capability is defined in [RFC4203] and Encoding in 340 [RFC3471]. The combination of these fields defines the type of 341 labels used in specifying the port label restrictions as well as the 342 interface type to which these restrictions apply. 344 Additional Restriction Parameters per RestrictType field is an 345 optional field that describes additional restriction parameters for 346 each RestrictionType pertaining to specific protocols. 348 2.2.1. SIMPLE_LABEL 350 In the case of the SIMPLE_LABEL, The format is given by: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | MatrixID | RstType = 0 | Switching Cap | Encoding | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Label Set Field | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 In this case the accompanying label set indicates the labels 361 permitted on the port. 363 See Section 2.6 for the definition of label set. 365 2.2.2. CHANNEL_COUNT 367 In the case of the CHANNEL_COUNT, the format is given by: 369 Internet-Draft General Network Element Constraint Encoding December 370 2014 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | MatrixID | RstType = 1 | Switching Cap | Encoding | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | MaxNumChannels | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 In this case the accompanying MaxNumChannels indicates the maximum 381 number of channels (labels) that can be simultaneously used on the 382 port/matrix. 384 2.2.3. LABEL_RANGE 386 In the case of the LABEL_RANGE, the format is given by: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | MatrixID | RstType = 2 |Switching Cap | Encoding | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | MaxLabelRange | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Label Set Field | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 This is a generalization of the waveband device. The MaxLabelRange 399 indicates the maximum width of the waveband in terms of the channels 400 spacing given in the Label Set Field. The corresponding label set is 401 used to indicate the overall tuning range. See Section 2.6.2 for the 402 explanation of label range. 404 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT 406 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 407 by: 409 Internet-Draft General Network Element Constraint Encoding December 410 2014 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | MatrixID | RstType = 3 | Switching Cap | Encoding | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | MaxNumChannels | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Label Set Field | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 In this case the accompanying label set and MaxNumChannels indicate 423 labels permitted on the port and the maximum number of labels that 424 can be simultaneously used on the port. 426 See Section 2.6 for the definition of label set. 428 2.2.5. Link Label Exclusivity 430 In the case of the Link Label Exclusivity the format is given by: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | MatrixID | RstType = 4 | Switching Cap | Encoding | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Link Set Field | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 In this case the accompanying link set indicates that a label may be 441 used at most once among the ports in the link set field. See Section 442 2.3 for the definition of link set. 444 2.3. Link Set Field 446 We will frequently need to describe properties of groups of links. 447 To do so efficiently we can make use of a link set concept similar 448 to the label set concept of [RFC3471]. This Link Set Field is used 449 in the , which is defined in Section 2.1. The 450 information carried in a Link Set is defined by: 452 Internet-Draft General Network Element Constraint Encoding December 453 2014 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Action |Dir| Format | Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Link Identifier 1 | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 : : : 463 : : : 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Link Identifier N | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Action: 8 bits 470 0 - Inclusive List 472 Indicates that one or more link identifiers are included in the Link 473 Set. Each identifies a separate link that is part of the set. 475 1 - Inclusive Range 477 Indicates that the Link Set defines a range of links. It contains 478 two link identifiers. The first identifier indicates the start of 479 the range. The second identifier indicates the end of the range. All 480 links with numeric values between the bounds are considered to be 481 part of the set. A value of zero in either position indicates that 482 there is no bound on the corresponding portion of the range. Note 483 that the Action field can be set to 0x01(Inclusive Range) only when 484 unnumbered link identifier is used. 486 Dir: Directionality of the Link Set (2 bits) 488 0 -- bidirectional 490 1 -- input 492 2 -- output 494 For example in optical networks we think in terms of unidirectional 495 as well as bidirectional links. For example, label restrictions or 496 connectivity may be different for an input port, than for its 497 "companion" output port if one exists. Note that "interfaces" such 498 as those discussed in the Interfaces MIB [RFC2863] are assumed to be 500 Internet-Draft General Network Element Constraint Encoding December 501 2014 503 bidirectional. This also applies to the links advertised in various 504 link state routing protocols. 506 Format: The format of the link identifier (6 bits) 508 0 -- Link Local Identifier 510 Indicates that the links in the Link Set are identified by link 511 local identifiers. All link local identifiers are supplied in the 512 context of the advertising node. 514 1 -- Local Interface IPv4 Address 516 2 -- Local Interface IPv6 Address 518 Indicates that the links in the Link Set are identified by Local 519 Interface IP Address. 521 Others -- Reserved for future use. 523 Note that all link identifiers in the same list must be of the same 524 type. 526 Length: 16 bits 528 This field indicates the total length in bytes of the Link Set field. 530 Link Identifier: length is dependent on the link format 532 The link identifier represents the port which is being described 533 either for connectivity or label restrictions. This can be the link 534 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 535 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link 536 local identifier format can result in more compact encodings when 537 the assignments are done in a reasonable fashion. 539 2.4. Available Labels Field 541 The Available Labels Field consists of priority flags, and a single 542 variable length label set field as follows: 544 Internet-Draft General Network Element Constraint Encoding December 545 2014 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | PRI | Reserved | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Label Set Field | 553 : : 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Where 558 PRI (Priority Flags, 8 bits): A bitmap used to indicate which 559 priorities are being advertised. The bitmap is in ascending order, 560 with the leftmost bit representing priority level 0 (i.e., the 561 highest) and the rightmost bit representing priority level 7 (i.e., 562 the lowest). A bit MUST be set (1) corresponding to each priority 563 represented in the sub-TLV, and MUST NOT be set (0) when the 564 corresponding priority is not represented. If a label is available 565 at priority M it MUST be advertised available at each priority N < 566 M. At least one priority level MUST be advertised. 568 The PRI field indicates the availability of the labels for use in 569 LSP set up and pre-emption as described in [RFC3209]. 571 When a label is advertised as available for priorities 0, 1, ... M 572 it may be used by any LSP of priority N <= M. When a label is in use 573 by an LSP of priority M it may be used by an LSP of priority N < M 574 if LSP preemption is supported. 576 When a label was initially advertised as available for priorities, 577 0, 1, ... M and once a label is used for an LSP at a priority, say N 578 (N<=M), then this label is advertised as available for 0, ... N-1. 580 Note that Label Set Field is defined in Section 2.6. See Appendix 581 A.5. for illustrative examples. 583 2.5. Shared Backup Labels Field 585 The Shared Backup Labels Field consists of priority flags, and 586 single variable length label set field as follows: 588 Internet-Draft General Network Element Constraint Encoding December 589 2014 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | PRI | Reserved | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Label Set Field | 597 : : 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Where 602 PRI (Priority Flags, 8 bits): A bitmap used to indicate which 603 priorities are being advertised. The bitmap is in ascending order, 604 with the leftmost bit representing priority level 0 (i.e., the 605 highest) and the rightmost bit representing priority level 7 (i.e., 606 the lowest). A bit MUST be set (1) corresponding to each priority 607 represented in the sub-TLV, and MUST NOT be set (0) when the 608 corresponding priority is not represented. If a label is available 609 at priority M it MUST be advertised available at each priority N < 610 M. At least one priority level MUST be advertised. 612 The same LSP set up and pre-emption rules specified in Section 2.4 613 apply here. 615 Note that Label Set Field is defined in Section 2.6. See Appendix 616 A.5. for illustrative examples. 618 2.6. Label Set Field 620 Label Set Field is used within the or the 621 , which is defined in Section 2.4. and 2.5., 622 respectively. 624 The general format for a label set is given below. This format uses 625 the Action concept from [RFC3471] with an additional Action to 626 define a "bit map" type of label set. Labels are variable in length. 627 Action specific fields are defined below. 629 Internet-Draft General Network Element Constraint Encoding December 630 2014 632 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Action| Num Labels | Length | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Base Label | 639 | . . . | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | (Action specific fields) | 642 | . . . . | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Action: 647 0 - Inclusive List 649 1 - Exclusive List 651 2 - Inclusive Range 653 3 - Exclusive Range 655 4 - Bitmap Set 657 Num Labels is generally the number of labels. It has a specific 658 meaning depending on the action value. See Sections 2.6.1 - 2.6.3 659 for details. 661 Length is the length in bytes of the entire label set field. 663 2.6.1. Inclusive/Exclusive Label Lists 665 In the case of the inclusive/exclusive lists the wavelength set 666 format is given by: 668 Internet-Draft General Network Element Constraint Encoding December 669 2014 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 |0 or 1 | Num Labels | Length | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Label #1 | 677 | . . . | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 : : 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Label #N | 682 | . . . | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 Where: 687 Label #1 is the first Label to be included/excluded and Label #N is 688 the last Label to be included/excluded. Num Labels MUST match with 689 N. 691 2.6.2. Inclusive/Exclusive Label Ranges 693 In the case of inclusive/exclusive ranges the label set format is 694 given by: 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 |2 or 3 | Num Labels | Length | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Start Label | 702 | . . . | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | End Label | 705 | . . . | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Note that that Start Label is the first Label in the range to be 709 included/excluded and End Label is the last label in the same range. 710 Num Labels MUST be two. 712 Internet-Draft General Network Element Constraint Encoding December 713 2014 715 2.6.3. Bitmap Label Set 717 In the case of Action = 4, the bitmap the label set format is given 718 by: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | 4 | Num Labels | Length | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Base Label | 726 | . . . | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Bit Map Word #1 (Lowest numerical labels) | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 : : 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Bit Map Word #N (Highest numerical labels) | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Where Num Labels in this case tells us the number of labels 736 represented by the bit map. Each bit in the bit map represents a 737 particular label with a value of 1/0 indicating whether the label is 738 in the set or not. Bit position zero represents the lowest label and 739 corresponds to the base label, while each succeeding bit position 740 represents the next label logically above the previous. 742 The size of the bit map is Num Label bits, but the bit map is padded 743 out to a full multiple of 32 bits so that the field is a multiple of 744 four bytes. Bits that do not represent labels (i.e., those in 745 positions (Num Labels) and beyond SHOULD be set to zero and MUST be 746 ignored. 748 3. Security Considerations 750 This document defines protocol-independent encodings for WSON 751 information and does not introduce any security issues. 753 However, other documents that make use of these encodings within 754 protocol extensions need to consider the issues and risks associated 756 Internet-Draft General Network Element Constraint Encoding December 757 2014 759 with, inspection, interception, modification, or spoofing of any of 760 this information. It is expected that any such documents will 761 describe the necessary security measures to provide adequate 762 protection. A general discussion on security in GMPLS networks can 763 be found in [RFC5920]. 765 4. IANA Considerations 767 This document provides general protocol independent information 768 encodings. There is no IANA allocation request for the information 769 elements defined in this document. IANA allocation requests will be 770 addressed in protocol specific documents based on the encodings 771 defined here. 773 5. Acknowledgments 775 This document was prepared using 2-Word-v2.0.template.dot. 777 Internet-Draft General Network Element Constraint Encoding December 778 2014 780 APPENDIX A: Encoding Examples 782 Here we give examples of the general encoding extensions applied to 783 some simple ROADM network elements and links. 785 A.1. Link Set Field 787 Suppose that we wish to describe a set of input ports that are have 788 link local identifiers number 3 through 42. In the link set field we 789 set the Action = 1 to denote an inclusive range; the Dir = 1 to 790 denote input links; and, the Format = 0 to denote link local 791 identifiers. In particular we have: 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Link Local Identifier = #3 | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Link Local Identifier = #42 | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 A.2. Label Set Field 803 Example: 805 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 806 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 807 (1530.3nm). These frequencies correspond to n = -11, and n = 28 808 respectively. Now suppose the following channels are available: 810 Frequency (THz) n Value bit map position 811 -------------------------------------------------- 812 192.0 -11 0 813 192.5 -6 5 814 193.1 0 11 815 193.9 8 19 816 194.0 9 20 817 195.2 21 32 818 195.8 27 38 820 Using the label format defined in [RFC6205], with the Grid value set 821 to indicate an ITU-T A/2 [G.694.1] DWDM grid, C.S. set to indicate 822 100GHz this lambda bit map set would then be encoded as follows: 824 Internet-Draft General Network Element Constraint Encoding December 825 2014 827 0 1 2 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | 4 | Num Labels = 40 | Length = 16 bytes | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 |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| 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 To encode this same set as an inclusive list we would have: 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | 0 | Num Labels = 7 | Length = 32 bytes | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 A.3. Connectivity Matrix 863 Example: 865 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 866 its two line side ports it has 80 add and 80 drop ports. The picture 868 Internet-Draft General Network Element Constraint Encoding December 869 2014 871 below illustrates how a typical 2-degree ROADM system that works 872 with bi-directional fiber pairs is a highly asymmetrical system 873 composed of two unidirectional ROADM subsystems. 875 (Tributary) Ports #3-#42 876 Input added to Output dropped from 877 West Line Output East Line Input 878 vvvvv ^^^^^ 879 | |||.| | |||.| 880 +-----| |||.|--------| |||.|------+ 881 | +----------------------+ | 882 | | | | 883 Output | | Unidirectional ROADM | | Input 884 -----------------+ | | +-------------- 885 <=====================| |===================< 886 -----------------+ +----------------------+ +-------------- 887 | | 888 Port #1 | | Port #2 889 (West Line Side) | |(East Line Side) 890 -----------------+ +----------------------+ +-------------- 891 >=====================| |===================> 892 -----------------+ | Unidirectional ROADM | +-------------- 893 Input | | | | Output 894 | | _ | | 895 | +----------------------+ | 896 +-----| |||.|--------| |||.|------+ 897 | |||.| | |||.| 898 vvvvv ^^^^^ 899 (Tributary) Ports #43-#82 900 Output dropped from Input added to 901 West Line Input East Line Output 903 Referring to the figure we see that the Input direction of ports #3- 904 #42 (add ports) can only connect to the output on port #1. While the 905 Input side of port #2 (line side) can only connect to the output on 906 ports #3-#42 (drop) and to the output on port #1 (pass through). 907 Similarly, the input direction of ports #43-#82 can only connect to 908 the output on port #2 (line). While the input direction of port #1 909 can only connect to the output on ports #43-#82 (drop) or port #2 910 (pass through). We can now represent this potential connectivity 911 matrix as follows. This representation uses only 29 32-bit words. 913 Internet-Draft General Network Element Constraint Encoding December 914 2014 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Conn = 1 | MatrixID | Reserved | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Note: adds to line 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Link Local Identifier = #3 | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Link Local Identifier = #42 | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Link Local Identifier = #1 | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 Note: line to drops 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Link Local Identifier = #2 | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Link Local Identifier = #3 | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Link Local Identifier = #42 | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 Note: line to line 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Link Local Identifier = #2 | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Link Local Identifier = #1 | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Note: adds to line 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Link Local Identifier = #43 | 961 Internet-Draft General Network Element Constraint Encoding December 962 2014 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Link Local Identifier = #82 | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Link Local Identifier = #2 | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 Note: line to drops 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Link Local Identifier = #1 | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Link Local Identifier = #43 | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Link Local Identifier = #82 | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 Note: line to line 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Link Local Identifier = #1 | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Link Local Identifier = #2 | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 A.4. Connectivity Matrix with Bi-directional Symmetry 996 If one has the ability to renumber the ports of the previous example 997 as shown in the next figure then we can take advantage of the bi- 998 directional symmetry and use bi-directional encoding of the 999 connectivity matrix. Note that we set dir=bidirectional in the link 1000 set fields. 1002 Internet-Draft General Network Element Constraint Encoding December 1003 2014 1005 (Tributary) 1006 Ports #3-42 Ports #43-82 1007 West Line Output East Line Input 1008 vvvvv ^^^^^ 1009 | |||.| | |||.| 1010 +-----| |||.|--------| |||.|------+ 1011 | +----------------------+ | 1012 | | | | 1013 Output | | Unidirectional ROADM | | Input 1014 -----------------+ | | +-------------- 1015 <=====================| |===================< 1016 -----------------+ +----------------------+ +-------------- 1017 | | 1018 Port #1 | | Port #2 1019 (West Line Side) | |(East Line Side) 1020 -----------------+ +----------------------+ +-------------- 1021 >=====================| |===================> 1022 -----------------+ | Unidirectional ROADM | +-------------- 1023 Input | | | | Output 1024 | | _ | | 1025 | +----------------------+ | 1026 +-----| |||.|--------| |||.|------+ 1027 | |||.| | |||.| 1028 vvvvv ^^^^^ 1029 Ports #3-#42 Ports #43-82 1030 Output dropped from Input added to 1031 West Line Input East Line Output 1033 Internet-Draft General Network Element Constraint Encoding December 1034 2014 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Conn = 1 | MatrixID | Reserved | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 Add/Drops #3-42 to Line side #1 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Link Local Identifier = #3 | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Link Local Identifier = #42 | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Link Local Identifier = #1 | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 Note: line #2 to add/drops #43-82 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Link Local Identifier = #2 | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Link Local Identifier = #43 | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Link Local Identifier = #82 | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Note: line to line 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Link Local Identifier = #1 | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Link Local Identifier = #2 | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 A.5. Priority Flags in Available/Shared Backup Labels 1078 If one wants to make a set of labels (indicated by Label Set Field 1079 #1) available only for the highest priority level (Priority Level 0) 1081 Internet-Draft General Network Element Constraint Encoding December 1082 2014 1084 while allowing a set of labels (indicated by Label Set Field #2) 1085 available to all priority levels, the following encoding will 1086 express such need. 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 |1 0 0 0 0 0 0 0| Reserved | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Label Set Field #1 | 1094 : : 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 |1 1 1 1 1 1 1 1| Reserved | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Label Set Field #2 | 1099 : : 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Internet-Draft General Network Element Constraint Encoding December 1103 2014 1105 6. References 1107 6.1. Normative References 1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, March 1997. 1112 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1113 MIB", RFC 2863, June 2000. 1115 [RFC3209] Awduche, D., et al. "RSVP-TE: Extensions to RSVP for LSP 1116 Tunnels", RFC 3209, December 2001. 1118 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1119 (GMPLS) Signaling Functional Description", RFC 3471, 1120 January 2003. 1122 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 1123 applications: DWDM frequency grid", June, 2002. 1125 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 1126 Extensions in Support of Generalized Multi-Protocol Label 1127 Switching (GMPLS)", RFC 4202, October 2005 1129 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 1130 in Support of Generalized Multi-Protocol Label Switching 1131 (GMPLS)", RFC 4203, October 2005. 1133 [RFC6205] T. Otani, Ed. and D. Li, Ed., "Generalized Labels for 1134 Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 1135 6205, March 2011. 1137 Internet-Draft General Network Element Constraint Encoding December 1138 2014 1140 6.2. Informative References 1142 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 1143 in Support of Generalized Multi-Protocol Label Switching 1144 (GMPLS)", RFC 5307, October 2008. 1146 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path 1147 Computation Element (PCE) communication Protocol (PCEP) - 1148 Version 1", RFC5440. 1150 [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS 1151 Networks", RFC 5920, July 2010. 1153 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and 1154 Path Computation Element (PCE) Control of Wavelength 1155 Switched Optical Networks (WSONs)", RFC 6163, April 2011. 1157 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 1158 WDM Wavelength Switching Systems for Use in GMPLS and 1159 Automated Path Computation", Journal of Optical 1160 Communications and Networking, vol. 1, June, 2009, pp. 1161 187-195. 1163 [RWA-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 1164 Wavelength Assignment Information Model for Wavelength 1165 Switched Optical Networks", work in progress: draft-ietf- 1166 ccamp-rwa-info. 1168 Internet-Draft General Network Element Constraint Encoding December 1169 2014 1171 7. Contributors 1173 Diego Caviglia 1174 Ericsson 1175 Via A. Negrone 1/A 16153 1176 Genoa Italy 1178 Phone: +39 010 600 3736 1179 Email: diego.caviglia@ericsson.com 1181 Anders Gavler 1182 Acreo AB 1183 Electrum 236 1184 SE - 164 40 Kista Sweden 1186 Email: Anders.Gavler@acreo.se 1188 Jonas Martensson 1189 Acreo AB 1190 Electrum 236 1191 SE - 164 40 Kista, Sweden 1193 Email: Jonas.Martensson@acreo.se 1195 Itaru Nishioka 1196 NEC Corp. 1197 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1198 Japan 1200 Phone: +81 44 396 3287 1201 Email: i-nishioka@cb.jp.nec.com 1203 Rao Rajan 1204 Infinera 1206 Email: rrao@infinera.com 1208 Giovanni Martinelli 1209 CISCO 1211 Email: giomarti@cisco.com 1213 Remi Theillaud 1215 Internet-Draft General Network Element Constraint Encoding December 1216 2014 1218 Marben 1219 remi.theillaud@marben-products.com 1221 Authors' Addresses 1223 Greg M. Bernstein (ed.) 1224 Grotto Networking 1225 Fremont California, USA 1227 Phone: (510) 573-2237 1228 Email: gregb@grotto-networking.com 1230 Young Lee (ed.) 1231 Huawei Technologies 1232 1700 Alma Drive, Suite 100 1233 Plano, TX 75075 1234 USA 1236 Phone: (972) 509-5599 (x2240) 1237 Email: ylee@huawei.com 1239 Dan Li 1240 Huawei Technologies Co., Ltd. 1241 F3-5-B R&D Center, Huawei Base, 1242 Bantian, Longgang District 1243 Shenzhen 518129 P.R.China 1245 Phone: +86-755-28973237 1246 Email: danli@huawei.com 1248 Wataru Imajuku 1249 NTT Network Innovation Labs 1250 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1251 Japan 1253 Phone: +81-(46) 859-4315 1254 Email: imajuku.wataru@lab.ntt.co.jp 1256 Internet-Draft General Network Element Constraint Encoding December 1257 2014 1259 Jianrui Han 1260 Huawei Technologies Co., Ltd. 1261 F3-5-B R&D Center, Huawei Base, 1262 Bantian, Longgang District 1263 Shenzhen 518129 P.R.China 1265 Phone: +86-755-28972916 1266 Email: hanjianrui@huawei.com 1268 Intellectual Property Statement 1270 The IETF Trust takes no position regarding the validity or scope of 1271 any Intellectual Property Rights or other rights that might be 1272 claimed to pertain to the implementation or use of the technology 1273 described in any IETF Document or the extent to which any license 1274 under such rights might or might not be available; nor does it 1275 represent that it has made any independent effort to identify any 1276 such rights. 1278 Copies of Intellectual Property disclosures made to the IETF 1279 Secretariat and any assurances of licenses to be made available, or 1280 the result of an attempt made to obtain a general license or 1281 permission for the use of such proprietary rights by implementers or 1282 users of this specification can be obtained from the IETF on-line 1283 IPR repository at http://www.ietf.org/ipr 1285 The IETF invites any interested party to bring to its attention any 1286 copyrights, patents or patent applications, or other proprietary 1287 rights that may cover technology that may be required to implement 1288 any standard or specification contained in an IETF Document. Please 1289 address the information to the IETF at ietf-ipr@ietf.org. 1291 Disclaimer of Validity 1293 All IETF Documents and the information contained therein are 1294 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 1295 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1296 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1297 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1298 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1299 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1300 FOR A PARTICULAR PURPOSE. 1302 Internet-Draft General Network Element Constraint Encoding December 1303 2014 1305 Acknowledgment 1307 Funding for the RFC Editor function is currently provided by the 1308 Internet Society.