idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-11.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 (May 6, 2013) is 4008 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 1025, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 1028, 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: November 2013 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 May 6, 2013 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-11.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 November 6, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 Generalized Multiprotocol Label Switching can be used to control a 57 wide variety of technologies. In some of these technologies network 58 elements and links may impose additional routing constraints such as 59 asymmetric switch connectivity, non-local label assignment, and 60 label range limitations on links. 62 This document provides efficient, protocol-agnostic encodings for 63 general information elements representing connectivity and label 64 constraints as well as label availability. It is intended that 65 protocol-specific documents will reference this memo to describe how 66 information is carried for specific uses. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119 [RFC2119]. 74 Table of Contents 76 1. Introduction...................................................3 77 1.1. Node Switching Asymmetry Constraints......................4 78 1.2. Non-Local Label Assignment Constraints....................4 79 1.3. Change Log................................................5 80 2. Encoding.......................................................6 81 2.1. Link Set Field............................................6 82 2.2. Label Set Field...........................................8 83 2.2.1. Inclusive/Exclusive Label Lists......................9 84 2.2.2. Inclusive/Exclusive Label Ranges.....................9 85 2.2.3. Bitmap Label Set....................................10 86 2.3. Available Labels Sub-TLV.................................11 87 2.4. Shared Backup Labels Sub-TLV.............................11 88 2.5. Connectivity Matrix Sub-TLV..............................12 89 2.6. Port Label Restriction sub-TLV...........................13 90 2.6.1. SIMPLE_LABEL........................................14 91 2.6.2. CHANNEL_COUNT.......................................15 92 2.6.3. LABEL_RANGE1........................................15 93 2.6.4. SIMPLE_LABEL & CHANNEL_COUNT........................16 94 2.6.5. Link Label Exclusivit...............................16 95 3. Security Considerations.......................................17 96 4. IANA Considerations...........................................17 97 5. Acknowledgments...............................................17 98 APPENDIX A: Encoding Examples....................................18 99 A.1. Link Set Field...........................................18 100 A.2. Label Set Field..........................................18 101 A.3. Connectivity Matrix Sub-TLV..............................19 102 A.4. Connectivity Matrix with Bi-directional Symmetry.........22 103 A.5. Priority Flags in Available/Shared Backup Labels sub-TLV.24 104 6. References....................................................26 105 6.1. Normative References.....................................26 106 6.2. Informative References...................................26 107 7. Contributors..................................................28 108 Authors' Addresses...............................................29 109 Intellectual Property Statement..................................30 110 Disclaimer of Validity...........................................30 112 1. Introduction 114 Some data plane technologies that wish to make use of a GMPLS 115 control plane contain additional constraints on switching capability 116 and label assignment. In addition, some of these technologies must 117 perform non-local label assignment based on the nature of the 118 technology, e.g., wavelength continuity constraint in WSON [WSON- 119 Frame]. Such constraints can lead to the requirement for link by 120 link label availability in path computation and label assignment. 122 This document provides efficient encodings of information needed by 123 the routing and label assignment process in technologies such as 124 WSON and are potentially applicable to a wider range of 125 technologies. Such encodings can be used to extend GMPLS signaling 126 and routing protocols. In addition these encodings could be used by 127 other mechanisms to convey this same information to a path 128 computation element (PCE). 130 1.1. Node Switching Asymmetry Constraints 132 For some network elements the ability of a signal or packet on a 133 particular ingress port to reach a particular egress port may be 134 limited. In addition, in some network elements the connectivity 135 between some ingress ports and egress ports may be fixed, e.g., a 136 simple multiplexer. To take into account such constraints during 137 path computation we model this aspect of a network element via a 138 connectivity matrix. 140 The connectivity matrix (ConnectivityMatrix) represents either the 141 potential connectivity matrix for asymmetric switches or fixed 142 connectivity for an asymmetric device such as a multiplexer. Note 143 that this matrix does not represent any particular internal blocking 144 behavior but indicates which ingress ports and labels (e.g., 145 wavelengths) could possibly be connected to a particular output 146 port. Representing internal state dependent blocking for a node is 147 beyond the scope of this document and due to it's highly 148 implementation dependent nature would most likely not be subject to 149 standardization in the future. The connectivity matrix is a 150 conceptual M by N matrix representing the potential switched or 151 fixed connectivity, where M represents the number of ingress ports 152 and N the number of egress ports. 154 1.2. Non-Local Label Assignment Constraints 156 If the nature of the equipment involved in a network results in a 157 requirement for non-local label assignment we can have constraints 158 based on limits imposed by the ports themselves and those that are 159 implied by the current label usage. Note that constraints such as 160 these only become important when label assignment has a non-local 161 character. For example in MPLS an LSR may have a limited range of 162 labels available for use on an egress port and a set of labels 163 already in use on that port and hence unavailable for use. This 164 information, however, does not need to be shared unless there is 165 some limitation on the LSR's label swapping ability. For example if 166 a TDM node lacks the ability to perform time-slot interchange or a 167 WSON lacks the ability to perform wavelength conversion then the 168 label assignment process is not local to a single node and it may be 169 advantageous to share the label assignment constraint information 170 for use in path computation. 172 Port label restrictions (PortLabelRestriction) model the label 173 restrictions that the network element (node) and link may impose on 174 a port. These restrictions tell us what labels may or may not be 175 used on a link and are intended to be relatively static. More 176 dynamic information is contained in the information on available 177 labels. Port label restrictions are specified relative to the port 178 in general or to a specific connectivity matrix for increased 179 modeling flexibility. Reference [Switch] gives an example where both 180 switch and fixed connectivity matrices are used and both types of 181 constraints occur on the same port. 183 1.3. Change Log 185 Changes from 03 version: 187 (a) Removed informational BNF from section 1. 189 (b) Removed section on "Extension Encoding Usage Recommendations" 191 Changes from 04,05 versions: 193 No changes just refreshed document that was expiring. 195 Changes from 06 version: 197 Added priority information to available wavelength encodings. 199 Changes from 07 version: 201 In port label constraint changed reserved field to Switching 202 Capability and Encoding to allow for self description of labels used 203 and interface capability. 205 Changes from 08 version: 207 Switching Capability and Encoding applied to all sub-cases for Port 208 Label Restriction sub-TLV in Section 2.6. 210 Eliminated A (Availability) Bit from Available Labels Sub-TLV and 211 Shared Backup Labels Sub-TLV. 213 Changes from 09 version: 215 Editorial change: Action field can be set to 0x01(Inclusive Range) 216 for Link Set Field Encoding in Section 2.1. 218 Changes from 10 version: 220 Editorial change: A.5 example was corrected to be consistent to 221 Sections 2.3 and 2.4. 223 2. Encoding 225 A type-length-value (TLV) encoding of the general connectivity and 226 label restrictions and availability extensions is given in this 227 section. This encoding is designed to be suitable for use in the 228 GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in 229 the PCE protocol PCEP [PCEP]. Note that the information distributed 230 in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs 231 within TLVs and this document makes use of such constructs. First, 232 however we define two general purpose fields that will be used 233 repeatedly in the subsequent TLVs. 235 2.1. Link Set Field 237 We will frequently need to describe properties of groups of links. 238 To do so efficiently we can make use of a link set concept similar 239 to the label set concept of [RFC3471]. This Link Set Field is used 240 in the sub-TLV, which is defined in Section 241 2.5. The information carried in a Link Set is defined by: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Action |Dir| Format | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Link Identifier 1 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 : : : 251 : : : 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Link Identifier N | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Action: 8 bits 258 0 - Inclusive List 260 Indicates that one or more link identifiers are included in the Link 261 Set. Each identifies a separate link that is part of the set. 263 1 - Inclusive Range 265 Indicates that the Link Set defines a range of links. It contains 266 two link identifiers. The first identifier indicates the start of 267 the range (inclusive). The second identifier indicates the end of 268 the range (inclusive). All links with numeric values between the 269 bounds are considered to be part of the set. A value of zero in 270 either position indicates that there is no bound on the 271 corresponding portion of the range. Note that the Action field can 272 be set to 0x01(Inclusive Range) only when unnumbered link identifier 273 is used. 275 Dir: Directionality of the Link Set (2 bits) 277 0 -- bidirectional 279 1 -- ingress 281 2 -- egress 283 For example in optical networks we think in terms of unidirectional 284 as well as bidirectional links. For example, label restrictions or 285 connectivity may be different for an ingress port, than for its 286 "companion" egress port if one exists. Note that "interfaces" such 287 as those discussed in the Interfaces MIB [RFC2863] are assumed to be 288 bidirectional. This also applies to the links advertised in various 289 link state routing protocols. 291 Format: The format of the link identifier (6 bits) 293 0 -- Link Local Identifier 295 Indicates that the links in the Link Set are identified by link 296 local identifiers. All link local identifiers are supplied in the 297 context of the advertising node. 299 1 -- Local Interface IPv4 Address 301 2 -- Local Interface IPv6 Address 303 Indicates that the links in the Link Set are identified by Local 304 Interface IP Address. All Local Interface IP Address are supplied in 305 the context of the advertising node. 307 Others TBD. 309 Note that all link identifiers in the same list must be of the same 310 type. 312 Length: 16 bits 314 This field indicates the total length in bytes of the Link Set field. 316 Link Identifier: length is dependent on the link format 318 The link identifier represents the port which is being described 319 either for connectivity or label restrictions. This can be the link 320 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 321 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link 322 local identifier format can result in more compact encodings when 323 the assignments are done in a reasonable fashion. 325 2.2. Label Set Field 327 Label Set Field is used within the sub-TLV or the 328 sub-TLV, which is defined in Section 2.3. and 329 2.4. ,respectively. 331 The general format for a label set is given below. This format uses 332 the Action concept from [RFC3471] with an additional Action to 333 define a "bit map" type of label set. The second 32 bit field is a 334 base label used as a starting point in many of the specific formats. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Action| Num Labels | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Base Label | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Additional fields as necessary per action | 344 | 346 Action: 348 0 - Inclusive List 350 1 - Exclusive List 351 2 - Inclusive Range 353 3 - Exclusive Range 355 4 - Bitmap Set 357 Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 358 indicates the number of labels represented by the bit map. See more 359 detail in section 3.2.3. 361 Length is the length in bytes of the entire field. 363 2.2.1. Inclusive/Exclusive Label Lists 365 In the case of the inclusive/exclusive lists the wavelength set 366 format is given by: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |0 or 1 | Num Labels (not used) | Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Base Label | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 : : 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Last Label | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Where: 382 Num Labels is not used in this particular format since the Length 383 parameter is sufficient to determine the number of labels in the 384 list. 386 2.2.2. Inclusive/Exclusive Label Ranges 388 In the case of inclusive/exclusive ranges the label set format is 389 given by: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |2 or 3 | Num Labels(not used) | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Start Label | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | End Label | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Note that the start and end label must in some sense "compatible" in 402 the technology being used. 404 2.2.3. Bitmap Label Set 406 In the case of Action = 4, the bitmap the label set format is given 407 by: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | 4 | Num Labels | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Base Label | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Bit Map Word #1 (Lowest numerical labels) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 : : 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Bit Map Word #N (Highest numerical labels) | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Where Num Labels in this case tells us the number of labels 424 represented by the bit map. Each bit in the bit map represents a 425 particular label with a value of 1/0 indicating whether the label is 426 in the set or not. Bit position zero represents the lowest label and 427 corresponds to the base label, while each succeeding bit position 428 represents the next label logically above the previous. 430 The size of the bit map is Num Label bits, but the bit map is padded 431 out to a full multiple of 32 bits so that the TLV is a multiple of 432 four bytes. Bits that do not represent labels (i.e., those in 433 positions (Num Labels) and beyond SHOULD be set to zero and MUST be 434 ignored. 436 2.3. Available Labels Sub-TLV 438 The Available Labels sub-TLV link consists of priority flags, and a 439 single variable length label set field as follows: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | PRI | Reserved | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Label Set Field | 447 : : 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Where 452 PRI (Priority Flags, 8 bits): Indicates priority level applied to 453 Label Set Field. Bit 8 corresponds to priority level 0 and bit 15 454 corresponds to priority level 7. 456 Note that Label Set Field is defined in Section 2.2. See Appendix 457 A.5. for illustrative examples. 459 2.4. Shared Backup Labels Sub-TLV 461 The Shared Backup Labels sub-TLV consists of priority flags, and 462 single variable length label set field as follows: 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | PRI | Reserved | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Label Set Field | 470 : : 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Where 474 PRI (Priority Flags, 8 bits): Indicates priority level applied to 475 Label Set Field. Bit 8 corresponds to priority level 0 and bit 15 476 corresponds to priority level 7. 478 2.5. Connectivity Matrix Sub-TLV 480 The Connectivity Matrix represents how ingress ports are connected 481 to egress ports for network elements. The switch and fixed 482 connectivity matrices can be compactly represented in terms of a 483 minimal list of ingress and egress port set pairs that have mutual 484 connectivity. As described in [Switch] such a minimal list 485 representation leads naturally to a graph representation for path 486 computation purposes that involves the fewest additional nodes and 487 links. 489 A TLV encoding of this list of link set pairs is: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Connectivity | MatrixID | Reserved | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Link Set A #1 | 497 : : : 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Link Set B #1 : 500 : : : 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Additional Link set pairs as needed | 503 : to specify connectivity : 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Where 508 Connectivity is the device type. 510 0 -- the device is fixed 512 1 -- the device is switched(e.g., ROADM/OXC) 514 MatrixID represents the ID of the connectivity matrix and is an 8 515 bit integer. The value of 0xFF is reserved for use with port 516 wavelength constraints and should not be used to identify a 517 connectivity matrix. 519 Link Set A #1 and Link Set B #1 together represent a pair of link 520 sets. There are two permitted combinations for the link set field 521 parameter "dir" for Link Set A and B pairs: 523 o Link Set A dir=ingress, Link Set B dir=egress 525 The meaning of the pair of link sets A and B in this case is that 526 any signal that ingresses a link in set A can be potentially 527 switched out of an egress link in set B. 529 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 531 The meaning of the pair of link sets A and B in this case is that 532 any signal that ingresses on the links in set A can potentially 533 egress on a link in set B, and any ingress signal on the links in 534 set B can potentially egress on a link in set A. 536 See Appendix A for both types of encodings as applied to a ROADM 537 example. 539 2.6. Port Label Restriction sub-TLV 541 Port Label Restriction tells us what labels may or may not be used 542 on a link. 544 The port label restriction of section 1.2. can be encoded as a sub- 545 TLV as follows. More than one of these sub-TLVs may be needed to 546 fully specify a complex port constraint. When more than one of these 547 sub-TLVs are present the resulting restriction is the intersection 548 of the restrictions expressed in each sub-TLV. To indicate that a 549 restriction applies to the port in general and not to a specific 550 connectivity matrix use the reserved value of 0xFF for the MatrixID. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | MatrixID |RestrictionType| Switching Cap | Encoding | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Additional Restriction Parameters per RestrictionType | 558 : : 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Where: 563 MatrixID: either is the value in the corresponding Connectivity 564 Matrix sub-TLV or takes the value OxFF to indicate the restriction 565 applies to the port regardless of any Connectivity Matrix. 567 RestrictionType can take the following values and meanings: 569 0: SIMPLE_LABEL (Simple label selective restriction) 571 1: CHANNEL_COUNT (Channel count restriction) 573 2: LABEL_RANGE1 (Label range device with a movable center 574 label and width) 576 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 577 and CHANNEL_COUNT restriction. The accompanying label set and 578 channel count indicate labels permitted on the port and the 579 maximum number of channels that can be simultaneously used on 580 the port) 582 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once 583 amongst a set of specified ports) 585 Switching Capability is defined in [RFC4203] and Encoding in 586 [RFC3471]. The combination of these fields defines the type of 587 labels used in specifying the port label restrictions as well as the 588 interface type to which these restrictions apply. 590 2.6.1. SIMPLE_LABEL 592 In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or 593 MatrixSpecificRestrictions) format is given by: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | MatrixID | RstType = 0 | Switching Cap | Encoding | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Label Set Field | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 In this case the accompanying label set indicates the labels 604 permitted on the port. 606 2.6.2. CHANNEL_COUNT 608 In the case of the CHANNEL_COUNT the format is given by: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | MatrixID | RstType = 1 | Switching Cap | Encoding | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | MaxNumChannels | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 In this case the accompanying MaxNumChannels indicates the maximum 619 number of channels (labels) that can be simultaneously used on the 620 port/matrix. 622 2.6.3. LABEL_RANGE1 624 In the case of the LABEL_RANGE1 the GeneralPortRestrictions (or 625 MatrixSpecificRestrictions) format is given by: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | MatrixID | RstType = 2 |Switching Cap | Encoding | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | MaxLabelRange | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Label Set Field | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 In this case the accompanying MaxLabelRange indicates the maximum 638 range of the labels. The corresponding label set is used to indicate 639 the overall label range. Specific center label information can be 640 obtained from dynamic label in use information. It is assumed that 641 both center label and range tuning can be done without causing 642 faults to existing signals. 644 2.6.4. SIMPLE_LABEL & CHANNEL_COUNT 646 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 647 by: 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | MatrixID | RstType = 3 | Switching Cap | Encoding | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | MaxNumChannels | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Label Set Field | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 In this case the accompanying label set and MaxNumChannels indicate 660 labels permitted on the port and the maximum number of labels that 661 can be simultaneously used on the port. 663 2.6.5. Link Label Exclusivity 665 In the case of the Link Label Exclusivity the format is given by: 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | MatrixID | RstType = 4 | Switching Cap | Encoding | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Link Set Field | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 In this case the accompanying port set indicate that a label may be 676 used at most once among the ports in the link set field. 678 3. Security Considerations 680 This document defines protocol-independent encodings for WSON 681 information and does not introduce any security issues. 683 However, other documents that make use of these encodings within 684 protocol extensions need to consider the issues and risks associated 685 with, inspection, interception, modification, or spoofing of any of 686 this information. It is expected that any such documents will 687 describe the necessary security measures to provide adequate 688 protection. 690 4. IANA Considerations 692 TBD. Once our approach is finalized we may need identifiers for the 693 various TLVs and sub-TLVs. 695 5. Acknowledgments 697 This document was prepared using 2-Word-v2.0.template.dot. 699 APPENDIX A: Encoding Examples 701 Here we give examples of the general encoding extensions applied to 702 some simple ROADM network elements and links. 704 A.1. Link Set Field 706 Suppose that we wish to describe a set of ingress ports that are 707 have link local identifiers number 3 through 42. In the link set 708 field we set the Action = 1 to denote an inclusive range; the Dir = 709 1 to denote ingress links; and, the Format = 0 to denote link local 710 identifiers. In particular we have: 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Link Local Identifier = #3 | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Link Local Identifier = #42 | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 A.2. Label Set Field 722 Example: 724 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 725 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 726 (1530.3nm). These frequencies correspond to n = -11, and n = 28 727 respectively. Now suppose the following channels are available: 729 Frequency (THz) n Value bit map position 730 -------------------------------------------------- 731 192.0 -11 0 732 192.5 -6 5 733 193.1 0 11 734 193.9 8 19 735 194.0 9 20 736 195.2 21 32 737 195.8 27 38 739 With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. 740 set to indicate 100GHz this lambda bit map set would then be encoded 741 as follows: 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | 4 | Num Wavelengths = 40 | Length = 16 bytes | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 |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| 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 To encode this same set as an inclusive list we would have: 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | 0 | Num Wavelengths = 40 | Length = 20 bytes | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 A.3. Connectivity Matrix Sub-TLV 779 Example: 781 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 782 its two line side ports it has 80 add and 80 drop ports. The picture 783 below illustrates how a typical 2-degree ROADM system that works 784 with bi-directional fiber pairs is a highly asymmetrical system 785 composed of two unidirectional ROADM subsystems. 787 (Tributary) Ports #3-#42 788 Ingress added to Egress dropped from 789 West Line Egress East Line Ingress 790 vvvvv ^^^^^ 791 | |||.| | |||.| 792 +-----| |||.|--------| |||.|------+ 793 | +----------------------+ | 794 | | | | 795 Egress | | Unidirectional ROADM | | Ingress 796 -----------------+ | | +-------------- 797 <=====================| |===================< 798 -----------------+ +----------------------+ +-------------- 799 | | 800 Port #1 | | Port #2 801 (West Line Side) | |(East Line Side) 802 -----------------+ +----------------------+ +-------------- 803 >=====================| |===================> 804 -----------------+ | Unidirectional ROADM | +-------------- 805 Ingress | | | | Egress 806 | | _ | | 807 | +----------------------+ | 808 +-----| |||.|--------| |||.|------+ 809 | |||.| | |||.| 810 vvvvv ^^^^^ 811 (Tributary) Ports #43-#82 812 Egress dropped from Ingress added to 813 West Line ingress East Line egress 815 Referring to the figure we see that the ingress direction of ports 816 #3-#42 (add ports) can only connect to the egress on port #1. While 817 the ingress side of port #2 (line side) can only connect to the 818 egress on ports #3-#42 (drop) and to the egress on port #1 (pass 819 through). Similarly, the ingress direction of ports #43-#82 can only 820 connect to the egress on port #2 (line). While the ingress direction 821 of port #1 can only connect to the egress on ports #43-#82 (drop) or 822 port #2 (pass through). We can now represent this potential 823 connectivity matrix as follows. This representation uses only 30 32- 824 bit words. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Conn = 1 | MatrixID | Reserved | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Note: adds to line 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Link Local Identifier = #3 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Link Local Identifier = #42 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Link Local Identifier = #1 | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 Note: line to drops 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Link Local Identifier = #2 | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Link Local Identifier = #3 | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Link Local Identifier = #42 | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Note: line to line 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Link Local Identifier = #2 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Link Local Identifier = #1 | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Note: adds to line 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Link Local Identifier = #43 | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Link Local Identifier = #82 | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Link Local Identifier = #2 | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 Note: line to drops 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Link Local Identifier = #1 | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Link Local Identifier = #43 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Link Local Identifier = #82 | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 Note: line to line 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Link Local Identifier = #1 | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Link Local Identifier = #2 | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 A.4. Connectivity Matrix with Bi-directional Symmetry 902 If one has the ability to renumber the ports of the previous example 903 as shown in the next figure then we can take advantage of the bi- 904 directional symmetry and use bi-directional encoding of the 905 connectivity matrix. Note that we set dir=bidirectional in the link 906 set fields. 908 (Tributary) 909 Ports #3-42 Ports #43-82 910 West Line Egress East Line Ingress 911 vvvvv ^^^^^ 912 | |||.| | |||.| 913 +-----| |||.|--------| |||.|------+ 914 | +----------------------+ | 915 | | | | 916 Egress | | Unidirectional ROADM | | Ingress 917 -----------------+ | | +-------------- 918 <=====================| |===================< 919 -----------------+ +----------------------+ +-------------- 920 | | 921 Port #1 | | Port #2 922 (West Line Side) | |(East Line Side) 923 -----------------+ +----------------------+ +-------------- 924 >=====================| |===================> 925 -----------------+ | Unidirectional ROADM | +-------------- 926 Ingress | | | | Egress 927 | | _ | | 928 | +----------------------+ | 929 +-----| |||.|--------| |||.|------+ 930 | |||.| | |||.| 931 vvvvv ^^^^^ 932 Ports #3-#42 Ports #43-82 933 Egress dropped from Ingress added to 934 West Line ingress East Line egress 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Conn = 1 | MatrixID | Reserved | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Add/Drops #3-42 to Line side #1 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Link Local Identifier = #3 | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Link Local Identifier = #42 | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Link Local Identifier = #1 | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Note: line #2 to add/drops #43-82 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Link Local Identifier = #2 | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Link Local Identifier = #43 | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Link Local Identifier = #82 | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 Note: line to line 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Link Local Identifier = #1 | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Link Local Identifier = #2 | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 A.5. Priority Flags in Available/Shared Backup Labels sub-TLV 978 If one wants to make a set of labels (indicated by Label Set Field 979 #1) available only for highest priority level (Priority Level 0) 980 while allowing a set of labels (indicated by Label Set Field #2) 981 available to all priority levels (Priority Level 7), the following 982 encoding will express such need. 984 0 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 |0 0 0 1 0 0 0 0| Reserved | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Label Set Field #1 | 990 : : 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 |1 1 1 1 0 0 0 0| Reserved | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Label Set Field #2 | 995 : : 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 6. References 1000 6.1. Normative References 1002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1003 Requirement Levels", BCP 14, RFC 2119, March 1997. 1005 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1006 MIB", RFC 2863, June 2000. 1008 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1009 (GMPLS) Signaling Functional Description", RFC 3471, 1010 January 2003. 1012 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 1013 applications: DWDM frequency grid", June, 2002. 1015 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 1016 Extensions in Support of Generalized Multi-Protocol Label 1017 Switching (GMPLS)", RFC 4202, October 2005 1019 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 1020 in Support of Generalized Multi-Protocol Label Switching 1021 (GMPLS)", RFC 4203, October 2005. 1023 6.2. Informative References 1025 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 1026 applications: DWDM frequency grid, June 2002. 1028 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 1029 applications: CWDM wavelength grid, December 2003. 1031 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 1032 in Support of Generalized Multi-Protocol Label Switching 1033 (GMPLS)", RFC 5307, October 2008. 1035 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 1036 WDM Wavelength Switching Systems for Use in GMPLS and 1037 Automated Path Computation", Journal of Optical Communications 1038 and Networking, vol. 1, June, 2009, pp. 187-195. 1040 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1041 Element (PCE) communication Protocol (PCEP) - Version 1", 1042 RFC5440. 1044 7. Contributors 1046 Diego Caviglia 1047 Ericsson 1048 Via A. Negrone 1/A 16153 1049 Genoa Italy 1051 Phone: +39 010 600 3736 1052 Email: diego.caviglia@(marconi.com, ericsson.com) 1054 Anders Gavler 1055 Acreo AB 1056 Electrum 236 1057 SE - 164 40 Kista Sweden 1059 Email: Anders.Gavler@acreo.se 1061 Jonas Martensson 1062 Acreo AB 1063 Electrum 236 1064 SE - 164 40 Kista, Sweden 1066 Email: Jonas.Martensson@acreo.se 1068 Itaru Nishioka 1069 NEC Corp. 1070 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1071 Japan 1073 Phone: +81 44 396 3287 1074 Email: i-nishioka@cb.jp.nec.com 1076 Rao Rajan 1077 Infinera 1079 Email: rrao@infinera.com 1081 Giovanni Martinelli 1082 CISCO 1084 Email: giomarti@cisco.com 1086 Remi Theillaud 1087 Marben 1088 remi.theillaud@marben-products.com 1090 Authors' Addresses 1092 Greg M. Bernstein (ed.) 1093 Grotto Networking 1094 Fremont California, USA 1096 Phone: (510) 573-2237 1097 Email: gregb@grotto-networking.com 1099 Young Lee (ed.) 1100 Huawei Technologies 1101 1700 Alma Drive, Suite 100 1102 Plano, TX 75075 1103 USA 1105 Phone: (972) 509-5599 (x2240) 1106 Email: ylee@huawei.com 1108 Dan Li 1109 Huawei Technologies Co., Ltd. 1110 F3-5-B R&D Center, Huawei Base, 1111 Bantian, Longgang District 1112 Shenzhen 518129 P.R.China 1114 Phone: +86-755-28973237 1115 Email: danli@huawei.com 1117 Wataru Imajuku 1118 NTT Network Innovation Labs 1119 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1120 Japan 1122 Phone: +81-(46) 859-4315 1123 Email: imajuku.wataru@lab.ntt.co.jp 1124 Jianrui Han 1125 Huawei Technologies Co., Ltd. 1126 F3-5-B R&D Center, Huawei Base, 1127 Bantian, Longgang District 1128 Shenzhen 518129 P.R.China 1130 Phone: +86-755-28972916 1131 Email: hanjianrui@huawei.com 1133 Intellectual Property Statement 1135 The IETF Trust takes no position regarding the validity or scope of 1136 any Intellectual Property Rights or other rights that might be 1137 claimed to pertain to the implementation or use of the technology 1138 described in any IETF Document or the extent to which any license 1139 under such rights might or might not be available; nor does it 1140 represent that it has made any independent effort to identify any 1141 such rights. 1143 Copies of Intellectual Property disclosures made to the IETF 1144 Secretariat and any assurances of licenses to be made available, or 1145 the result of an attempt made to obtain a general license or 1146 permission for the use of such proprietary rights by implementers or 1147 users of this specification can be obtained from the IETF on-line 1148 IPR repository at http://www.ietf.org/ipr 1150 The IETF invites any interested party to bring to its attention any 1151 copyrights, patents or patent applications, or other proprietary 1152 rights that may cover technology that may be required to implement 1153 any standard or specification contained in an IETF Document. Please 1154 address the information to the IETF at ietf-ipr@ietf.org. 1156 Disclaimer of Validity 1158 All IETF Documents and the information contained therein are 1159 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 1160 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1161 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1162 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1163 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1164 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1165 FOR A PARTICULAR PURPOSE. 1167 Acknowledgment 1169 Funding for the RFC Editor function is currently provided by the 1170 Internet Society.