idnits 2.17.1 draft-ietf-ccamp-wson-signal-compatibility-ospf-11.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 6, 2013) is 4068 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 277, but not defined == Unused Reference: 'G.694.1' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC6250' is defined on line 482, 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: August 2013 Grotto Networking 6 February 6, 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-11.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 February 6, 2007. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 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 February 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 February 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 2. The Optical Node Property TLV 167 [RFC3630] defines OSPF TE LSA using an opaque LSA. This document 168 adds a new top level TLV for use in the OSPF TE LSA: the Optical 169 Node Property TLV. The Optical Node property TLV describes a single 170 node. It is constructed of a set of sub-TLVs. There are no ordering 171 requirements for the sub-TLVs. Only one Optical Node TLV shall be 172 advertised in each LSA. 174 The Optical Node Property TLV contains all WSON-specific node 175 properties and signal compatibility constraints. The detailed 176 encodings of these properties are defined in [WSON-Encode]. 178 The following sub-TLVs of the Optical Node Property TLV are defined: 180 Value Length Sub-TLV Type 182 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 183 2013 185 TBA variable Resource Block Information 186 TBA variable Resource Pool Accessibility 187 TBA variable Resource Block Wavelength Constraints 188 TBA variable Resource Pool State 189 TBA variable Block Shared Access Wavelength Availability 191 The detail encodings of these sub-TLVs are found in [WSON-Encode] as 192 indicated in the table below. 194 Sub-TLV Type Section [WSON-Encode] 196 Resource Block Information 5.1 197 Resource Pool Accessibility 4.1 198 Resource Block Wavelength Constraints 4.2 199 Resource Pool State 4.3 200 Block Shared Access Wavelength Availability 4.4 202 All sub-TLVs defined here may occur at most once in any given 203 Optical Node TLV. "At most once" means that if there is sub-TLV 204 related information, it should be always included. These 205 restrictions need not apply to future sub-TLVs. Unrecognized sub- 206 TLVs are ignored. 208 2.1. Sub-TLV Details 210 Among the sub-TLVs defined above, the Resource Pool State sub-TLV 211 and Block Shared Access Wavelength Availability are dynamic in 212 nature while the rest are static. As such, they can be separated out 213 from the rest and be advertised with multiple TE LSAs per OSPF 214 router, as described in [RFC3630] and [RFC5250]. Resource Block 215 Information 217 Resource Block Information sub-TLVs are used to convey relatively 218 static information about individual resource blocks including the 219 resource block properties and the number of resources in a block. 221 There are five nested sub-TLVs defined in the Resource Block 222 Information sub-TLV. 224 Value Length Sub-TLV Type 226 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 227 2013 229 TBA variable Optical Interface Class List 230 TBA variable Input Client Signal List 231 TBA variable Processing Capability List 233 The detail encodings of these sub-TLVs are found in [WSON-Encode] as 234 indicated in the table below. 236 Name Section [WSON-Encode] 238 Optical Interface Class List 5.2 239 Input Client Signal List 5.3 240 Processing Capability List 5.4 242 2.1.1. Resource Pool Accessibility 244 This sub-TLV describes the structure of the resource pool in 245 relation to the switching device. In particular it indicates the 246 ability of an ingress port to reach a resource block and of a 247 resource block to reach a particular egress port. 249 2.1.2. Resource Block Wavelength Constraints 251 Resources, such as wavelength converters, etc., may have a limited 252 input or output wavelength ranges. Additionally, due to the 253 structure of the optical system not all wavelengths can necessarily 254 reach or leave all the resources. Resource Block Wavelength 255 Constraints sub-TLV describe these properties. 257 2.1.3. Resource Pool State 259 This sub-TLV describes the usage state of a resource that can be 260 encoded as either a list of 16 bit integer values or a bit map 261 indicating whether a single resource is available or in use. This 262 information can be relatively dynamic, i.e., can change when a 263 connection is established or torn down. 265 2.1.4. Block Shared Access Wavelength Availability 267 Resources blocks may be accessed via a shared fiber. If this is the 268 case then wavelength availability on these shared fibers is needed 269 to understand resource availability. 271 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 272 2013 274 3. ISCD format extensions 276 The Interface Switching Capability Descriptor describes switching 277 capability of an interface [RFC 4202]. This document defines a new 278 Switching Capability value for WSON as follows: 280 Value Type 281 ----- ---- 282 151 (TBA by IANA) WSON-LSC capable (WSON-LSC) 284 Switching Capability and Encoding values MUST be used as follows: 286 Switching Capability = WSON-LSC 288 Encoding Type = Lambda [as defined in RFC3471] 290 When Switching Capability and Encoding fields are set to values as 291 stated above, the Interface Switching Capability Descriptor MUST be 292 interpreted as in RFC4203 with the optional inclusion of one or more 293 Switching Capability Specific Information sub-TLVs. 295 3.1. Switch Capability Specific Information 297 The technology specific part of the WSON ISCD may include a variable 298 number of sub-TLVs called Bandwidth sub-TLVs. Two types of 299 Bandwidth TLV are defined (TBA by IANA): 301 - Type 1 - Available Labels 303 - Type 2 - Shared Backup Labels 305 The format of the SCSI MUST be as depicted in the following figure: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type = 1 (Available) | Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | 313 | Available Label Sub-TLV | 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ ... ~ 318 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 319 2013 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type = 2 (Shared backup) | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | 325 | Shared Backup Label Sub-TLV | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 1: SCSI format 331 Where the Available Label Sub-TLV and Shared Backup Label sub-TLV 332 are defined in [Gen-Encode]. 334 4. WSON Specific Scalability and Timeliness 336 This document has defined five sub-TLVs specific to WSON. The 337 examples given in [WSON-Encode] show that very large systems, in 338 terms of channel count, ports, or resources, can be very efficiently 339 encoded. 341 There has been concern expressed that some possible systems may 342 produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In 343 a typical node configuration, the optical node property TLV will not 344 exceed the IP MTU. In a rare case where the TLV exceed the IP MTU, 345 IP fragmentation/reassembly can be used, which is an acceptable 346 method. 348 If the size of this LSA is greater than the MTU, then these sub-TLVs 349 can be packed into separate LSAs. From the point of view of path 350 computation, the presence of the Resource Block Information sub-TLV 351 indicates that resources exist in the system and may have signal 352 compatibility or other constraints. The other four sub-TLVs indicate 353 constraints on access to, and availability of those resources. 355 Hence the "synchronization" procedure from a path computation point 356 of view is quite simple. Until a Resource Block Information sub-TLV 357 is received for a system path cannot make use of the other four sub- 358 TLVs since it does not know the nature of the resources, e.g., are 359 the resources wavelength converters, regenerators, or something 360 else. Once this sub-TLV is received path computation can proceed 361 with whatever of the additional types of sub-TLVs it may have 362 received (there use is dependent upon the system type). If path 363 computation proceeds with out of date or missing information from 365 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 366 2013 368 these sub-TLVs then there is the possibility of either (a) path 369 computation computing a path that does not exist in the network, (b) 370 path computation failing to find a path through the network that 371 actually exists. Both situations are currently encountered with 372 GMPLS, i.e., out of date information on constraints or resource 373 availability. 375 Note that the connection establishment mechanism (signaling or 376 management) is ultimately responsible for the establishment of the 377 connection, and this implies that such mechanisms must insure signal 378 compatibility. 380 5. Security Considerations 382 This document does not introduce any further security issues other 383 than those discussed in [RFC3630], [RFC4203]. 385 6. IANA Considerations 387 This document introduces a new Top Level Node TLV (Optical Node 388 Property TLV) under the OSPF TE LSA defined in [RFC3630]. 390 Value TLV Type 392 TBA Optical Node Property 394 IANA is to allocate a new TLV Type and its Value for this Top Level 395 Node TLV. 397 This document also introduces the following sub-TLVs associated with 398 the Optical Node Property TLV as defined in Section 2.1 as follows: 400 Value Length Sub-TLV Type 402 TBA variable Resource Block Information 403 TBA variable Resource Pool Accessibility 404 TBA variable Resource Block Wavelength Constraints 405 TBA variable Resource Pool State 406 TBA variable Block Shared Access Wavelength Availability 408 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 409 2013 411 IANA is to allocate new sub-TLV Types and their Values for these 412 sub-TLVs defined under the Optical Node Property TLV. 414 There are three nested sub-TLVs defined in the Resource Block 415 Information sub-TLV as follows: 417 Value Length Sub-TLV Type 419 TBA variable Optical Interface Class List 420 TBA variable Input Client Signal List 421 TBA variable Processing Capability List 423 IANA is to allocate new Sub-TLV Types and their Values for these 424 Sub-TLVs defined under the Resource Block Information Sub-TLV. 426 Upon approval of this document, IANA will make the assignment of a 427 new Switching Capability value for the existing ISCD located at http: 428 //www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng- 429 tlvs.xml: 431 15 Interface Switching Capability Descriptor [RFC4203] 433 Switching capability Description Reference 434 ---------------------- -------------------------- ---------- 435 151 (suggested) WSON-LSC capable (WSON-LSC) [This.I-D] 437 This document defines the following sub-TLVs of the ISCD TLV: 439 Value Sub-TLV 440 ----- ------------------------------------------------- 441 1 Available Labels 442 2 Shared Backup Labels 444 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 445 2013 447 7. References 449 7.1. Normative References 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 455 Engineering (TE) Extensions to OSPF Version 2", RFC 456 3630, September 2003. 458 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 459 applications: DWDM frequency grid", June, 2002. 461 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 462 in Support of Generalized Multi-Protocol Label Switching 463 (GMPLS)", RFC 4203, October 2005. 465 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 466 Wavelength Assignment Information Encoding for Wavelength 467 Switched Optical Networks", draft-ietf-ccamp-rwa-wson- 468 encode, work in progress. 470 [Gen-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General 471 Network Element Constraint Encoding for GMPLS Controlled 472 Networks", draft-ietf-ccamp-general-constraint-encode, 473 work in progress. 475 7.2. Informative References 477 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 478 Wavelength Assignment Information Model for Wavelength 479 Switched Optical Networks", draft-ietf-ccamp-rwa-info, 480 work in progress. 482 [RFC6250] T. Otani, Ed., D. Li, Ed., "Generalized Labels for G.694 483 Lambda-Switching Capable Label Switching Routers", RFC 484 6250, March 2011. 486 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 487 2013 489 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 490 and PCE Control of Wavelength Switched Optical Networks", 491 RFC 6163, April 2011. 493 [RFC5250] Berger, L., et al., "The OSPF Opauqe LSA option", RFC 494 5250, July 2008. 496 8. Authors and Contributors 498 Authors' Addresses 500 Young Lee (ed.) 501 Huawei Technologies 502 1700 Alma Drive, Suite 100 503 Plano, TX 75075 504 USA 506 Phone: (972) 509-5599 (x2240) 507 Email: ylee@huawei.com 509 Greg M. Bernstein (ed.) 510 Grotto Networking 511 Fremont California, USA 513 Phone: (510) 573-2237 514 Email: gregb@grotto-networking.com 516 Internet-Draft OSPF Enhancement for WSON Signal Compatibility February 517 2013 519 Intellectual Property Statement 521 The IETF Trust takes no position regarding the validity or scope of 522 any Intellectual Property Rights or other rights that might be 523 claimed to pertain to the implementation or use of the technology 524 described in any IETF Document or the extent to which any license 525 under such rights might or might not be available; nor does it 526 represent that it has made any independent effort to identify any 527 such rights. 529 Copies of Intellectual Property disclosures made to the IETF 530 Secretariat and any assurances of licenses to be made available, or 531 the result of an attempt made to obtain a general license or 532 permission for the use of such proprietary rights by implementers or 533 users of this specification can be obtained from the IETF on-line 534 IPR repository at http://www.ietf.org/ipr 536 The IETF invites any interested party to bring to its attention any 537 copyrights, patents or patent applications, or other proprietary 538 rights that may cover technology that may be required to implement 539 any standard or specification contained in an IETF Document. Please 540 address the information to the IETF at ietf-ipr@ietf.org. 542 Disclaimer of Validity 544 All IETF Documents and the information contained therein are 545 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 546 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 547 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 548 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 549 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 550 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 551 FOR A PARTICULAR PURPOSE. 553 Acknowledgment 555 Funding for the RFC Editor function is currently provided by the 556 Internet Society.