idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2010) is 5163 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) -- Missing reference section? 'RFC2119' on line 871 looks like a reference -- Missing reference section? 'WSON-Encode' on line 924 looks like a reference -- Missing reference section? 'RFC3471' on line 877 looks like a reference -- Missing reference section? 'RFC2863' on line 874 looks like a reference -- Missing reference section? 'RFC4202' on line 884 looks like a reference -- Missing reference section? 'RFC4203' on line 888 looks like a reference -- Missing reference section? 'RFC5307' on line 905 looks like a reference -- Missing reference section? 'PCEP' on line 929 looks like a reference -- Missing reference section? 'WSON-Info' on line 919 looks like a reference -- Missing reference section? 'Switch' on line 909 looks like a reference -- Missing reference section? 'G.694.1' on line 894 looks like a reference -- Missing reference section? 'G.694.2' on line 897 looks like a reference -- Missing reference section? 'Otani' on line 900 looks like a reference -- Missing reference section? 'WSON-Frame' on line 914 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 16 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: September 2010 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 March 2, 2010 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-01.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 September 2, 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 such as 59 asymmetric switch connectivity, label limitation and label 60 availability 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. 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. Extension Encoding Usage Recommendations.......................4 79 2.1. Extension Node TLV........................................4 80 2.2. Extension Link TLV........................................4 81 2.3. Extension Dynamic Link TLV................................4 82 3. Link Set Field.................................................4 83 4. Label Set Field................................................6 84 4.1. Inclusive/Exclusive Label Lists...........................7 85 4.2. Inclusive/Exclusive Label Ranges..........................8 86 4.3. Bitmap Label Set..........................................8 88 5. Label and Connectivity sub-TLV Encodings.......................9 89 5.1. Available Labels Sub-TLV..................................9 90 5.2. Shared Backup Labels Sub-TLV.............................10 91 5.3. Connectivity Matrix Sub-TLV..............................10 92 5.4. Port Label Restriction sub-TLV...........................12 93 5.4.1. SIMPLE_LABEL........................................13 94 5.4.2. CHANNEL_COUNT.......................................13 95 5.4.3. LABEL_RANGE1........................................13 96 5.4.4. SIMPLE_LABEL & CHANNEL_COUNT........................14 97 6. Security Considerations.......................................14 98 7. IANA Considerations...........................................15 99 8. 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 9. References....................................................23 106 9.1. Normative References.....................................23 107 9.2. Informative References...................................23 108 10. 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. Extension Encoding Usage Recommendations 137 In this section we give recommendations of typical usage of the sub- 138 TLVs and composite TLVs. 140 2.1. Extension Node TLV 142 The Extension Node TLV could consist of the following list of sub- 143 TLVs: 145 ::= [Other GMPLS sub- 146 TLVs][...] 148 2.2. Extension Link TLV 150 The new link related sub-TLVs could be incorporated into a composite 151 link TLV as follows: 153 ::= [Other GMPLS sub-TLVs] 154 [...][] [] 156 2.3. Extension Dynamic Link TLV 158 If the protocol supports the separation of dynamic information from 159 relatively static information then the available wavelength and 160 shared backup status can be separated from the general link TLV into 161 a TLV for dynamic link information. 163 ::= 164 [] 166 3. Link Set Field 168 We will frequently need to describe properties of groups of links. To 169 do so efficiently we can make use of a link set concept similar to 170 the label set concept of [RFC3471]. This Link Set Field is used in 171 the sub-TLV, which is defined in Section 6.3. 172 The information carried in a Link Set is defined by: 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Action |Dir| Format | Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Link Identifier 1 | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 : : : 182 : : : 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Link Identifier N | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Action: 8 bits 189 0 - Inclusive List 191 Indicates that one or more link identifiers are included in the Link 192 Set. Each identifies a separate link that is part of the set. 194 1 - Inclusive Range 196 Indicates that the Link Set defines a range of links. It contains 197 two link identifiers. The first identifier indicates the start of the 198 range (inclusive). The second identifier indicates the end of the 199 range (inclusive). All links with numeric values between the bounds 200 are considered to be part of the set. A value of zero in either 201 position indicates that there is no bound on the corresponding 202 portion of the range. Note that the Action field can be set to 203 0x02(Inclusive Range) only when unnumbered link identifier is used. 205 Dir: Directionality of the Link Set (2 bits) 207 0 -- bidirectional 208 1 -- ingress 210 2 -- egress 212 For example in optical networks we think in terms of unidirectional 213 as well as bidirectional links. For example, label restrictions or 214 connectivity may be different for an ingress port, than for its 215 "companion" egress port if one exists. Note that "interfaces" such as 216 those discussed in the Interfaces MIB [RFC2863] are assumed to be 217 bidirectional. This also applies to the links advertised in various 218 link state routing protocols. 220 Format: The format of the link identifier (6 bits) 222 0 -- Link Local Identifier 224 Indicates that the links in the Link Set are identified by link local 225 identifiers. All link local identifiers are supplied in the context 226 of the advertising node. 228 1 -- Local Interface IPv4 Address 230 2 -- Local Interface IPv6 Address 232 Indicates that the links in the Link Set are identified by Local 233 Interface IP Address. All Local Interface IP Address are supplied in 234 the context of the advertising node. 236 Others TBD. 238 Note that all link identifiers in the same list must be of the same 239 type. 241 Length: 16 bits 243 This field indicates the total length in bytes of the Link Set field. 245 Link Identifier: length is dependent on the link format 247 The link identifier represents the port which is being described 248 either for connectivity or label restrictions. This can be the link 249 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 250 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link local 251 identifier format can result in more compact encodings when the 252 assignments are done in a reasonable fashion. 254 4. Label Set Field 256 Label Set Field is used within the sub-TLV or the 257 sub-TLV, which is defined in Section 6.1 and 258 6.2, respectively. 260 The general format for a label set is given below. This format uses 261 the Action concept from [RFC3471] with an additional Action to define 262 a "bit map" type of label set. The second 32 bit field is a base 263 label used as a starting point in many of the specific formats. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Action| Num Labels | Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Base Label | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Additional fields as necessary per action | 273 | 275 Action: 277 0 - Inclusive List 279 1 - Exclusive List 281 2 - Inclusive Range 283 3 - Exclusive Range 285 4 - Bitmap Set 287 Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 288 indicates the number of labels represented by the bit map. See more 289 detail in section 3.2.3. 291 Length is the length in bytes of the entire field. 293 4.1. Inclusive/Exclusive Label Lists 295 In the case of the inclusive/exclusive lists the wavelength set 296 format is given by: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |0 or 1 | Num Labels (not used) | Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Base Label | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 : : 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Last Label | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Where: 312 Num Labels is not used in this particular format since the Length 313 parameter is sufficient to determine the number of labels in the 314 list. 316 4.2. Inclusive/Exclusive Label Ranges 318 In the case of inclusive/exclusive ranges the label set format is 319 given by: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 |2 or 3 | Num Labels(not used) | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Start Label | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | End Label | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Note that the start and end label must in some sense "compatible" in 332 the technology being used. 334 4.3. Bitmap Label Set 336 In the case of Action = 4, the bitmap the label set format is given 337 by: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | 4 | Num Labels | Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Base Label | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Bit Map Word #1 (Lowest numerical labels) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 : : 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Bit Map Word #N (Highest numerical labels) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Where Num Labels in this case tells us the number of labels 354 represented by the bit map. Each bit in the bit map represents a 355 particular label with a value of 1/0 indicating whether the label is 356 in the set or not. Bit position zero represents the lowest label and 357 corresponds to the base label, while each succeeding bit position 358 represents the next label logically above the previous. 360 The size of the bit map is Num Label bits, but the bit map is padded 361 out to a full multiple of 32 bits so that the TLV is a multiple of 362 four bytes. Bits that do not represent labels (i.e., those in 363 positions (Num Labels) and beyond SHOULD be set to zero and MUST be 364 ignored. 366 5. Label and Connectivity sub-TLV Encodings 368 A type-length-value (TLV) encoding of the general connectivity and 369 label restrictions and availability extensions is given in the 370 following sections. This encoding is designed to be suitable for use 371 in the GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and 372 in the PCE protocol PCEP [PCEP]. Note that the information 373 distributed in [RFC4203] and [RFC5307] is arranged via the nesting of 374 sub-TLVs within TLVs and this document makes use of such constructs. 376 5.1. Available Labels Sub-TLV 378 To indicate the labels available for use on a link the Available 379 Labels sub-TLV consists of a single variable length label set field 380 as follows: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Label Set Field | 386 : : 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Note that Label Set Field is defined in Section 3.2. 391 5.2. Shared Backup Labels Sub-TLV 393 To indicate the labels available for shared backup use on a link the 394 Shared Backup Labels sub-TLV consists of a single variable length 395 label set field as follows: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Label Set Field | 401 : : 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 5.3. Connectivity Matrix Sub-TLV 406 The switch and fixed connectivity matrices of [WSON-Info] can be 407 compactly represented in terms of a minimal list of ingress and 408 egress port set pairs that have mutual connectivity. As described in 409 [Switch] such a minimal list representation leads naturally to a 410 graph representation for path computation purposes that involves the 411 fewest additional nodes and links. 413 A TLV encoding of this list of link set pairs is: 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Connectivity | MatrixID | Reserved | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Link Set A #1 | 421 : : : 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Link Set B #1 : 424 : : : 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Additional Link set pairs as needed | 427 : to specify connectivity : 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Where 432 Connectivity is the device type. 434 0 -- the device is fixed 436 1 -- the device is switched(e.g., ROADM/OXC) 438 MatrixID represents the ID of the connectivity matrix and is an 8 bit 439 integer. The value of 0xFF is reserved for use with port wavelength 440 constraints and should not be used to identify a connectivity matrix. 442 Link Set A #1 and Link Set B #1 together represent a pair of link 443 sets. There are two permitted combinations for the link set field 444 parameter "dir" for Link Set A and B pairs: 446 o Link Set A dir=ingress, Link Set B dir=egress 448 The meaning of the pair of link sets A and B in this case is that 449 any signal that ingresses a link in set A can be potentially 450 switched out of an egress link in set B. 452 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 454 The meaning of the pair of link sets A and B in this case is that 455 any signal that ingresses on the links in set A can potentially 456 egress on a link in set B, and any ingress signal on the links in 457 set B can potentially egress on a link in set A. 459 See Appendix A for both types of encodings as applied to a WSON 460 example. 462 5.4. Port Label Restriction sub-TLV 464 The port label restriction of [WSON-Info] can be encoded as a sub-TLV 465 as follows. More than one of these sub-TLVs may be needed to fully 466 specify a complex port constraint. When more than one of these sub- 467 TLVs are present the resulting restriction is the intersection of the 468 restrictions expressed in each sub-TLV. To indicate that a 469 restriction applies to the port in general and not to a specific 470 connectivity matrix use the reserved value of 0xFF for the MatrixID. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | MatrixID | RestrictionType | Reserved/Parameter | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Additional Restriction Parameters per RestrictionType | 478 : : 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Where: 483 MatrixID: either is the value in the corresponding Connectivity 484 Matrix sub-TLV or takes the value OxFF to indicate the restriction 485 applies to the port regardless of any Connectivity Matrix. 487 RestrictionType can take the following values and meanings: 489 0: SIMPLE_LABEL (Simple label selective restriction) 491 1: CHANNEL_COUNT (Channel count restriction) 493 2: LABEL_RANGE1 (Label range device with a movable center label 494 and width) 496 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 497 and CHANNEL_COUNT restriction. The accompanying label set and 498 channel count indicate labels permitted on the port and the 499 maximum number of channels that can be simultaneously used on 500 the port) 502 5.4.1. SIMPLE_LABEL 504 In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or 505 MatrixSpecificRestrictions) format is given by: 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | MatrixID | RstType = 0 | Reserved | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Label Set Field | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 In this case the accompanying label set indicates the labels 516 permitted on the port. 518 5.4.2. CHANNEL_COUNT 520 In the case of the CHANNEL_COUNT the format is given by: 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | MatrixID | RstType = 1 | MaxNumChannels | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 In this case the accompanying MaxNumChannels indicates the maximum 529 number of channels (labels) that can be simultaneously used on the 530 port/matrix. 532 5.4.3. LABEL_RANGE1 534 In the case of the LABEL_RANGE1 the GeneralPortRestrictions (or 535 MatrixSpecificRestrictions) format is given by: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | MatrixID | RstType = 2 | MaxLabelRange | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Label Set Field | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 In this case the accompanying MaxLabelRange indicates the maximum 546 range of the labels. The corresponding label set is used to indicate 547 the overall label range. Specific center label information can be 548 obtained from dynamic label in use information. It is assumed that 549 both center label and range tuning can be done without causing faults 550 to existing signals. 552 5.4.4. SIMPLE_LABEL & CHANNEL_COUNT 554 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 555 by: 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | MatrixInfo | RstType = 3 | MaxNumChannels | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Label Set Field | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 In this case the accompanying label set and MaxNumChannels indicate 566 labels permitted on the port and the maximum number of labels that 567 can be simultaneously used on the port. 569 6. Security Considerations 571 This document defines protocol-independent encodings for WSON 572 information and does not introduce any security issues. 574 However, other documents that make use of these encodings within 575 protocol extensions need to consider the issues and risks associated 576 with, inspection, interception, modification, or spoofing of any of 577 this information. It is expected that any such documents will 578 describe the necessary security measures to provide adequate 579 protection. 581 7. IANA Considerations 583 TBD. Once our approach is finalized we may need identifiers for the 584 various TLVs and sub-TLVs. 586 8. Acknowledgments 588 This document was prepared using 2-Word-v2.0.template.dot. 590 APPENDIX A: Encoding Examples 592 Here we give examples of the general encoding extensions applied to 593 some simple WSON network elements and links. 595 A.1. Link Set Field 597 Suppose that we wish to describe a set of ingress ports that are have 598 link local identifiers number 3 through 42. In the link set field we 599 set the Action = 1 to denote an inclusive range; the Dir = 1 to 600 denote ingress links; and, the Format = 0 to denote link local 601 identifiers. In particular we have: 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Link Local Identifier = #3 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Link Local Identifier = #42 | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 A.2. Label Set Field 613 Example: 615 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 616 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 617 (1530.3nm). These frequencies correspond to n = -11, and n = 28 618 respectively. Now suppose the following channels are available: 620 Frequency (THz) n Value bit map position 621 -------------------------------------------------- 622 192.0 -11 0 623 192.5 -6 5 624 193.1 0 11 625 193.9 8 19 626 194.0 9 20 627 195.2 21 32 628 195.8 27 38 630 With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. 631 set to indicate 100GHz this lambda bit map set would then be encoded 632 as follows: 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | 4 | Num Wavelengths = 40 | Length = 16 bytes | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |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| 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 To encode this same set as an inclusive list we would have: 648 0 1 2 3 649 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | 0 | Num Wavelengths = 40 | Length = 20 bytes | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 A.3. Connectivity Matrix Sub-TLV 670 Example: 672 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 673 its two line side ports it has 80 add and 80 drop ports. The picture 674 below illustrates how a typical 2-degree ROADM system that works with 675 bi-directional fiber pairs is a highly asymmetrical system composed 676 of two unidirectional ROADM subsystems. 678 (Tributary) Ports #3-#42 679 Ingress added to Egress dropped from 680 West Line Egress East Line Ingress 681 vvvvv ^^^^^ 682 | |||.| | |||.| 683 +-----| |||.|--------| |||.|------+ 684 | +----------------------+ | 685 | | | | 686 Egress | | Unidirectional ROADM | | Ingress 687 -----------------+ | | +-------------- 688 <=====================| |===================< 689 -----------------+ +----------------------+ +-------------- 690 | | 691 Port #1 | | Port #2 692 (West Line Side) | |(East Line Side) 693 -----------------+ +----------------------+ +-------------- 694 >=====================| |===================> 695 -----------------+ | Unidirectional ROADM | +-------------- 696 Ingress | | | | Egress 697 | | _ | | 698 | +----------------------+ | 699 +-----| |||.|--------| |||.|------+ 700 | |||.| | |||.| 701 vvvvv ^^^^^ 702 (Tributary) Ports #43-#82 703 Egress dropped from Ingress added to 704 West Line ingress East Line egress 706 Referring to the figure we see that the ingress direction of ports 707 #3-#42 (add ports) can only connect to the egress on port #1. While 708 the ingress side of port #2 (line side) can only connect to the 709 egress on ports #3-#42 (drop) and to the egress on port #1 (pass 710 through). Similarly, the ingress direction of ports #43-#82 can only 711 connect to the egress on port #2 (line). While the ingress direction 712 of port #1 can only connect to the egress on ports #43-#82 (drop) or 713 port #2 (pass through). We can now represent this potential 714 connectivity matrix as follows. This representation uses only 30 32- 715 bit words. 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Conn = 1 | MatrixID | Reserved |1 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Note: adds to line 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |2 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Link Local Identifier = #3 |3 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Link Local Identifier = #42 |4 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |5 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Link Local Identifier = #1 |6 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 Note: line to drops 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |7 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Link Local Identifier = #2 |8 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |9 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Link Local Identifier = #3 |10 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Link Local Identifier = #42 |11 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Note: line to line 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |12 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Link Local Identifier = #2 |13 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |14 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Link Local Identifier = #1 |15 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Note: adds to line 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |16 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Link Local Identifier = #43 |17 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Link Local Identifier = #82 |18 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |19 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Link Local Identifier = #2 |20 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Note: line to drops 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 |21 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Link Local Identifier = #1 |22 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |23 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Link Local Identifier = #43 |24 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Link Local Identifier = #82 |25 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Note: line to line 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |26 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Link Local Identifier = #1 |27 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |28 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Link Local Identifier = #2 |30 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 A.4. Connectivity Matrix with Bi-directional Symmetry 793 If one has the ability to renumber the ports of the previous example 794 as shown in the next figure then we can take advantage of the bi- 795 directional symmetry and use bi-directional encoding of the 796 connectivity matrix. Note that we set dir=bidirectional in the link 797 set fields. 799 (Tributary) 800 Ports #3-42 Ports #43-82 801 West Line Egress East Line Ingress 802 vvvvv ^^^^^ 803 | |||.| | |||.| 804 +-----| |||.|--------| |||.|------+ 805 | +----------------------+ | 806 | | | | 807 Egress | | Unidirectional ROADM | | Ingress 808 -----------------+ | | +-------------- 809 <=====================| |===================< 810 -----------------+ +----------------------+ +-------------- 811 | | 812 Port #1 | | Port #2 813 (West Line Side) | |(East Line Side) 814 -----------------+ +----------------------+ +-------------- 815 >=====================| |===================> 816 -----------------+ | Unidirectional ROADM | +-------------- 817 Ingress | | | | Egress 818 | | _ | | 819 | +----------------------+ | 820 +-----| |||.|--------| |||.|------+ 821 | |||.| | |||.| 822 vvvvv ^^^^^ 823 Ports #3-#42 Ports #43-82 824 Egress dropped from Ingress added to 825 West Line ingress East Line egress 827 0 1 2 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Conn = 1 | MatrixID | Reserved |1 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Add/Drops #3-42 to Line side #1 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |2 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Link Local Identifier = #3 |3 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Link Local Identifier = #42 |4 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |5 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Link Local Identifier = #1 |6 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 Note: line #2 to add/drops #43-82 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |7 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Link Local Identifier = #2 |8 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |9 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Link Local Identifier = #43 |10 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Link Local Identifier = #82 |11 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Note: line to line 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |12 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Link Local Identifier = #1 |13 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |14 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Link Local Identifier = #2 |15 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 9. References 869 9.1. Normative References 871 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 872 Requirement Levels", BCP 14, RFC 2119, March 1997. 874 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 875 MIB", RFC 2863, June 2000. 877 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 878 (GMPLS) Signaling Functional Description", RFC 3471, 879 January 2003. 881 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 882 applications: DWDM frequency grid", June, 2002. 884 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 885 in Support of Generalized Multi-Protocol Label Switching 886 (GMPLS)", RFC 4202, October 2005 888 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 889 Support of Generalized Multi-Protocol Label Switching 890 (GMPLS)", RFC 4203, October 2005. 892 9.2. Informative References 894 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 895 applications: DWDM frequency grid, June 2002. 897 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 898 applications: CWDM wavelength grid, December 2003. 900 [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 901 Labels for G.694 Lambda-Switching Capable Label Switching 902 Routers", work in progress: draft-ietf-ccamp-gmpls-g-694- 903 lambda-labels. 905 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 906 in Support of Generalized Multi-Protocol Label Switching 907 (GMPLS)", RFC 5307, October 2008. 909 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 910 WDM Wavelength Switching Systems for Use in GMPLS and Automated 911 Path Computation", Journal of Optical Communications and 912 Networking, vol. 1, June, 2009, pp. 187-195. 914 [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 915 and PCE Control of Wavelength Switched Optical Networks", 916 work in progress: draft-ietf-ccamp-wavelength-switched- 917 framework, February, 2010. 919 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 920 Wavelength Assignment Information Model for Wavelength 921 Switched Optical Networks", work in progress: draft-ietf- 922 ccamp-rwa-info, February, 2010. 924 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 925 Wavelength Assignment Information Encoding for Wavelength 926 Switched Optical Networks", work in progress: draft-ietf- 927 ccamp-rwa-wson-encode, Februsary, 2010. 929 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 930 Element (PCE) communication Protocol (PCEP) - Version 1", 931 RFC5440. 933 10. Contributors 935 Diego Caviglia 936 Ericsson 937 Via A. Negrone 1/A 16153 938 Genoa Italy 940 Phone: +39 010 600 3736 941 Email: diego.caviglia@(marconi.com, ericsson.com) 943 Anders Gavler 944 Acreo AB 945 Electrum 236 946 SE - 164 40 Kista Sweden 948 Email: Anders.Gavler@acreo.se 950 Jonas Martensson 951 Acreo AB 952 Electrum 236 953 SE - 164 40 Kista, Sweden 955 Email: Jonas.Martensson@acreo.se 957 Itaru Nishioka 958 NEC Corp. 959 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 960 Japan 962 Phone: +81 44 396 3287 963 Email: i-nishioka@cb.jp.nec.com 965 Authors' Addresses 967 Greg M. Bernstein (ed.) 968 Grotto Networking 969 Fremont California, USA 971 Phone: (510) 573-2237 972 Email: gregb@grotto-networking.com 973 Young Lee (ed.) 974 Huawei Technologies 975 1700 Alma Drive, Suite 100 976 Plano, TX 75075 977 USA 979 Phone: (972) 509-5599 (x2240) 980 Email: ylee@huawei.com 982 Dan Li 983 Huawei Technologies Co., Ltd. 984 F3-5-B R&D Center, Huawei Base, 985 Bantian, Longgang District 986 Shenzhen 518129 P.R.China 988 Phone: +86-755-28973237 989 Email: danli@huawei.com 991 Wataru Imajuku 992 NTT Network Innovation Labs 993 1-1 Hikari-no-oka, Yokosuka, Kanagawa 994 Japan 996 Phone: +81-(46) 859-4315 997 Email: imajuku.wataru@lab.ntt.co.jp 999 Jianrui Han 1000 Huawei Technologies Co., Ltd. 1001 F3-5-B R&D Center, Huawei Base, 1002 Bantian, Longgang District 1003 Shenzhen 518129 P.R.China 1005 Phone: +86-755-28972916 1006 Email: hanjianrui@huawei.com 1008 Intellectual Property Statement 1010 The IETF Trust takes no position regarding the validity or scope of 1011 any Intellectual Property Rights or other rights that might be 1012 claimed to pertain to the implementation or use of the technology 1013 described in any IETF Document or the extent to which any license 1014 under such rights might or might not be available; nor does it 1015 represent that it has made any independent effort to identify any 1016 such rights. 1018 Copies of Intellectual Property disclosures made to the IETF 1019 Secretariat and any assurances of licenses to be made available, or 1020 the result of an attempt made to obtain a general license or 1021 permission for the use of such proprietary rights by implementers or 1022 users of this specification can be obtained from the IETF on-line IPR 1023 repository at http://www.ietf.org/ipr 1025 The IETF invites any interested party to bring to its attention any 1026 copyrights, patents or patent applications, or other proprietary 1027 rights that may cover technology that may be required to implement 1028 any standard or specification contained in an IETF Document. Please 1029 address the information to the IETF at ietf-ipr@ietf.org. 1031 Disclaimer of Validity 1033 All IETF Documents and the information contained therein are provided 1034 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1035 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1036 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1037 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1038 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1039 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1040 FOR A PARTICULAR PURPOSE. 1042 Acknowledgment 1044 Funding for the RFC Editor function is currently provided by the 1045 Internet Society.