idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-09.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 (September 27, 2012) is 4226 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) == Unused Reference: 'G.694.1' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 1103, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: March 2013 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 September 27, 2012 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-09.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 March 27, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 Internet-Draft General Network Element Constraint Encoding September 45 2012 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 1.3. Change Log................................................5 83 2. Encoding.......................................................6 84 2.1. Link Set Field............................................6 85 2.2. Label Set Field...........................................8 86 2.2.1. Inclusive/Exclusive Label Lists......................9 87 2.2.2. Inclusive/Exclusive Label Ranges.....................9 88 2.2.3. Bitmap Label Set ...................................10 90 Internet-Draft General Network Element Constraint Encoding September 91 2012 93 2.3. Available Labels Sub-TLV.................................11 94 2.4. Shared Backup Labels Sub-TLV.............................11 95 2.5. Connectivity Matrix Sub-TLV..............................12 96 2.6. Port Label Restriction sub-TLV...........................13 97 2.6.1. SIMPLE_LABEL........................................14 98 2.6.2. CHANNEL_COUNT.......................................15 99 2.6.3. LABEL_RANGE1........................................15 100 2.6.4. SIMPLE_LABEL & CHANNEL_COUNT........................16 101 2.6.5. Link Label Exclusivity..............................16 102 3. Security Considerations.......................................17 103 4. IANA Considerations...........................................17 104 5. Acknowledgments...............................................17 105 APPENDIX A: Encoding Examples....................................18 106 A.1. Link Set Field...........................................18 107 A.2. Label Set Field..........................................18 108 A.3. Connectivity Matrix Sub-TLV..............................19 109 A.4. Connectivity Matrix with Bi-directional Symmetry.........22 110 A.5. Priority Flags in Available/Shared Backup Labels sub-TLV.24 111 6. References....................................................26 112 6.1. Normative References.....................................26 113 6.2. Informative References...................................26 114 7. Contributors..................................................28 115 Authors' Addresses...............................................29 116 Intellectual Property Statement..................................30 117 Disclaimer of Validity...........................................30 119 1. Introduction 121 Some data plane technologies that wish to make use of a GMPLS 122 control plane contain additional constraints on switching capability 123 and label assignment. In addition, some of these technologies must 124 perform non-local label assignment based on the nature of the 125 technology, e.g., wavelength continuity constraint in WSON [WSON- 126 Frame]. Such constraints can lead to the requirement for link by 127 link label availability in path computation and label assignment. 129 This document provides efficient encodings of information needed by 130 the routing and label assignment process in technologies such as 131 WSON and are potentially applicable to a wider range of 132 technologies. Such encodings can be used to extend GMPLS signaling 133 and routing protocols. In addition these encodings could be used by 134 other mechanisms to convey this same information to a path 135 computation element (PCE). 137 Internet-Draft General Network Element Constraint Encoding September 138 2012 140 1.1. Node Switching Asymmetry Constraints 142 For some network elements the ability of a signal or packet on a 143 particular ingress port to reach a particular egress port may be 144 limited. In addition, in some network elements the connectivity 145 between some ingress ports and egress ports may be fixed, e.g., a 146 simple multiplexer. To take into account such constraints during 147 path computation we model this aspect of a network element via a 148 connectivity matrix. 150 The connectivity matrix (ConnectivityMatrix) represents either the 151 potential connectivity matrix for asymmetric switches or fixed 152 connectivity for an asymmetric device such as a multiplexer. Note 153 that this matrix does not represent any particular internal blocking 154 behavior but indicates which ingress ports and labels (e.g., 155 wavelengths) could possibly be connected to a particular output 156 port. Representing internal state dependent blocking for a node is 157 beyond the scope of this document and due to it's highly 158 implementation dependent nature would most likely not be subject to 159 standardization in the future. The connectivity matrix is a 160 conceptual M by N matrix representing the potential switched or 161 fixed connectivity, where M represents the number of ingress ports 162 and N the number of egress ports. 164 1.2. Non-Local Label Assignment Constraints 166 If the nature of the equipment involved in a network results in a 167 requirement for non-local label assignment we can have constraints 168 based on limits imposed by the ports themselves and those that are 169 implied by the current label usage. Note that constraints such as 170 these only become important when label assignment has a non-local 171 character. For example in MPLS an LSR may have a limited range of 172 labels available for use on an egress port and a set of labels 173 already in use on that port and hence unavailable for use. This 174 information, however, does not need to be shared unless there is 175 some limitation on the LSR's label swapping ability. For example if 176 a TDM node lacks the ability to perform time-slot interchange or a 177 WSON lacks the ability to perform wavelength conversion then the 178 label assignment process is not local to a single node and it may be 179 advantageous to share the label assignment constraint information 180 for use in path computation. 182 Internet-Draft General Network Element Constraint Encoding September 183 2012 185 Port label restrictions (PortLabelRestriction) model the label 186 restrictions that the network element (node) and link may impose on 187 a port. These restrictions tell us what labels may or may not be 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 1.3. Change Log 198 Changes from 03 version: 200 (a) Removed informational BNF from section 1. 202 (b) Removed section on "Extension Encoding Usage Recommendations" 204 Changes from 04,05 versions: 206 No changes just refreshed document that was expiring. 208 Changes from 06 version: 210 Added priority information to available wavelength encodings. 212 Changes from 07 version: 214 In port label constraint changed reserved field to Switching 215 Capability and Encoding to allow for self description of labels used 216 and interface capability. 218 Changes from 08 version: 220 Switching Capability and Encoding applied to all sub-cases for Port 221 Label Restriction sub-TLV in Section 2.6. 223 Eliminated A (Availability) Bit from Available Labels Sub-TLV and 224 Shared Backup Labels Sub-TLV. 226 Internet-Draft General Network Element Constraint Encoding September 227 2012 229 2. Encoding 231 A type-length-value (TLV) encoding of the general connectivity and 232 label restrictions and availability extensions is given in this 233 section. This encoding is designed to be suitable for use in the 234 GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in 235 the PCE protocol PCEP [PCEP]. Note that the information distributed 236 in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs 237 within TLVs and this document makes use of such constructs. First, 238 however we define two general purpose fields that will be used 239 repeatedly in the subsequent TLVs. 241 2.1. Link Set Field 243 We will frequently need to describe properties of groups of links. 244 To do so efficiently we can make use of a link set concept similar 245 to the label set concept of [RFC3471]. This Link Set Field is used 246 in the sub-TLV, which is defined in Section 247 2.5. The information carried in a Link Set is defined by: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Action |Dir| Format | Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Link Identifier 1 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 : : : 257 : : : 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Link Identifier N | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Action: 8 bits 264 0 - Inclusive List 266 Indicates that one or more link identifiers are included in the Link 267 Set. Each identifies a separate link that is part of the set. 269 1 - Inclusive Range 271 Internet-Draft General Network Element Constraint Encoding September 272 2012 274 Indicates that the Link Set defines a range of links. It contains 275 two link identifiers. The first identifier indicates the start of 276 the range (inclusive). The second identifier indicates the end of 277 the range (inclusive). All links with numeric values between the 278 bounds are considered to be part of the set. A value of zero in 279 either position indicates that there is no bound on the 280 corresponding portion of the range. Note that the Action field can 281 be set to 0x02(Inclusive Range) only when unnumbered link identifier 282 is used. 284 Dir: Directionality of the Link Set (2 bits) 286 0 -- bidirectional 288 1 -- ingress 290 2 -- egress 292 For example in optical networks we think in terms of unidirectional 293 as well as bidirectional links. For example, label restrictions or 294 connectivity may be different for an ingress port, than for its 295 "companion" egress port if one exists. Note that "interfaces" such 296 as those discussed in the Interfaces MIB [RFC2863] are assumed to be 297 bidirectional. This also applies to the links advertised in various 298 link state routing protocols. 300 Format: The format of the link identifier (6 bits) 302 0 -- Link Local Identifier 304 Indicates that the links in the Link Set are identified by link 305 local identifiers. All link local identifiers are supplied in the 306 context of the advertising node. 308 1 -- Local Interface IPv4 Address 310 2 -- Local Interface IPv6 Address 312 Indicates that the links in the Link Set are identified by Local 313 Interface IP Address. All Local Interface IP Address are supplied in 314 the context of the advertising node. 316 Others TBD. 318 Internet-Draft General Network Element Constraint Encoding September 319 2012 321 Note that all link identifiers in the same list must be of the same 322 type. 324 Length: 16 bits 326 This field indicates the total length in bytes of the Link Set field. 328 Link Identifier: length is dependent on the link format 330 The link identifier represents the port which is being described 331 either for connectivity or label restrictions. This can be the link 332 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 333 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link 334 local identifier format can result in more compact encodings when 335 the assignments are done in a reasonable fashion. 337 2.2. Label Set Field 339 Label Set Field is used within the sub-TLV or the 340 sub-TLV, which is defined in Section 2.3. and 341 2.4. ,respectively. 343 The general format for a label set is given below. This format uses 344 the Action concept from [RFC3471] with an additional Action to 345 define a "bit map" type of label set. The second 32 bit field is a 346 base label used as a starting point in many of the specific formats. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Action| Num Labels | Length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Base Label | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Additional fields as necessary per action | 356 | 358 Action: 360 0 - Inclusive List 362 1 - Exclusive List 364 Internet-Draft General Network Element Constraint Encoding September 365 2012 367 2 - Inclusive Range 369 3 - Exclusive Range 371 4 - Bitmap Set 373 Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 374 indicates the number of labels represented by the bit map. See more 375 detail in section 3.2.3. 377 Length is the length in bytes of the entire field. 379 2.2.1. Inclusive/Exclusive Label Lists 381 In the case of the inclusive/exclusive lists the wavelength set 382 format is given by: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 |0 or 1 | Num Labels (not used) | Length | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Base Label | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 : : 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Last Label | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Where: 398 Num Labels is not used in this particular format since the Length 399 parameter is sufficient to determine the number of labels in the 400 list. 402 2.2.2. Inclusive/Exclusive Label Ranges 404 In the case of inclusive/exclusive ranges the label set format is 405 given by: 407 Internet-Draft General Network Element Constraint Encoding September 408 2012 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |2 or 3 | Num Labels(not used) | Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Start Label | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | End Label | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Note that the start and end label must in some sense "compatible" in 421 the technology being used. 423 2.2.3. Bitmap Label Set 425 In the case of Action = 4, the bitmap the label set format is given 426 by: 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | 4 | Num Labels | Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Base Label | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Bit Map Word #1 (Lowest numerical labels) | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 : : 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Bit Map Word #N (Highest numerical labels) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Where Num Labels in this case tells us the number of labels 443 represented by the bit map. Each bit in the bit map represents a 444 particular label with a value of 1/0 indicating whether the label is 445 in the set or not. Bit position zero represents the lowest label and 446 corresponds to the base label, while each succeeding bit position 447 represents the next label logically above the previous. 449 The size of the bit map is Num Label bits, but the bit map is padded 450 out to a full multiple of 32 bits so that the TLV is a multiple of 451 four bytes. Bits that do not represent labels (i.e., those in 453 Internet-Draft General Network Element Constraint Encoding September 454 2012 456 positions (Num Labels) and beyond SHOULD be set to zero and MUST be 457 ignored. 459 2.3. Available Labels Sub-TLV 461 The Available Labels sub-TLV link consists of an availability flag, 462 priority flags, and a single variable length label set field as 463 follows: 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 | PRI | Reserved | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Label Set Field | 471 : : 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Where 476 PRI (Priority Flags, 8 bits): Indicates priority level applied to 477 Label Set Field. Bit 8 corresponds to priority level 0 and bit 15 478 corresponds to priority level 7. 480 Note that Label Set Field is defined in Section 2.2. See Appendix 481 A.5. for illustrative examples. 483 2.4. Shared Backup Labels Sub-TLV 485 The Shared Backup Labels sub-TLV consists of an availability flag, 486 priority flags, and single variable length label set field as 487 follows: 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | PRI | Reserved | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Label Set Field | 495 : : 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Internet-Draft General Network Element Constraint Encoding September 499 2012 501 Where 503 PRI (Priority Flags, 8 bits): Indicates priority level applied to 504 Label Set Field. Bit 8 corresponds to priority level 0 and bit 15 505 corresponds to priority level 7. 507 2.5. Connectivity Matrix Sub-TLV 509 The Connectivity Matrix represents how ingress ports are connected 510 to egress ports for network elements. The switch and fixed 511 connectivity matrices can be compactly represented in terms of a 512 minimal list of ingress and egress port set pairs that have mutual 513 connectivity. As described in [Switch] such a minimal list 514 representation leads naturally to a graph representation for path 515 computation purposes that involves the fewest additional nodes and 516 links. 518 A TLV encoding of this list of link set pairs is: 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Connectivity | MatrixID | Reserved | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Link Set A #1 | 526 : : : 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Link Set B #1 : 529 : : : 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Additional Link set pairs as needed | 532 : to specify connectivity : 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Where 537 Connectivity is the device type. 539 0 -- the device is fixed 541 Internet-Draft General Network Element Constraint Encoding September 542 2012 544 1 -- the device is switched(e.g., ROADM/OXC) 546 MatrixID represents the ID of the connectivity matrix and is an 8 547 bit integer. The value of 0xFF is reserved for use with port 548 wavelength constraints and should not be used to identify a 549 connectivity matrix. 551 Link Set A #1 and Link Set B #1 together represent a pair of link 552 sets. There are two permitted combinations for the link set field 553 parameter "dir" for Link Set A and B pairs: 555 o Link Set A dir=ingress, Link Set B dir=egress 557 The meaning of the pair of link sets A and B in this case is that 558 any signal that ingresses a link in set A can be potentially 559 switched out of an egress link in set B. 561 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 563 The meaning of the pair of link sets A and B in this case is that 564 any signal that ingresses on the links in set A can potentially 565 egress on a link in set B, and any ingress signal on the links in 566 set B can potentially egress on a link in set A. 568 See Appendix A for both types of encodings as applied to a ROADM 569 example. 571 2.6. Port Label Restriction sub-TLV 573 Port Label Restriction tells us what labels may or may not be used 574 on a link. 576 The port label restriction of section 1.2. can be encoded as a sub- 577 TLV as follows. More than one of these sub-TLVs may be needed to 578 fully specify a complex port constraint. When more than one of these 579 sub-TLVs are present the resulting restriction is the intersection 580 of the restrictions expressed in each sub-TLV. To indicate that a 581 restriction applies to the port in general and not to a specific 582 connectivity matrix use the reserved value of 0xFF for the MatrixID. 584 Internet-Draft General Network Element Constraint Encoding September 585 2012 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | MatrixID |RestrictionType| Switching Cap | Encoding | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Additional Restriction Parameters per RestrictionType | 593 : : 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Where: 598 MatrixID: either is the value in the corresponding Connectivity 599 Matrix sub-TLV or takes the value OxFF to indicate the restriction 600 applies to the port regardless of any Connectivity Matrix. 602 RestrictionType can take the following values and meanings: 604 0: SIMPLE_LABEL (Simple label selective restriction) 606 1: CHANNEL_COUNT (Channel count restriction) 608 2: LABEL_RANGE1 (Label range device with a movable center 609 label and width) 611 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 612 and CHANNEL_COUNT restriction. The accompanying label set and 613 channel count indicate labels permitted on the port and the 614 maximum number of channels that can be simultaneously used on 615 the port) 617 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once 618 amongst a set of specified ports) 620 Switching Capability is defined in [RFC4203] and Encoding in 621 [RFC3471]. The combination of these fields defines the type of 622 labels used in specifying the port label restrictions as well as the 623 interface type to which these restrictions apply. 625 2.6.1. SIMPLE_LABEL 627 In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or 628 MatrixSpecificRestrictions) format is given by: 630 Internet-Draft General Network Element Constraint Encoding September 631 2012 633 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 | MatrixID | RstType = 0 | Switching Cap | Encoding | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Label Set Field | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 In this case the accompanying label set indicates the labels 642 permitted on the port. 644 2.6.2. CHANNEL_COUNT 646 In the case of the CHANNEL_COUNT the format is given by: 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | MatrixID | RstType = 1 | Switching Cap | Encoding | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | MaxNumChannels | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 In this case the accompanying MaxNumChannels indicates the maximum 657 number of channels (labels) that can be simultaneously used on the 658 port/matrix. 660 2.6.3. LABEL_RANGE1 662 In the case of the LABEL_RANGE1 the GeneralPortRestrictions (or 663 MatrixSpecificRestrictions) format is given by: 665 Internet-Draft General Network Element Constraint Encoding September 666 2012 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | MatrixID | RstType = 2 |Switching Cap | Encoding | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | MaxLabelRange | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Label Set Field | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 In this case the accompanying MaxLabelRange indicates the maximum 679 range of the labels. The corresponding label set is used to indicate 680 the overall label range. Specific center label information can be 681 obtained from dynamic label in use information. It is assumed that 682 both center label and range tuning can be done without causing 683 faults to existing signals. 685 2.6.4. SIMPLE_LABEL & CHANNEL_COUNT 687 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 688 by: 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | MatrixID | RstType = 3 | Switching Cap | Encoding | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | MaxNumChannels | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Label Set Field | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 In this case the accompanying label set and MaxNumChannels indicate 701 labels permitted on the port and the maximum number of labels that 702 can be simultaneously used on the port. 704 2.6.5. Link Label Exclusivity 706 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 707 by: 709 Internet-Draft General Network Element Constraint Encoding September 710 2012 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | MatrixID | RstType = 4 | Switching Cap | Encoding | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Link Set Field | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 In this case the accompanying port set indicate that a label may be 721 used at most once among the ports in the link set field. 723 3. Security Considerations 725 This document defines protocol-independent encodings for WSON 726 information and does not introduce any security issues. 728 However, other documents that make use of these encodings within 729 protocol extensions need to consider the issues and risks associated 730 with, inspection, interception, modification, or spoofing of any of 731 this information. It is expected that any such documents will 732 describe the necessary security measures to provide adequate 733 protection. 735 4. IANA Considerations 737 TBD. Once our approach is finalized we may need identifiers for the 738 various TLVs and sub-TLVs. 740 5. Acknowledgments 742 This document was prepared using 2-Word-v2.0.template.dot. 744 Internet-Draft General Network Element Constraint Encoding September 745 2012 747 APPENDIX A: Encoding Examples 749 Here we give examples of the general encoding extensions applied to 750 some simple ROADM network elements and links. 752 A.1. Link Set Field 754 Suppose that we wish to describe a set of ingress ports that are 755 have link local identifiers number 3 through 42. In the link set 756 field we set the Action = 1 to denote an inclusive range; the Dir = 757 1 to denote ingress links; and, the Format = 0 to denote link local 758 identifiers. In particular we have: 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Link Local Identifier = #3 | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Link Local Identifier = #42 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 A.2. Label Set Field 770 Example: 772 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 773 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 774 (1530.3nm). These frequencies correspond to n = -11, and n = 28 775 respectively. Now suppose the following channels are available: 777 Frequency (THz) n Value bit map position 778 -------------------------------------------------- 779 192.0 -11 0 780 192.5 -6 5 781 193.1 0 11 782 193.9 8 19 783 194.0 9 20 784 195.2 21 32 785 195.8 27 38 787 With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. 788 set to indicate 100GHz this lambda bit map set would then be encoded 789 as follows: 791 Internet-Draft General Network Element Constraint Encoding September 792 2012 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | 4 | Num Wavelengths = 40 | Length = 16 bytes | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 |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| 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 To encode this same set as an inclusive list we would have: 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | 0 | Num Wavelengths = 40 | Length = 20 bytes | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 A.3. Connectivity Matrix Sub-TLV 830 Example: 832 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 833 its two line side ports it has 80 add and 80 drop ports. The picture 835 Internet-Draft General Network Element Constraint Encoding September 836 2012 838 below illustrates how a typical 2-degree ROADM system that works 839 with bi-directional fiber pairs is a highly asymmetrical system 840 composed of two unidirectional ROADM subsystems. 842 (Tributary) Ports #3-#42 843 Ingress added to Egress dropped from 844 West Line Egress East Line Ingress 845 vvvvv ^^^^^ 846 | |||.| | |||.| 847 +-----| |||.|--------| |||.|------+ 848 | +----------------------+ | 849 | | | | 850 Egress | | Unidirectional ROADM | | Ingress 851 -----------------+ | | +-------------- 852 <=====================| |===================< 853 -----------------+ +----------------------+ +-------------- 854 | | 855 Port #1 | | Port #2 856 (West Line Side) | |(East Line Side) 857 -----------------+ +----------------------+ +-------------- 858 >=====================| |===================> 859 -----------------+ | Unidirectional ROADM | +-------------- 860 Ingress | | | | Egress 861 | | _ | | 862 | +----------------------+ | 863 +-----| |||.|--------| |||.|------+ 864 | |||.| | |||.| 865 vvvvv ^^^^^ 866 (Tributary) Ports #43-#82 867 Egress dropped from Ingress added to 868 West Line ingress East Line egress 870 Referring to the figure we see that the ingress direction of ports 871 #3-#42 (add ports) can only connect to the egress on port #1. While 872 the ingress side of port #2 (line side) can only connect to the 873 egress on ports #3-#42 (drop) and to the egress on port #1 (pass 874 through). Similarly, the ingress direction of ports #43-#82 can only 875 connect to the egress on port #2 (line). While the ingress direction 876 of port #1 can only connect to the egress on ports #43-#82 (drop) or 877 port #2 (pass through). We can now represent this potential 878 connectivity matrix as follows. This representation uses only 30 32- 879 bit words. 881 Internet-Draft General Network Element Constraint Encoding September 882 2012 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Conn = 1 | MatrixID | Reserved | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 Note: adds to line 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Link Local Identifier = #3 | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Link Local Identifier = #42 | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Link Local Identifier = #1 | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 Note: line to drops 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Link Local Identifier = #2 | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Link Local Identifier = #3 | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Link Local Identifier = #42 | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 Note: line to line 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Link Local Identifier = #2 | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Link Local Identifier = #1 | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Note: adds to line 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Link Local Identifier = #43 | 929 Internet-Draft General Network Element Constraint Encoding September 930 2012 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Link Local Identifier = #82 | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Link Local Identifier = #2 | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 Note: line to drops 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Link Local Identifier = #1 | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Link Local Identifier = #43 | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Link Local Identifier = #82 | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Note: line to line 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Link Local Identifier = #1 | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Link Local Identifier = #2 | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 A.4. Connectivity Matrix with Bi-directional Symmetry 964 If one has the ability to renumber the ports of the previous example 965 as shown in the next figure then we can take advantage of the bi- 966 directional symmetry and use bi-directional encoding of the 967 connectivity matrix. Note that we set dir=bidirectional in the link 968 set fields. 970 Internet-Draft General Network Element Constraint Encoding September 971 2012 973 (Tributary) 974 Ports #3-42 Ports #43-82 975 West Line Egress East Line Ingress 976 vvvvv ^^^^^ 977 | |||.| | |||.| 978 +-----| |||.|--------| |||.|------+ 979 | +----------------------+ | 980 | | | | 981 Egress | | Unidirectional ROADM | | Ingress 982 -----------------+ | | +-------------- 983 <=====================| |===================< 984 -----------------+ +----------------------+ +-------------- 985 | | 986 Port #1 | | Port #2 987 (West Line Side) | |(East Line Side) 988 -----------------+ +----------------------+ +-------------- 989 >=====================| |===================> 990 -----------------+ | Unidirectional ROADM | +-------------- 991 Ingress | | | | Egress 992 | | _ | | 993 | +----------------------+ | 994 +-----| |||.|--------| |||.|------+ 995 | |||.| | |||.| 996 vvvvv ^^^^^ 997 Ports #3-#42 Ports #43-82 998 Egress dropped from Ingress added to 999 West Line ingress East Line egress 1001 Internet-Draft General Network Element Constraint Encoding September 1002 2012 1004 0 1 2 3 1005 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 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Conn = 1 | MatrixID | Reserved | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Add/Drops #3-42 to Line side #1 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Link Local Identifier = #3 | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Link Local Identifier = #42 | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Link Local Identifier = #1 | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 Note: line #2 to add/drops #43-82 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Link Local Identifier = #2 | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Link Local Identifier = #43 | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Link Local Identifier = #82 | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 Note: line to line 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Link Local Identifier = #1 | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Link Local Identifier = #2 | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 A.5. Priority Flags in Available/Shared Backup Labels sub-TLV 1046 If one wants to make a set of labels (indicated by Label Set Field 1047 #1) available for all priority levels (level 0 to 7) while allowing 1049 Internet-Draft General Network Element Constraint Encoding September 1050 2012 1052 a set of labels (indicated by Label Set Field #2) only to available 1053 to the highest priority (Priority Level 7), the following encoding 1054 will express such need. 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 |0 0 0| Reserved | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Label Set Field #1 | 1062 : : 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 |1 1 1| Reserved | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Label Set Field #2 | 1067 : : 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 Internet-Draft General Network Element Constraint Encoding September 1071 2012 1073 6. References 1075 6.1. Normative References 1077 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1078 Requirement Levels", BCP 14, RFC 2119, March 1997. 1080 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1081 MIB", RFC 2863, June 2000. 1083 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1084 (GMPLS) Signaling Functional Description", RFC 3471, 1085 January 2003. 1087 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 1088 applications: DWDM frequency grid", June, 2002. 1090 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 1091 Extensions in Support of Generalized Multi-Protocol Label 1092 Switching (GMPLS)", RFC 4202, October 2005 1094 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 1095 in Support of Generalized Multi-Protocol Label Switching 1096 (GMPLS)", RFC 4203, October 2005. 1098 6.2. Informative References 1100 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 1101 applications: DWDM frequency grid, June 2002. 1103 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 1104 applications: CWDM wavelength grid, December 2003. 1106 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 1107 in Support of Generalized Multi-Protocol Label Switching 1108 (GMPLS)", RFC 5307, October 2008. 1110 Internet-Draft General Network Element Constraint Encoding September 1111 2012 1113 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 1114 WDM Wavelength Switching Systems for Use in GMPLS and 1115 Automated Path Computation", Journal of Optical Communications 1116 and Networking, vol. 1, June, 2009, pp. 187-195. 1118 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1119 Element (PCE) communication Protocol (PCEP) - Version 1", 1120 RFC5440. 1122 Internet-Draft General Network Element Constraint Encoding September 1123 2012 1125 7. Contributors 1127 Diego Caviglia 1128 Ericsson 1129 Via A. Negrone 1/A 16153 1130 Genoa Italy 1132 Phone: +39 010 600 3736 1133 Email: diego.caviglia@(marconi.com, ericsson.com) 1135 Anders Gavler 1136 Acreo AB 1137 Electrum 236 1138 SE - 164 40 Kista Sweden 1140 Email: Anders.Gavler@acreo.se 1142 Jonas Martensson 1143 Acreo AB 1144 Electrum 236 1145 SE - 164 40 Kista, Sweden 1147 Email: Jonas.Martensson@acreo.se 1149 Itaru Nishioka 1150 NEC Corp. 1151 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1152 Japan 1154 Phone: +81 44 396 3287 1155 Email: i-nishioka@cb.jp.nec.com 1157 Rao Rajan 1158 Infinera 1160 Email: rrao@infinera.com 1162 Giovanni Martinelli 1163 CISCO 1165 Email: giomarti@cisco.com 1167 Internet-Draft General Network Element Constraint Encoding September 1168 2012 1170 Authors' Addresses 1172 Greg M. Bernstein (ed.) 1173 Grotto Networking 1174 Fremont California, USA 1176 Phone: (510) 573-2237 1177 Email: gregb@grotto-networking.com 1179 Young Lee (ed.) 1180 Huawei Technologies 1181 1700 Alma Drive, Suite 100 1182 Plano, TX 75075 1183 USA 1185 Phone: (972) 509-5599 (x2240) 1186 Email: ylee@huawei.com 1188 Dan Li 1189 Huawei Technologies Co., Ltd. 1190 F3-5-B R&D Center, Huawei Base, 1191 Bantian, Longgang District 1192 Shenzhen 518129 P.R.China 1194 Phone: +86-755-28973237 1195 Email: danli@huawei.com 1197 Wataru Imajuku 1198 NTT Network Innovation Labs 1199 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1200 Japan 1202 Phone: +81-(46) 859-4315 1203 Email: imajuku.wataru@lab.ntt.co.jp 1205 Internet-Draft General Network Element Constraint Encoding September 1206 2012 1208 Jianrui Han 1209 Huawei Technologies Co., Ltd. 1210 F3-5-B R&D Center, Huawei Base, 1211 Bantian, Longgang District 1212 Shenzhen 518129 P.R.China 1214 Phone: +86-755-28972916 1215 Email: hanjianrui@huawei.com 1217 Intellectual Property Statement 1219 The IETF Trust takes no position regarding the validity or scope of 1220 any Intellectual Property Rights or other rights that might be 1221 claimed to pertain to the implementation or use of the technology 1222 described in any IETF Document or the extent to which any license 1223 under such rights might or might not be available; nor does it 1224 represent that it has made any independent effort to identify any 1225 such rights. 1227 Copies of Intellectual Property disclosures made to the IETF 1228 Secretariat and any assurances of licenses to be made available, or 1229 the result of an attempt made to obtain a general license or 1230 permission for the use of such proprietary rights by implementers or 1231 users of this specification can be obtained from the IETF on-line 1232 IPR repository at http://www.ietf.org/ipr 1234 The IETF invites any interested party to bring to its attention any 1235 copyrights, patents or patent applications, or other proprietary 1236 rights that may cover technology that may be required to implement 1237 any standard or specification contained in an IETF Document. Please 1238 address the information to the IETF at ietf-ipr@ietf.org. 1240 Disclaimer of Validity 1242 All IETF Documents and the information contained therein are 1243 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 1244 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1245 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1246 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1247 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1248 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1249 FOR A PARTICULAR PURPOSE. 1251 Internet-Draft General Network Element Constraint Encoding September 1252 2012 1254 Acknowledgment 1256 Funding for the RFC Editor function is currently provided by the 1257 Internet Society.