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