idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-05.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 25, 2011) is 4714 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 946, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 949, 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 2011 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 May 25, 2011 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-05.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 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 months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 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 25, 2011. 39 Copyright Notice 41 Copyright (c) 2011 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 respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 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 label 60 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......................3 78 1.2. Non-Local Label Assignment Constraints....................4 79 1.3. Change Log................................................5 80 2. Encoding.......................................................5 81 2.1. Link Set Field............................................5 82 2.2. Label Set Field...........................................7 83 2.2.1. Inclusive/Exclusive Label Lists......................8 84 2.2.2. Inclusive/Exclusive Label Ranges.....................9 85 2.2.3. Bitmap Label Set.....................................9 86 2.3. Available Labels Sub-TLV.................................10 87 2.4. Shared Backup Labels Sub-TLV.............................11 88 2.5. Connectivity Matrix Sub-TLV..............................11 89 2.6. Port Label Restriction sub-TLV...........................12 90 2.6.1. SIMPLE_LABEL........................................13 91 2.6.2. CHANNEL_COUNT.......................................14 92 2.6.3. LABEL_RANGE1........................................14 93 2.6.4. SIMPLE_LABEL & CHANNEL_COUNT........................15 94 2.6.5. Link Label Exclusivity..............................15 95 3. Security Considerations.......................................15 96 4. IANA Considerations...........................................16 97 5. Acknowledgments...............................................16 98 APPENDIX A: Encoding Examples....................................17 99 A.1. Link Set Field...........................................17 100 A.2. Label Set Field..........................................17 101 A.3. Connectivity Matrix Sub-TLV..............................18 102 A.4. Connectivity Matrix with Bi-directional Symmetry.........21 103 6. References....................................................24 104 6.1. Normative References.....................................24 105 6.2. Informative References...................................24 106 7. Contributors..................................................25 107 Authors' Addresses...............................................26 108 Intellectual Property Statement..................................27 109 Disclaimer of Validity...........................................27 111 1. Introduction 113 Some data plane technologies that wish to make use of a GMPLS control 114 plane contain additional constraints on switching capability and 115 label assignment. In addition, some of these technologies must 116 perform non-local label assignment based on the nature of the 117 technology, e.g., wavelength continuity constraint in WSON [WSON- 118 Frame]. Such constraints can lead to the requirement for link by link 119 label availability in path computation and label assignment. 121 This document provides efficient encodings of information needed by 122 the routing and label assignment process in technologies such as WSON 123 and are potentially applicable to a wider range of technologies. Such 124 encodings can be used to extend GMPLS signaling and routing 125 protocols. In addition these encodings could be used by other 126 mechanisms to convey this same information to a path computation 127 element (PCE). 129 1.1. Node Switching Asymmetry Constraints 131 For some network elements the ability of a signal or packet on a 132 particular ingress port to reach a particular egress port may be 133 limited. In addition, in some network elements the connectivity 134 between some ingress ports and egress ports may be fixed, e.g., a 135 simple multiplexer. To take into account such constraints during path 136 computation we model this aspect of a network element via a 137 connectivity matrix. 139 The connectivity matrix (ConnectivityMatrix) represents either the 140 potential connectivity matrix for asymmetric switches or fixed 141 connectivity for an asymmetric device such as a multiplexer. Note 142 that this matrix does not represent any particular internal blocking 143 behavior but indicates which ingress ports and labels (e.g., 144 wavelengths) could possibly be connected to a particular output port. 145 Representing internal state dependent blocking for a node is beyond 146 the scope of this document and due to it's highly implementation 147 dependent nature would most likely not be subject to standardization 148 in the future. The connectivity matrix is a conceptual M by N matrix 149 representing the potential switched or fixed connectivity, where M 150 represents the number of ingress ports and N the number of egress 151 ports. 153 1.2. Non-Local Label Assignment Constraints 155 If the nature of the equipment involved in a network results in a 156 requirement for non-local label assignment we can have constraints 157 based on limits imposed by the ports themselves and those that are 158 implied by the current label usage. Note that constraints such as 159 these only become important when label assignment has a non-local 160 character. For example in MPLS an LSR may have a limited range of 161 labels available for use on an egress port and a set of labels 162 already in use on that port and hence unavailable for use. This 163 information, however, does not need to be shared unless there is some 164 limitation on the LSR's label swapping ability. For example if a TDM 165 node lacks the ability to perform time-slot interchange or a WSON 166 lacks the ability to perform wavelength conversion then the label 167 assignment process is not local to a single node and it may be 168 advantageous to share the label assignment constraint information for 169 use in path computation. 171 Port label restrictions (PortLabelRestriction) model the label 172 restrictions that the network element (node) and link may impose on a 173 port. These restrictions tell us what labels may or may not be used 174 on a link and are intended to be relatively static. More dynamic 175 information is contained in the information on available labels. Port 176 label restrictions are specified relative to the port in general or 177 to a specific connectivity matrix for increased modeling flexibility. 178 Reference [Switch] gives an example where both switch and fixed 179 connectivity matrices are used and both types of constraints occur on 180 the same port. 182 1.3. Change Log 184 Changes from 03 version: 186 (a)Removed informational BNF from section 1. 188 (b) Removed section on "Extension Encoding Usage Recommendations" 190 Changes from 04 version: 192 No changes just refreshed document that was expiring. 194 2. Encoding 196 A type-length-value (TLV) encoding of the general connectivity and 197 label restrictions and availability extensions is given in this 198 section. This encoding is designed to be suitable for use in the 199 GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in the 200 PCE protocol PCEP [PCEP]. Note that the information distributed in 201 [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs 202 within TLVs and this document makes use of such constructs. First, 203 however we define two general purpose fields that will be used 204 repeatedly in the subsequent TLVs. 206 2.1. Link Set Field 208 We will frequently need to describe properties of groups of links. To 209 do so efficiently we can make use of a link set concept similar to 210 the label set concept of [RFC3471]. This Link Set Field is used in 211 the sub-TLV, which is defined in Section 2.5. 212 The information carried in a Link Set is defined by: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Action |Dir| Format | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Link Identifier 1 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 : : : 222 : : : 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Link Identifier N | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Action: 8 bits 229 0 - Inclusive List 231 Indicates that one or more link identifiers are included in the Link 232 Set. Each identifies a separate link that is part of the set. 234 1 - Inclusive Range 236 Indicates that the Link Set defines a range of links. It contains 237 two link identifiers. The first identifier indicates the start of the 238 range (inclusive). The second identifier indicates the end of the 239 range (inclusive). All links with numeric values between the bounds 240 are considered to be part of the set. A value of zero in either 241 position indicates that there is no bound on the corresponding 242 portion of the range. Note that the Action field can be set to 243 0x02(Inclusive Range) only when unnumbered link identifier is used. 245 Dir: Directionality of the Link Set (2 bits) 247 0 -- bidirectional 248 1 -- ingress 250 2 -- egress 252 For example in optical networks we think in terms of unidirectional 253 as well as bidirectional links. For example, label restrictions or 254 connectivity may be different for an ingress port, than for its 255 "companion" egress port if one exists. Note that "interfaces" such as 256 those discussed in the Interfaces MIB [RFC2863] are assumed to be 257 bidirectional. This also applies to the links advertised in various 258 link state routing protocols. 260 Format: The format of the link identifier (6 bits) 262 0 -- Link Local Identifier 264 Indicates that the links in the Link Set are identified by link local 265 identifiers. All link local identifiers are supplied in the context 266 of the advertising node. 268 1 -- Local Interface IPv4 Address 270 2 -- Local Interface IPv6 Address 272 Indicates that the links in the Link Set are identified by Local 273 Interface IP Address. All Local Interface IP Address are supplied in 274 the context of the advertising node. 276 Others TBD. 278 Note that all link identifiers in the same list must be of the same 279 type. 281 Length: 16 bits 283 This field indicates the total length in bytes of the Link Set field. 285 Link Identifier: length is dependent on the link format 287 The link identifier represents the port which is being described 288 either for connectivity or label restrictions. This can be the link 289 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 290 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link local 291 identifier format can result in more compact encodings when the 292 assignments are done in a reasonable fashion. 294 2.2. Label Set Field 296 Label Set Field is used within the sub-TLV or the 297 sub-TLV, which is defined in Section 2.3. and 298 2.4. , respectively. 300 The general format for a label set is given below. This format uses 301 the Action concept from [RFC3471] with an additional Action to define 302 a "bit map" type of label set. The second 32 bit field is a base 303 label used as a starting point in many of the specific formats. 305 0 1 2 3 306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Action| Num Labels | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Base Label | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Additional fields as necessary per action | 313 | 315 Action: 317 0 - Inclusive List 319 1 - Exclusive List 321 2 - Inclusive Range 323 3 - Exclusive Range 325 4 - Bitmap Set 327 Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 328 indicates the number of labels represented by the bit map. See more 329 detail in section 3.2.3. 331 Length is the length in bytes of the entire field. 333 2.2.1. Inclusive/Exclusive Label Lists 335 In the case of the inclusive/exclusive lists the wavelength set 336 format is given by: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |0 or 1 | Num Labels (not used) | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Base Label | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 : : 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Last Label | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Where: 352 Num Labels is not used in this particular format since the Length 353 parameter is sufficient to determine the number of labels in the 354 list. 356 2.2.2. Inclusive/Exclusive Label Ranges 358 In the case of inclusive/exclusive ranges the label set format is 359 given by: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |2 or 3 | Num Labels(not used) | Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Start Label | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | End Label | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Note that the start and end label must in some sense "compatible" in 372 the technology being used. 374 2.2.3. Bitmap Label Set 376 In the case of Action = 4, the bitmap the label set format is given 377 by: 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | 4 | Num Labels | Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Base Label | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Bit Map Word #1 (Lowest numerical labels) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 : : 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Bit Map Word #N (Highest numerical labels) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Where Num Labels in this case tells us the number of labels 394 represented by the bit map. Each bit in the bit map represents a 395 particular label with a value of 1/0 indicating whether the label is 396 in the set or not. Bit position zero represents the lowest label and 397 corresponds to the base label, while each succeeding bit position 398 represents the next label logically above the previous. 400 The size of the bit map is Num Label bits, but the bit map is padded 401 out to a full multiple of 32 bits so that the TLV is a multiple of 402 four bytes. Bits that do not represent labels (i.e., those in 403 positions (Num Labels) and beyond SHOULD be set to zero and MUST be 404 ignored. 406 2.3. Available Labels Sub-TLV 408 To indicate the labels available for use on a link the Available 409 Labels sub-TLV consists of a single variable length label set field 410 as follows: 412 0 1 2 3 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Label Set Field | 416 : : 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Note that Label Set Field is defined in Section 3.2. 421 2.4. Shared Backup Labels Sub-TLV 423 To indicate the labels available for shared backup use on a link the 424 Shared Backup Labels sub-TLV consists of a single variable length 425 label set field as follows: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Label Set Field | 431 : : 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 2.5. Connectivity Matrix Sub-TLV 436 The Connectivity Matrix represents how ingress ports are connected to 437 egress ports for network elements. The switch and fixed connectivity 438 matrices can be compactly represented in terms of a minimal list of 439 ingress and egress port set pairs that have mutual connectivity. As 440 described in [Switch] such a minimal list representation leads 441 naturally to a graph representation for path computation purposes 442 that involves the fewest additional nodes and links. 444 A TLV encoding of this list of link set pairs is: 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Connectivity | MatrixID | Reserved | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Link Set A #1 | 452 : : : 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Link Set B #1 : 455 : : : 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Additional Link set pairs as needed | 458 : to specify connectivity : 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Where 462 Connectivity is the device type. 464 0 -- the device is fixed 466 1 -- the device is switched(e.g., ROADM/OXC) 468 MatrixID represents the ID of the connectivity matrix and is an 8 bit 469 integer. The value of 0xFF is reserved for use with port wavelength 470 constraints and should not be used to identify a connectivity matrix. 472 Link Set A #1 and Link Set B #1 together represent a pair of link 473 sets. There are two permitted combinations for the link set field 474 parameter "dir" for Link Set A and B pairs: 476 o Link Set A dir=ingress, Link Set B dir=egress 478 The meaning of the pair of link sets A and B in this case is that 479 any signal that ingresses a link in set A can be potentially 480 switched out of an egress link in set B. 482 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 484 The meaning of the pair of link sets A and B in this case is that 485 any signal that ingresses on the links in set A can potentially 486 egress on a link in set B, and any ingress signal on the links in 487 set B can potentially egress on a link in set A. 489 See Appendix A for both types of encodings as applied to a ROADM 490 example. 492 2.6. Port Label Restriction sub-TLV 494 Port Label Restriction tells us what labels may or may not be used on 495 a link. 497 The port label restriction of section 1.2. can be encoded as a sub- 498 TLV as follows. More than one of these sub-TLVs may be needed to 499 fully specify a complex port constraint. When more than one of these 500 sub-TLVs are present the resulting restriction is the intersection of 501 the restrictions expressed in each sub-TLV. To indicate that a 502 restriction applies to the port in general and not to a specific 503 connectivity matrix use the reserved value of 0xFF for the MatrixID. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | MatrixID | RestrictionType | Reserved/Parameter | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Additional Restriction Parameters per RestrictionType | 511 : : 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Where: 516 MatrixID: either is the value in the corresponding Connectivity 517 Matrix sub-TLV or takes the value OxFF to indicate the restriction 518 applies to the port regardless of any Connectivity Matrix. 520 RestrictionType can take the following values and meanings: 522 0: SIMPLE_LABEL (Simple label selective restriction) 524 1: CHANNEL_COUNT (Channel count restriction) 526 2: LABEL_RANGE1 (Label range device with a movable center label 527 and width) 529 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 530 and CHANNEL_COUNT restriction. The accompanying label set and 531 channel count indicate labels permitted on the port and the 532 maximum number of channels that can be simultaneously used on 533 the port) 535 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once 536 amongst a set of specified ports) 538 2.6.1. SIMPLE_LABEL 540 In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or 541 MatrixSpecificRestrictions) format is given by: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | MatrixID | RstType = 0 | Reserved | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Label Set Field | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 In this case the accompanying label set indicates the labels 552 permitted on the port. 554 2.6.2. CHANNEL_COUNT 556 In the case of the CHANNEL_COUNT the format is given by: 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | MatrixID | RstType = 1 | MaxNumChannels | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 In this case the accompanying MaxNumChannels indicates the maximum 565 number of channels (labels) that can be simultaneously used on the 566 port/matrix. 568 2.6.3. LABEL_RANGE1 570 In the case of the LABEL_RANGE1 the GeneralPortRestrictions (or 571 MatrixSpecificRestrictions) format is given by: 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | MatrixID | RstType = 2 | MaxLabelRange | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Label Set Field | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 In this case the accompanying MaxLabelRange indicates the maximum 582 range of the labels. The corresponding label set is used to indicate 583 the overall label range. Specific center label information can be 584 obtained from dynamic label in use information. It is assumed that 585 both center label and range tuning can be done without causing faults 586 to existing signals. 588 2.6.4. SIMPLE_LABEL & CHANNEL_COUNT 590 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 591 by: 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | MatrixID | RstType = 3 | MaxNumChannels | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Label Set Field | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 In this case the accompanying label set and MaxNumChannels indicate 602 labels permitted on the port and the maximum number of labels that 603 can be simultaneously used on the port. 605 2.6.5. Link Label Exclusivity 607 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 608 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 = 4 | Reserved | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Link Set Field | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 In this case the accompanying port set indicate that a label may be 619 used at most once among the ports in the link set field. 621 3. Security Considerations 623 This document defines protocol-independent encodings for WSON 624 information and does not introduce any security issues. 626 However, other documents that make use of these encodings within 627 protocol extensions need to consider the issues and risks associated 628 with, inspection, interception, modification, or spoofing of any of 629 this information. It is expected that any such documents will 630 describe the necessary security measures to provide adequate 631 protection. 633 4. IANA Considerations 635 TBD. Once our approach is finalized we may need identifiers for the 636 various TLVs and sub-TLVs. 638 5. Acknowledgments 640 This document was prepared using 2-Word-v2.0.template.dot. 642 APPENDIX A: Encoding Examples 644 Here we give examples of the general encoding extensions applied to 645 some simple ROADM network elements and links. 647 A.1. Link Set Field 649 Suppose that we wish to describe a set of ingress ports that are have 650 link local identifiers number 3 through 42. In the link set field we 651 set the Action = 1 to denote an inclusive range; the Dir = 1 to 652 denote ingress links; and, the Format = 0 to denote link local 653 identifiers. In particular we have: 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Link Local Identifier = #3 | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Link Local Identifier = #42 | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 A.2. Label Set Field 665 Example: 667 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 668 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 669 (1530.3nm). These frequencies correspond to n = -11, and n = 28 670 respectively. Now suppose the following channels are available: 672 Frequency (THz) n Value bit map position 673 -------------------------------------------------- 674 192.0 -11 0 675 192.5 -6 5 676 193.1 0 11 677 193.9 8 19 678 194.0 9 20 679 195.2 21 32 680 195.8 27 38 682 With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. 683 set to indicate 100GHz this lambda bit map set would then be encoded 684 as follows: 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | 4 | Num Wavelengths = 40 | Length = 16 bytes | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 |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| 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 To encode this same set as an inclusive list we would have: 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | 0 | Num Wavelengths = 40 | Length = 20 bytes | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 A.3. Connectivity Matrix Sub-TLV 722 Example: 724 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 725 its two line side ports it has 80 add and 80 drop ports. The picture 726 below illustrates how a typical 2-degree ROADM system that works with 727 bi-directional fiber pairs is a highly asymmetrical system composed 728 of two unidirectional ROADM subsystems. 730 (Tributary) Ports #3-#42 731 Ingress added to Egress dropped from 732 West Line Egress East Line Ingress 733 vvvvv ^^^^^ 734 | |||.| | |||.| 735 +-----| |||.|--------| |||.|------+ 736 | +----------------------+ | 737 | | | | 738 Egress | | Unidirectional ROADM | | Ingress 739 -----------------+ | | +-------------- 740 <=====================| |===================< 741 -----------------+ +----------------------+ +-------------- 742 | | 743 Port #1 | | Port #2 744 (West Line Side) | |(East Line Side) 745 -----------------+ +----------------------+ +-------------- 746 >=====================| |===================> 747 -----------------+ | Unidirectional ROADM | +-------------- 748 Ingress | | | | Egress 749 | | _ | | 750 | +----------------------+ | 751 +-----| |||.|--------| |||.|------+ 752 | |||.| | |||.| 753 vvvvv ^^^^^ 754 (Tributary) Ports #43-#82 755 Egress dropped from Ingress added to 756 West Line ingress East Line egress 758 Referring to the figure we see that the ingress direction of ports 759 #3-#42 (add ports) can only connect to the egress on port #1. While 760 the ingress side of port #2 (line side) can only connect to the 761 egress on ports #3-#42 (drop) and to the egress on port #1 (pass 762 through). Similarly, the ingress direction of ports #43-#82 can only 763 connect to the egress on port #2 (line). While the ingress direction 764 of port #1 can only connect to the egress on ports #43-#82 (drop) or 765 port #2 (pass through). We can now represent this potential 766 connectivity matrix as follows. This representation uses only 30 32- 767 bit words. 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Conn = 1 | MatrixID | Reserved |1 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Note: adds to line 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |2 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Link Local Identifier = #3 |3 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Link Local Identifier = #42 |4 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |5 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Link Local Identifier = #1 |6 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Note: line to drops 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |7 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Link Local Identifier = #2 |8 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |9 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Link Local Identifier = #3 |10 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Link Local Identifier = #42 |11 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Note: line to line 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |12 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Link Local Identifier = #2 |13 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |14 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Link Local Identifier = #1 |15 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Note: adds to line 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |16 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Link Local Identifier = #43 |17 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Link Local Identifier = #82 |18 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |19 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Link Local Identifier = #2 |20 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 Note: line to drops 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 |21 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Link Local Identifier = #1 |22 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |23 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Link Local Identifier = #43 |24 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Link Local Identifier = #82 |25 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Note: line to line 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |26 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Link Local Identifier = #1 |27 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |28 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Link Local Identifier = #2 |30 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 A.4. Connectivity Matrix with Bi-directional Symmetry 845 If one has the ability to renumber the ports of the previous example 846 as shown in the next figure then we can take advantage of the bi- 847 directional symmetry and use bi-directional encoding of the 848 connectivity matrix. Note that we set dir=bidirectional in the link 849 set fields. 851 (Tributary) 852 Ports #3-42 Ports #43-82 853 West Line Egress East Line Ingress 854 vvvvv ^^^^^ 855 | |||.| | |||.| 856 +-----| |||.|--------| |||.|------+ 857 | +----------------------+ | 858 | | | | 859 Egress | | Unidirectional ROADM | | Ingress 860 -----------------+ | | +-------------- 861 <=====================| |===================< 862 -----------------+ +----------------------+ +-------------- 863 | | 864 Port #1 | | Port #2 865 (West Line Side) | |(East Line Side) 866 -----------------+ +----------------------+ +-------------- 867 >=====================| |===================> 868 -----------------+ | Unidirectional ROADM | +-------------- 869 Ingress | | | | Egress 870 | | _ | | 871 | +----------------------+ | 872 +-----| |||.|--------| |||.|------+ 873 | |||.| | |||.| 874 vvvvv ^^^^^ 875 Ports #3-#42 Ports #43-82 876 Egress dropped from Ingress added to 877 West Line ingress East Line egress 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Conn = 1 | MatrixID | Reserved |1 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Add/Drops #3-42 to Line side #1 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |2 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Link Local Identifier = #3 |3 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Link Local Identifier = #42 |4 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |5 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Link Local Identifier = #1 |6 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Note: line #2 to add/drops #43-82 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |7 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Link Local Identifier = #2 |8 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |9 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Link Local Identifier = #43 |10 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Link Local Identifier = #82 |11 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Note: line to line 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |12 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Link Local Identifier = #1 |13 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |14 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Link Local Identifier = #2 |15 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 6. References 921 6.1. Normative References 923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 924 Requirement Levels", BCP 14, RFC 2119, March 1997. 926 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 927 MIB", RFC 2863, June 2000. 929 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 930 (GMPLS) Signaling Functional Description", RFC 3471, 931 January 2003. 933 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 934 applications: DWDM frequency grid", June, 2002. 936 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 937 in Support of Generalized Multi-Protocol Label Switching 938 (GMPLS)", RFC 4202, October 2005 940 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 941 Support of Generalized Multi-Protocol Label Switching 942 (GMPLS)", RFC 4203, October 2005. 944 6.2. Informative References 946 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 947 applications: DWDM frequency grid, June 2002. 949 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 950 applications: CWDM wavelength grid, December 2003. 952 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 953 in Support of Generalized Multi-Protocol Label Switching 954 (GMPLS)", RFC 5307, October 2008. 956 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 957 WDM Wavelength Switching Systems for Use in GMPLS and Automated 958 Path Computation", Journal of Optical Communications and 959 Networking, vol. 1, June, 2009, pp. 187-195. 961 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 962 Element (PCE) communication Protocol (PCEP) - Version 1", 963 RFC5440. 965 7. Contributors 967 Diego Caviglia 968 Ericsson 969 Via A. Negrone 1/A 16153 970 Genoa Italy 972 Phone: +39 010 600 3736 973 Email: diego.caviglia@(marconi.com, ericsson.com) 975 Anders Gavler 976 Acreo AB 977 Electrum 236 978 SE - 164 40 Kista Sweden 980 Email: Anders.Gavler@acreo.se 982 Jonas Martensson 983 Acreo AB 984 Electrum 236 985 SE - 164 40 Kista, Sweden 987 Email: Jonas.Martensson@acreo.se 989 Itaru Nishioka 990 NEC Corp. 991 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 992 Japan 994 Phone: +81 44 396 3287 995 Email: i-nishioka@cb.jp.nec.com 997 Authors' Addresses 999 Greg M. Bernstein (ed.) 1000 Grotto Networking 1001 Fremont California, USA 1003 Phone: (510) 573-2237 1004 Email: gregb@grotto-networking.com 1006 Young Lee (ed.) 1007 Huawei Technologies 1008 1700 Alma Drive, Suite 100 1009 Plano, TX 75075 1010 USA 1012 Phone: (972) 509-5599 (x2240) 1013 Email: ylee@huawei.com 1015 Dan Li 1016 Huawei Technologies Co., Ltd. 1017 F3-5-B R&D Center, Huawei Base, 1018 Bantian, Longgang District 1019 Shenzhen 518129 P.R.China 1021 Phone: +86-755-28973237 1022 Email: danli@huawei.com 1024 Wataru Imajuku 1025 NTT Network Innovation Labs 1026 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1027 Japan 1029 Phone: +81-(46) 859-4315 1030 Email: imajuku.wataru@lab.ntt.co.jp 1031 Jianrui Han 1032 Huawei Technologies Co., Ltd. 1033 F3-5-B R&D Center, Huawei Base, 1034 Bantian, Longgang District 1035 Shenzhen 518129 P.R.China 1037 Phone: +86-755-28972916 1038 Email: hanjianrui@huawei.com 1040 Intellectual Property Statement 1042 The IETF Trust takes no position regarding the validity or scope of 1043 any Intellectual Property Rights or other rights that might be 1044 claimed to pertain to the implementation or use of the technology 1045 described in any IETF Document or the extent to which any license 1046 under such rights might or might not be available; nor does it 1047 represent that it has made any independent effort to identify any 1048 such rights. 1050 Copies of Intellectual Property disclosures made to the IETF 1051 Secretariat and any assurances of licenses to be made available, or 1052 the result of an attempt made to obtain a general license or 1053 permission for the use of such proprietary rights by implementers or 1054 users of this specification can be obtained from the IETF on-line IPR 1055 repository at http://www.ietf.org/ipr 1057 The IETF invites any interested party to bring to its attention any 1058 copyrights, patents or patent applications, or other proprietary 1059 rights that may cover technology that may be required to implement 1060 any standard or specification contained in an IETF Document. Please 1061 address the information to the IETF at ietf-ipr@ietf.org. 1063 Disclaimer of Validity 1065 All IETF Documents and the information contained therein are provided 1066 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1067 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1068 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1069 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1070 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1071 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1072 FOR A PARTICULAR PURPOSE. 1074 Acknowledgment 1076 Funding for the RFC Editor function is currently provided by the 1077 Internet Society.