idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2010) is 5179 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 919, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'Otani' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'WSON-Frame' is defined on line 939, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' Summary: 0 errors (**), 0 flaws (~~), 5 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: August 2010 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 February 18, 2010 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-00.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 August 18, 2010. 39 Copyright Notice 41 Copyright (c) 2010 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. An 59 example of such additional constraints occurs in wavelength switched 60 optical networks (WSON). 62 This document provides efficient, protocol-agnostic encodings for 63 general information elements representing connectivity and label 64 constraints as well as label availability. These encodings are 65 applicable to a wide range of technologies and not limited to WSON. 66 It is intended that protocol-specific documents will reference this 67 memo to describe how information is carried for specific uses. 69 Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC-2119 [RFC2119]. 75 Table of Contents 77 1. Introduction...................................................3 78 2. Terminology....................................................4 79 3. Extension Encoding Usage Recommendations.......................4 80 3.1. Extension Node TLV........................................4 81 3.2. Extension Link TLV........................................4 82 3.3. Extension Dynamic Link TLV................................5 83 4. Link Set Field.................................................5 84 5. Label Set Field................................................7 85 5.1. Inclusive/Exclusive Label Lists...........................8 86 5.2. Inclusive/Exclusive Label Ranges..........................8 87 5.3. Bitmap Label Set..........................................9 88 6. Label and Connectivity sub-TLV Encodings......................10 89 6.1. Available Labels Sub-TLV.................................10 90 6.2. Shared Backup Labels Sub-TLV.............................10 91 6.3. Connectivity Matrix Sub-TLV..............................11 92 6.4. Port Label Restriction sub-TLV...........................12 93 6.4.1. SIMPLE_LABEL........................................13 94 6.4.2. CHANNEL_COUNT.......................................13 95 6.4.3. WAVEBAND1...........................................13 96 6.4.4. SIMPLE_LABEL & CHANNEL_COUNT........................14 97 7. Security Considerations.......................................14 98 8. IANA Considerations...........................................15 99 9. Acknowledgments...............................................15 100 APPENDIX A: Encoding Examples....................................16 101 A.1. Link Set Field...........................................16 102 A.2. Label Set Field..........................................16 103 A.3. Connectivity Matrix Sub-TLV..............................17 104 A.4. Connectivity Matrix with Bi-directional Symmetry.........20 105 10. References...................................................23 106 10.1. Normative References....................................23 107 10.2. Informative References..................................23 108 11. Contributors.................................................25 109 Authors' Addresses...............................................25 110 Intellectual Property Statement..................................26 111 Disclaimer of Validity...........................................27 113 1. Introduction 115 Some data plane technologies that wish to make use of a GMPLS control 116 plane contain additional constraints on switching capability and 117 label assignment. In addition, some of these technologies must 118 perform non-local label assignment based on the nature of the 119 technology, e.g., wavelength continuity constraint in WSON [WSON- 120 Frame]. Such constraints can lead to the requirement for link by link 121 label availability in path computation and label assignment. 123 This document provides efficient encodings of information needed by 124 the routing and label assignment process in technologies such as WSON 125 but that are potentially applicable to a wider range of technologies. 126 Such encodings can be used to extend GMPLS signaling and routing 127 protocols. In addition these encodings could be used by other 128 mechanisms to convey this same information to a path computation 129 element (PCE). 131 Encodings of information needed by the routing and wavelength 132 assignment (RWA) process unique to WSON is addressed in a separate 133 document [WSON-Encode]. 135 2. Terminology 137 CWDM: Coarse Wavelength Division Multiplexing. 139 DWDM: Dense Wavelength Division Multiplexing. 141 FOADM: Fixed Optical Add/Drop Multiplexer. 143 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 144 count wavelength selective switching element featuring ingress and 145 egress line side ports as well as add/drop side ports. 147 RWA: Routing and Wavelength Assignment. 149 WDM: Wavelength Division Multiplexing. 151 Wavelength Switched Optical Network (WSON): A WDM based optical 152 network in which switching is performed selectively based on the 153 center wavelength of an optical signal. 155 3. Extension Encoding Usage Recommendations 157 In this section we give recommendations of typical usage of the sub- 158 TLVs and composite TLVs which are based on four high level 159 information bundles of [WSON-Info]. 161 3.1. Extension Node TLV 163 The Extension Node TLV could consist of the following list of sub- 164 TLVs: 166 ::= [Other GMPLS sub- 167 TLVs][...] 169 3.2. Extension Link TLV 171 The new link related sub-TLVs could be incorporated into a composite 172 link TLV as follows: 174 ::= [Other GMPLS sub-TLVs] 175 [...][] [] 177 3.3. Extension Dynamic Link TLV 179 If the protocol supports the separation of dynamic information from 180 relatively static information then the available wavelength and 181 shared backup status can be separated from the general link TLV into 182 a TLV for dynamic link information. 184 ::= 185 [] 187 4. Link Set Field 189 We will frequently need to describe properties of groups of links. To 190 do so efficiently we can make use of a link set concept similar to 191 the label set concept of [RFC3471]. This Link Set Field is used in 192 the sub-TLV, which is defined in Section 6.3. 193 The information carried in a Link Set is defined by: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Action |Dir| Format | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Link Identifier 1 | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 : : : 203 : : : 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Link Identifier N | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Action: 8 bits 210 0 - Inclusive List 212 Indicates that one or more link identifiers are included in the Link 213 Set. Each identifies a separate link that is part of the set. 215 1 - Inclusive Range 217 Indicates that the Link Set defines a range of links. It contains 218 two link identifiers. The first identifier indicates the start of the 219 range (inclusive). The second identifier indicates the end of the 220 range (inclusive). All links with numeric values between the bounds 221 are considered to be part of the set. A value of zero in either 222 position indicates that there is no bound on the corresponding 223 portion of the range. Note that the Action field can be set to 224 0x02(Inclusive Range) only when unnumbered link identifier is used. 226 Dir: Directionality of the Link Set (2 bits) 228 0 -- bidirectional 229 1 -- ingress 231 2 -- egress 233 In optical networks we think in terms of unidirectional as well as 234 bidirectional links. For example, label restrictions or connectivity 235 may be different for an ingress port, than for its "companion" egress 236 port if one exists. Note that "interfaces" such as those discussed in 237 the Interfaces MIB [RFC2863] are assumed to be bidirectional. This 238 also applies to the links advertised in various link state routing 239 protocols. 241 Format: The format of the link identifier (6 bits) 243 0 -- Link Local Identifier 245 Indicates that the links in the Link Set are identified by link local 246 identifiers. All link local identifiers are supplied in the context 247 of the advertising node. 249 1 -- Local Interface IPv4 Address 251 2 -- Local Interface IPv6 Address 253 Indicates that the links in the Link Set are identified by Local 254 Interface IP Address. All Local Interface IP Address are supplied in 255 the context of the advertising node. 257 Others TBD. 259 Note that all link identifiers in the same list must be of the same 260 type. 262 Length: 16 bits 264 This field indicates the total length in bytes of the Link Set field. 266 Link Identifier: length is dependent on the link format 268 The link identifier represents the port which is being described 269 either for connectivity or label restrictions. This can be the link 270 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 271 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link local 272 identifier format can result in more compact WSON encodings when the 273 assignments are done in a reasonable fashion. 275 5. Label Set Field 277 Label sets come up frequently in WSONs to describe the range of a 278 laser transmitter, the wavelength restrictions on ROADM ports, or the 279 availability of wavelengths on a DWDM link. Label Set Field is used 280 within the sub-TLV or the sub- 281 TLV, which is defined in Section 6.1 and 6.2, respectively. 283 The general format for a label set is given below. This format uses 284 the Action concept from [RFC3471] with an additional Action to define 285 a "bit map" type of label set. The second 32 bit field is a base 286 label used as a starting point in many of the specific formats. In 287 the case of WSONs this provides important information on the WDM grid 288 type and channel spacing. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Action| Num Labels | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Base Label | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Additional fields as necessary per action | 298 | 300 Action: 302 0 - Inclusive List 304 1 - Exclusive List 306 2 - Inclusive Range 307 3 - Exclusive Range 309 4 - Bitmap Set 311 Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 312 indicates the number of labels represented by the bit map. See more 313 detail in section 3.2.3. 315 Length is the length in bytes of the entire field. 317 5.1. Inclusive/Exclusive Label Lists 319 In the case of the inclusive/exclusive lists the wavelength set 320 format is given by: 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |0 or 1 | Num Labels (not used) | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Base Label | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 : : 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Last Label | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Where: 336 Num Labels is not used in this particular format since the Length 337 parameter is sufficient to determine the number of labels in the 338 list. 340 5.2. Inclusive/Exclusive Label Ranges 342 In the case of inclusive/exclusive ranges the label set format is 343 given by: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |2 or 3 | Num Labels(not used) | Length | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Start Label | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | End Label | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Note that the start and end label must in some sense "compatible" in 356 the technology being used. For example in WSONs the labels must be of 357 the same general type (DWDM versus CWDM), and the channel spacings 358 must be the same. 360 5.3. Bitmap Label Set 362 In the case of Action = 4, the bitmap the label set format is given 363 by: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | 4 | Num Labels | Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Base Label | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Bit Map Word #1 (Lowest numerical labels) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 : : 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Bit Map Word #N (Highest numerical labels) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Where Num Labels in this case tells us the number of labels 380 represented by the bit map. Each bit in the bit map represents a 381 particular label with a value of 1/0 indicating whether the label is 382 in the set or not. Bit position zero represents the lowest label and 383 corresponds to the base label, while each succeeding bit position 384 represents the next label logically above the previous. 386 The size of the bit map is Num Label bits, but the bit map is padded 387 out to a full multiple of 32 bits so that the TLV is a multiple of 388 four bytes. Bits that do not represent labels (i.e., those in 389 positions (Num Labels) and beyond SHOULD be set to zero and MUST be 390 ignored. 392 6. Label and Connectivity sub-TLV Encodings 394 A type-length-value (TLV) encoding of the general connectivity and 395 label restrictions and availability extensions is given in the 396 following sections. This encoding is designed to be suitable for use 397 in the GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and 398 in the PCE protocol PCEP [PCEP]. Note that the information 399 distributed in [RFC4203] and [RFC5307] is arranged via the nesting of 400 sub-TLVs within TLVs and this document makes use of such constructs. 402 6.1. Available Labels Sub-TLV 404 To indicate the labels available for use on a link the Available 405 Labels sub-TLV consists of a single variable length label set field 406 as follows: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Label Set Field | 412 : : 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Note that Label Set Field is defined in Section 3.2. 417 6.2. Shared Backup Labels Sub-TLV 419 To indicate the labels available for shared backup use on a link the 420 Shared Backup Labels sub-TLV consists of a single variable length 421 label set field as follows: 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Label Set Field | 427 : : 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 6.3. Connectivity Matrix Sub-TLV 432 The switch and fixed connectivity matrices of [WSON-Info] can be 433 compactly represented in terms of a minimal list of ingress and 434 egress port set pairs that have mutual connectivity. As described in 435 [Switch] such a minimal list representation leads naturally to a 436 graph representation for path computation purposes that involves the 437 fewest additional nodes and links. 439 A TLV encoding of this list of link set pairs is: 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 | Connectivity | MatrixID | Reserved | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Link Set A #1 | 447 : : : 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Link Set B #1 : 450 : : : 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Additional Link set pairs as needed | 453 : to specify connectivity : 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Where 458 Connectivity is the device type. 460 0 -- the device is fixed 462 1 -- the device is switched(e.g., ROADM/OXC) 464 MatrixID represents the ID of the connectivity matrix and is an 8 bit 465 integer. The value of 0xFF is reserved for use with port wavelength 466 constraints and should not be used to identify a connectivity matrix. 468 Link Set A #1 and Link Set B #1 together represent a pair of link 469 sets. There are two permitted combinations for the link set field 470 parameter "dir" for Link Set A and B pairs: 472 o Link Set A dir=ingress, Link Set B dir=egress 473 The meaning of the pair of link sets A and B in this case is that 474 any signal that ingresses a link in set A can be potentially 475 switched out of an egress link in set B. 477 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 479 The meaning of the pair of link sets A and B in this case is that 480 any signal that ingresses on the links in set A can potentially 481 egress on a link in set B, and any ingress signal on the links in 482 set B can potentially egress on a link in set A. 484 See Appendix A for examples of both types of encodings as applied to 485 a WSON example. 487 6.4. Port Label Restriction sub-TLV 489 The port label restriction of [WSON-Info] can be encoded as a sub-TLV 490 as follows. More than one of these sub-TLVs may be needed to fully 491 specify a complex port constraint. When more than one of these sub- 492 TLVs are present the resulting restriction is the intersection of the 493 restrictions expressed in each sub-TLV. To indicate that a 494 restriction applies to the port in general and not to a specific 495 connectivity matrix use the reserved value of 0xFF for the MatrixID. 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | MatrixID | RestrictionType | Reserved/Parameter | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Additional Restriction Parameters per RestrictionType | 503 : : 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Where: 508 MatrixID: either is the value in the corresponding Connectivity 509 Matrix sub-TLV or takes the value OxFF to indicate the restriction 510 applies to the port regardless of any Connectivity Matrix. 512 RestrictionType can take the following values and meanings: 514 0: SIMPLE_LABEL (Simple wavelength selective restriction) 516 1: CHANNEL_COUNT (Channel count restriction) 517 2: WAVEBAND1 (Waveband device with a tunable center frequency 518 and passband) 520 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 521 and CHANNEL_COUNT restriction. The accompanying wavelength set 522 and channel count indicate wavelength permitted on the port and 523 the maximum number of channels that can be simultaneously used 524 on the port) 526 6.4.1. SIMPLE_LABEL 528 In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or 529 MatrixSpecificRestrictions) format is given by: 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | MatrixID | RstType = 0 | Reserved | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Label Set Field | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 In this case the accompanying label set indicates the labels 540 permitted on the port. 542 6.4.2. CHANNEL_COUNT 544 In the case of the CHANNEL_COUNT the format is given by: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | MatrixID | RstType = 1 | MaxNumChannels | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 In this case the accompanying MaxNumChannels indicates the maximum 553 number of channels (labels) that can be simultaneously used on the 554 port/matrix. 556 6.4.3. WAVEBAND1 558 In the case of the WAVEBAND1 the GeneralPortRestrictions (or 559 MatrixSpecificRestrictions) format is given by: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | MatrixID | RstType = 2 | MaxWaveBandWidth | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Label Set Field | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 In this case the accompanying MaxWaveBandWidth indicates the maximum 570 width of the waveband in terms of the channels spacing given in the 571 wavelength set. The corresponding wavelength set is used to indicate 572 the overall tuning range. Specific center frequency tuning 573 information can be obtained from dynamic channel in use information. 574 It is assumed that both center frequency and bandwidth (Q) tuning can 575 be done without causing faults in existing signals. 577 6.4.4. SIMPLE_LABEL & CHANNEL_COUNT 579 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 580 by: 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | MatrixInfo | RstType = 3 | MaxNumChannels | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Label Set Field | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 In this case the accompanying label set and MaxNumChannels indicate 591 labels permitted on the port and the maximum number of labels that 592 can be simultaneously used on the port. 594 7. Security Considerations 596 This document defines protocol-independent encodings for WSON 597 information and does not introduce any security issues. 599 However, other documents that make use of these encodings within 600 protocol extensions need to consider the issues and risks associated 601 with, inspection, interception, modification, or spoofing of any of 602 this information. It is expected that any such documents will 603 describe the necessary security measures to provide adequate 604 protection. 606 8. IANA Considerations 608 TBD. Once our approach is finalized we may need identifiers for the 609 various TLVs and sub-TLVs. 611 9. Acknowledgments 613 This document was prepared using 2-Word-v2.0.template.dot. 615 APPENDIX A: Encoding Examples 617 Here we give examples of the general encoding extensions applied to 618 some simple WSON network elements and links. 620 A.1. Link Set Field 622 Suppose that we wish to describe a set of ingress ports that are have 623 link local identifiers number 3 through 42. In the link set field we 624 set the Action = 1 to denote an inclusive range; the Dir = 1 to 625 denote ingress links; and, the Format = 0 to denote link local 626 identifiers. In particular we have: 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Link Local Identifier = #3 | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Link Local Identifier = #42 | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 A.2. Label Set Field 638 Example: 640 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 641 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 642 (1530.3nm). These frequencies correspond to n = -11, and n = 28 643 respectively. Now suppose the following channels are available: 645 Frequency (THz) n Value bit map position 646 -------------------------------------------------- 647 192.0 -11 0 648 192.5 -6 5 649 193.1 0 11 650 193.9 8 19 651 194.0 9 20 652 195.2 21 32 653 195.8 27 38 655 With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. 656 set to indicate 100GHz this lambda bit map set would then be encoded 657 as follows: 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | 4 | Num Wavelengths = 40 | Length = 16 bytes | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |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| 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 To encode this same set as an inclusive list we would have: 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | 0 | Num Wavelengths = 40 | Length = 20 bytes | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 A.3. Connectivity Matrix Sub-TLV 695 Example: 697 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 698 its two line side ports it has 80 add and 80 drop ports. The picture 699 below illustrates how a typical 2-degree ROADM system that works with 700 bi-directional fiber pairs is a highly asymmetrical system composed 701 of two unidirectional ROADM subsystems. 703 (Tributary) Ports #3-#42 704 Ingress added to Egress dropped from 705 West Line Egress East Line Ingress 706 vvvvv ^^^^^ 707 | |||.| | |||.| 708 +-----| |||.|--------| |||.|------+ 709 | +----------------------+ | 710 | | | | 711 Egress | | Unidirectional ROADM | | Ingress 712 -----------------+ | | +-------------- 713 <=====================| |===================< 714 -----------------+ +----------------------+ +-------------- 715 | | 716 Port #1 | | Port #2 717 (West Line Side) | |(East Line Side) 718 -----------------+ +----------------------+ +-------------- 719 >=====================| |===================> 720 -----------------+ | Unidirectional ROADM | +-------------- 721 Ingress | | | | Egress 722 | | _ | | 723 | +----------------------+ | 724 +-----| |||.|--------| |||.|------+ 725 | |||.| | |||.| 726 vvvvv ^^^^^ 727 (Tributary) Ports #43-#82 728 Egress dropped from Ingress added to 729 West Line ingress East Line egress 731 Referring to the figure we see that the ingress direction of ports 732 #3-#42 (add ports) can only connect to the egress on port #1. While 733 the ingress side of port #2 (line side) can only connect to the 734 egress on ports #3-#42 (drop) and to the egress on port #1 (pass 735 through). Similarly, the ingress direction of ports #43-#82 can only 736 connect to the egress on port #2 (line). While the ingress direction 737 of port #1 can only connect to the egress on ports #43-#82 (drop) or 738 port #2 (pass through). We can now represent this potential 739 connectivity matrix as follows. This representation uses only 30 32- 740 bit words. 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Conn = 1 | MatrixID | Reserved |1 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 Note: adds to line 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |2 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Link Local Identifier = #3 |3 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Link Local Identifier = #42 |4 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |5 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Link Local Identifier = #1 |6 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Note: line to drops 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |7 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Link Local Identifier = #2 |8 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |9 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Link Local Identifier = #3 |10 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Link Local Identifier = #42 |11 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Note: line to line 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |12 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Link Local Identifier = #2 |13 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |14 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Link Local Identifier = #1 |15 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Note: adds to line 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |16 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Link Local Identifier = #43 |17 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Link Local Identifier = #82 |18 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |19 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Link Local Identifier = #2 |20 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 Note: line to drops 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 |21 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Link Local Identifier = #1 |22 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |23 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Link Local Identifier = #43 |24 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Link Local Identifier = #82 |25 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Note: line to line 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |26 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Link Local Identifier = #1 |27 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |28 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Link Local Identifier = #2 |30 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 A.4. Connectivity Matrix with Bi-directional Symmetry 818 If one has the ability to renumber the ports of the previous example 819 as shown in the next figure then we can take advantage of the bi- 820 directional symmetry and use bi-directional encoding of the 821 connectivity matrix. Note that we set dir=bidirectional in the link 822 set fields. 824 (Tributary) 825 Ports #3-42 Ports #43-82 826 West Line Egress East Line Ingress 827 vvvvv ^^^^^ 828 | |||.| | |||.| 829 +-----| |||.|--------| |||.|------+ 830 | +----------------------+ | 831 | | | | 832 Egress | | Unidirectional ROADM | | Ingress 833 -----------------+ | | +-------------- 834 <=====================| |===================< 835 -----------------+ +----------------------+ +-------------- 836 | | 837 Port #1 | | Port #2 838 (West Line Side) | |(East Line Side) 839 -----------------+ +----------------------+ +-------------- 840 >=====================| |===================> 841 -----------------+ | Unidirectional ROADM | +-------------- 842 Ingress | | | | Egress 843 | | _ | | 844 | +----------------------+ | 845 +-----| |||.|--------| |||.|------+ 846 | |||.| | |||.| 847 vvvvv ^^^^^ 848 Ports #3-#42 Ports #43-82 849 Egress dropped from Ingress added to 850 West Line ingress East Line egress 852 0 1 2 3 853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Conn = 1 | MatrixID | Reserved |1 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Add/Drops #3-42 to Line side #1 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |2 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Link Local Identifier = #3 |3 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Link Local Identifier = #42 |4 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |5 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Link Local Identifier = #1 |6 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 Note: line #2 to add/drops #43-82 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |7 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Link Local Identifier = #2 |8 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |9 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Link Local Identifier = #43 |10 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Link Local Identifier = #82 |11 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Note: line to line 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |12 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Link Local Identifier = #1 |13 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |14 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Link Local Identifier = #2 |15 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 10. References 894 10.1. Normative References 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 900 MIB", RFC 2863, June 2000. 902 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 903 (GMPLS) Signaling Functional Description", RFC 3471, 904 January 2003. 906 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 907 applications: DWDM frequency grid", June, 2002. 909 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 910 in Support of Generalized Multi-Protocol Label Switching 911 (GMPLS)", RFC 4202, October 2005 913 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 914 Support of Generalized Multi-Protocol Label Switching 915 (GMPLS)", RFC 4203, October 2005. 917 10.2. Informative References 919 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 920 applications: DWDM frequency grid, June 2002. 922 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 923 applications: CWDM wavelength grid, December 2003. 925 [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 926 Labels for G.694 Lambda-Switching Capable Label Switching 927 Routers", work in progress: draft-ietf-ccamp-gmpls-g-694- 928 lambda-labels. 930 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 931 in Support of Generalized Multi-Protocol Label Switching 932 (GMPLS)", RFC 5307, October 2008. 934 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 935 WDM Wavelength Switching Systems for Use in GMPLS and Automated 936 Path Computation", Journal of Optical Communications and 937 Networking, vol. 1, June, 2009, pp. 187-195. 939 [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 940 and PCE Control of Wavelength Switched Optical Networks", 941 work in progress: draft-ietf-ccamp-wavelength-switched- 942 framework, February, 2010. 944 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 945 Wavelength Assignment Information Model for Wavelength 946 Switched Optical Networks", work in progress: draft-ietf- 947 ccamp-rwa-info, February, 2010. 949 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 950 Wavelength Assignment Information Encoding for Wavelength 951 Switched Optical Networks", work in progress: draft-ietf- 952 ccamp-rwa-wson-encode, Februsary, 2010. 954 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 955 Element (PCE) communication Protocol (PCEP) - Version 1", 956 RFC5440. 958 11. Contributors 960 Diego Caviglia 961 Ericsson 962 Via A. Negrone 1/A 16153 963 Genoa Italy 965 Phone: +39 010 600 3736 966 Email: diego.caviglia@(marconi.com, ericsson.com) 968 Anders Gavler 969 Acreo AB 970 Electrum 236 971 SE - 164 40 Kista Sweden 973 Email: Anders.Gavler@acreo.se 975 Jonas Martensson 976 Acreo AB 977 Electrum 236 978 SE - 164 40 Kista, Sweden 980 Email: Jonas.Martensson@acreo.se 982 Itaru Nishioka 983 NEC Corp. 984 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 985 Japan 987 Phone: +81 44 396 3287 988 Email: i-nishioka@cb.jp.nec.com 990 Authors' Addresses 992 Greg M. Bernstein (ed.) 993 Grotto Networking 994 Fremont California, USA 996 Phone: (510) 573-2237 997 Email: gregb@grotto-networking.com 998 Young Lee (ed.) 999 Huawei Technologies 1000 1700 Alma Drive, Suite 100 1001 Plano, TX 75075 1002 USA 1004 Phone: (972) 509-5599 (x2240) 1005 Email: ylee@huawei.com 1007 Dan Li 1008 Huawei Technologies Co., Ltd. 1009 F3-5-B R&D Center, Huawei Base, 1010 Bantian, Longgang District 1011 Shenzhen 518129 P.R.China 1013 Phone: +86-755-28973237 1014 Email: danli@huawei.com 1016 Wataru Imajuku 1017 NTT Network Innovation Labs 1018 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1019 Japan 1021 Phone: +81-(46) 859-4315 1022 Email: imajuku.wataru@lab.ntt.co.jp 1024 Jianrui Han 1025 Huawei Technologies Co., Ltd. 1026 F3-5-B R&D Center, Huawei Base, 1027 Bantian, Longgang District 1028 Shenzhen 518129 P.R.China 1030 Phone: +86-755-28972916 1031 Email: hanjianrui@huawei.com 1033 Intellectual Property Statement 1035 The IETF Trust takes no position regarding the validity or scope of 1036 any Intellectual Property Rights or other rights that might be 1037 claimed to pertain to the implementation or use of the technology 1038 described in any IETF Document or the extent to which any license 1039 under such rights might or might not be available; nor does it 1040 represent that it has made any independent effort to identify any 1041 such rights. 1043 Copies of Intellectual Property disclosures made to the IETF 1044 Secretariat and any assurances of licenses to be made available, or 1045 the result of an attempt made to obtain a general license or 1046 permission for the use of such proprietary rights by implementers or 1047 users of this specification can be obtained from the IETF on-line IPR 1048 repository at http://www.ietf.org/ipr 1050 The IETF invites any interested party to bring to its attention any 1051 copyrights, patents or patent applications, or other proprietary 1052 rights that may cover technology that may be required to implement 1053 any standard or specification contained in an IETF Document. Please 1054 address the information to the IETF at ietf-ipr@ietf.org. 1056 Disclaimer of Validity 1058 All IETF Documents and the information contained therein are provided 1059 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1060 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1061 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1062 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1063 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1064 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1065 FOR A PARTICULAR PURPOSE. 1067 Acknowledgment 1069 Funding for the RFC Editor function is currently provided by the 1070 Internet Society.