idnits 2.17.1 draft-bernstein-ccamp-wson-signaling-07.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5038 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) == Unused Reference: 'WSON-CompOSPF' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'Winzer06' is defined on line 834, but no explicit reference was found in the text == Unused Reference: 'G.959.1' is defined on line 841, but no explicit reference was found in the text == Unused Reference: 'G.694.1' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'G.Sup43' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'RFC4427' is defined on line 856, but no explicit reference was found in the text -- No information found for draft-lee-ccamp-wson-signal-compatibility-OSPF - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 8 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 Sugang Xu 4 NICT 5 Expires: January 2011 Y.Lee 6 Huawei 7 Hiroaki Harai 8 NICT 10 July 12, 2010 12 Signaling Extensions for Wavelength Switched Optical Networks 13 draft-bernstein-ccamp-wson-signaling-07.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on January 12, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 This memo provides extensions to Generalized Multi-Protocol Label 56 Switching (GMPLS) signaling for control of wavelength switched optical 57 networks (WSON). Such extensions are necessary in WSONs under a number 58 of conditions including: (a) when optional processing, such as 59 regeneration, must be configured to occur at specific nodes along a 60 path, (b) where equipment must be configured to accept an optical signal 61 with specific attributes, or (c) where equipment must be configured to 62 output an optical signal with specific attributes. In addition this memo 63 provides mechanisms to support distributed wavelength assignment with 64 bidirectional LSPs, and choice in distributed wavelength assignment 65 algorithms. These extensions build on previous work for the control of 66 lambda and G.709 based networks. 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 [RFC2119]. 74 Table of Contents 76 1. Introduction...................................................3 77 2. Terminology....................................................3 78 3. Requirements for WSON Signaling................................4 79 3.1. WSON Signal Characterization..............................4 80 3.2. Per LSP Network Element Processing Configuration..........5 81 3.3. Bi-Directional Distributed Wavelength Assignment..........5 82 3.4. Distributed Wavelength Assignment Support.................7 83 3.5. Out of Scope..............................................7 84 4. WSON Signal Traffic Parameters, Attributes and Processing......7 85 4.1. Traffic Parameters for Optical Tributary Signals..........7 86 4.2. Signal Attributes and Processing..........................7 87 4.2.1. Modulation Type sub-TLV..............................8 88 4.2.2. FEC Type sub-TLV....................................10 89 4.2.3. Regeneration Processing TLV.........................12 90 5. Bidirectional Lightpath using Same Wavelength.................13 91 5.1. Using LSP_ATTRIBUTES Object..............................13 92 5.2. Bidirectional Lightpath Signaling Procedure..............14 93 5.3. Backward Compatibility Considerations....................15 95 6. Bidirectional Lightpath using Different Wavelengths...........15 96 7. RWA Related...................................................15 97 7.1. Wavelength Set Metric....................................15 98 7.2. Wavelength Assignment Method Selection...................17 99 8. Security Considerations.......................................17 100 9. IANA Considerations...........................................18 101 10. Acknowledgments..............................................18 102 11. References...................................................19 103 11.1. Normative References....................................19 104 11.2. Informative References..................................19 105 Author's Addresses...............................................21 106 Intellectual Property Statement..................................22 107 Disclaimer of Validity...........................................22 109 1. Introduction 111 This memo provides extensions to Generalized Multi-Protocol Label 112 Switching (GMPLS) signaling for control of wavelength switched 113 optical networks (WSON). Fundamental extensions are given to permit 114 simultaneous bi-directional wavelength assignment while more advanced 115 extensions are given to support the networks described in [WSON- 116 Frame] which feature connections requiring configuration of input, 117 output, and general signal processing capabilities at a node along a 118 LSP 120 These extensions build on previous work for the control of lambda and 121 G.709 based networks. 123 2. Terminology 125 CWDM: Coarse Wavelength Division Multiplexing. 127 DWDM: Dense Wavelength Division Multiplexing. 129 FOADM: Fixed Optical Add/Drop Multiplexer. 131 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 132 count wavelength selective switching element featuring ingress and 133 egress line side ports as well as add/drop side ports. 135 RWA: Routing and Wavelength Assignment. 137 Wavelength Conversion/Converters: The process of converting an 138 information bearing optical signal centered at a given wavelength to 139 one with "equivalent" content centered at a different wavelength. 140 Wavelength conversion can be implemented via an optical-electronic- 141 optical (OEO) process or via a strictly optical process. 143 WDM: Wavelength Division Multiplexing. 145 Wavelength Switched Optical Networks (WSON): WDM based optical 146 networks in which switching is performed selectively based on the 147 center wavelength of an optical signal. 149 AWG: Arrayed Waveguide Grating. 151 OXC: Optical Cross Connect. 153 Optical Transmitter: A device that has both a laser tuned on certain 154 wavelength and electronic components, which converts electronic 155 signals into optical signals. 157 Optical Responder: A device that has both optical and electronic 158 components. It detects optical signals and converts optical signals 159 into electronic signals. 161 Optical Transponder: A device that has both an optical transmitter 162 and an optical responder. 164 Optical End Node: The end of a wavelength (optical lambdas) lightpath 165 in the data plane. It may be equipped with some optical/electronic 166 devices such as wavelength multiplexers/demultiplexer (e.g. AWG), 167 optical transponder, etc., which are employed to transmit/terminate 168 the optical signals for data transmission. 170 3. Requirements for WSON Signaling 172 The following requirements for GMPLS based WSON signaling are in 173 addition to the functionality already provided by existing GMPLS 174 signaling mechanisms. 176 3.1. WSON Signal Characterization 178 WSON signaling MUST convey sufficient information characterizing the 179 signal to allow systems along the path to determine compatibility and 180 perform any required local configuration. Examples of such systems 181 include intermediate nodes (ROADMs, OXCs, Wavelength converters, 182 Regenerators, OEO Switches, etc...), links (WDM systems) and end 183 systems (detectors, demodulators, etc...). The details of any local 184 configuration processes are out of the scope of this document. 186 From [WSON-Frame] we have the following list of WSON signal 187 characteristic information: 189 List 1. WSON Signal Characteristics 191 1. Optical tributary signal class (modulation format). 192 2. FEC: whether forward error correction is used in the digital stream 193 and what type of error correcting code is used 194 3. Center frequency (wavelength) 195 4. Bit rate 196 5. G-PID: General Protocol Identifier for the information format 198 The first three items on this list can change as a WSON signal 199 traverses a network with regenerators, OEO switches, or wavelength 200 converters. An ability to control wavelength conversion already 201 exists in GMPLS signaling along with the ability to share client 202 signal type information (G-PID). In addition, bit rate is a standard 203 GMPLS signaling traffic parameter. It is referred to as Bandwidth 204 Encoding in [RFC3471]. This leaves two new parameters: modulation 205 format and FEC type, needed to fully characterize the optical signal. 207 3.2. Per LSP Network Element Processing Configuration 209 In addition to configuring a network element (NE) along an LSP to 210 input or output a signal with specific attributes, we may need to 211 signal the NE to perform specific processing, such as 3R 212 regeneration, on the signal at a particular NE. In [WSON-Frame] we 213 discussed three types of processing not currently covered by GMPLS: 215 (A) Regeneration (possibly different types) 217 (B) Fault and Performance Monitoring 219 (C) Attribute Conversion 221 The extensions here MUST provide for the configuration of these types 222 of processing at nodes along an LSP. 224 3.3. Bi-Directional Distributed Wavelength Assignment 226 WSON signaling MAY support distributed wavelength assignment 227 consistent with the wavelength continuity constraint for bi- 228 directional connections. The following two cases MAY be separately 229 supported: (a) Where the same wavelength is used for both upstream 230 and downstream directions, and (b) Where different wavelengths can be 231 used for both upstream and downstream directions. 233 The need for the same wavelength on both directions mainly comes from 234 the color constraint on some edges' hardware. In fact, the edges can 235 be classified into two types, i.e. without and with the wavelength- 236 port mapping re-configurability. 238 Without the mapping re-configurability at edges, the edge nodes must 239 use the same wavelength in both directions. For example, (1) 240 transponders are only connected to AWGs (i.e. multiplexer/de- 241 multiplexer) ports directly and fixedly, or (2) transponders are 242 connected to the add/drop ports of ROADM and each port is mapped to a 243 dedicated wavelength fixedly. 245 On the other hand, with the mapping re-configurability at edges, the 246 edge nodes can use different wavelengths in different directions. For 247 example, in edge nodes, transponders are connected to add/drop ports 248 of colorless ROADM. Thus, the wavelength-port remapping problem can 249 be solved locally by appropriately configuring the colorless ROADM. 250 If the colorless ROADM consists of OXC and AWGs, the OXC is 251 configured appropriately. 253 The edges of data-plane in WSON can be constructed in different types 254 based on cost and flexibility concerns. Without re-configurability 255 we should consider the constraint of the same wavelength usage on 256 both directions, but have lower costs. While, with wavelength-port 257 mapping re-configurability we can relax the constraint, but have 258 higher costs. 260 These two types of edges will co-exist in WSON mesh, till all the 261 edges are unified by the same type. The existence of the first type 262 edges presents a requirement of the same wavelength usage on both 263 directions, which must be supported. 265 Moreover, if some carriers prefer an easy management lightpath usage, 266 say use the same wavelength on both directions to reduce the burden 267 on lightpath management, the same wavelength usage would be 268 beneficial. 270 In cases of equipment failure, etc., fast provisioning used in quick 271 recovery is critical to protect Carriers/Users against system loss. 272 This requires efficient signaling which supports distributed 273 wavelength assignment, in particular when the centralized wavelength 274 assignment capability is not available. 276 3.4. Distributed Wavelength Assignment Support 278 WSON signaling MAY support the selection of a specific distributed 279 wavelength assignment method. 281 As discussed in the [WSON-Frame] a variety of different wavelength 282 assignment algorithms have been developed. A number of these are 283 suitable for use in distributed wavelength assignment. This feature 284 would allow the specification of a particular approach when more than 285 one are implemented in the systems along the path. 287 3.5. Out of Scope 289 This draft does not address signaling information related to optical 290 impairments. 292 4. WSON Signal Traffic Parameters, Attributes and Processing 294 As discussed in [WSON-Frame] single channel optical signals used in 295 WSONs are called "optical tributary signals" and come in a number of 296 classes characterized by modulation format and bit rate. Although 297 WSONs are fairly transparent to the signals they carry, to ensure 298 compatibility amongst various networks devices and end systems it can 299 be important to include key lightpath characteristics as traffic 300 parameters in signaling [WSON-Frame]. 302 4.1. Traffic Parameters for Optical Tributary Signals 304 In [RFC3471] we see that the G-PID (client signal type) and bit rate 305 (byte rate) of the signals are defined as parameters and in [RFC3473] 306 they are conveyed Generalized Label Request object and the RSVP 307 SENDER_TSPEC/FLOWSPEC objects respectively. 309 4.2. Signal Attributes and Processing 311 Section 3.2. gave the requirements for signaling to indicate to a 312 particular NE along an LSP what type of processing to perform on an 313 optical signal or how to configure that NE to accept or transmit an 314 optical signal with particular attributes. 316 One way of accomplishing this is via a new EXPLICIT_ROUTE subobject. 317 Reference [RFC3209] defines the EXPLICIT_ROUTE object (ERO) and a 318 number of subobjects, while reference [RFC5420] defines general 319 mechanisms for dealing with additional LSP attributes. Although 320 reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes 321 subobject, it does not define an ERO subobject for LSP attributes. 323 Regardless of the exact coding for the ERO subobject conveying the 324 input, output, or processing instructions. This new "processing" 325 subobject would follow a subobject containing the IP address, or the 326 interface identifier [RFC3477], associated with the link on which it 327 is to be used along with any label subobjects [RFC3473]. 329 The contents of this new "processing" subobject would be a list of 330 TLVs that could include: 332 o Modulation Type TLV (input and/or output) 334 o FEC Type TLV (input and/or output) 336 o Processing Instruction TLV 338 Currently the only processing instruction TLV currently defined is 339 for regeneration. Possible encodings and values for these TLV are 340 given in below. 342 4.2.1. Modulation Type sub-TLV 344 The modulation type sub-TLV may come in two different formats: a 345 standard modulation field or a vendor specific modulation field. Both 346 start with the same 32 bit header shown below. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |S|I| Modulation ID | Length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Where S bit set to 1 indicates a standardized modulation format and S 355 bit set to 0 indicates a vendor specific modulation format. The 356 length is the length in bytes of the entire modulation type field. 358 Where I bit set to 1 indicates an input modulation format and where I 359 bit set to 0 indicates an output modulation format. Note that the 360 source modulation type is implied when I bit is set to 0 and that the 361 sink modulation type is implied when I bit is set to 1. For signaling 362 purposes only the output form (I=0) is needed. 364 The format for the standardized type is given by: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |1|I| Modulation ID | Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Possible additional modulation parameters depending upon | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 : the modulation ID : 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Modulation ID 378 Takes on the following currently defined values: 380 0 Reserved 382 1 optical tributary signal class NRZ 1.25G 384 2 optical tributary signal class NRZ 2.5G 386 3 optical tributary signal class NRZ 10G 388 4 optical tributary signal class NRZ 40G 390 5 optical tributary signal class RZ 40G 392 Note that future modulation types may require additional parameters 393 in their characterization. 395 The format for vendor specific modulation is given by: 397 0 1 2 3 398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |0|I| Vendor Modulation ID | Length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Enterprise Number | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 : Any vendor specific additional modulation parameters : 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Vendor Modulation ID 409 This is a vendor assigned identifier for the modulation type. 411 Enterprise Number 413 A unique identifier of an organization encoded as a 32-bit integer. 414 Enterprise Numbers are assigned by IANA and managed through an IANA 415 registry [RFC2578]. 417 Vendor Specific Additional parameters 419 There can be potentially additional parameters characterizing the 420 vendor specific modulation. 422 4.2.2. FEC Type sub-TLV 424 The FEC Type TLV indicates the FEC type output at particular node 425 along the LSP. The FEC type sub-TLV comes in two different types: a 426 standard FEC field or a vendor specific FEC field. Both start with 427 the same 32 bit header shown below. 429 0 1 2 3 430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 |S|I| FEC ID | Length | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Possible additional FEC parameters depending upon | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 : the FEC ID : 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Where S bit set to 1 indicates a standardized FEC format and S bit 440 set to 0 indicates a vendor specific FEC format. The length is the 441 length in bytes of the entire FEC type field. 443 Where the length is the length in bytes of the entire FEC type field. 445 Where I bit set to 1 indicates an input FEC format and where I bit 446 set to 0 indicates an output FEC format. Note that the source FEC 447 type is implied when I bit is set to 0 and that the sink FEC type is 448 implied when I bit is set to 1. Only the output form (I=0) is used in 449 signaling. 451 The format for standard FEC field is given by: 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |1|I| FEC ID | Length | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Possible additional FEC parameters depending upon | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 : the FEC ID : 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Takes on the following currently defined values for the standard 464 FEC ID [G.709, G.975.1]: 466 0 Reserved 468 1 G.709 RS FEC 470 2 G.709V compliant Ultra FEC 472 3 G.975.1 Concatenated FEC 473 (RS(255,239)/CSOC(n0/k0=7/6,J=8)) 475 4 G.975.1 Concatenated FEC (BCH(3860,3824)/BCH(2040,1930)) 477 5 G.975.1 Concatenated FEC (RS(1023,1007)/BCH(2407,1952)) 479 6 G.975.1 Concatenated FEC (RS(1901,1855)/Extended Hamming 480 Product Code (512,502)X(510,500)) 482 7 G.975.1 LDPC Code 484 8 G.975.1 Concatenated FEC (Two orthogonally concatenated 485 BCH codes) 487 9 G.975.1 RS(2720,2550) 489 10 G.975.1 Concatenated FEC (Two interleaved extended BCH 490 (1020,988) codes) 492 Where RS stands for Reed-Solomon and BCH for Bose-Chaudhuri- 493 Hocquengham. 495 The format for vendor-specific FEC field is given by: 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 |0|I| Vendor FEC ID | Length | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Enterprise Number | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 : Any vendor specific additional FEC parameters : 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Vendor FEC ID 509 This is a vendor assigned identifier for the FEC type. 511 Enterprise Number 513 A unique identifier of an organization encoded as a 32-bit integer. 514 Enterprise Numbers are assigned by IANA and managed through an IANA 515 registry [RFC2578]. 517 Vendor Specific Additional FEC parameters 519 There can be potentially additional parameters characterizing the 520 vendor specific FEC. 522 4.2.3. Regeneration Processing TLV 524 The Regeneration Processing TLV is used to indicate that this 525 particular node is to perform the specified type of regeneration 526 processing on the signal. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | T | C | Reserved | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Where T bit indicates the type of regenerator: 536 T=0: Reserved 537 T=1: 1R Regenerator 539 T=2: 2R Regenerator 541 T=3: 3R Regenerator 543 Where C bit indicates the capability of regenerator: 545 C=0: Reserved 547 C=1: Fixed Regeneration Point 549 C=2: Selective Regeneration Pools 551 Note that the use of the C field is optional in signaling. 553 5. Bidirectional Lightpath using Same Wavelength 555 With the wavelength continuity constraint in CI-incapable [RFC3471] 556 WSONs, where the nodes in the networks cannot support wavelength 557 conversion, the same wavelength on each link along a unidirectional 558 lightpath should be reserved. Per the definition in [RFC3471], a 559 bidirectional lightpath can be seen as a pair of unidirectional 560 lightpaths, which are provisioned along the same route simultaneously 561 by the RSVP-TE signaling with Upstream Label and Label Set Objects in 562 the messages [RFC3473]. This does not necessarily require the same 563 wavelength in both directions. 565 In addition to the wavelength continuity constraint, requirement 3.2 566 gives us another constraint on wavelength usage in data plane, in 567 particular, it requires the same wavelength to be used in both 568 directions. 570 The simplest and efficient way is to only define an extension to the 571 processing of Label Set [RFC3473], and leave the other processes 572 untouched. The issues related to this new functionality including an 573 LSP_ATTRIBUTES object defined in [RFC5420] and the new procedure are 574 described in the following sections. This approach would have a lower 575 blocking probability and a shorter provisioning time. In cases of 576 equipment failure, etc., fast provisioning used in quick recovery is 577 critical to protect Carriers/Users against system loss. 579 5.1. Using LSP_ATTRIBUTES Object 581 To trigger the new functionality at each GMPLS node, it is necessary 582 to notify the receiver the new type lightpath request. One multi- 583 purpose flag/attribute parameter container object called 584 LSP_ATTRIBUTES object and related mechanism defined in [RFC5420] meet 585 this requirement. One bit in Attributes Flags TLV which indicates the 586 new type lightpath, say, the bidirectional same wavelength lightpath 587 will be present in an LSP_ATTRIBUTES object. Please refer to 588 [RFC5420] for detailed descriptions of the Flag and related issues. 590 5.2. Bidirectional Lightpath Signaling Procedure 592 Considering the system configuration mentioned above, it is needed to 593 add a new function into RSVP-TE to support bidirectional lightpath 594 with same wavelength on both directions. 596 The lightpath setup procedure is described below: 598 1. Ingress node adds the new type lightpath indication in an 599 LSP_ATTRIBUTES object. It is propagated in the Path message in 600 the same way as that of a Label Set object for downstream; 602 2. On reception of a Path message containing both the new type 603 lightpath indication in an LSP_ATTRIBUTES object and Label Set 604 object, the receiver of message along the path checks the local 605 LSP database to see if the Label Set TLVs are acceptable on both 606 directions jointly. If there are acceptable wavelengths, then 607 copy the values of them into new Label Set TLVs, and forward the 608 Path message to the downstream node. Otherwise the Path message 609 will be terminated, and a PathErr message with a "Routing 610 problem/Label Set" indication will be generated; 612 3. On reception of a Path message containing both such a new type 613 lightpath indication in an LSP_ATTRIBUTES object and an Upstream 614 Label object, the receiver MUST terminate the Path message using 615 a PathErr message with Error Code "Unknown Attributes TLV" and 616 Error Value set to the value of the new type lightpath TLV type 617 code; 619 4. On reception of a Path message containing both the new type 620 lightpath indication in an LSP_ATTRIBUTES object and Label Set 621 object, the egress node verifies whether the Label Set TLVs are 622 acceptable, if one or more wavelengths are available on both 623 directions, then any one available wavelength could be selected. 624 A Resv message is generated and propagated to upstream node; 626 5. When a Resv message is received at an intermediate node, if it is 627 a new type lightpath, the intermediate node allocates the label 628 to interfaces on both directions and update internal database for 629 this bidirectional same wavelength lightpath, then configures the 630 local ROADM or OXC on both directions. 632 Except the procedure related to Label Set object, the other processes 633 will be left untouched. 635 5.3. Backward Compatibility Considerations 637 Due to the introduction of new processing on Label Set object, it is 638 required that each node in the lightpath is able to recognize the new 639 type lightpath indication Flag carried by an LSP_ATTRIBUTES object, 640 and deal with the new Label Set operation correctly. It is noted 641 that this new extension is not backward compatible. 643 According to the descriptions in [RFC5420], an LSR that does not 644 recognize a TLV type code carried in this object MUST reject the Path 645 message using a PathErr message with Error Code "Unknown Attributes 646 TLV" and Error Value set to the value of the Attributes Flags TLV 647 type code. 649 An LSR that does not recognize a bit set in the Attributes Flags TLV 650 MUST reject the Path message using a PathErr message with Error Code 651 "Unknown Attributes Bit" and Error Value set to the bit number of the 652 new type lightpath Flag in the Attributes Flags.The reader is 653 referred to the detailed backward compatibility considerations 654 expressed in [RFC5420]. 656 6. Bidirectional Lightpath using Different Wavelengths 658 TBD 660 7. RWA Related 662 7.1. Wavelength Set Metric 664 Distributed wavelength assignment makes extensive use of the label 665 set object/TLV of [RFC3471]. Some wavelength assignment algorithms 666 require supplemental information concerning the potential lambdas to 667 be used. An ordered set of TLVs in correspondence with the group of 668 one or more label set TLVs can be used to convey this information in 669 the form of a general wavelength "acceptability" metric. 671 Note that the label set syntax of [RFC3471] allows group of 672 wavelengths into ranges. For the purpose of supplementing this 673 information with wavelength count only those wavelengths with the 674 same counts could be grouped. 676 The general format for supplemental wavelength selection information 677 could be as follows: 679 The information carried in a Wavelength Set Metric TLV is: 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Info Type | Metric Size | Num Metrics | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Wavelength Metric Info | 687 | From lowest to highest frequency if more that one value | 688 | ... | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 Info Type: 8 bits 693 0 - Single Value 695 The enclosed single value for the wavelength metric is given to all 696 wavelengths in the corresponding wavelength set. 698 1 - List 700 The enclosed list gets applied in a one-to-one fashion to each 701 wavelength in the corresponding wavelength set. An error occurs if 702 the number of metrics in this list and the number of wavelengths in 703 the wavelength set is not equal. 705 Metric Size: 707 Indicates the size of the wavelength metric information as follows 709 0 - 8 bits 711 1 - 16 bits 713 2 - 32 bits 715 Number 0f Metrics: 24 bits 717 Wavelength Metric: (1, 2, or 4 octets) 718 The wavelength metric represents in some fashion the desirability or 719 lack thereof to use this wavelength over another available 720 wavelength. Different wavelength assignment algorithms may use this 721 information differently. 723 7.2. Wavelength Assignment Method Selection 725 As discussed in [HZang00] a number of different wavelength assignment 726 algorithms maybe employed. In addition as discussed in [WSON-Frame] 727 the wavelength assignment can be either for a unidirectional 728 lightpath or for a bidirectional lightpath constrained to use the 729 same lambda in both directions. A simple TLV could be used to 730 indication wavelength assignment directionality and wavelength 731 assignment method. This would be placed in an LSP_REQUIRED_ATTRIBUTES 732 object per [RFC5420]. The use of a TLV in the LSP required attributes 733 object was pointed out in [Xu]. 735 [TO DO: The directionality stuff needs to be reconciled with the 736 earlier material] 738 Directionality: 0 unidirectional, 1 bidirectional 740 Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2 741 Random, 3 Least-Loaded (multi-fiber). Others TBD. 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Direction | WA Method | Reserved | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 [TBD: Should we have a vendor specific extension mechanism or bits 750 allocated for private use for the case of non-standardized methods?] 752 8. Security Considerations 754 This document has no requirement for a change to the security models 755 within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE, 756 and PCEP security models could be operated unchanged. 758 However satisfying the requirements for RWA using the existing 759 protocols may significantly affect the loading of those protocols. 761 This makes the operation of the network more vulnerable to denial of 762 service attacks. Therefore additional care maybe required to ensure 763 that the protocols are secure in the WSON environment. 765 Furthermore the additional information distributed in order to 766 address the RWA problem represents a disclosure of network 767 capabilities that an operator may wish to keep private. Consideration 768 should be given to securing this information. 770 9. IANA Considerations 772 TBD. Once finalized in our approach we will need identifiers for such 773 things and modulation types, modulation parameters, wavelength 774 assignment methods, etc... 776 10. Acknowledgments 778 This document was prepared using 2-Word-v2.0.template.dot. 780 11. References 782 11.1. Normative References 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, March 1997. 787 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 788 "Structure of Management Information Version 2 (SMIv2)", 789 STD 58, RFC 2578, April 1999. 791 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 792 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 793 Tunnels", RFC 3209, December 2001. 795 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 796 (GMPLS) Signaling Functional Description", RFC 3471, 797 January 2003. 799 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 800 Switching (GMPLS) Signaling Resource ReserVation Protocol- 801 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 802 January 2003. 804 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 805 in Resource ReSerVation Protocol - Traffic Engineering 806 (RSVP-TE)", RFC 3477, January 2003. 808 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. 809 Ayyangar, " Encoding of Attributes for MPLS LSP 810 Establishment Using Resource Reservation Protocol Traffic 811 Engineering (RSVP-TE)", RFC 5420, February 2006. 813 11.2. Informative References 815 [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal 816 and Network Element Compatibility for Wavelength Switched 817 Optical Networks", work in progress: draft-lee-ccamp-wson- 818 signal-compatibility-OSPF. 820 [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 821 and PCE Control of Wavelength Switched Optical Networks", 822 work in progress: draft-bernstein-ccamp-wavelength- 823 switched-03.txt, February 2008. 825 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing and 826 wavelength assignment approaches for wavelength-routed 827 optical WDM networks", Optical Networks Magazine, January 828 2000. 830 [Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE 831 for Bidirectional Lightpath the Same Wavelength", work in 832 progress: draft-xu-rsvpte-bidir-wave-01, November 2007. 834 [Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced 835 Optical Modulation Formats", Proceedings of the IEEE, vol. 836 94, no. 5, pp. 952-985, May 2006. 838 [G.709] ITU-T Recommendation G.709, Interfaces for the Optical 839 Transport Network(OTN), March 2003. 841 [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network 842 Physical Layer Interfaces, March 2006. 844 [G.975.1] ITU-T Recommendation G.975.1, Forward error correction for 845 high bit-rate DWDM submarine systems, February, 2004. 847 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 848 applications: DWDM frequency grid, June 2002. 850 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 851 applications: CWDM wavelength grid, December 2003. 853 [G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R 854 in optical transport networks (OTN), November 2006. 856 [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery 857 (Protection and Restoration) Terminology for Generalized 858 Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 859 2006. 861 Author's Addresses 863 Greg M. Bernstein (editor) 864 Grotto Networking 865 Fremont California, USA 867 Phone: (510) 573-2237 868 Email: gregb@grotto-networking.com 870 Nicola Andriolli 871 Scuola Superiore Sant'Anna, Pisa, Italy 872 Email: nick@sssup.it 874 Alessio Giorgetti 875 Scuola Superiore Sant'Anna, Pisa, Italy 876 Email: a.giorgetti@sssup.it 878 Lin Guo 879 Key Laboratory of Optical Communication and Lightwave Technologies 880 Ministry of Education 881 P.O. Box 128, Beijing University of Posts and Telecommunications, 882 P.R.China 883 Email: guolintom@gmail.com 885 Hiroaki Harai 886 National Institute of Information and Communications Technology 887 4-2-1 Nukui-Kitamachi, Koganei, 888 Tokyo, 184-8795 Japan 890 Phone: +81 42-327-5418 891 Email: harai@nict.go.jp 893 Yuefeng Ji 894 Key Laboratory of Optical Communication and Lightwave Technologies 895 Ministry of Education 896 P.O. Box 128, Beijing University of Posts and Telecommunications, 897 P.R.China 898 Email: jyf@bupt.edu.cn 900 Daniel King 901 Old Dog Consulting 903 Email: daniel@olddog.co.uk 905 Young Lee (editor) 906 Huawei Technologies 907 1700 Alma Drive, Suite 100 908 Plano, TX 75075 909 USA 911 Phone: (972) 509-5599 (x2240) 912 Email: ylee@huawei.com 914 Sugang Xu 915 National Institute of Information and Communications Technology 916 4-2-1 Nukui-Kitamachi, Koganei, 917 Tokyo, 184-8795 Japan 919 Phone: +81 42-327-6927 920 Email: xsg@nict.go.jp 922 Intellectual Property Statement 924 The IETF Trust takes no position regarding the validity or scope of 925 any Intellectual Property Rights or other rights that might be 926 claimed to pertain to the implementation or use of the technology 927 described in any IETF Document or the extent to which any license 928 under such rights might or might not be available; nor does it 929 represent that it has made any independent effort to identify any 930 such rights. 932 Copies of Intellectual Property disclosures made to the IETF 933 Secretariat and any assurances of licenses to be made available, or 934 the result of an attempt made to obtain a general license or 935 permission for the use of such proprietary rights by implementers or 936 users of this specification can be obtained from the IETF on-line IPR 937 repository at http://www.ietf.org/ipr 939 The IETF invites any interested party to bring to its attention any 940 copyrights, patents or patent applications, or other proprietary 941 rights that may cover technology that may be required to implement 942 any standard or specification contained in an IETF Document. Please 943 address the information to the IETF at ietf-ipr@ietf.org. 945 Disclaimer of Validity 947 All IETF Documents and the information contained therein are provided 948 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 949 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 950 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 951 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 952 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 953 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 954 FOR A PARTICULAR PURPOSE. 956 Acknowledgment 958 Funding for the RFC Editor function is currently provided by the 959 Internet Society.