idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-18.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 (February 2, 2015) is 3363 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 February 2, 2015 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-18.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 2, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 Internet-Draft General Network Element Constraint Encoding February 45 2015 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......................3 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........................................9 87 2.2.3. LABEL_RANGE..........................................9 88 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT........................10 90 Internet-Draft General Network Element Constraint Encoding February 91 2015 93 2.2.5. Link Label Exclusivity..............................10 94 2.3. Link Set Field...........................................11 95 2.4. Available Labels Field...................................13 96 2.5. Shared Backup Labels Field...............................14 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 116 1. Introduction 118 Some data plane technologies that wish to make use of a GMPLS 119 control plane contain additional constraints on switching capability 120 and label assignment. In addition, some of these technologies must 121 perform non-local label assignment based on the nature of the 122 technology, e.g., wavelength continuity constraint in WSON 123 [RFC6163]. Such constraints can lead to the requirement for link by 124 link label availability in path computation and label assignment. 126 This document provides efficient encodings of information needed by 127 the routing and label assignment process in technologies such as 128 WSON and are potentially applicable to a wider range of 129 technologies. Such encodings can be used to extend GMPLS signaling 130 and routing protocols. In addition these encodings could be used by 131 other mechanisms to convey this same information to a path 132 computation element (PCE). 134 1.1. Node Switching Asymmetry Constraints 136 For some network elements, the ability of a signal or packet on a 137 particular input port to reach a particular output port may be 139 Internet-Draft General Network Element Constraint Encoding February 140 2015 142 limited. In addition, in some network elements the connectivity 143 between some input ports and output ports may be fixed, e.g., a 144 simple multiplexer. To take into account such constraints during 145 path computation, we model this aspect of a network element via a 146 connectivity matrix. 148 The connectivity matrix (ConnectivityMatrix) represents either the 149 potential connectivity matrix for asymmetric switches or fixed 150 connectivity for an asymmetric device such as a multiplexer. Note 151 that this matrix does not represent any particular internal blocking 152 behavior but indicates which input ports and labels (e.g., 153 wavelengths) could possibly be connected to a particular output port 154 and label pair. Representing internal state dependent blocking for a 155 node is beyond the scope of this document and, due to its highly 156 implementation-dependent nature, would most likely not be subject to 157 standardization in the future. The connectivity matrix is a 158 conceptual M*m by N*n matrix where M represents the number of input 159 ports each with m labels and N the number of output ports each with 160 n labels. 162 1.2. Non-Local Label Assignment Constraints 164 If the nature of the equipment involved in a network results in a 165 requirement for non-local label assignment, we can have constraints 166 based on limits imposed by the ports themselves and those that are 167 implied by the current label usage. Note that constraints such as 168 these only become important when label assignment has a non-local 169 character. For example, in MPLS an LSR may have a limited range of 170 labels available for use on an output port, and a set of labels 171 already in use on that port, and hence unavailable for use. This 172 information, however, does not need to be shared unless there is 173 some limitation on the LSR's label swapping ability. For example, if 174 a TDM node lacks the ability to perform time-slot interchange, or a 175 WSON lacks the ability to perform wavelength conversion, then the 176 label assignment process is not local to a single node. In this 177 case, it may be advantageous to share the label assignment 178 constraint information for use in path computation. 180 Port label restrictions (PortLabelRestriction) model the label 181 restrictions that the network element (node) and link may impose on 182 a port. These restrictions tell us what labels may or may not be 183 used on a link and are intended to be relatively static. More 184 dynamic information is contained in the information on available 185 labels. Port label restrictions are specified relative to the port 186 in general or to a specific connectivity matrix for increased 188 Internet-Draft General Network Element Constraint Encoding February 189 2015 191 modeling flexibility. Reference [Switch] gives an example where both 192 switch and fixed connectivity matrices are used and both types of 193 constraints occur on the same port. 195 2. Encoding 197 This section provides encodings for the information elements defined 198 in [RWA-Info] that have applicability to WSON. The encodings are 199 designed to be suitable for use in the GMPLS routing protocols OSPF 200 [RFC4203] and IS-IS [RFC5307] and in the PCE protocol (PCEP) 201 [RFC5440]. Note that the information distributed in [RFC4203] and 202 [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and 203 this document defines elements to be used within such constructs. 204 Specific constructs of sub-TLVs and the nesting of sub-TLVs of the 205 information element defined by this document will be defined in the 206 respective protocol enhancement documents. 208 2.1. Connectivity Matrix Field 210 The Connectivity Matrix Field represents how input ports are 211 connected to output ports for network elements. The switch and fixed 212 connectivity matrices can be compactly represented in terms of a 213 minimal list of input and output port set pairs that have mutual 214 connectivity. As described in [Switch], such a minimal list 215 representation leads naturally to a graph representation for path 216 computation purposes that involves the fewest additional nodes and 217 links. 219 The Connectivity Matrix is uniquely identified only by the 220 advertising node. There may be more than one matrix associated with 221 a node as the node can partition the switch matrix into several sub- 222 matrices for various reasons such as incremental updates, etc. When 223 the matrix is partitioned into sub-matrices, it is envisioned that 224 they are mutually exclusive to one another in representing which 225 ports/labels are associated with each sub-matrix. This implies that 226 two matrices will not have the same {src port, src label, dst port, 227 dst label}. 229 Each sub-matrix is assigned a unique Matrix ID to represent a 230 mutually exclusive set of {src port, src label, dst port, dst label} 231 from other sub-matrices. 233 A TLV encoding of this list of link set pairs is: 235 Internet-Draft General Network Element Constraint Encoding February 236 2015 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Conn | MatrixID | Reserved | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Link Set A #1 | 244 : : : 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Link Set B #1 : 247 : : : 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Additional Link set pairs as needed | 250 : to specify connectivity : 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Where 255 Connectivity (Conn) (4 bit) is the device type. 257 0 -- the device is fixed 259 1 -- the device is switched (e.g., ROADM/OXC) 261 MatrixID represents the ID of the connectivity matrix and is an 8 262 bit integer. The value of 0xFF is reserved for use with port label 263 constraints and should not be used to identify a connectivity matrix. 265 Link Set A #1 and Link Set B #1 together represent a pair of link 266 sets. See Section 2.3. for a detail description of the link set 267 field. There are two permitted combinations for the link set field 268 parameter "dir" for Link Set A and B pairs: 270 o Link Set A dir=input, Link Set B dir=output 272 In this case, the meaning of the pair of link sets A and B in this 273 case is that any signal that inputs a link in set A can be 274 potentially switched out of an output link in set B. 276 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 278 Internet-Draft General Network Element Constraint Encoding February 279 2015 281 The meaning of the pair of link sets A and B in this case is that 282 any signal that inputs on the links in set A can potentially 283 output on a link in set B, and any input signal on the links in 284 set B can potentially output on a link in set A. If link set A is 285 an input and link set B is an output for a signal, then it 286 implies that link set A is an output and link set B is an input 287 for that signal. 289 See Appendix A for both types of encodings as applied to a ROADM 290 example. 292 2.2. Port Label Restriction Field 294 Port Label Restriction Field tells us what labels may or may not be 295 used on a link. 297 The port label restriction can be encoded as follows: More than one 298 of these fields may be needed to fully specify a complex port 299 constraint. When more than one of these fields are present, the 300 resulting restriction is the union of the restrictions expressed in 301 each field. The use of the reserved value of 0xFF for the MatrixID 302 indicates that a restriction applies to the port, and not to a 303 specific connectivity matrix. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | MatrixID |RestrictionType| Switching Cap | Encoding | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Additional Restriction Parameters per RestrictionType | 311 : : 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Where: 316 MatrixID: either is the value in the corresponding Connectivity 317 Matrix field or takes the value 0xFF to indicate the restriction 318 applies to the port regardless of any Connectivity Matrix. 320 RestrictionType can take the following values and meanings: 322 0: SIMPLE_LABEL (Simple label selective restriction; See 323 Section 2.2.1 for details) 325 Internet-Draft General Network Element Constraint Encoding February 326 2015 328 1: CHANNEL_COUNT (Channel count restriction; See Section 2.2.2 329 for details) 331 2: LABEL_RANGE (Label range device with a movable center label 332 and width; See Section 2.2.3 for details) 334 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 335 and CHANNEL_COUNT restriction. The accompanying label set and 336 channel count indicate labels permitted on the port and the 337 maximum number of channels that can be simultaneously used on 338 the port; See Section 2.2.4 for details) 340 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once 341 amongst a set of specified ports; See Section 2.2.5 for 342 details) 344 Switching Capability is defined in [RFC4203] and Encoding in 345 [RFC3471]. The combination of these fields defines the type of 346 labels used in specifying the port label restrictions as well as the 347 interface type to which these restrictions apply. 349 Additional Restriction Parameters per RestrictionType field is an 350 optional field that describes additional restriction parameters for 351 each RestrictionType pertaining to specific protocols. 353 2.2.1. SIMPLE_LABEL 355 In the case of the SIMPLE_LABEL, The format is given by: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | MatrixID | RstType = 0 | Switching Cap | Encoding | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Label Set Field | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 In this case the accompanying label set indicates the labels 366 permitted on the port/matrix. 368 See Section 2.6 for the definition of label set. 370 Internet-Draft General Network Element Constraint Encoding February 371 2015 373 2.2.2. CHANNEL_COUNT 375 In the case of the CHANNEL_COUNT, the format is given by: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | MatrixID | RstType = 1 | Switching Cap | Encoding | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | MaxNumChannels | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 In this case the accompanying MaxNumChannels indicates the maximum 386 number of channels (labels) that can be simultaneously used on the 387 port/matrix. 389 MaxNumChannels is a 32-bit integer. 391 2.2.3. LABEL_RANGE 393 In the case of the LABEL_RANGE, the format is given by: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | MatrixID | RstType = 2 |Switching Cap | Encoding | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | MaxLabelRange | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Label Set Field | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 This is a generalization of the waveband device. The MaxLabelRange 406 indicates the maximum width of the waveband in terms of the channels 407 spacing given in the Label Set Field. The corresponding label set is 408 used to indicate the overall tuning range. 410 MaxLabelRange is a 32-bit integer. 412 See Section 2.6.2 for the explanation of label range. 414 Internet-Draft General Network Element Constraint Encoding February 415 2015 417 2.2.4. SIMPLE_LABEL & CHANNEL_COUNT 419 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 420 by: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | MatrixID | RstType = 3 | Switching Cap | Encoding | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | MaxNumChannels | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Label Set Field | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 In this case the accompanying label set and MaxNumChannels indicate 433 labels permitted on the port and the maximum number of labels that 434 can be simultaneously used on the port. 436 See Section 2.6 for the definition of label set. 438 2.2.5. Link Label Exclusivity 440 In the case of the Link Label Exclusivity the format is given by: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | MatrixID | RstType = 4 | Switching Cap | Encoding | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Link Set Field | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 In this case the accompanying link set indicates that a label may be 451 used at most once among the ports in the link set field. See Section 452 2.3 for the definition of link set. 454 Internet-Draft General Network Element Constraint Encoding February 455 2015 457 2.3. Link Set Field 459 We will frequently need to describe properties of groups of links. 460 To do so efficiently we can make use of a link set concept similar 461 to the label set concept of [RFC3471]. This Link Set Field is used 462 in the , which is defined in Section 2.1. The 463 information carried in a Link Set is defined by: 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Action |Dir| Format | Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Link Identifier 1 | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 : : : 473 : : : 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Link Identifier N | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Action: 8 bits 480 0 - Inclusive List 482 Indicates that one or more link identifiers are included in the Link 483 Set. Each identifies a separate link that is part of the set. 485 1 - Inclusive Range 487 Indicates that the Link Set defines a range of links. It contains 488 two link identifiers. The first identifier indicates the start of 489 the range. The second identifier indicates the end of the range. All 490 links with numeric values between the bounds are considered to be 491 part of the set. A value of zero in either position indicates that 492 there is no bound on the corresponding portion of the range. Note 493 that the Action field can be set to 0x01 (Inclusive Range) only when 494 identifier for unnumbered link is used. 496 Dir: Directionality of the Link Set (2 bits) 498 0 -- bidirectional 500 1 -- input 502 Internet-Draft General Network Element Constraint Encoding February 503 2015 505 2 -- output 507 For example, in optical networks we think in terms of unidirectional 508 as well as bidirectional links. For example, label restrictions or 509 connectivity may be different for an input port, than for its 510 "companion" output port if one exists. Note that "interfaces" such 511 as those discussed in the Interfaces MIB [RFC2863] are assumed to be 512 bidirectional. This also applies to the links advertised in various 513 link state routing protocols. 515 Format: The format of the link identifier (6 bits) 517 0 -- Link Local Identifier 519 Indicates that the links in the Link Set are identified by link 520 local identifiers. All link local identifiers are supplied in the 521 context of the advertising node. 523 1 -- Local Interface IPv4 Address 525 2 -- Local Interface IPv6 Address 527 Indicates that the links in the Link Set are identified by Local 528 Interface IP Address. 530 Others -- Reserved for future use. 532 Note that all link identifiers in the same list must be of the same 533 type. 535 Length: 16 bits 537 This field indicates the total length in bytes of the Link Set field. 539 Link Identifier: length is dependent on the link format 541 The link identifier represents the port which is being described 542 either for connectivity or label restrictions. This can be the link 543 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 544 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link 545 local identifier format can result in more compact encodings when 546 the assignments are done in a reasonable fashion. 548 Internet-Draft General Network Element Constraint Encoding February 549 2015 551 2.4. Available Labels Field 553 The Available Labels Field consists of priority flags, and a single 554 variable length label set field as follows: 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | PRI | Reserved | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Label Set Field | 562 : : 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Where 567 PRI (Priority Flags, 8 bits): A bitmap used to indicate which 568 priorities are being advertised. The bitmap is in ascending order, 569 with the leftmost bit representing priority level 0 (i.e., the 570 highest) and the rightmost bit representing priority level 7 (i.e., 571 the lowest). A bit MUST be set (1) corresponding to each priority 572 represented in the sub-TLV, and MUST NOT be set (0) when the 573 corresponding priority is not represented. If a label is available 574 at priority M it MUST be advertised available at each priority N < 575 M. At least one priority level MUST be advertised. 577 The PRI field indicates the availability of the labels for use in 578 LSP set up and pre-emption as described in [RFC3209]. 580 When a label is advertised as available for priorities 0, 1, ... M 581 it may be used by any LSP of priority N <= M. When a label is in use 582 by an LSP of priority M it may be used by an LSP of priority N < M 583 if LSP preemption is supported. 585 When a label was initially advertised as available for priorities, 586 0, 1, ... M and once a label is used for an LSP at a priority, say N 587 (N<=M), then this label is advertised as available for 0, ... N-1. 589 Note that Label Set Field is defined in Section 2.6. See Appendix 590 A.5. for illustrative examples. 592 Internet-Draft General Network Element Constraint Encoding February 593 2015 595 2.5. Shared Backup Labels Field 597 The Shared Backup Labels Field consists of priority flags, and 598 single variable length label set field as follows: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | PRI | Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Label Set Field | 606 : : 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Where 611 PRI (Priority Flags, 8 bits): A bitmap used to indicate which 612 priorities are being advertised. The bitmap is in ascending order, 613 with the leftmost bit representing priority level 0 (i.e., the 614 highest) and the rightmost bit representing priority level 7 (i.e., 615 the lowest). A bit MUST be set (1) corresponding to each priority 616 represented in the sub-TLV, and MUST NOT be set (0) when the 617 corresponding priority is not represented. If a label is available 618 at priority M it MUST be advertised available at each priority N < 619 M. At least one priority level MUST be advertised. 621 The same LSP set up and pre-emption rules specified in Section 2.4 622 apply here. 624 Note that Label Set Field is defined in Section 2.6. See Appendix 625 A.5. for illustrative examples. 627 2.6. Label Set Field 629 Label Set Field is used within the or the 630 , which is defined in Sections 2.4. and 2.5., 631 respectively. It is also used within the , 632 , or , which is defined 633 in Sections 2.1.1. - 2.1.4., respectively. 635 The general format for a label set is given below. This format uses 636 the Action concept from [RFC3471] with an additional Action to 637 define a "bit map" type of label set. Labels are variable in length. 638 Action specific fields are defined below. 640 Internet-Draft General Network Element Constraint Encoding February 641 2015 643 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Action| Num Labels = N | Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Base Label | 650 | . . . | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | (Action specific fields) | 653 | . . . . | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Action: 658 0 - Inclusive List 660 1 - Exclusive List 662 2 - Inclusive Range 664 3 - Exclusive Range 666 4 - Bitmap Set 668 Num Labels is generally the number of labels. It has a specific 669 meaning depending on the action value. See Sections 2.6.1 - 2.6.3 670 for details. Num Labels is a 12 bit integer. 672 Length is the length in bytes of the entire label set field. 674 2.6.1. Inclusive/Exclusive Label Lists 676 In the case of the inclusive/exclusive lists the wavelength set 677 format is given by: 679 Internet-Draft General Network Element Constraint Encoding February 680 2015 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 |0 or 1 | Num Labels = 2 | Length | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Label #1 | 688 | . . . | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 : : 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Label #N | 693 | . . . | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Where: 698 Label #1 is the first Label to be included/excluded and Label #N is 699 the last Label to be included/excluded. Num Labels MUST match with 700 N. 702 2.6.2. Inclusive/Exclusive Label Ranges 704 In the case of inclusive/exclusive ranges the label set format is 705 given by: 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 |2 or 3 | Num Labels | Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Start Label | 713 | . . . | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | End Label | 716 | . . . | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 Note that that Start Label is the first Label in the range to be 720 included/excluded and End Label is the last label in the same range. 721 Num Labels MUST be two. 723 Internet-Draft General Network Element Constraint Encoding February 724 2015 726 2.6.3. Bitmap Label Set 728 In the case of Action = 4, the bitmap the label set format is given 729 by: 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | 4 | Num Labels | Length | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Base Label | 737 | . . . | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Bit Map Word #1 (Lowest numerical labels) | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 : : 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Bit Map Word #N (Highest numerical labels) | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Where Num Labels in this case tells us the number of labels 747 represented by the bit map. Each bit in the bit map represents a 748 particular label with a value of 1/0 indicating whether the label is 749 in the set or not. Bit position zero represents the lowest label and 750 corresponds to the base label, while each succeeding bit position 751 represents the next label logically above the previous. 753 The size of the bit map is Num Label bits, but the bit map is padded 754 out to a full multiple of 32 bits so that the field is a multiple of 755 four bytes. Bits that do not represent labels (i.e., those in 756 positions (Num Labels) and beyond) SHOULD be set to zero and MUST be 757 ignored. 759 3. Security Considerations 761 This document defines protocol-independent encodings for WSON 762 information and does not introduce any security issues. 764 However, other documents that make use of these encodings within 765 protocol extensions need to consider the issues and risks associated 767 Internet-Draft General Network Element Constraint Encoding February 768 2015 770 with inspection, interception, modification, or spoofing of any of 771 this information. It is expected that any such documents will 772 describe the necessary security measures to provide adequate 773 protection. A general discussion on security in GMPLS networks can 774 be found in [RFC5920]. 776 4. IANA Considerations 778 This document provides general protocol independent information 779 encodings. There is no IANA allocation request for the information 780 elements defined in this document. IANA allocation requests will be 781 addressed in protocol specific documents based on the encodings 782 defined here. 784 5. Acknowledgments 786 This document was prepared using 2-Word-v2.0.template.dot. 788 Internet-Draft General Network Element Constraint Encoding February 789 2015 791 APPENDIX A: Encoding Examples 793 Here we give examples of the general encoding extensions applied to 794 some simple ROADM network elements and links. 796 A.1. Link Set Field 798 Suppose that we wish to describe a set of input ports that are have 799 link local identifiers number 3 through 42. In the link set field we 800 set the Action = 1 to denote an inclusive range; the Dir = 1 to 801 denote input links; and, the Format = 0 to denote link local 802 identifiers. In particular we have: 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Link Local Identifier = #3 | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Link Local Identifier = #42 | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 A.2. Label Set Field 814 Example: 816 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 817 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 818 (1530.3nm). These frequencies correspond to n = -11, and n = 28 819 respectively. Now suppose the following channels are available: 821 Frequency (THz) n Value bit map position 822 -------------------------------------------------- 823 192.0 -11 0 824 192.5 -6 5 825 193.1 0 11 826 193.9 8 19 827 194.0 9 20 828 195.2 21 32 829 195.8 27 38 831 Using the label format defined in [RFC6205], with the Grid value set 832 to indicate an ITU-T A/2 [G.694.1] DWDM grid, C.S. set to indicate 833 100GHz this lambda bit map set would then be encoded as follows: 835 Internet-Draft General Network Element Constraint Encoding February 836 2015 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | 4 | Num Labels = 40 | Length = 16 bytes | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 |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| 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 To encode this same set as an inclusive list we would have: 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | 0 | Num Labels = 7 | Length = 32 bytes | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 A.3. Connectivity Matrix 874 Example: 876 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 877 its two line side ports it has 80 add and 80 drop ports. The picture 879 Internet-Draft General Network Element Constraint Encoding February 880 2015 882 below illustrates how a typical 2-degree ROADM system that works 883 with bi-directional fiber pairs is a highly asymmetrical system 884 composed of two unidirectional ROADM subsystems. 886 (Tributary) Ports #3-#42 887 Input added to Output dropped from 888 West Line Output East Line Input 889 vvvvv ^^^^^ 890 | |||.| | |||.| 891 +-----| |||.|--------| |||.|------+ 892 | +----------------------+ | 893 | | | | 894 Output | | Unidirectional ROADM | | Input 895 -----------------+ | | +-------------- 896 <=====================| |===================< 897 -----------------+ +----------------------+ +-------------- 898 | | 899 Port #1 | | Port #2 900 (West Line Side) | |(East Line Side) 901 -----------------+ +----------------------+ +-------------- 902 >=====================| |===================> 903 -----------------+ | Unidirectional ROADM | +-------------- 904 Input | | | | Output 905 | | _ | | 906 | +----------------------+ | 907 +-----| |||.|--------| |||.|------+ 908 | |||.| | |||.| 909 vvvvv ^^^^^ 910 (Tributary) Ports #43-#82 911 Output dropped from Input added to 912 West Line Input East Line Output 914 Referring to the figure we see that the Input direction of ports #3- 915 #42 (add ports) can only connect to the output on port #1. While the 916 Input side of port #2 (line side) can only connect to the output on 917 ports #3-#42 (drop) and to the output on port #1 (pass through). 918 Similarly, the input direction of ports #43-#82 can only connect to 919 the output on port #2 (line). While the input direction of port #1 920 can only connect to the output on ports #43-#82 (drop) or port #2 921 (pass through). We can now represent this potential connectivity 922 matrix as follows. This representation uses only 29 32-bit words. 924 Internet-Draft General Network Element Constraint Encoding February 925 2015 927 0 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Conn = 1 | MatrixID | Reserved | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Note: adds to line 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Link Local Identifier = #3 | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Link Local Identifier = #42 | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Link Local Identifier = #1 | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Note: line to drops 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Link Local Identifier = #2 | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Link Local Identifier = #3 | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Link Local Identifier = #42 | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Note: line to line 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Link Local Identifier = #2 | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Link Local Identifier = #1 | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 Note: adds to line 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Link Local Identifier = #43 | 972 Internet-Draft General Network Element Constraint Encoding February 973 2015 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Link Local Identifier = #82 | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Link Local Identifier = #2 | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 Note: line to drops 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Link Local Identifier = #1 | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Link Local Identifier = #43 | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Link Local Identifier = #82 | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 Note: line to line 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Link Local Identifier = #1 | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Link Local Identifier = #2 | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 A.4. Connectivity Matrix with Bi-directional Symmetry 1007 If one has the ability to renumber the ports of the previous example 1008 as shown in the next figure then we can take advantage of the bi- 1009 directional symmetry and use bi-directional encoding of the 1010 connectivity matrix. Note that we set dir=bidirectional in the link 1011 set fields. 1013 Internet-Draft General Network Element Constraint Encoding February 1014 2015 1016 (Tributary) 1017 Ports #3-42 Ports #43-82 1018 West Line Output East Line Input 1019 vvvvv ^^^^^ 1020 | |||.| | |||.| 1021 +-----| |||.|--------| |||.|------+ 1022 | +----------------------+ | 1023 | | | | 1024 Output | | Unidirectional ROADM | | Input 1025 -----------------+ | | +-------------- 1026 <=====================| |===================< 1027 -----------------+ +----------------------+ +-------------- 1028 | | 1029 Port #1 | | Port #2 1030 (West Line Side) | |(East Line Side) 1031 -----------------+ +----------------------+ +-------------- 1032 >=====================| |===================> 1033 -----------------+ | Unidirectional ROADM | +-------------- 1034 Input | | | | Output 1035 | | _ | | 1036 | +----------------------+ | 1037 +-----| |||.|--------| |||.|------+ 1038 | |||.| | |||.| 1039 vvvvv ^^^^^ 1040 Ports #3-#42 Ports #43-82 1041 Output dropped from Input added to 1042 West Line Input East Line Output 1044 Internet-Draft General Network Element Constraint Encoding February 1045 2015 1047 0 1 2 3 1048 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 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Conn = 1 | MatrixID | Reserved | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 Add/Drops #3-42 to Line side #1 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Link Local Identifier = #3 | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Link Local Identifier = #42 | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Link Local Identifier = #1 | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 Note: line #2 to add/drops #43-82 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Link Local Identifier = #2 | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Link Local Identifier = #43 | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Link Local Identifier = #82 | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Note: line to line 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Link Local Identifier = #1 | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Link Local Identifier = #2 | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 A.5. Priority Flags in Available/Shared Backup Labels 1089 If one wants to make a set of labels (indicated by Label Set Field 1090 #1) available only for the highest priority level (Priority Level 0) 1092 Internet-Draft General Network Element Constraint Encoding February 1093 2015 1095 while allowing a set of labels (indicated by Label Set Field #2) 1096 available to all priority levels, the following encoding will 1097 express such need. 1099 0 1 2 3 1100 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 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 |1 0 0 0 0 0 0 0| Reserved | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Label Set Field #1 | 1105 : : 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 |1 1 1 1 1 1 1 1| Reserved | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Label Set Field #2 | 1110 : : 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Internet-Draft General Network Element Constraint Encoding February 1114 2015 1116 6. References 1118 6.1. Normative References 1120 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1121 Requirement Levels", BCP 14, RFC 2119, March 1997. 1123 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1124 MIB", RFC 2863, June 2000. 1126 [RFC3209] Awduche, D., et al. "RSVP-TE: Extensions to RSVP for LSP 1127 Tunnels", RFC 3209, December 2001. 1129 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1130 (GMPLS) Signaling Functional Description", RFC 3471, 1131 January 2003. 1133 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 1134 applications: DWDM frequency grid", June, 2002. 1136 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 1137 Extensions in Support of Generalized Multi-Protocol Label 1138 Switching (GMPLS)", RFC 4202, October 2005 1140 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 1141 in Support of Generalized Multi-Protocol Label Switching 1142 (GMPLS)", RFC 4203, October 2005. 1144 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 1145 in Support of Generalized Multi-Protocol Label Switching 1146 (GMPLS)", RFC 5307, October 2008. 1148 [RFC6205] T. Otani, Ed. and D. Li, Ed., "Generalized Labels for 1149 Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 1150 6205, March 2011. 1152 Internet-Draft General Network Element Constraint Encoding February 1153 2015 1155 6.2. Informative References 1157 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1158 Element (PCE) communication Protocol (PCEP) - Version 1", 1159 RFC5440. 1161 [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS 1162 Networks", RFC 5920, July 2010. 1164 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and 1165 Path Computation Element (PCE) Control of Wavelength 1166 Switched Optical Networks (WSONs)", RFC 6163, April 2011. 1168 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 1169 WDM Wavelength Switching Systems for Use in GMPLS and 1170 Automated Path Computation", Journal of Optical 1171 Communications and Networking, vol. 1, June, 2009, pp. 1172 187-195. 1174 [RWA-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 1175 Wavelength Assignment Information Model for Wavelength 1176 Switched Optical Networks", work in progress: draft-ietf- 1177 ccamp-rwa-info. 1179 Internet-Draft General Network Element Constraint Encoding February 1180 2015 1182 7. Contributors 1184 Diego Caviglia 1185 Ericsson 1186 Via A. Negrone 1/A 16153 1187 Genoa Italy 1189 Phone: +39 010 600 3736 1190 Email: diego.caviglia@ericsson.com 1192 Anders Gavler 1193 Acreo AB 1194 Electrum 236 1195 SE - 164 40 Kista Sweden 1197 Email: Anders.Gavler@acreo.se 1199 Jonas Martensson 1200 Acreo AB 1201 Electrum 236 1202 SE - 164 40 Kista, Sweden 1204 Email: Jonas.Martensson@acreo.se 1206 Itaru Nishioka 1207 NEC Corp. 1208 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1209 Japan 1211 Phone: +81 44 396 3287 1212 Email: i-nishioka@cb.jp.nec.com 1214 Rao Rajan 1215 Infinera 1217 Email: rrao@infinera.com 1219 Giovanni Martinelli 1220 CISCO 1222 Email: giomarti@cisco.com 1224 Remi Theillaud 1226 Internet-Draft General Network Element Constraint Encoding February 1227 2015 1229 Marben 1230 remi.theillaud@marben-products.com 1232 Authors' Addresses 1234 Greg M. Bernstein (ed.) 1235 Grotto Networking 1236 Fremont California, USA 1238 Phone: (510) 573-2237 1239 Email: gregb@grotto-networking.com 1241 Young Lee (ed.) 1242 Huawei Technologies 1243 1700 Alma Drive, Suite 100 1244 Plano, TX 75075 1245 USA 1247 Phone: (972) 509-5599 (x2240) 1248 Email: ylee@huawei.com 1250 Dan Li 1251 Huawei Technologies Co., Ltd. 1252 F3-5-B R&D Center, Huawei Base, 1253 Bantian, Longgang District 1254 Shenzhen 518129 P.R.China 1256 Phone: +86-755-28973237 1257 Email: danli@huawei.com 1259 Wataru Imajuku 1260 NTT Network Innovation Labs 1261 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1262 Japan 1264 Phone: +81-(46) 859-4315 1265 Email: imajuku.wataru@lab.ntt.co.jp 1267 Internet-Draft General Network Element Constraint Encoding February 1268 2015 1270 Jianrui Han 1271 Huawei Technologies Co., Ltd. 1272 F3-5-B R&D Center, Huawei Base, 1273 Bantian, Longgang District 1274 Shenzhen 518129 P.R.China 1276 Phone: +86-755-28972916 1277 Email: hanjianrui@huawei.com