idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-02.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: ' 4. 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: ' 5. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2010) is 5063 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 957 looks like a reference -- Missing reference section? 'Switch' on line 995 looks like a reference -- Missing reference section? 'RFC4203' on line 974 looks like a reference -- Missing reference section? 'RFC5307' on line 991 looks like a reference -- Missing reference section? 'PCEP' on line 1015 looks like a reference -- Missing reference section? 'RFC3471' on line 963 looks like a reference -- Missing reference section? 'RFC2863' on line 960 looks like a reference -- Missing reference section? 'RFC4202' on line 970 looks like a reference -- Missing reference section? 'WSON-Info' on line 1005 looks like a reference -- Missing reference section? 'G.694.1' on line 980 looks like a reference -- Missing reference section? 'G.694.2' on line 983 looks like a reference -- Missing reference section? 'Otani' on line 986 looks like a reference -- Missing reference section? 'WSON-Frame' on line 1000 looks like a reference -- Missing reference section? 'WSON-Encode' on line 1010 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: December 2010 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 June 9, 2010 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-02.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 December 9, 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, 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......................4 78 1.2. Non-Local Label Assignment Constraints....................4 79 2. Extension Encoding Usage Recommendations.......................5 80 2.1. Extension Node TLV........................................6 81 2.2. Extension Link TLV........................................6 82 2.3. Extension Dynamic Link TLV................................6 83 3. Encoding.......................................................6 84 3.1. Link Set Field............................................6 85 3.2. Label Set Field...........................................8 86 3.2.1. Inclusive/Exclusive Label Lists......................9 87 3.2.2. Inclusive/Exclusive Label Ranges....................10 88 3.2.3. Bitmap Label Set....................................10 89 3.3. Available Labels Sub-TLV.................................11 90 3.4. Shared Backup Labels Sub-TLV.............................12 91 3.5. Connectivity Matrix Sub-TLV..............................12 92 3.6. Port Label Restriction sub-TLV...........................13 93 3.6.1. SIMPLE_LABEL........................................14 94 3.6.2. CHANNEL_COUNT.......................................15 95 3.6.3. LABEL_RANGE1........................................15 96 3.6.4. SIMPLE_LABEL & CHANNEL_COUNT........................15 97 4. Security Considerations.......................................16 98 5. IANA Considerations...........................................16 99 6. Acknowledgments...............................................16 100 APPENDIX A: Encoding Examples....................................17 101 A.1. Link Set Field...........................................17 102 A.2. Label Set Field..........................................17 103 A.3. Connectivity Matrix Sub-TLV..............................18 104 A.4. Connectivity Matrix with Bi-directional Symmetry.........21 105 7. References....................................................24 106 7.1. Normative References.....................................24 107 7.2. Informative References...................................24 108 8. Contributors..................................................26 109 Authors' Addresses...............................................26 110 Intellectual Property Statement..................................27 111 Disclaimer of Validity...........................................28 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 and are potentially applicable to a wider range of technologies. Such 126 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 1.1. Node Switching Asymmetry Constraints 133 For some network elements the ability of a signal or packet on a 134 particular ingress port to reach a particular egress port may be 135 limited. In addition, in some network elements the connectivity 136 between some ingress ports and egress ports may be fixed, e.g., a 137 simple multiplexer. To take into account such constraints during path 138 computation we model this aspect of a network element via a 139 connectivity matrix. 141 The connectivity matrix (ConnectivityMatrix) represents either the 142 potential connectivity matrix for asymmetric switches or fixed 143 connectivity for an asymmetric device such as a multiplexer. Note 144 that this matrix does not represent any particular internal blocking 145 behavior but indicates which ingress ports and labels (e.g., 146 wavelengths) could possibly be connected to a particular output port. 147 Representing internal state dependent blocking for a node is beyond 148 the scope of this document and due to it's highly implementation 149 dependent nature would most likely not be subject to standardization 150 in the future. The connectivity matrix is a conceptual M by N matrix 151 representing the potential switched or fixed connectivity, where M 152 represents the number of ingress ports and N the number of egress 153 ports. 155 ConnectivityMatrix(i, j) ::= 157 Where 159 is a unique identifier for the matrix. 161 can be either 0 or 1 depending upon whether the 162 connectivity is either fixed or potentially switched. 164 represents the fixed or switched connectivity in that 165 Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect 166 to egress port j for one or more labels. 168 1.2. Non-Local Label Assignment Constraints 170 If the nature of the equipment involved in a network results in a 171 requirement for non-local label assignment we can have constraints 172 based on limits imposed by the ports themselves and those that are 173 implied by the current label usage. Note that constraints such as 174 these only become important when label assignment has a non-local 175 character. For example in MPLS an LSR may have a limited range of 176 labels available for use on an egress port and a set of labels 177 already in use on that port and hence unavailable for use. This 178 information, however, does not need to be shared unless there is some 179 limitation on the LSR's label swapping ability. For example if a TDM 180 node lacks the ability to perform time-slot interchange or a WSON 181 lacks the ability to perform wavelength conversion then the label 182 assignment process is not local to a single node and it may be 183 advantageous to share the label assignment constraint information for 184 use in path computation. 186 Port label restrictions (PortLabelRestriction) model the label 187 restrictions that the network element (node) and link may impose on a 188 port. These restrictions tell us what labels may or may not be used 189 on a link and are intended to be relatively static. More dynamic 190 information is contained in the information on available labels. Port 191 label restrictions are specified relative to the port in general or 192 to a specific connectivity matrix for increased modeling flexibility. 193 Reference [Switch] gives an example where both switch and fixed 194 connectivity matrices are used and both types of constraints occur on 195 the same port. 197 ::= [...] 198 [...] 200 ::= 201 [] 203 ::= 204 [] 206 Where 208 MatrixID is the ID of the corresponding connectivity matrix 210 The RestrictionType parameter is used to specify general port 211 restrictions and matrix specific restrictions. 213 2. Extension Encoding Usage Recommendations 215 In this section we give recommendations of typical usage of the sub- 216 TLVs and composite TLVs. 218 2.1. Extension Node TLV 220 The Extension Node TLV could consist of the following list of sub- 221 TLVs: 223 ::= [Other GMPLS sub-TLVs] 224 [...] 226 2.2. Extension Link TLV 228 The new link related sub-TLVs could be incorporated into a composite 229 link TLV as follows: 231 ::= [Other GMPLS sub-TLVs] 232 [...][] [] 234 2.3. Extension Dynamic Link TLV 236 If the protocol supports the separation of dynamic information from 237 relatively static information then the available wavelength and 238 shared backup status can be separated from the general link TLV into 239 a TLV for dynamic link information. 241 ::= 242 [] 244 3. Encoding 246 A type-length-value (TLV) encoding of the general connectivity and 247 label restrictions and availability extensions is given in this 248 section. This encoding is designed to be suitable for use in the 249 GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in the 250 PCE protocol PCEP [PCEP]. Note that the information distributed in 251 [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs 252 within TLVs and this document makes use of such constructs. First, 253 however we define two general purpose fields that will be used 254 repeatedly in the subsequent TLVs. 256 3.1. Link Set Field 258 We will frequently need to describe properties of groups of links. To 259 do so efficiently we can make use of a link set concept similar to 260 the label set concept of [RFC3471]. This Link Set Field is used in 261 the sub-TLV, which is defined in Section 6.3. 262 The information carried in a Link Set is defined by: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Action |Dir| Format | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Link Identifier 1 | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 : : : 272 : : : 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Link Identifier N | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Action: 8 bits 279 0 - Inclusive List 281 Indicates that one or more link identifiers are included in the Link 282 Set. Each identifies a separate link that is part of the set. 284 1 - Inclusive Range 286 Indicates that the Link Set defines a range of links. It contains 287 two link identifiers. The first identifier indicates the start of the 288 range (inclusive). The second identifier indicates the end of the 289 range (inclusive). All links with numeric values between the bounds 290 are considered to be part of the set. A value of zero in either 291 position indicates that there is no bound on the corresponding 292 portion of the range. Note that the Action field can be set to 293 0x02(Inclusive Range) only when unnumbered link identifier is used. 295 Dir: Directionality of the Link Set (2 bits) 297 0 -- bidirectional 298 1 -- ingress 300 2 -- egress 302 For example in optical networks we think in terms of unidirectional 303 as well as bidirectional links. For example, label restrictions or 304 connectivity may be different for an ingress port, than for its 305 "companion" egress port if one exists. Note that "interfaces" such as 306 those discussed in the Interfaces MIB [RFC2863] are assumed to be 307 bidirectional. This also applies to the links advertised in various 308 link state routing protocols. 310 Format: The format of the link identifier (6 bits) 312 0 -- Link Local Identifier 314 Indicates that the links in the Link Set are identified by link local 315 identifiers. All link local identifiers are supplied in the context 316 of the advertising node. 318 1 -- Local Interface IPv4 Address 320 2 -- Local Interface IPv6 Address 322 Indicates that the links in the Link Set are identified by Local 323 Interface IP Address. All Local Interface IP Address are supplied in 324 the context of the advertising node. 326 Others TBD. 328 Note that all link identifiers in the same list must be of the same 329 type. 331 Length: 16 bits 333 This field indicates the total length in bytes of the Link Set field. 335 Link Identifier: length is dependent on the link format 337 The link identifier represents the port which is being described 338 either for connectivity or label restrictions. This can be the link 339 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 340 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link local 341 identifier format can result in more compact encodings when the 342 assignments are done in a reasonable fashion. 344 3.2. Label Set Field 346 Label Set Field is used within the sub-TLV or the 347 sub-TLV, which is defined in Section 6.1 and 348 6.2, respectively. 350 The general format for a label set is given below. This format uses 351 the Action concept from [RFC3471] with an additional Action to define 352 a "bit map" type of label set. The second 32 bit field is a base 353 label used as a starting point in many of the specific formats. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Action| Num Labels | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Base Label | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Additional fields as necessary per action | 363 | 365 Action: 367 0 - Inclusive List 369 1 - Exclusive List 371 2 - Inclusive Range 373 3 - Exclusive Range 375 4 - Bitmap Set 377 Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 378 indicates the number of labels represented by the bit map. See more 379 detail in section 3.2.3. 381 Length is the length in bytes of the entire field. 383 3.2.1. Inclusive/Exclusive Label Lists 385 In the case of the inclusive/exclusive lists the wavelength set 386 format is given by: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |0 or 1 | Num Labels (not used) | Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Base Label | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 : : 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Last Label | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Where: 402 Num Labels is not used in this particular format since the Length 403 parameter is sufficient to determine the number of labels in the 404 list. 406 3.2.2. Inclusive/Exclusive Label Ranges 408 In the case of inclusive/exclusive ranges the label set format is 409 given by: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |2 or 3 | Num Labels(not used) | Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Start Label | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | End Label | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Note that the start and end label must in some sense "compatible" in 422 the technology being used. 424 3.2.3. Bitmap Label Set 426 In the case of Action = 4, the bitmap the label set format is given 427 by: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | 4 | Num Labels | Length | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Base Label | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Bit Map Word #1 (Lowest numerical labels) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 : : 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Bit Map Word #N (Highest numerical labels) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Where Num Labels in this case tells us the number of labels 444 represented by the bit map. Each bit in the bit map represents a 445 particular label with a value of 1/0 indicating whether the label is 446 in the set or not. Bit position zero represents the lowest label and 447 corresponds to the base label, while each succeeding bit position 448 represents the next label logically above the previous. 450 The size of the bit map is Num Label bits, but the bit map is padded 451 out to a full multiple of 32 bits so that the TLV is a multiple of 452 four bytes. Bits that do not represent labels (i.e., those in 453 positions (Num Labels) and beyond SHOULD be set to zero and MUST be 454 ignored. 456 3.3. Available Labels Sub-TLV 458 To indicate the labels available for use on a link the Available 459 Labels sub-TLV consists of a single variable length label set field 460 as follows: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Label Set Field | 466 : : 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Note that Label Set Field is defined in Section 3.2. 471 3.4. Shared Backup Labels Sub-TLV 473 To indicate the labels available for shared backup use on a link the 474 Shared Backup Labels sub-TLV consists of a single variable length 475 label set field as follows: 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Label Set Field | 481 : : 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 3.5. Connectivity Matrix Sub-TLV 486 Connectivity Matrix represents how ingress ports are connected to 487 egress ports for network elements. 489 The switch and fixed connectivity matrices of [WSON-Info] can be 490 compactly represented in terms of a minimal list of ingress and 491 egress port set pairs that have mutual connectivity. As described in 492 [Switch] such a minimal list representation leads naturally to a 493 graph representation for path computation purposes that involves the 494 fewest additional nodes and links. 496 A TLV encoding of this list of link set pairs is: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Connectivity | MatrixID | Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Link Set A #1 | 504 : : : 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Link Set B #1 : 507 : : : 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Additional Link set pairs as needed | 510 : to specify connectivity : 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Where 515 Connectivity is the device type. 517 0 -- the device is fixed 519 1 -- the device is switched(e.g., ROADM/OXC) 521 MatrixID represents the ID of the connectivity matrix and is an 8 bit 522 integer. The value of 0xFF is reserved for use with port wavelength 523 constraints and should not be used to identify a connectivity matrix. 525 Link Set A #1 and Link Set B #1 together represent a pair of link 526 sets. There are two permitted combinations for the link set field 527 parameter "dir" for Link Set A and B pairs: 529 o Link Set A dir=ingress, Link Set B dir=egress 531 The meaning of the pair of link sets A and B in this case is that 532 any signal that ingresses a link in set A can be potentially 533 switched out of an egress link in set B. 535 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 537 The meaning of the pair of link sets A and B in this case is that 538 any signal that ingresses on the links in set A can potentially 539 egress on a link in set B, and any ingress signal on the links in 540 set B can potentially egress on a link in set A. 542 See Appendix A for both types of encodings as applied to a ROADM 543 example. 545 3.6. Port Label Restriction sub-TLV 547 Port Label Restriction tells us what labels may or may not be used on 548 a link. 550 The port label restriction of [WSON-Info] can be encoded as a sub-TLV 551 as follows. More than one of these sub-TLVs may be needed to fully 552 specify a complex port constraint. When more than one of these sub- 553 TLVs are present the resulting restriction is the intersection of the 554 restrictions expressed in each sub-TLV. To indicate that a 555 restriction applies to the port in general and not to a specific 556 connectivity matrix use the reserved value of 0xFF for the MatrixID. 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 | RestrictionType | Reserved/Parameter | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Additional Restriction Parameters per RestrictionType | 564 : : 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Where: 569 MatrixID: either is the value in the corresponding Connectivity 570 Matrix sub-TLV or takes the value OxFF to indicate the restriction 571 applies to the port regardless of any Connectivity Matrix. 573 RestrictionType can take the following values and meanings: 575 0: SIMPLE_LABEL (Simple label selective restriction) 577 1: CHANNEL_COUNT (Channel count restriction) 579 2: LABEL_RANGE1 (Label range device with a movable center label 580 and width) 582 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 583 and CHANNEL_COUNT restriction. The accompanying label set and 584 channel count indicate labels permitted on the port and the 585 maximum number of channels that can be simultaneously used on 586 the port) 588 3.6.1. SIMPLE_LABEL 590 In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or 591 MatrixSpecificRestrictions) format is given 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 = 0 | Reserved | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Label Set Field | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 In this case the accompanying label set indicates the labels 602 permitted on the port. 604 3.6.2. CHANNEL_COUNT 606 In the case of the CHANNEL_COUNT the format is given by: 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | MatrixID | RstType = 1 | MaxNumChannels | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 In this case the accompanying MaxNumChannels indicates the maximum 615 number of channels (labels) that can be simultaneously used on the 616 port/matrix. 618 3.6.3. LABEL_RANGE1 620 In the case of the LABEL_RANGE1 the GeneralPortRestrictions (or 621 MatrixSpecificRestrictions) format is given by: 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | MatrixID | RstType = 2 | MaxLabelRange | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Label Set Field | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 In this case the accompanying MaxLabelRange indicates the maximum 632 range of the labels. The corresponding label set is used to indicate 633 the overall label range. Specific center label information can be 634 obtained from dynamic label in use information. It is assumed that 635 both center label and range tuning can be done without causing faults 636 to existing signals. 638 3.6.4. SIMPLE_LABEL & CHANNEL_COUNT 640 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 641 by: 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | MatrixInfo | RstType = 3 | MaxNumChannels | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Label Set Field | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 In this case the accompanying label set and MaxNumChannels indicate 652 labels permitted on the port and the maximum number of labels that 653 can be simultaneously used on the port. 655 4. Security Considerations 657 This document defines protocol-independent encodings for WSON 658 information and does not introduce any security issues. 660 However, other documents that make use of these encodings within 661 protocol extensions need to consider the issues and risks associated 662 with, inspection, interception, modification, or spoofing of any of 663 this information. It is expected that any such documents will 664 describe the necessary security measures to provide adequate 665 protection. 667 5. IANA Considerations 669 TBD. Once our approach is finalized we may need identifiers for the 670 various TLVs and sub-TLVs. 672 6. Acknowledgments 674 This document was prepared using 2-Word-v2.0.template.dot. 676 APPENDIX A: Encoding Examples 678 Here we give examples of the general encoding extensions applied to 679 some simple ROADM network elements and links. 681 A.1. Link Set Field 683 Suppose that we wish to describe a set of ingress ports that are have 684 link local identifiers number 3 through 42. In the link set field we 685 set the Action = 1 to denote an inclusive range; the Dir = 1 to 686 denote ingress links; and, the Format = 0 to denote link local 687 identifiers. In particular we have: 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Link Local Identifier = #3 | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Link Local Identifier = #42 | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 A.2. Label Set Field 699 Example: 701 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 702 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 703 (1530.3nm). These frequencies correspond to n = -11, and n = 28 704 respectively. Now suppose the following channels are available: 706 Frequency (THz) n Value bit map position 707 -------------------------------------------------- 708 192.0 -11 0 709 192.5 -6 5 710 193.1 0 11 711 193.9 8 19 712 194.0 9 20 713 195.2 21 32 714 195.8 27 38 716 With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. 717 set to indicate 100GHz this lambda bit map set would then be encoded 718 as follows: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | 4 | Num Wavelengths = 40 | Length = 16 bytes | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 |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| 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 To encode this same set as an inclusive list we would have: 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | 0 | Num Wavelengths = 40 | Length = 20 bytes | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 A.3. Connectivity Matrix Sub-TLV 756 Example: 758 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 759 its two line side ports it has 80 add and 80 drop ports. The picture 760 below illustrates how a typical 2-degree ROADM system that works with 761 bi-directional fiber pairs is a highly asymmetrical system composed 762 of two unidirectional ROADM subsystems. 764 (Tributary) Ports #3-#42 765 Ingress added to Egress dropped from 766 West Line Egress East Line Ingress 767 vvvvv ^^^^^ 768 | |||.| | |||.| 769 +-----| |||.|--------| |||.|------+ 770 | +----------------------+ | 771 | | | | 772 Egress | | Unidirectional ROADM | | Ingress 773 -----------------+ | | +-------------- 774 <=====================| |===================< 775 -----------------+ +----------------------+ +-------------- 776 | | 777 Port #1 | | Port #2 778 (West Line Side) | |(East Line Side) 779 -----------------+ +----------------------+ +-------------- 780 >=====================| |===================> 781 -----------------+ | Unidirectional ROADM | +-------------- 782 Ingress | | | | Egress 783 | | _ | | 784 | +----------------------+ | 785 +-----| |||.|--------| |||.|------+ 786 | |||.| | |||.| 787 vvvvv ^^^^^ 788 (Tributary) Ports #43-#82 789 Egress dropped from Ingress added to 790 West Line ingress East Line egress 792 Referring to the figure we see that the ingress direction of ports 793 #3-#42 (add ports) can only connect to the egress on port #1. While 794 the ingress side of port #2 (line side) can only connect to the 795 egress on ports #3-#42 (drop) and to the egress on port #1 (pass 796 through). Similarly, the ingress direction of ports #43-#82 can only 797 connect to the egress on port #2 (line). While the ingress direction 798 of port #1 can only connect to the egress on ports #43-#82 (drop) or 799 port #2 (pass through). We can now represent this potential 800 connectivity matrix as follows. This representation uses only 30 32- 801 bit words. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Conn = 1 | MatrixID | Reserved |1 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Note: adds to line 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |2 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Link Local Identifier = #3 |3 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Link Local Identifier = #42 |4 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |5 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Link Local Identifier = #1 |6 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 Note: line to drops 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |7 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Link Local Identifier = #2 |8 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |9 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Link Local Identifier = #3 |10 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Link Local Identifier = #42 |11 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Note: line to line 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |12 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Link Local Identifier = #2 |13 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |14 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Link Local Identifier = #1 |15 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Note: adds to line 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |16 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Link Local Identifier = #43 |17 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Link Local Identifier = #82 |18 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |19 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Link Local Identifier = #2 |20 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 Note: line to drops 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 |21 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Link Local Identifier = #1 |22 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |23 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Link Local Identifier = #43 |24 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Link Local Identifier = #82 |25 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 Note: line to line 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |26 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Link Local Identifier = #1 |27 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |28 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Link Local Identifier = #2 |30 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 A.4. Connectivity Matrix with Bi-directional Symmetry 879 If one has the ability to renumber the ports of the previous example 880 as shown in the next figure then we can take advantage of the bi- 881 directional symmetry and use bi-directional encoding of the 882 connectivity matrix. Note that we set dir=bidirectional in the link 883 set fields. 885 (Tributary) 886 Ports #3-42 Ports #43-82 887 West Line Egress East Line Ingress 888 vvvvv ^^^^^ 889 | |||.| | |||.| 890 +-----| |||.|--------| |||.|------+ 891 | +----------------------+ | 892 | | | | 893 Egress | | Unidirectional ROADM | | Ingress 894 -----------------+ | | +-------------- 895 <=====================| |===================< 896 -----------------+ +----------------------+ +-------------- 897 | | 898 Port #1 | | Port #2 899 (West Line Side) | |(East Line Side) 900 -----------------+ +----------------------+ +-------------- 901 >=====================| |===================> 902 -----------------+ | Unidirectional ROADM | +-------------- 903 Ingress | | | | Egress 904 | | _ | | 905 | +----------------------+ | 906 +-----| |||.|--------| |||.|------+ 907 | |||.| | |||.| 908 vvvvv ^^^^^ 909 Ports #3-#42 Ports #43-82 910 Egress dropped from Ingress added to 911 West Line ingress East Line egress 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Conn = 1 | MatrixID | Reserved |1 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Add/Drops #3-42 to Line side #1 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |2 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Link Local Identifier = #3 |3 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Link Local Identifier = #42 |4 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |5 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Link Local Identifier = #1 |6 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Note: line #2 to add/drops #43-82 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |7 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Link Local Identifier = #2 |8 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |9 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Link Local Identifier = #43 |10 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Link Local Identifier = #82 |11 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Note: line to line 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |12 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Link Local Identifier = #1 |13 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |14 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Link Local Identifier = #2 |15 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 7. References 955 7.1. Normative References 957 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 958 Requirement Levels", BCP 14, RFC 2119, March 1997. 960 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 961 MIB", RFC 2863, June 2000. 963 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 964 (GMPLS) Signaling Functional Description", RFC 3471, 965 January 2003. 967 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 968 applications: DWDM frequency grid", June, 2002. 970 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 971 in Support of Generalized Multi-Protocol Label Switching 972 (GMPLS)", RFC 4202, October 2005 974 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 975 Support of Generalized Multi-Protocol Label Switching 976 (GMPLS)", RFC 4203, October 2005. 978 7.2. Informative References 980 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 981 applications: DWDM frequency grid, June 2002. 983 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 984 applications: CWDM wavelength grid, December 2003. 986 [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 987 Labels for G.694 Lambda-Switching Capable Label Switching 988 Routers", work in progress: draft-ietf-ccamp-gmpls-g-694- 989 lambda-labels. 991 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 992 in Support of Generalized Multi-Protocol Label Switching 993 (GMPLS)", RFC 5307, October 2008. 995 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 996 WDM Wavelength Switching Systems for Use in GMPLS and Automated 997 Path Computation", Journal of Optical Communications and 998 Networking, vol. 1, June, 2009, pp. 187-195. 1000 [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 1001 and PCE Control of Wavelength Switched Optical Networks", 1002 work in progress: draft-ietf-ccamp-wavelength-switched- 1003 framework, February, 2010. 1005 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 1006 Wavelength Assignment Information Model for Wavelength 1007 Switched Optical Networks", work in progress: draft-ietf- 1008 ccamp-rwa-info, February, 2010. 1010 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 1011 Wavelength Assignment Information Encoding for Wavelength 1012 Switched Optical Networks", work in progress: draft-ietf- 1013 ccamp-rwa-wson-encode, Februsary, 2010. 1015 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1016 Element (PCE) communication Protocol (PCEP) - Version 1", 1017 RFC5440. 1019 8. Contributors 1021 Diego Caviglia 1022 Ericsson 1023 Via A. Negrone 1/A 16153 1024 Genoa Italy 1026 Phone: +39 010 600 3736 1027 Email: diego.caviglia@(marconi.com, ericsson.com) 1029 Anders Gavler 1030 Acreo AB 1031 Electrum 236 1032 SE - 164 40 Kista Sweden 1034 Email: Anders.Gavler@acreo.se 1036 Jonas Martensson 1037 Acreo AB 1038 Electrum 236 1039 SE - 164 40 Kista, Sweden 1041 Email: Jonas.Martensson@acreo.se 1043 Itaru Nishioka 1044 NEC Corp. 1045 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1046 Japan 1048 Phone: +81 44 396 3287 1049 Email: i-nishioka@cb.jp.nec.com 1051 Authors' Addresses 1053 Greg M. Bernstein (ed.) 1054 Grotto Networking 1055 Fremont California, USA 1057 Phone: (510) 573-2237 1058 Email: gregb@grotto-networking.com 1059 Young Lee (ed.) 1060 Huawei Technologies 1061 1700 Alma Drive, Suite 100 1062 Plano, TX 75075 1063 USA 1065 Phone: (972) 509-5599 (x2240) 1066 Email: ylee@huawei.com 1068 Dan Li 1069 Huawei Technologies Co., Ltd. 1070 F3-5-B R&D Center, Huawei Base, 1071 Bantian, Longgang District 1072 Shenzhen 518129 P.R.China 1074 Phone: +86-755-28973237 1075 Email: danli@huawei.com 1077 Wataru Imajuku 1078 NTT Network Innovation Labs 1079 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1080 Japan 1082 Phone: +81-(46) 859-4315 1083 Email: imajuku.wataru@lab.ntt.co.jp 1085 Jianrui Han 1086 Huawei Technologies Co., Ltd. 1087 F3-5-B R&D Center, Huawei Base, 1088 Bantian, Longgang District 1089 Shenzhen 518129 P.R.China 1091 Phone: +86-755-28972916 1092 Email: hanjianrui@huawei.com 1094 Intellectual Property Statement 1096 The IETF Trust takes no position regarding the validity or scope of 1097 any Intellectual Property Rights or other rights that might be 1098 claimed to pertain to the implementation or use of the technology 1099 described in any IETF Document or the extent to which any license 1100 under such rights might or might not be available; nor does it 1101 represent that it has made any independent effort to identify any 1102 such rights. 1104 Copies of Intellectual Property disclosures made to the IETF 1105 Secretariat and any assurances of licenses to be made available, or 1106 the result of an attempt made to obtain a general license or 1107 permission for the use of such proprietary rights by implementers or 1108 users of this specification can be obtained from the IETF on-line IPR 1109 repository at http://www.ietf.org/ipr 1111 The IETF invites any interested party to bring to its attention any 1112 copyrights, patents or patent applications, or other proprietary 1113 rights that may cover technology that may be required to implement 1114 any standard or specification contained in an IETF Document. Please 1115 address the information to the IETF at ietf-ipr@ietf.org. 1117 Disclaimer of Validity 1119 All IETF Documents and the information contained therein are provided 1120 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1121 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1122 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1123 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1124 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1125 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1126 FOR A PARTICULAR PURPOSE. 1128 Acknowledgment 1130 Funding for the RFC Editor function is currently provided by the 1131 Internet Society.