idnits 2.17.1 draft-ietf-ccamp-general-constraint-encode-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2010) is 4941 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'G.694.1' is defined on line 997, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 1000, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein 2 Internet Draft Grotto Networking 3 Intended status: Standards Track Y. Lee 4 Expires: April 2011 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 October 13, 2010 11 General Network Element Constraint Encoding for GMPLS Controlled 12 Networks 14 draft-ietf-ccamp-general-constraint-encode-03.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 March 13, 2007. 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........................16 97 3.6.5. Link Label Exclusivity..............................16 98 4. Security Considerations.......................................16 99 5. IANA Considerations...........................................17 100 6. Acknowledgments...............................................17 101 APPENDIX A: Encoding Examples....................................18 102 A.1. Link Set Field...........................................18 103 A.2. Label Set Field..........................................18 104 A.3. Connectivity Matrix Sub-TLV..............................19 105 A.4. Connectivity Matrix with Bi-directional Symmetry.........22 106 7. References....................................................25 107 7.1. Normative References.....................................25 108 7.2. Informative References...................................25 109 8. Contributors..................................................26 110 Authors' Addresses...............................................27 111 Intellectual Property Statement..................................28 112 Disclaimer of Validity...........................................28 114 1. Introduction 116 Some data plane technologies that wish to make use of a GMPLS control 117 plane contain additional constraints on switching capability and 118 label assignment. In addition, some of these technologies must 119 perform non-local label assignment based on the nature of the 120 technology, e.g., wavelength continuity constraint in WSON [WSON- 121 Frame]. Such constraints can lead to the requirement for link by link 122 label availability in path computation and label assignment. 124 This document provides efficient encodings of information needed by 125 the routing and label assignment process in technologies such as WSON 126 and are potentially applicable to a wider range of technologies. Such 127 encodings can be used to extend GMPLS signaling and routing 128 protocols. In addition these encodings could be used by other 129 mechanisms to convey this same information to a path computation 130 element (PCE). 132 1.1. Node Switching Asymmetry Constraints 134 For some network elements the ability of a signal or packet on a 135 particular ingress port to reach a particular egress port may be 136 limited. In addition, in some network elements the connectivity 137 between some ingress ports and egress ports may be fixed, e.g., a 138 simple multiplexer. To take into account such constraints during path 139 computation we model this aspect of a network element via a 140 connectivity matrix. 142 The connectivity matrix (ConnectivityMatrix) represents either the 143 potential connectivity matrix for asymmetric switches or fixed 144 connectivity for an asymmetric device such as a multiplexer. Note 145 that this matrix does not represent any particular internal blocking 146 behavior but indicates which ingress ports and labels (e.g., 147 wavelengths) could possibly be connected to a particular output port. 148 Representing internal state dependent blocking for a node is beyond 149 the scope of this document and due to it's highly implementation 150 dependent nature would most likely not be subject to standardization 151 in the future. The connectivity matrix is a conceptual M by N matrix 152 representing the potential switched or fixed connectivity, where M 153 represents the number of ingress ports and N the number of egress 154 ports. 156 ConnectivityMatrix(i, j) ::= 158 Where 160 is a unique identifier for the matrix. 162 can be either 0 or 1 depending upon whether the 163 connectivity is either fixed or potentially switched. 165 represents the fixed or switched connectivity in that 166 Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect 167 to egress port j for one or more labels. 169 1.2. Non-Local Label Assignment Constraints 171 If the nature of the equipment involved in a network results in a 172 requirement for non-local label assignment we can have constraints 173 based on limits imposed by the ports themselves and those that are 174 implied by the current label usage. Note that constraints such as 175 these only become important when label assignment has a non-local 176 character. For example in MPLS an LSR may have a limited range of 177 labels available for use on an egress port and a set of labels 178 already in use on that port and hence unavailable for use. This 179 information, however, does not need to be shared unless there is some 180 limitation on the LSR's label swapping ability. For example if a TDM 181 node lacks the ability to perform time-slot interchange or a WSON 182 lacks the ability to perform wavelength conversion then the label 183 assignment process is not local to a single node and it may be 184 advantageous to share the label assignment constraint information for 185 use in path computation. 187 Port label restrictions (PortLabelRestriction) model the label 188 restrictions that the network element (node) and link may impose on a 189 port. These restrictions tell us what labels may or may not be used 190 on a link and are intended to be relatively static. More dynamic 191 information is contained in the information on available labels. Port 192 label restrictions are specified relative to the port in general or 193 to a specific connectivity matrix for increased modeling flexibility. 194 Reference [Switch] gives an example where both switch and fixed 195 connectivity matrices are used and both types of constraints occur on 196 the same port. 198 ::= [...] 199 [...] 201 ::= 202 [] 204 ::= 205 [] 207 Where 209 MatrixID is the ID of the corresponding connectivity matrix 211 The RestrictionType parameter is used to specify general port 212 restrictions and matrix specific restrictions. 214 2. Extension Encoding Usage Recommendations 216 In this section we give recommendations of typical usage of the sub- 217 TLVs and composite TLVs. 219 2.1. Extension Node TLV 221 The Extension Node TLV could consist of the following list of sub- 222 TLVs: 224 ::= [Other GMPLS sub-TLVs] 225 [...] 227 2.2. Extension Link TLV 229 The new link related sub-TLVs could be incorporated into a composite 230 link TLV as follows: 232 ::= [Other GMPLS sub-TLVs] 233 [...][] [] 235 2.3. Extension Dynamic Link TLV 237 If the protocol supports the separation of dynamic information from 238 relatively static information then the available wavelength and 239 shared backup status can be separated from the general link TLV into 240 a TLV for dynamic link information. 242 ::= 243 [] 245 3. Encoding 247 A type-length-value (TLV) encoding of the general connectivity and 248 label restrictions and availability extensions is given in this 249 section. This encoding is designed to be suitable for use in the 250 GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in the 251 PCE protocol PCEP [PCEP]. Note that the information distributed in 252 [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs 253 within TLVs and this document makes use of such constructs. First, 254 however we define two general purpose fields that will be used 255 repeatedly in the subsequent TLVs. 257 3.1. Link Set Field 259 We will frequently need to describe properties of groups of links. To 260 do so efficiently we can make use of a link set concept similar to 261 the label set concept of [RFC3471]. This Link Set Field is used in 262 the sub-TLV, which is defined in Section 3.5. 263 The information carried in a Link Set is defined by: 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 |Dir| Format | Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Link Identifier 1 | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 : : : 273 : : : 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Link Identifier N | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Action: 8 bits 280 0 - Inclusive List 282 Indicates that one or more link identifiers are included in the Link 283 Set. Each identifies a separate link that is part of the set. 285 1 - Inclusive Range 287 Indicates that the Link Set defines a range of links. It contains 288 two link identifiers. The first identifier indicates the start of the 289 range (inclusive). The second identifier indicates the end of the 290 range (inclusive). All links with numeric values between the bounds 291 are considered to be part of the set. A value of zero in either 292 position indicates that there is no bound on the corresponding 293 portion of the range. Note that the Action field can be set to 294 0x02(Inclusive Range) only when unnumbered link identifier is used. 296 Dir: Directionality of the Link Set (2 bits) 298 0 -- bidirectional 299 1 -- ingress 301 2 -- egress 303 For example in optical networks we think in terms of unidirectional 304 as well as bidirectional links. For example, label restrictions or 305 connectivity may be different for an ingress port, than for its 306 "companion" egress port if one exists. Note that "interfaces" such as 307 those discussed in the Interfaces MIB [RFC2863] are assumed to be 308 bidirectional. This also applies to the links advertised in various 309 link state routing protocols. 311 Format: The format of the link identifier (6 bits) 313 0 -- Link Local Identifier 315 Indicates that the links in the Link Set are identified by link local 316 identifiers. All link local identifiers are supplied in the context 317 of the advertising node. 319 1 -- Local Interface IPv4 Address 321 2 -- Local Interface IPv6 Address 323 Indicates that the links in the Link Set are identified by Local 324 Interface IP Address. All Local Interface IP Address are supplied in 325 the context of the advertising node. 327 Others TBD. 329 Note that all link identifiers in the same list must be of the same 330 type. 332 Length: 16 bits 334 This field indicates the total length in bytes of the Link Set field. 336 Link Identifier: length is dependent on the link format 338 The link identifier represents the port which is being described 339 either for connectivity or label restrictions. This can be the link 340 local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS OSPF 341 routing, and [RFC5307] IS-IS GMPLS routing. The use of the link local 342 identifier format can result in more compact encodings when the 343 assignments are done in a reasonable fashion. 345 3.2. Label Set Field 347 Label Set Field is used within the sub-TLV or the 348 sub-TLV, which is defined in Section 3.3. and 349 3.4. , respectively. 351 The general format for a label set is given below. This format uses 352 the Action concept from [RFC3471] with an additional Action to define 353 a "bit map" type of label set. The second 32 bit field is a base 354 label used as a starting point in many of the specific formats. 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Action| Num Labels | Length | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Base Label | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Additional fields as necessary per action | 364 | 366 Action: 368 0 - Inclusive List 370 1 - Exclusive List 372 2 - Inclusive Range 374 3 - Exclusive Range 376 4 - Bitmap Set 378 Num Labels is only meaningful for Action value of 4 (Bitmap Set). It 379 indicates the number of labels represented by the bit map. See more 380 detail in section 3.2.3. 382 Length is the length in bytes of the entire field. 384 3.2.1. Inclusive/Exclusive Label Lists 386 In the case of the inclusive/exclusive lists the wavelength set 387 format is given by: 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |0 or 1 | Num Labels (not used) | Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Base Label | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 : : 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Last Label | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Where: 403 Num Labels is not used in this particular format since the Length 404 parameter is sufficient to determine the number of labels in the 405 list. 407 3.2.2. Inclusive/Exclusive Label Ranges 409 In the case of inclusive/exclusive ranges the label set format is 410 given by: 412 0 1 2 3 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |2 or 3 | Num Labels(not used) | Length | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Start Label | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | End Label | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Note that the start and end label must in some sense "compatible" in 423 the technology being used. 425 3.2.3. Bitmap Label Set 427 In the case of Action = 4, the bitmap the label set format is given 428 by: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | 4 | Num Labels | Length | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Base Label | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Bit Map Word #1 (Lowest numerical labels) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 : : 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Bit Map Word #N (Highest numerical labels) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Where Num Labels in this case tells us the number of labels 445 represented by the bit map. Each bit in the bit map represents a 446 particular label with a value of 1/0 indicating whether the label is 447 in the set or not. Bit position zero represents the lowest label and 448 corresponds to the base label, while each succeeding bit position 449 represents the next label logically above the previous. 451 The size of the bit map is Num Label bits, but the bit map is padded 452 out to a full multiple of 32 bits so that the TLV is a multiple of 453 four bytes. Bits that do not represent labels (i.e., those in 454 positions (Num Labels) and beyond SHOULD be set to zero and MUST be 455 ignored. 457 3.3. Available Labels Sub-TLV 459 To indicate the labels available for use on a link the Available 460 Labels sub-TLV consists of a single variable length label set field 461 as follows: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Label Set Field | 467 : : 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Note that Label Set Field is defined in Section 3.2. 472 3.4. Shared Backup Labels Sub-TLV 474 To indicate the labels available for shared backup use on a link the 475 Shared Backup Labels sub-TLV consists of a single variable length 476 label set field as follows: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Label Set Field | 482 : : 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 3.5. Connectivity Matrix Sub-TLV 487 The Connectivity Matrix represents how ingress ports are connected to 488 egress ports for network elements. The switch and fixed connectivity 489 matrices can be compactly represented in terms of a minimal list of 490 ingress and egress port set pairs that have mutual connectivity. As 491 described in [Switch] such a minimal list representation leads 492 naturally to a graph representation for path computation purposes 493 that involves the fewest additional nodes and links. 495 A TLV encoding of this list of link set pairs is: 497 0 1 2 3 498 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Connectivity | MatrixID | Reserved | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Link Set A #1 | 503 : : : 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Link Set B #1 : 506 : : : 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Additional Link set pairs as needed | 509 : to specify connectivity : 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Where 513 Connectivity is the device type. 515 0 -- the device is fixed 517 1 -- the device is switched(e.g., ROADM/OXC) 519 MatrixID represents the ID of the connectivity matrix and is an 8 bit 520 integer. The value of 0xFF is reserved for use with port wavelength 521 constraints and should not be used to identify a connectivity matrix. 523 Link Set A #1 and Link Set B #1 together represent a pair of link 524 sets. There are two permitted combinations for the link set field 525 parameter "dir" for Link Set A and B pairs: 527 o Link Set A dir=ingress, Link Set B dir=egress 529 The meaning of the pair of link sets A and B in this case is that 530 any signal that ingresses a link in set A can be potentially 531 switched out of an egress link in set B. 533 o Link Set A dir=bidirectional, Link Set B dir=bidirectional 535 The meaning of the pair of link sets A and B in this case is that 536 any signal that ingresses on the links in set A can potentially 537 egress on a link in set B, and any ingress signal on the links in 538 set B can potentially egress on a link in set A. 540 See Appendix A for both types of encodings as applied to a ROADM 541 example. 543 3.6. Port Label Restriction sub-TLV 545 Port Label Restriction tells us what labels may or may not be used on 546 a link. 548 The port label restriction of section 1.2. can be encoded as a sub- 549 TLV as follows. More than one of these sub-TLVs may be needed to 550 fully specify a complex port constraint. When more than one of these 551 sub-TLVs are present the resulting restriction is the intersection of 552 the restrictions expressed in each sub-TLV. To indicate that a 553 restriction applies to the port in general and not to a specific 554 connectivity matrix use the reserved value of 0xFF for the MatrixID. 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | MatrixID | RestrictionType | Reserved/Parameter | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Additional Restriction Parameters per RestrictionType | 562 : : 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Where: 567 MatrixID: either is the value in the corresponding Connectivity 568 Matrix sub-TLV or takes the value OxFF to indicate the restriction 569 applies to the port regardless of any Connectivity Matrix. 571 RestrictionType can take the following values and meanings: 573 0: SIMPLE_LABEL (Simple label selective restriction) 575 1: CHANNEL_COUNT (Channel count restriction) 577 2: LABEL_RANGE1 (Label range device with a movable center label 578 and width) 580 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL 581 and CHANNEL_COUNT restriction. The accompanying label set and 582 channel count indicate labels permitted on the port and the 583 maximum number of channels that can be simultaneously used on 584 the port) 586 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once 587 amongst a set of specified ports) 589 3.6.1. SIMPLE_LABEL 591 In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or 592 MatrixSpecificRestrictions) format is given by: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | MatrixID | RstType = 0 | Reserved | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Label Set Field | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 In this case the accompanying label set indicates the labels 603 permitted on the port. 605 3.6.2. CHANNEL_COUNT 607 In the case of the CHANNEL_COUNT the format is given by: 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | MatrixID | RstType = 1 | MaxNumChannels | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 In this case the accompanying MaxNumChannels indicates the maximum 616 number of channels (labels) that can be simultaneously used on the 617 port/matrix. 619 3.6.3. LABEL_RANGE1 621 In the case of the LABEL_RANGE1 the GeneralPortRestrictions (or 622 MatrixSpecificRestrictions) format is given by: 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | MatrixID | RstType = 2 | MaxLabelRange | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Label Set Field | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 In this case the accompanying MaxLabelRange indicates the maximum 633 range of the labels. The corresponding label set is used to indicate 634 the overall label range. Specific center label information can be 635 obtained from dynamic label in use information. It is assumed that 636 both center label and range tuning can be done without causing faults 637 to existing signals. 639 3.6.4. SIMPLE_LABEL & CHANNEL_COUNT 641 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 642 by: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | MatrixID | RstType = 3 | MaxNumChannels | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Label Set Field | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 In this case the accompanying label set and MaxNumChannels indicate 653 labels permitted on the port and the maximum number of labels that 654 can be simultaneously used on the port. 656 3.6.5. Link Label Exclusivity 658 In the case of the SIMPLE_LABEL & CHANNEL_COUNT the format is given 659 by: 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | MatrixID | RstType = 4 | Reserved | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Link Set Field | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 In this case the accompanying port set indicate that a label may be 670 used at most once among the ports in the link set field. 672 4. Security Considerations 674 This document defines protocol-independent encodings for WSON 675 information and does not introduce any security issues. 677 However, other documents that make use of these encodings within 678 protocol extensions need to consider the issues and risks associated 679 with, inspection, interception, modification, or spoofing of any of 680 this information. It is expected that any such documents will 681 describe the necessary security measures to provide adequate 682 protection. 684 5. IANA Considerations 686 TBD. Once our approach is finalized we may need identifiers for the 687 various TLVs and sub-TLVs. 689 6. Acknowledgments 691 This document was prepared using 2-Word-v2.0.template.dot. 693 APPENDIX A: Encoding Examples 695 Here we give examples of the general encoding extensions applied to 696 some simple ROADM network elements and links. 698 A.1. Link Set Field 700 Suppose that we wish to describe a set of ingress ports that are have 701 link local identifiers number 3 through 42. In the link set field we 702 set the Action = 1 to denote an inclusive range; the Dir = 1 to 703 denote ingress links; and, the Format = 0 to denote link local 704 identifiers. In particular we have: 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Link Local Identifier = #3 | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Link Local Identifier = #42 | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 A.2. Label Set Field 716 Example: 718 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 719 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 720 (1530.3nm). These frequencies correspond to n = -11, and n = 28 721 respectively. Now suppose the following channels are available: 723 Frequency (THz) n Value bit map position 724 -------------------------------------------------- 725 192.0 -11 0 726 192.5 -6 5 727 193.1 0 11 728 193.9 8 19 729 194.0 9 20 730 195.2 21 32 731 195.8 27 38 733 With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. 734 set to indicate 100GHz this lambda bit map set would then be encoded 735 as follows: 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | 4 | Num Wavelengths = 40 | Length = 16 bytes | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 |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| 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 To encode this same set as an inclusive list we would have: 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | 0 | Num Wavelengths = 40 | Length = 20 bytes | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 |Grid | C.S. | Reserved | n for lowest frequency = -11 | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 |Grid | C.S. | Reserved | n for lowest frequency = -6 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |Grid | C.S. | Reserved | n for lowest frequency = -0 | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 |Grid | C.S. | Reserved | n for lowest frequency = 8 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 |Grid | C.S. | Reserved | n for lowest frequency = 9 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 |Grid | C.S. | Reserved | n for lowest frequency = 21 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 |Grid | C.S. | Reserved | n for lowest frequency = 27 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 A.3. Connectivity Matrix Sub-TLV 773 Example: 775 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 776 its two line side ports it has 80 add and 80 drop ports. The picture 777 below illustrates how a typical 2-degree ROADM system that works with 778 bi-directional fiber pairs is a highly asymmetrical system composed 779 of two unidirectional ROADM subsystems. 781 (Tributary) Ports #3-#42 782 Ingress added to Egress dropped from 783 West Line Egress East Line Ingress 784 vvvvv ^^^^^ 785 | |||.| | |||.| 786 +-----| |||.|--------| |||.|------+ 787 | +----------------------+ | 788 | | | | 789 Egress | | Unidirectional ROADM | | Ingress 790 -----------------+ | | +-------------- 791 <=====================| |===================< 792 -----------------+ +----------------------+ +-------------- 793 | | 794 Port #1 | | Port #2 795 (West Line Side) | |(East Line Side) 796 -----------------+ +----------------------+ +-------------- 797 >=====================| |===================> 798 -----------------+ | Unidirectional ROADM | +-------------- 799 Ingress | | | | Egress 800 | | _ | | 801 | +----------------------+ | 802 +-----| |||.|--------| |||.|------+ 803 | |||.| | |||.| 804 vvvvv ^^^^^ 805 (Tributary) Ports #43-#82 806 Egress dropped from Ingress added to 807 West Line ingress East Line egress 809 Referring to the figure we see that the ingress direction of ports 810 #3-#42 (add ports) can only connect to the egress on port #1. While 811 the ingress side of port #2 (line side) can only connect to the 812 egress on ports #3-#42 (drop) and to the egress on port #1 (pass 813 through). Similarly, the ingress direction of ports #43-#82 can only 814 connect to the egress on port #2 (line). While the ingress direction 815 of port #1 can only connect to the egress on ports #43-#82 (drop) or 816 port #2 (pass through). We can now represent this potential 817 connectivity matrix as follows. This representation uses only 30 32- 818 bit words. 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Conn = 1 | MatrixID | Reserved |1 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 Note: adds to line 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |2 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Link Local Identifier = #3 |3 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Link Local Identifier = #42 |4 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |5 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Link Local Identifier = #1 |6 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Note: line to drops 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |7 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Link Local Identifier = #2 |8 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |9 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Link Local Identifier = #3 |10 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Link Local Identifier = #42 |11 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Note: line to line 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |12 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Link Local Identifier = #2 |13 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |14 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Link Local Identifier = #1 |15 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 Note: adds to line 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Action=1 |0 1|0 0 0 0 0 0| Length = 12 |16 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Link Local Identifier = #43 |17 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Link Local Identifier = #82 |18 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |19 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Link Local Identifier = #2 |20 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Note: line to drops 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Action=0 |0 1|0 0 0 0 0 0|| Length = 8 |21 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Link Local Identifier = #1 |22 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Action=1 |1 0|0 0 0 0 0 0| Length = 12 |23 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Link Local Identifier = #43 |24 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Link Local Identifier = #82 |25 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Note: line to line 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Action=0 |0 1|0 0 0 0 0 0| Length = 8 |26 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Link Local Identifier = #1 |27 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 |28 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Link Local Identifier = #2 |30 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 A.4. Connectivity Matrix with Bi-directional Symmetry 896 If one has the ability to renumber the ports of the previous example 897 as shown in the next figure then we can take advantage of the bi- 898 directional symmetry and use bi-directional encoding of the 899 connectivity matrix. Note that we set dir=bidirectional in the link 900 set fields. 902 (Tributary) 903 Ports #3-42 Ports #43-82 904 West Line Egress East Line Ingress 905 vvvvv ^^^^^ 906 | |||.| | |||.| 907 +-----| |||.|--------| |||.|------+ 908 | +----------------------+ | 909 | | | | 910 Egress | | Unidirectional ROADM | | Ingress 911 -----------------+ | | +-------------- 912 <=====================| |===================< 913 -----------------+ +----------------------+ +-------------- 914 | | 915 Port #1 | | Port #2 916 (West Line Side) | |(East Line Side) 917 -----------------+ +----------------------+ +-------------- 918 >=====================| |===================> 919 -----------------+ | Unidirectional ROADM | +-------------- 920 Ingress | | | | Egress 921 | | _ | | 922 | +----------------------+ | 923 +-----| |||.|--------| |||.|------+ 924 | |||.| | |||.| 925 vvvvv ^^^^^ 926 Ports #3-#42 Ports #43-82 927 Egress dropped from Ingress added to 928 West Line ingress East Line egress 930 0 1 2 3 931 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 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Conn = 1 | MatrixID | Reserved |1 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 Add/Drops #3-42 to Line side #1 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |2 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Link Local Identifier = #3 |3 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Link Local Identifier = #42 |4 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |5 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Link Local Identifier = #1 |6 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 Note: line #2 to add/drops #43-82 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |7 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Link Local Identifier = #2 |8 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Action=1 |0 0|0 0 0 0 0 0| Length = 12 |9 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Link Local Identifier = #43 |10 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Link Local Identifier = #82 |11 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Note: line to line 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |12 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Link Local Identifier = #1 |13 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Action=0 |0 0|0 0 0 0 0 0| Length = 8 |14 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Link Local Identifier = #2 |15 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 7. References 972 7.1. Normative References 974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 975 Requirement Levels", BCP 14, RFC 2119, March 1997. 977 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 978 MIB", RFC 2863, June 2000. 980 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 981 (GMPLS) Signaling Functional Description", RFC 3471, 982 January 2003. 984 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 985 applications: DWDM frequency grid", June, 2002. 987 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 988 in Support of Generalized Multi-Protocol Label Switching 989 (GMPLS)", RFC 4202, October 2005 991 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 992 Support of Generalized Multi-Protocol Label Switching 993 (GMPLS)", RFC 4203, October 2005. 995 7.2. Informative References 997 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 998 applications: DWDM frequency grid, June 2002. 1000 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 1001 applications: CWDM wavelength grid, December 2003. 1003 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 1004 in Support of Generalized Multi-Protocol Label Switching 1005 (GMPLS)", RFC 5307, October 2008. 1007 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 1008 WDM Wavelength Switching Systems for Use in GMPLS and Automated 1009 Path Computation", Journal of Optical Communications and 1010 Networking, vol. 1, June, 2009, pp. 187-195. 1012 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1013 Element (PCE) communication Protocol (PCEP) - Version 1", 1014 RFC5440. 1016 8. Contributors 1018 Diego Caviglia 1019 Ericsson 1020 Via A. Negrone 1/A 16153 1021 Genoa Italy 1023 Phone: +39 010 600 3736 1024 Email: diego.caviglia@(marconi.com, ericsson.com) 1026 Anders Gavler 1027 Acreo AB 1028 Electrum 236 1029 SE - 164 40 Kista Sweden 1031 Email: Anders.Gavler@acreo.se 1033 Jonas Martensson 1034 Acreo AB 1035 Electrum 236 1036 SE - 164 40 Kista, Sweden 1038 Email: Jonas.Martensson@acreo.se 1040 Itaru Nishioka 1041 NEC Corp. 1042 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1043 Japan 1045 Phone: +81 44 396 3287 1046 Email: i-nishioka@cb.jp.nec.com 1048 Authors' Addresses 1050 Greg M. Bernstein (ed.) 1051 Grotto Networking 1052 Fremont California, USA 1054 Phone: (510) 573-2237 1055 Email: gregb@grotto-networking.com 1057 Young Lee (ed.) 1058 Huawei Technologies 1059 1700 Alma Drive, Suite 100 1060 Plano, TX 75075 1061 USA 1063 Phone: (972) 509-5599 (x2240) 1064 Email: ylee@huawei.com 1066 Dan Li 1067 Huawei Technologies Co., Ltd. 1068 F3-5-B R&D Center, Huawei Base, 1069 Bantian, Longgang District 1070 Shenzhen 518129 P.R.China 1072 Phone: +86-755-28973237 1073 Email: danli@huawei.com 1075 Wataru Imajuku 1076 NTT Network Innovation Labs 1077 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1078 Japan 1080 Phone: +81-(46) 859-4315 1081 Email: imajuku.wataru@lab.ntt.co.jp 1082 Jianrui Han 1083 Huawei Technologies Co., Ltd. 1084 F3-5-B R&D Center, Huawei Base, 1085 Bantian, Longgang District 1086 Shenzhen 518129 P.R.China 1088 Phone: +86-755-28972916 1089 Email: hanjianrui@huawei.com 1091 Intellectual Property Statement 1093 The IETF Trust takes no position regarding the validity or scope of 1094 any Intellectual Property Rights or other rights that might be 1095 claimed to pertain to the implementation or use of the technology 1096 described in any IETF Document or the extent to which any license 1097 under such rights might or might not be available; nor does it 1098 represent that it has made any independent effort to identify any 1099 such rights. 1101 Copies of Intellectual Property disclosures made to the IETF 1102 Secretariat and any assurances of licenses to be made available, or 1103 the result of an attempt made to obtain a general license or 1104 permission for the use of such proprietary rights by implementers or 1105 users of this specification can be obtained from the IETF on-line IPR 1106 repository at http://www.ietf.org/ipr 1108 The IETF invites any interested party to bring to its attention any 1109 copyrights, patents or patent applications, or other proprietary 1110 rights that may cover technology that may be required to implement 1111 any standard or specification contained in an IETF Document. Please 1112 address the information to the IETF at ietf-ipr@ietf.org. 1114 Disclaimer of Validity 1116 All IETF Documents and the information contained therein are provided 1117 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1118 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1119 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1120 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1121 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1122 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1123 FOR A PARTICULAR PURPOSE. 1125 Acknowledgment 1127 Funding for the RFC Editor function is currently provided by the 1128 Internet Society.