idnits 2.17.1 draft-ietf-ccamp-wson-signal-compatibility-ospf-12.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 (September 30, 2013) is 3858 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: 'RFC 4202' is mentioned on line 279, but not defined == Unused Reference: 'G.694.1' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC6250' is defined on line 484, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Lee 2 Internet Draft Huawei 3 Intended status: Standards Track G. Bernstein 4 Expires: March 2014 Grotto Networking 6 September 30, 2013 8 GMPLS OSPF Enhancement for Signal and Network Element Compatibility 9 for Wavelength Switched Optical Networks 11 draft-ietf-ccamp-wson-signal-compatibility-ospf-12.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on August 30, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 42 2013 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 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 This document provides GMPLS OSPF routing enhancements to support 57 signal compatibility constraints associated with WSON network 58 elements. These routing enhancements are required in common optical 59 or hybrid electro-optical networks where not all of the optical 60 signals in the network are compatible with all network elements 61 participating in the network. 63 This compatibility constraint model is applicable to common optical 64 or hybrid electro optical systems such as OEO switches, 65 regenerators, and wavelength converters since such systems can be 66 limited to processing only certain types of WSON signals. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119 [RFC2119]. 74 Table of Contents 76 1. Introduction...................................................3 77 1.1. Revision History..........................................3 78 2. The Optical Node Property TLV..................................4 79 2.1. Sub-TLV Details...........................................5 80 2.1.1. Resource Pool Accessibility..........................6 81 2.1.2. Resource Block Wavelength Constraints................6 82 2.1.3. Resource Pool State..................................6 83 2.1.4. Block Shared Access Wavelength Availability..........6 84 3. ISCD format extensions.........................................7 85 3.1. Switch Capability Specific Information....................7 86 4. WSON Specific Scalability and Timeliness.......................8 87 5. Security Considerations........................................9 89 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 90 2013 92 6. IANA Considerations............................................9 93 7. References....................................................11 94 7.1. Normative References.....................................11 95 7.2. Informative References...................................11 96 8. Authors and Contributors......................................12 97 Authors' Addresses...............................................12 98 Intellectual Property Statement..................................13 99 Disclaimer of Validity...........................................13 101 1. Introduction 103 The documents [RFC6163, WSON-Info, WSON-Encode] explain how to 104 extend the wavelength switched optical network (WSON) control plane 105 to allow both multiple WSON signal types and common hybrid electro 106 optical systems as well hybrid systems containing optical switching 107 and electro-optical resources. In WSON, not all of the optical 108 signals in the network are compatible with all network elements 109 participating in the network. Therefore, signal compatibility is an 110 important constraint in path computation in a WSON. 112 This document provides GMPLS OSPF routing enhancements to support 113 signal compatibility constraints associated with general WSON 114 network elements. These routing enhancements are required in common 115 optical or hybrid electro-optical networks where not all of the 116 optical signals in the network are compatible with all network 117 elements participating in the network. 119 This compatibility constraint model is applicable to common optical 120 or hybrid electro optical systems such as OEO switches, 121 regenerators, and wavelength converters since such systems can be 122 limited to processing only certain types of WSON signals. 124 1.1. Revision History 126 From 00 to 01: The details of the encodings for compatibility moved 127 from this document to [WSON-Encode]. 129 From 01 to 02: Editorial changes. 131 From 02 to 03: Add a new Top Level Node TLV, Optical Node Property 132 TLV to carry WSON specific node information. 134 From 03 to 04: Add a new sub-TLV, Block Shared Access Wavelength 135 Availability TLV to be consistent with [WSON-Encode] and editorial 136 changes. 138 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 139 2013 141 From 04 to 05: Add a new section that discusses OSPF scalability and 142 timeliness and editorial changes. 144 From 05 to 06: Change the title of the draft to "GMPLS OSPF 145 Enhancement" from "OSPF Enhancement" to make sure the changes apply 146 to the GMPLS OSPF rather than the base OSPF. Add specific OSPF 147 procedures on how sub-TLVs are packaged per [RFC3630] and editorial 148 changes. 150 From 06 to 07: Add clarifying texts on how to sub-divide the Optical 151 Node TLV in case it exceeds the IP MTU fragmentation limit. Delete 152 Section 3.2. to avoid multiple rules so as to avoid confusion. 154 From 07 to 08: Clean some old texts in Section 3. Align with [WSON- 155 Encode] on the modulation and FEC type. 157 From 08 to 09: Added ISCD extensions for available labels and shared 158 backup labels. 160 From 09 to 10: Revised for OIC changes consistent with encoding 161 document. 163 From 10 to 11: Editorial clean-up only. 165 From 11 to 12: Revived the expired version. 167 2. The Optical Node Property TLV 169 [RFC3630] defines OSPF TE LSA using an opaque LSA. This document 170 adds a new top level TLV for use in the OSPF TE LSA: the Optical 171 Node Property TLV. The Optical Node property TLV describes a single 172 node. It is constructed of a set of sub-TLVs. There are no ordering 173 requirements for the sub-TLVs. Only one Optical Node TLV shall be 174 advertised in each LSA. 176 The Optical Node Property TLV contains all WSON-specific node 177 properties and signal compatibility constraints. The detailed 178 encodings of these properties are defined in [WSON-Encode]. 180 The following sub-TLVs of the Optical Node Property TLV are defined: 182 Value Length Sub-TLV Type 184 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 185 2013 187 TBA variable Resource Block Information 188 TBA variable Resource Pool Accessibility 189 TBA variable Resource Block Wavelength Constraints 190 TBA variable Resource Pool State 191 TBA variable Block Shared Access Wavelength Availability 193 The detail encodings of these sub-TLVs are found in [WSON-Encode] as 194 indicated in the table below. 196 Sub-TLV Type Section [WSON-Encode] 198 Resource Block Information 5.1 199 Resource Pool Accessibility 4.1 200 Resource Block Wavelength Constraints 4.2 201 Resource Pool State 4.3 202 Block Shared Access Wavelength Availability 4.4 204 All sub-TLVs defined here may occur at most once in any given 205 Optical Node TLV. "At most once" means that if there is sub-TLV 206 related information, it should be always included. These 207 restrictions need not apply to future sub-TLVs. Unrecognized sub- 208 TLVs are ignored. 210 2.1. Sub-TLV Details 212 Among the sub-TLVs defined above, the Resource Pool State sub-TLV 213 and Block Shared Access Wavelength Availability are dynamic in 214 nature while the rest are static. As such, they can be separated out 215 from the rest and be advertised with multiple TE LSAs per OSPF 216 router, as described in [RFC3630] and [RFC5250]. Resource Block 217 Information 219 Resource Block Information sub-TLVs are used to convey relatively 220 static information about individual resource blocks including the 221 resource block properties and the number of resources in a block. 223 There are five nested sub-TLVs defined in the Resource Block 224 Information sub-TLV. 226 Value Length Sub-TLV Type 228 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 229 2013 231 TBA variable Optical Interface Class List 232 TBA variable Input Client Signal List 233 TBA variable Processing Capability List 235 The detail encodings of these sub-TLVs are found in [WSON-Encode] as 236 indicated in the table below. 238 Name Section [WSON-Encode] 240 Optical Interface Class List 5.2 241 Input Client Signal List 5.3 242 Processing Capability List 5.4 244 2.1.1. Resource Pool Accessibility 246 This sub-TLV describes the structure of the resource pool in 247 relation to the switching device. In particular it indicates the 248 ability of an ingress port to reach a resource block and of a 249 resource block to reach a particular egress port. 251 2.1.2. Resource Block Wavelength Constraints 253 Resources, such as wavelength converters, etc., may have a limited 254 input or output wavelength ranges. Additionally, due to the 255 structure of the optical system not all wavelengths can necessarily 256 reach or leave all the resources. Resource Block Wavelength 257 Constraints sub-TLV describe these properties. 259 2.1.3. Resource Pool State 261 This sub-TLV describes the usage state of a resource that can be 262 encoded as either a list of 16 bit integer values or a bit map 263 indicating whether a single resource is available or in use. This 264 information can be relatively dynamic, i.e., can change when a 265 connection is established or torn down. 267 2.1.4. Block Shared Access Wavelength Availability 269 Resources blocks may be accessed via a shared fiber. If this is the 270 case then wavelength availability on these shared fibers is needed 271 to understand resource availability. 273 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 274 2013 276 3. ISCD format extensions 278 The Interface Switching Capability Descriptor describes switching 279 capability of an interface [RFC 4202]. This document defines a new 280 Switching Capability value for WSON as follows: 282 Value Type 283 ----- ---- 284 151 (TBA by IANA) WSON-LSC capable (WSON-LSC) 286 Switching Capability and Encoding values MUST be used as follows: 288 Switching Capability = WSON-LSC 290 Encoding Type = Lambda [as defined in RFC3471] 292 When Switching Capability and Encoding fields are set to values as 293 stated above, the Interface Switching Capability Descriptor MUST be 294 interpreted as in RFC4203 with the optional inclusion of one or more 295 Switching Capability Specific Information sub-TLVs. 297 3.1. Switch Capability Specific Information 299 The technology specific part of the WSON ISCD may include a variable 300 number of sub-TLVs called Bandwidth sub-TLVs. Two types of 301 Bandwidth TLV are defined (TBA by IANA): 303 - Type 1 - Available Labels 305 - Type 2 - Shared Backup Labels 307 The format of the SCSI MUST be as depicted in the following figure: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type = 1 (Available) | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 | Available Label Sub-TLV | 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 ~ ... ~ 320 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 321 2013 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type = 2 (Shared backup) | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 | Shared Backup Label Sub-TLV | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 1: SCSI format 333 Where the Available Label Sub-TLV and Shared Backup Label sub-TLV 334 are defined in [Gen-Encode]. 336 4. WSON Specific Scalability and Timeliness 338 This document has defined five sub-TLVs specific to WSON. The 339 examples given in [WSON-Encode] show that very large systems, in 340 terms of channel count, ports, or resources, can be very efficiently 341 encoded. 343 There has been concern expressed that some possible systems may 344 produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In 345 a typical node configuration, the optical node property TLV will not 346 exceed the IP MTU. In a rare case where the TLV exceed the IP MTU, 347 IP fragmentation/reassembly can be used, which is an acceptable 348 method. 350 If the size of this LSA is greater than the MTU, then these sub-TLVs 351 can be packed into separate LSAs. From the point of view of path 352 computation, the presence of the Resource Block Information sub-TLV 353 indicates that resources exist in the system and may have signal 354 compatibility or other constraints. The other four sub-TLVs indicate 355 constraints on access to, and availability of those resources. 357 Hence the "synchronization" procedure from a path computation point 358 of view is quite simple. Until a Resource Block Information sub-TLV 359 is received for a system path cannot make use of the other four sub- 360 TLVs since it does not know the nature of the resources, e.g., are 361 the resources wavelength converters, regenerators, or something 362 else. Once this sub-TLV is received path computation can proceed 363 with whatever of the additional types of sub-TLVs it may have 364 received (there use is dependent upon the system type). If path 365 computation proceeds with out of date or missing information from 367 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 368 2013 370 these sub-TLVs then there is the possibility of either (a) path 371 computation computing a path that does not exist in the network, (b) 372 path computation failing to find a path through the network that 373 actually exists. Both situations are currently encountered with 374 GMPLS, i.e., out of date information on constraints or resource 375 availability. 377 Note that the connection establishment mechanism (signaling or 378 management) is ultimately responsible for the establishment of the 379 connection, and this implies that such mechanisms must insure signal 380 compatibility. 382 5. Security Considerations 384 This document does not introduce any further security issues other 385 than those discussed in [RFC3630], [RFC4203]. 387 6. IANA Considerations 389 This document introduces a new Top Level Node TLV (Optical Node 390 Property TLV) under the OSPF TE LSA defined in [RFC3630]. 392 Value TLV Type 394 TBA Optical Node Property 396 IANA is to allocate a new TLV Type and its Value for this Top Level 397 Node TLV. 399 This document also introduces the following sub-TLVs associated with 400 the Optical Node Property TLV as defined in Section 2.1 as follows: 402 Value Length Sub-TLV Type 404 TBA variable Resource Block Information 405 TBA variable Resource Pool Accessibility 406 TBA variable Resource Block Wavelength Constraints 407 TBA variable Resource Pool State 408 TBA variable Block Shared Access Wavelength Availability 410 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 411 2013 413 IANA is to allocate new sub-TLV Types and their Values for these 414 sub-TLVs defined under the Optical Node Property TLV. 416 There are three nested sub-TLVs defined in the Resource Block 417 Information sub-TLV as follows: 419 Value Length Sub-TLV Type 421 TBA variable Optical Interface Class List 422 TBA variable Input Client Signal List 423 TBA variable Processing Capability List 425 IANA is to allocate new Sub-TLV Types and their Values for these 426 Sub-TLVs defined under the Resource Block Information Sub-TLV. 428 Upon approval of this document, IANA will make the assignment of a 429 new Switching Capability value for the existing ISCD located at http: 430 //www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng- 431 tlvs.xml: 433 15 Interface Switching Capability Descriptor [RFC4203] 435 Switching capability Description Reference 436 ---------------------- -------------------------- ---------- 437 151 (suggested) WSON-LSC capable (WSON-LSC) [This.I-D] 439 This document defines the following sub-TLVs of the ISCD TLV: 441 Value Sub-TLV 442 ----- ------------------------------------------------- 443 1 Available Labels 444 2 Shared Backup Labels 446 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 447 2013 449 7. References 451 7.1. Normative References 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 457 Engineering (TE) Extensions to OSPF Version 2", RFC 458 3630, September 2003. 460 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 461 applications: DWDM frequency grid", June, 2002. 463 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 464 in Support of Generalized Multi-Protocol Label Switching 465 (GMPLS)", RFC 4203, October 2005. 467 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 468 Wavelength Assignment Information Encoding for Wavelength 469 Switched Optical Networks", draft-ietf-ccamp-rwa-wson- 470 encode, work in progress. 472 [Gen-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General 473 Network Element Constraint Encoding for GMPLS Controlled 474 Networks", draft-ietf-ccamp-general-constraint-encode, 475 work in progress. 477 7.2. Informative References 479 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 480 Wavelength Assignment Information Model for Wavelength 481 Switched Optical Networks", draft-ietf-ccamp-rwa-info, 482 work in progress. 484 [RFC6250] T. Otani, Ed., D. Li, Ed., "Generalized Labels for G.694 485 Lambda-Switching Capable Label Switching Routers", RFC 486 6250, March 2011. 488 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 489 2013 491 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 492 and PCE Control of Wavelength Switched Optical Networks", 493 RFC 6163, April 2011. 495 [RFC5250] Berger, L., et al., "The OSPF Opauqe LSA option", RFC 496 5250, July 2008. 498 8. Authors and Contributors 500 Authors' Addresses 502 Young Lee (ed.) 503 Huawei Technologies 504 1700 Alma Drive, Suite 100 505 Plano, TX 75075 506 USA 508 Phone: (972) 509-5599 (x2240) 509 Email: ylee@huawei.com 511 Greg M. Bernstein (ed.) 512 Grotto Networking 513 Fremont California, USA 515 Phone: (510) 573-2237 516 Email: gregb@grotto-networking.com 518 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 519 2013 521 Intellectual Property Statement 523 The IETF Trust takes no position regarding the validity or scope of 524 any Intellectual Property Rights or other rights that might be 525 claimed to pertain to the implementation or use of the technology 526 described in any IETF Document or the extent to which any license 527 under such rights might or might not be available; nor does it 528 represent that it has made any independent effort to identify any 529 such rights. 531 Copies of Intellectual Property disclosures made to the IETF 532 Secretariat and any assurances of licenses to be made available, or 533 the result of an attempt made to obtain a general license or 534 permission for the use of such proprietary rights by implementers or 535 users of this specification can be obtained from the IETF on-line 536 IPR repository at http://www.ietf.org/ipr 538 The IETF invites any interested party to bring to its attention any 539 copyrights, patents or patent applications, or other proprietary 540 rights that may cover technology that may be required to implement 541 any standard or specification contained in an IETF Document. Please 542 address the information to the IETF at ietf-ipr@ietf.org. 544 Disclaimer of Validity 546 All IETF Documents and the information contained therein are 547 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 548 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 549 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 550 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 551 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 552 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 553 FOR A PARTICULAR PURPOSE. 555 Acknowledgment 557 Funding for the RFC Editor function is currently provided by the 558 Internet Society.