idnits 2.17.1 draft-ietf-ccamp-rwa-wson-encode-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2010) is 5179 days in the past. Is this intentional? 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: 'RFC2578' is mentioned on line 728, but not defined == Missing Reference: 'RFC4328' is mentioned on line 786, but not defined == Unused Reference: 'RFC2863' is defined on line 1138, but no explicit reference was found in the text == Unused Reference: 'G.694.1' is defined on line 1158, but no explicit reference was found in the text == Unused Reference: 'RFC4202' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 1152, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 1161, but no explicit reference was found in the text == Unused Reference: 'RFC5307' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'Switch' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'PCEP' is defined on line 1193, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' -- No information found for draft-ietf-ccamp-general-ext-encode - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein 2 Internet Draft Grotto Networking 3 Intended status: Standards Track Y. Lee 4 Expires: August 2010 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 February 18, 2010 11 Routing and Wavelength Assignment Information Encoding for 12 Wavelength Switched Optical Networks 14 draft-ietf-ccamp-rwa-wson-encode-04.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on August 18, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Abstract 56 A wavelength switched optical network (WSON) requires that certain 57 key information elements are made available to facilitate path 58 computation and the establishment of label switching paths (LSPs). 59 The information model described in "Routing and Wavelength Assignment 60 Information for Wavelength Switched Optical Networks" shows what 61 information is required at specific points in the WSON. Part of the 62 WSON information model contains aspects that may be of general 63 applicability to other technologies, while other parts are fairly 64 specific to WSONs. 66 This document provides efficient, protocol-agnostic encodings for the 67 WSON specific information elements. It is intended that protocol- 68 specific documents will reference this memo to describe how 69 information is carried for specific uses. Such encodings can be used 70 to extend GMPLS signaling and routing protocols. In addition these 71 encodings could be used by other mechanisms to convey this same 72 information to a path computation element (PCE). 74 Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC-2119 [RFC2119]. 80 Table of Contents 82 1. Introduction...................................................3 83 1.1. Revision History..........................................4 84 1.1.1. Changes from 00 draft................................4 85 1.1.2. Changes from 01 draft................................4 86 1.1.3. Changes from 02 draft................................5 87 1.1.4. Changes from 03 draft................................5 88 2. Terminology....................................................5 89 3. WSON Encoding Usage Recommendations............................6 90 3.1. WSON Node TLV.............................................6 91 3.2. WSON Dynamic Node TLV.....................................6 92 4. Resource Accessibility/Availability............................6 93 4.1. Resource Block Accessibility Sub-TLV......................8 94 4.2. Resource Wavelength Constraints Sub-TLV..................10 95 4.3. Resource Block Pool State Sub-TLV........................10 96 5. Resource Properties Encoding..................................12 97 5.1. Resource Block Information Sub-TLV.......................12 98 5.2. Input Modulation Format List Sub-Sub-TLV.................13 99 5.2.1. Modulation Format Field.............................13 100 5.3. Input FEC Type List Sub-Sub-TLV..........................15 101 5.3.1. FEC Type Field......................................16 102 5.4. Input Bit Range List Sub-Sub-TLV.........................18 103 5.4.1. Bit Range Field.....................................18 104 5.5. Input Client Signal List Sub-Sub-TLV.....................19 105 5.6. Processing Capability List Sub-Sub-TLV...................20 106 5.6.1. Processing Capabilities Field.......................20 107 5.7. Output Modulation Format List Sub-Sub-TLV................22 108 5.8. Output FEC Type List Sub-Sub-TLV.........................22 109 6. Security Considerations.......................................22 110 7. IANA Considerations...........................................23 111 8. Acknowledgments...............................................23 112 APPENDIX A: Encoding Examples....................................24 113 A.1. Wavelength Converter Accessibility Sub-TLV...............24 114 A.2. Wavelength Conversion Range Sub-TLV......................25 115 A.3. An OEO Switch with DWDM Optics...........................26 116 9. References....................................................29 117 9.1. Normative References.....................................29 118 9.2. Informative References...................................29 119 10. Contributors.................................................31 120 Authors' Addresses...............................................31 121 Intellectual Property Statement..................................32 122 Disclaimer of Validity...........................................33 124 1. Introduction 126 A Wavelength Switched Optical Network (WSON) is a Wavelength Division 127 Multiplexing (WDM) optical network in which switching is performed 128 selectively based on the center wavelength of an optical signal. 130 [WSON-Frame] describes a framework for Generalized Multiprotocol 131 Label Switching (GMPLS) and Path Computation Element (PCE) control of 132 a WSON. Based on this framework, [WSON-Info] describes an information 133 model that specifies what information is needed at various points in 134 a WSON in order to compute paths and establish Label Switched Paths 135 (LSPs). 137 This document provides efficient encodings of information needed by 138 the routing and wavelength assignment (RWA) process in a WSON. Such 139 encodings can be used to extend GMPLS signaling and routing 140 protocols. In addition these encodings could be used by other 141 mechanisms to convey this same information to a path computation 142 element (PCE). Note that since these encodings are relatively 143 efficient they can provide more accurate analysis of the control 144 plane communications/processing load for WSONs looking to utilize a 145 GMPLS control plane. 147 Note that encodings of information needed by the routing and label 148 assignment process applicable to general networks beyond WSON are 149 addressed in a separate document [Gen-Encode]. 151 1.1. Revision History 153 1.1.1. Changes from 00 draft 155 Edits to make consistent with update to [Otani], i.e., removal of 156 sign bit. 158 Clarification of TBD on connection matrix type and possibly 159 numbering. 161 New sections for wavelength converter pool encoding: Wavelength 162 Converter Set Sub-TLV, Wavelength Converter Accessibility Sub-TLV, 163 Wavelength Conversion Range Sub-TLV, WC Usage State Sub-TLV. 165 Added optional wavelength converter pool TLVs to the composite node 166 TLV. 168 1.1.2. Changes from 01 draft 170 The encoding examples have been moved to an appendix. Classified and 171 corrected information elements as either reusable fields or sub-TLVs. 172 Updated Port Wavelength Restriction sub-TLV. Added available 173 wavelength and shared backup wavelength sub-TLVs. Changed the title 174 and scope of section 6 to recommendations since the higher level TLVs 175 that this encoding will be used in is somewhat protocol specific. 177 1.1.3. Changes from 02 draft 179 Removed inconsistent text concerning link local identifiers and the 180 link set field. 182 Added E bit to the Wavelength Converter Set Field. 184 Added bidirectional connectivity matrix example. Added simple link 185 set example. Edited examples for consistency. 187 1.1.4. Changes from 03 draft 189 Removed encodings for general concepts to [Gen-Encode]. 191 Added in WSON signal compatibility and processing capability 192 information encoding. 194 2. Terminology 196 CWDM: Coarse Wavelength Division Multiplexing. 198 DWDM: Dense Wavelength Division Multiplexing. 200 FOADM: Fixed Optical Add/Drop Multiplexer. 202 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 203 count wavelength selective switching element featuring ingress and 204 egress line side ports as well as add/drop side ports. 206 RWA: Routing and Wavelength Assignment. 208 Wavelength Conversion. The process of converting an information 209 bearing optical signal centered at a given wavelength to one with 210 "equivalent" content centered at a different wavelength. Wavelength 211 conversion can be implemented via an optical-electronic-optical (OEO) 212 process or via a strictly optical process. 214 WDM: Wavelength Division Multiplexing. 216 Wavelength Switched Optical Network (WSON): A WDM based optical 217 network in which switching is performed selectively based on the 218 center wavelength of an optical signal. 220 3. WSON Encoding Usage Recommendations 222 In this section we give recommendations of typical usage of the sub- 223 TLVs and composite TLVs which are based on the high level information 224 bundles of [WSON-Info]. 226 3.1. WSON Node TLV 228 The WSON Node TLV would consist of the following list of sub-TLVs: 230 ::= [Other GMPLS sub-TLVs] 231 [][] 233 Where 235 ::= ... 236 [...] [...] 238 The encoding of structure and properties of a general resource pool 239 utilizes a resource block info sub-TLV ( in 240 section 5. ), an accessibility sub-TLV ( 241 in section 4.1. ), and a resource pool wavelength constraint sub-TLV 242 ( in section 4.2. ). 244 3.2. WSON Dynamic Node TLV 246 If the protocol supports the separation of dynamic information from 247 relatively static information then the wavelength converter pool 248 state can be separated from the general Node TLV into a dynamic Node 249 TLV as follows. 251 ::= [] 253 Where the resource pool state sub-TLV is defined in 254 section 4.3. Note that currently the only dynamic information modeled 255 with a node is associated with the status of the wavelength converter 256 pool. 258 4. Resource Accessibility/Availability 260 In this section we define the sub-TLVs for dealing with accessibility 261 and availability of resource blocks. These in include the following 262 ResourceBlockAccessibility, ResourceWaveConstraints, and RBPoolState 263 sub-TLVs. All these sub-TLVs are concerned with sets of resources. 265 In a WSON node that includes resource blocks (RB) we will want to 266 denote subsets these blocks to efficiently describe common properties 267 the blocks and to describe the structure, if non-trivial, of the 268 resource pool. The RB Set field is defined in a similar manner to the 269 label set concept of [RFC3471]. 271 The information carried in a RB set field is defined by: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Action |E|C| Reserved | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | RB Identifier 1 | RB Identifier 2 | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 : : : 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | RB Identifier n-1 | RB Identifier n | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Action: 8 bits 287 0 - Inclusive List 289 Indicates that the TLV contains one or more RB elements that are 290 included in the list. 292 2 - Inclusive Range 294 Indicates that the TLV contains a range of RBs. The object/TLV 295 contains two WC elements. The first element indicates the start of 296 the range. The second element indicates the end of the range. A value 297 of zero indicates that there is no bound on the corresponding portion 298 of the range. 300 E (Even bit): Set to 0 denotes an odd number of RB identifiers in 301 the list (last entry zero pad); Set to 1 denotes an even number of RB 302 identifiers in the list (no zero padding). 304 C (Connectivity bit): Set to 0 to denote fixed (possibly multi- 305 cast) connectivity; Set to 1 to denote potential (switched) 306 connectivity. Used in resource pool accessibility sub-TLV. Ignored 307 elsewhere. 309 Reserved: 6 bits 311 This field is reserved. It MUST be set to zero on transmission and 312 MUST be ignored on receipt. 314 Length: 16 bits 316 The total length of this field in bytes. 318 RB Identifier: 320 The RB identifier represents the ID of the resource block which is a 321 16 bit integer. 323 4.1. Resource Block Accessibility Sub-TLV 325 This sub-TLV describes the structure of the resource pool in relation 326 to the switching device. In particular it indicates the ability of an 327 ingress port to reach a resource block and of a resource block to 328 reach a particular egress port. This is the PoolIngressMatrix and 329 PoolEgressMatrix of [WSON-Info]. 331 The resource block accessibility sub-TLV is defined by: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Connectivity | Reserved | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Ingress Link Set Field A #1 | 339 : : 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | RB Set Field A #1 | 342 : : 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Additional Link set and RB set pairs as needed to | 345 : specify PoolIngressMatrix : 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Egress Link Set Field B #1 | 348 : : 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | RB Set B Field #1 (for egress connectivity) | 351 : : 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Additional Link Set and RB set pairs as needed to | 354 : specify PoolEgressMatrix : 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Where 359 Connectivity indicates how the ingress/egress ports connect to the 360 resource blocks. 362 0 -- the device is fixed (e.g. a connected port must go through 363 the resource block) 365 1 -- the device is switched(e.g., a port can be configured to 366 go through a resource but isn't required ) 368 The Link Set Field is defined in [Gen-Encode]. 370 Note that the direction parameter within the Link Set Field is used 371 to indicate whether the link set is an ingress or egress link set, 372 and the bidirectional value for this parameter is not permitted in 373 this sub-TLV. 375 See Appendix A.1 for an illustration of this encoding. 377 4.2. Resource Wavelength Constraints Sub-TLV 379 Resources, such as wavelength converters, etc., may have a limited 380 input or output wavelength ranges. Additionally, due to the structure 381 of the optical system not all wavelengths can necessarily reach or 382 leave all the resources. These properties are described by using one 383 or more resource wavelength restrictions sub-TLVs as defined below: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | RB Set Field | 389 : : 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Input Wavelength Set Field | 392 : : 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Output Wavelength Set Field | 395 : : 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 RB Set Field: 400 A set of resource blocks (RBs) which have the same wavelength 401 restrictions. 403 Input Wavelength Set Field: 405 Indicates the wavelength input restrictions of the RBs in the 406 corresponding RB set. 408 Output Wavelength Set Field: 410 Indicates the wavelength output restrictions of RBs in the 411 corresponding RB set. 413 4.3. Resource Block Pool State Sub-TLV 415 The usage state of a resource is encoded as either a list of 16 bit 416 integer values or a bit map indicating whether a single resource is 417 available or in use. This information can be relatively dynamic, 418 i.e., can change when a connection is established or torn down. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Action | Reserved | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | RB Set Field | 426 : : 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | RB Usage state | 429 : : 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Where Action = 0 denotes a list of 16 bit integers and Action = 1 433 denotes a bit map. In both cases the elements of the RB Set field are 434 in a one-to-one correspondence with the values in the usage RB usage 435 state area. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Action = 0 | Reserved | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | RB Set Field | 443 : : 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | RB#1 state | RB#2 state | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 : : 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | RB#n-1 state | RB#n state or Padding | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Whether the last 16 bits is a wavelength converter (RB) state or 453 padding is determined by the number of elements in the RB set field. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Action = 1 | Reserved | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | RB Set Field | 461 : : 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | RB Usage state bitmap | 464 : : 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | ...... | Padding bits | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 RB Usage state: Variable Length but must be a multiple of 4 byes. 472 Each bit indicates the usage status of one RB with 0 indicating the 473 RB is available and 1 indicating the RB is in used. The sequence of 474 the bit map is ordered according to the RB Set field with this sub- 475 TLV. 477 Padding bits: Variable Length 479 5. Resource Properties Encoding 481 Within a WSON network element (NE) there may be resources with signal 482 compatibility constraints. Such resources typically come in "blocks" 483 which contain a group on identical and indistinguishable individual 484 resources. These resource blocks may consist of regenerators, 485 wavelength converters, etc... Such resource blocks may also 486 constitute the network element as a whole as in the case of an 487 electro optical switch. In this section we focus on the signal 488 compatibility and processing properties of such a resource block, 489 i.e., of section 3.1. the accessibility aspects 490 of a resource in a shared pool were encoded in the previous section. 492 The fundamental properties of a resource block, such as a regenerator 493 or wavelength converter, are: 495 (a)Input constraints (modulation, FEC, bit rate, GPID) 497 (b)Processing capabilities (number of resources in a block, 498 regeneration, performance monitoring, vendor specific) 500 (c)Output Constraints (modulation, FEC) 502 5.1. Resource Block Information Sub-TLV 504 Resource Block descriptor sub-TLVs are used to convey relatively 505 static information about individual resource blocks including the 506 resource block properties of section 3. and the number of resources 507 in a block. 509 This sub-TLV has the following format: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | RB Set Field | 515 : : 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Input Modulation Type List Sub-Sub-TLV (opt) | 518 : : 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Input FEC Type List Sub-Sub-TLV (opt) | 521 : : 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Input Client Signal Type Sub-TLV (opt) | 524 : : 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Input Bit Rate Range List Sub-Sub-TLV (opt) | 527 : : 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Processing Capabilities List Sub-Sub-TLV (opt) | 530 : : 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Output Modulation Type List Sub-Sub-TLV (opt) | 533 : : 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Output FEC Type List Sub-Sub-TLV (opt) | 536 : : 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 5.2. Input Modulation Format List Sub-Sub-TLV 541 This sub-TLV contains a list of acceptable input modulation formats. 543 Type := Input Modulation Format List 545 Value:= A list of Modulation Format Fields 547 5.2.1. Modulation Format Field 549 Two different types of modulation format fields are defined: a 550 standard modulation field and a vendor specific modulation field. 551 Both start with the same 32 bit header shown below. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 |S|I| Modulation ID | Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Where S bit set to 1 indicates a standardized modulation format and S 560 bit set to 0 indicates a vendor specific modulation format. The 561 length is the length in bytes of the entire modulation type field. 563 Where I bit set to 1 indicates it is an input modulation constraint 564 and I bit set to 0 indicates it is an output modulation constraint. 566 Note that if an output modulation is not specified then it is implied 567 that it is the same as the input modulation. In such case, no 568 modulation conversion is performed. 570 The format for the standardized type for the input modulation is 571 given by: 573 0 1 2 3 574 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 |1|1| Modulation ID | Length | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Possible additional modulation parameters depending upon | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 : the modulation ID : 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Modulation ID (S bit = 1); Input modulation (I bit = 1) 585 Takes on the following currently defined values: 587 0 Reserved 589 1 optical tributary signal class NRZ 1.25G 591 2 optical tributary signal class NRZ 2.5G 593 3 optical tributary signal class NRZ 10G 595 4 optical tributary signal class NRZ 40G 596 5 optical tributary signal class RZ 40G 598 Note that future modulation types may require additional parameters 599 in their characterization. 601 The format for vendor specific modulation field (for input 602 constraint) is given by: 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 |0|1| Vendor Modulation ID | Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Enterprise Number | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 : Any vendor specific additional modulation parameters : 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Vendor Modulation ID 616 This is a vendor assigned identifier for the modulation type. 618 Enterprise Number 620 A unique identifier of an organization encoded as a 32-bit integer. 621 Enterprise Numbers are assigned by IANA and managed through an IANA 622 registry [RFC2578]. 624 Vendor Specific Additional parameters 626 There can be potentially additional parameters characterizing the 627 vendor specific modulation. 629 5.3. Input FEC Type List Sub-Sub-TLV 631 This sub-TLV contains a list of acceptable FEC types. 633 Type := Input FEC Type field List 635 Value:= A list of FEC type Fields 636 5.3.1. FEC Type Field 638 The FEC type Field may consist of two different formats of fields: a 639 standard FEC field or a vendor specific FEC field. Both start with 640 the same 32 bit header shown below. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 |S|I| FEC ID | Length | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Possible additional FEC parameters depending upon | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 : the FEC ID : 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Where S bit set to 1 indicates a standardized FEC format and S bit 653 set to 0 indicates a vendor specific FEC format. The length is the 654 length in bytes of the entire FEC type field. 656 Where I bit set to 1 indicates it is an input FEC constraint and I 657 bit set to 0 indicates it is an output FEC constraint. 659 Note that if an output FEC is not specified then it is implied that 660 it is the same as the input FEC. In such case, no FEC conversion is 661 performed. 663 The length is the length in bytes of the entire FEC type field. 665 The format for input standard FEC field is given by: 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 |1|1| FEC ID | Length | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Possible additional FEC parameters depending upon | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 : the FEC ID : 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Takes on the following currently defined values for the standard 677 FEC ID: 679 0 Reserved 681 1 G.709 RS FEC 683 2 G.709V compliant Ultra FEC 685 3 G.975.1 Concatenated FEC 686 (RS(255,239)/CSOC(n0/k0=7/6,J=8)) 688 4 G.975.1 Concatenated FEC (BCH(3860,3824)/BCH(2040,1930)) 690 5 G.975.1 Concatenated FEC (RS(1023,1007)/BCH(2407,1952)) 692 6 G.975.1 Concatenated FEC (RS(1901,1855)/Extended Hamming 693 Product Code (512,502)X(510,500)) 695 7 G.975.1 LDPC Code 697 8 G.975.1 Concatenated FEC (Two orthogonally concatenated 698 BCH codes) 700 9 G.975.1 RS(2720,2550) 702 10 G.975.1 Concatenated FEC (Two interleaved extended BCH 703 (1020,988) codes) 705 Where RS stands for Reed-Solomon and BCH for Bose-Chaudhuri- 706 Hocquengham. 708 The format for input vendor-specific FEC field is given by: 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 |0|1| Vendor FEC ID | Length | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Enterprise Number | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 : Any vendor specific additional FEC parameters : 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Vendor FEC ID 722 This is a vendor assigned identifier for the FEC type. 724 Enterprise Number 726 A unique identifier of an organization encoded as a 32-bit integer. 727 Enterprise Numbers are assigned by IANA and managed through an IANA 728 registry [RFC2578]. 730 Vendor Specific Additional FEC parameters 732 There can be potentially additional parameters characterizing the 733 vendor specific FEC. 735 5.4. Input Bit Range List Sub-Sub-TLV 737 This sub-TLV contains a list of acceptable input bit rate ranges. 739 Type := Input Bit Range List 741 Value:= A list of Bit Range Fields 743 5.4.1. Bit Range Field 745 The bit rate range list sub-TLV makes use of the following bit rate 746 range field: 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Starting Bit Rate | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Ending Bit Rate | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 The starting and ending bit rates are given as 32 bit IEEE floating 757 point numbers in bits per second. Note that the starting bit rate is 758 less than or equal to the ending bit rate. 760 The bit rate range list sub-TLV is then given by: 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 +-+-+-+-+-+-+-+-+-+-+-+-+ Bit Range Field #1 +-+-+-+-+-+-+-+-+-+ 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 : : : 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | | 772 +-+-+-+-+-+-+-+-+-+-+-+-+ Bit Range Field #M +-+-+-+-+-+-+-+-+-+ 773 | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 5.5. Input Client Signal List Sub-Sub-TLV 778 This sub-TLV contains a list of acceptable input client signal types. 780 Type := Input Client Signal List 782 Value:= A list of GPIDs 784 The acceptable client signal list sub-TLV is a list of Generalized 785 Protocol Identifiers (GPIDs). GPIDs are assigned by IANA and many are 786 defined in [RFC3471] and [RFC4328]. 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Number of GPIDs | GPID #1 | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 : | : 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | GPID #N | | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Where the number of GPIDs is an integer greater than or equal to one. 800 5.6. Processing Capability List Sub-Sub-TLV 802 This sub-TLV contains a list of resource block processing 803 capabilities. 805 Type := Processing Capabilities List 807 Value:= A list of Processing Capabilities Fields 809 The processing capability list sub-TLV is a list of WSON network 810 element (NE) that can perform signal processing functions including: 812 1. Number of Resources within the block 814 2. Regeneration capability 816 3. Fault and performance monitoring 818 4. Vendor Specific capability 820 Note that the code points for Fault and performance monitoring and 821 vendor specific capability are subject to further study. 823 5.6.1. Processing Capabilities Field 825 The processing capability field is then given by: 827 0 1 2 3 828 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Processing Cap ID | Length | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Possible additional capability parameters depending upon | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 : the processing ID : 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 When the processing Cap ID is "number of resources" the format is 838 simply: 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Processing Cap ID | Length = 8 | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Number of resources per block | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 When the processing Cap ID is "regeneration capability", the 849 following additional capability parameters are provided in the sub- 850 TLV: 852 0 1 2 3 853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | T | C | Reserved | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Where T bit indicates the type of regenerator: 860 T=0: Reserved 862 T=1: 1R Regenerator 864 T=2: 2R Regenerator 866 T=3: 3R Regenerator 868 Where C bit indicates the capability of regenerator: 870 C=0: Reserved 872 C=1: Fixed Regeneration Point 874 C=2: Selective Regeneration Point 876 Note that when the capability of regenerator is indicated to be 877 Selective Regeneration Pools, regeneration pool properties such as 878 ingress and egress restrictions and availability need to be 879 specified. This encoding is to be determined in the later revision. 881 5.7. Output Modulation Format List Sub-Sub-TLV 883 This sub-TLV contains a list of available output modulation formats. 885 Type := Output Modulation Format List 887 Value:= A list of Modulation Format Fields 889 5.8. Output FEC Type List Sub-Sub-TLV 891 This sub-TLV contains a list of output FEC types. 893 Type := Output FEC Type field List 895 Value:= A list of FEC type Fields 897 6. Security Considerations 899 This document defines protocol-independent encodings for WSON 900 information and does not introduce any security issues. 902 However, other documents that make use of these encodings within 903 protocol extensions need to consider the issues and risks associated 904 with, inspection, interception, modification, or spoofing of any of 905 this information. It is expected that any such documents will 906 describe the necessary security measures to provide adequate 907 protection. 909 7. IANA Considerations 911 TBD. Once our approach is finalized we may need identifiers for the 912 various TLVs and sub-TLVs. 914 8. Acknowledgments 916 This document was prepared using 2-Word-v2.0.template.dot. 918 APPENDIX A: Encoding Examples 920 A.1. Wavelength Converter Accessibility Sub-TLV 922 Example: 924 Figure 1 shows a wavelength converter pool architecture know as 925 "shared per fiber". In this case the ingress and egress pool matrices 926 are simply: 928 +-----+ +-----+ 929 | 1 1 | | 1 0 | 930 WI =| |, WE =| | 931 | 1 1 | | 0 1 | 932 +-----+ +-----+ 934 +-----------+ +------+ 935 | |--------------------->| | 936 | |--------------------->| C | 937 /| | |--------------------->| o | 938 /D+--->| |--------------------->| m | 939 + e+--->| | | b |========> 940 ========>| M| | Optical | +-----------+ | i | Port E1 941 Port I1 + u+--->| Switch | | WC Pool | | n | 942 \x+--->| | | +-----+ | | e | 943 \| | +----+->|WC #1|--+---->| r | 944 | | | +-----+ | +------+ 945 | | | | +------+ 946 /| | | | +-----+ | | | 947 /D+--->| +----+->|WC #2|--+---->| C | 948 + e+--->| | | +-----+ | | o | 949 ========>| M| | | +-----------+ | m |========> 950 Port I2 + u+--->| | | b | Port E2 951 \x+--->| |--------------------->| i | 952 \| | |--------------------->| n | 953 | |--------------------->| e | 954 | |--------------------->| r | 955 +-----------+ +------+ 956 Figure 1 An optical switch featuring a shared per fiber wavelength 957 converter pool architecture. 959 This wavelength converter pool can be encoded as follows: 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Connectivity=1| Reserved | 965 Note: I1,I2 can connect to either WC1 or WC2 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Action=0 |0 1|0 0 0 0 0 0| Length = 12 | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Link Local Identifier = #1 | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Link Local Identifier = #2 | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Action=0 |1| Reserved | Length = 8 | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | WC ID = #1 | WC ID = #2 | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Note: WC1 can only connect to E1 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Action=0 |0| Reserved | Length = 8 | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | WC ID = #1 | zero padding | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Link Local Identifier = #1 | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Note: WC2 can only connect to E2 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Action=0 |0| | Length = 8 | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | WC ID = #2 | zero padding | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Action=0 |1 0|0 0 0 0 0 0| Length = 8 | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Link Local Identifier = #2 | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 A.2. Wavelength Conversion Range Sub-TLV 1000 Example: 1002 We give an example based on figure 1 about how to represent the 1003 wavelength conversion range of wavelength converters. Suppose the 1004 wavelength range of input and output of WC1 and WC2 are {L1, L2, L3, 1005 L4}: 1007 0 1 2 3 1008 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 1009 Note: WC Set 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Action=0 |1| Reserved | Length = 8 | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | WC ID = #1 | WC ID = #2 | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 Note: wavelength input range 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | 2 | Num Wavelengths = 4 | Length = 8 | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 |Grid | C.S. | Reserved | n for lowest frequency = 1 | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 Note: wavelength output range 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | 2 | Num Wavelengths = 4 | Length = 8 | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 |Grid | C.S. | Reserved | n for lowest frequency = 1 | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 A.3. An OEO Switch with DWDM Optics 1030 In Figure 2 we show an electronic switch fabric surrounded by DWDM 1031 optics. In this example the electronic fabric can can handle either 1032 G.709 or SDH signals only (2.5 or 10 Gbps). To describe this node we 1033 have the potential information: 1035 ::= [Other GMPLS sub- 1036 TLVs][...] [][] 1038 In this case there is complete port to port connectivity so the 1039 is not required. In addition since there are 1040 sufficient ports to handle all wavelength signals we will not need 1041 the element. 1043 Hence our attention will be focused on the sub-TLV: 1045 ::= 1046 [...][...] 1048 /| +-----------+ +-------------+ +------+ 1049 /D+--->| +--->|Tunable Laser|-->| | 1050 + e+--->| | +-------------+ | C | 1051 ========>| M| | | ... | o |========> 1052 Port I1 + u+--->| | +-------------+ | m | Port E1 1053 \x+--->| |--->|Tunable Laser|-->| b | 1054 \| | Electric | +-------------+ +------+ 1055 | Switch | 1056 /| | | +-------------+ +------+ 1057 /D+--->| +--->|Tunable Laser|-->| | 1058 + e+--->| | +-------------+ | C | 1059 ========>| M| | | ... | o |========> 1060 Port I2 + u+--->| | +-------------+ | m | Port E2 1061 \x+--->| +--->|Tunable Laser|-->| b | 1062 \| | | +-------------+ +------+ 1063 | | 1064 /| | | +-------------+ +------+ 1065 /D+--->| |--->|Tunable Laser|-->| | 1066 + e+--->| | +-------------+ | C | 1067 ========>| M| | | ... | o |========> 1068 Port I3 + u+--->| | +-------------+ | m | Port E3 1069 \x+--->| |--->|Tunable Laser|-->| b | 1070 \| +-----------+ +-------------+ +------+ 1072 Figure 2 An optical switch built around an electronic switching 1073 fabric. 1075 The resource block information will tell us about the processing 1076 constraints of the receivers, transmitters and the electronic switch. 1077 The resource availability information, although very simple, tells us 1078 that all signals must traverse the electronic fabric (fixed 1079 connectivity). The resource wavelength constraints are not needed 1080 since there are no special wavelength constraints for the resources 1081 that would not appear as port/wavelength constraints. 1083 : 1085 0 1 2 3 1086 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 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | RB Set Field | 1089 : (only one resource block in this example) | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Input Modulation Type List Sub-Sub-TLV | 1092 : (The receivers can only process NRZ) : 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Input FEC Type List Sub-Sub-TLV | 1095 : (Only Standard SDH and G.709 FECs) : 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Input Client Signal Type Sub-TLV | 1098 : (GPIDs for SDH and G.709) : 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Input Bit Rate Range List Sub-Sub-TLV | 1101 : (2.5Gbps, 10Gbps) : 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Processing Capabilities List Sub-Sub-TLV | 1104 : Fixed (non optional) 3R regeneration : 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Output Modulation Type List Sub-Sub-TLV | 1107 : NRZ : 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Output FEC Type List Sub-Sub-TLV | 1110 : Standard SDH, G.709 FECs : 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Since we have fixed connectivity to resource block (the electronic 1114 switch) we get : 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Connectivity=1|Reserved | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Ingress Link Set Field A #1 | 1122 : (All ingress links connect to resource) : 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | RB Set Field A #1 | 1125 : (trivial set only one resource block) : 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Egress Link Set Field B #1 | 1128 : (All egress links connect to resource) : 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 9. References 1133 9.1. Normative References 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, March 1997. 1138 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1139 MIB", RFC 2863, June 2000. 1141 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1142 (GMPLS) Signaling Functional Description", RFC 3471, 1143 January 2003. 1145 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 1146 applications: DWDM frequency grid", June, 2002. 1148 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 1149 in Support of Generalized Multi-Protocol Label Switching 1150 (GMPLS)", RFC 4202, October 2005 1152 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 1153 Support of Generalized Multi-Protocol Label Switching 1154 (GMPLS)", RFC 4203, October 2005. 1156 9.2. Informative References 1158 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 1159 applications: DWDM frequency grid, June 2002. 1161 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 1162 applications: CWDM wavelength grid, December 2003. 1164 [Gen-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General 1165 Network Element Constraint Encoding for GMPLS Controlled 1166 Networks", work in progress: draft-ietf-ccamp-general-ext- 1167 encode-00.txt. 1169 [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 1170 Labels for G.694 Lambda-Switching Capable Label Switching 1171 Routers", work in progress: draft-ietf-ccamp-gmpls-g-694- 1172 lambda-labels. 1174 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 1175 in Support of Generalized Multi-Protocol Label Switching 1176 (GMPLS)", RFC 5307, October 2008. 1178 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 1179 WDM Wavelength Switching Systems for Use in GMPLS and Automated 1180 Path Computation", Journal of Optical Communications and 1181 Networking, vol. 1, June, 2009, pp. 187-195. 1183 [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 1184 and PCE Control of Wavelength Switched Optical Networks", 1185 work in progress: draft-ietf-ccamp-wavelength-switched- 1186 framework, Marh 2009. 1188 [WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 1189 Wavelength Assignment Information Model for Wavelength 1190 Switched Optical Networks", work in progress: draft-ietf- 1191 ccamp-rwa-info, March 2009. 1193 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1194 Element (PCE) communication Protocol (PCEP) - Version 1", 1195 RFC5440. 1197 10. Contributors 1199 Diego Caviglia 1200 Ericsson 1201 Via A. Negrone 1/A 16153 1202 Genoa Italy 1204 Phone: +39 010 600 3736 1205 Email: diego.caviglia@(marconi.com, ericsson.com) 1207 Anders Gavler 1208 Acreo AB 1209 Electrum 236 1210 SE - 164 40 Kista Sweden 1212 Email: Anders.Gavler@acreo.se 1214 Jonas Martensson 1215 Acreo AB 1216 Electrum 236 1217 SE - 164 40 Kista, Sweden 1219 Email: Jonas.Martensson@acreo.se 1221 Itaru Nishioka 1222 NEC Corp. 1223 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1224 Japan 1226 Phone: +81 44 396 3287 1227 Email: i-nishioka@cb.jp.nec.com 1229 Authors' Addresses 1231 Greg M. Bernstein (ed.) 1232 Grotto Networking 1233 Fremont California, USA 1235 Phone: (510) 573-2237 1236 Email: gregb@grotto-networking.com 1237 Young Lee (ed.) 1238 Huawei Technologies 1239 1700 Alma Drive, Suite 100 1240 Plano, TX 75075 1241 USA 1243 Phone: (972) 509-5599 (x2240) 1244 Email: ylee@huawei.com 1246 Dan Li 1247 Huawei Technologies Co., Ltd. 1248 F3-5-B R&D Center, Huawei Base, 1249 Bantian, Longgang District 1250 Shenzhen 518129 P.R.China 1252 Phone: +86-755-28973237 1253 Email: danli@huawei.com 1255 Wataru Imajuku 1256 NTT Network Innovation Labs 1257 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1258 Japan 1260 Phone: +81-(46) 859-4315 1261 Email: imajuku.wataru@lab.ntt.co.jp 1263 Jianrui Han 1264 Huawei Technologies Co., Ltd. 1265 F3-5-B R&D Center, Huawei Base, 1266 Bantian, Longgang District 1267 Shenzhen 518129 P.R.China 1269 Phone: +86-755-28972916 1270 Email: hanjianrui@huawei.com 1272 Intellectual Property Statement 1274 The IETF Trust takes no position regarding the validity or scope of 1275 any Intellectual Property Rights or other rights that might be 1276 claimed to pertain to the implementation or use of the technology 1277 described in any IETF Document or the extent to which any license 1278 under such rights might or might not be available; nor does it 1279 represent that it has made any independent effort to identify any 1280 such rights. 1282 Copies of Intellectual Property disclosures made to the IETF 1283 Secretariat and any assurances of licenses to be made available, or 1284 the result of an attempt made to obtain a general license or 1285 permission for the use of such proprietary rights by implementers or 1286 users of this specification can be obtained from the IETF on-line IPR 1287 repository at http://www.ietf.org/ipr 1289 The IETF invites any interested party to bring to its attention any 1290 copyrights, patents or patent applications, or other proprietary 1291 rights that may cover technology that may be required to implement 1292 any standard or specification contained in an IETF Document. Please 1293 address the information to the IETF at ietf-ipr@ietf.org. 1295 Disclaimer of Validity 1297 All IETF Documents and the information contained therein are provided 1298 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1299 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1300 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1301 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1302 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1303 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1304 FOR A PARTICULAR PURPOSE. 1306 Acknowledgment 1308 Funding for the RFC Editor function is currently provided by the 1309 Internet Society.