idnits 2.17.1 draft-ietf-ccamp-wson-signal-compatibility-ospf-08.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 24, 2012) is 4385 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: 'G.694.1' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'Gen-Encode' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC6250' is defined on line 400, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' Summary: 0 errors (**), 0 flaws (~~), 5 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: October 2012 Grotto Networking 6 April 24, 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-08.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 October 24, 2012. 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 April 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..........7 84 3. WSON Specific Scalability and Timeliness.......................7 85 4. Security Considerations........................................8 86 5. IANA Considerations............................................8 87 6. References....................................................10 89 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 90 2012 92 6.1. Normative References.....................................10 93 6.2. Informative References...................................10 94 7. Authors and Contributors......................................11 95 Authors' Addresses...............................................11 96 Intellectual Property Statement..................................12 97 Disclaimer of Validity...........................................12 99 1. Introduction 101 The documents [RFC6163, WSON-Info, WSON-Encode] explain how to 102 extend the wavelength switched optical network (WSON) control plane 103 to allow both multiple WSON signal types and common hybrid electro 104 optical systems as well hybrid systems containing optical switching 105 and electro-optical resources. In WSON, not all of the optical 106 signals in the network are compatible with all network elements 107 participating in the network. Therefore, signal compatibility is an 108 important constraint in path computation in a WSON. 110 This document provides GMPLS OSPF routing enhancements to support 111 signal compatibility constraints associated with general WSON 112 network elements. These routing enhancements are required in common 113 optical or hybrid electro-optical networks where not all of the 114 optical signals in the network are compatible with all network 115 elements participating in the network. 117 This compatibility constraint model is applicable to common optical 118 or hybrid electro optical systems such as OEO switches, 119 regenerators, and wavelength converters since such systems can be 120 limited to processing only certain types of WSON signals. 122 1.1. Revision History 124 From 00 to 01: The details of the encodings for compatibility moved 125 from this document to [WSON-Encode]. 127 From 01 to 02: Editorial changes. 129 From 02 to 03: Add a new Top Level Node TLV, Optical Node Property 130 TLV to carry WSON specific node information. 132 From 03 to 04: Add a new sub-TLV, Block Shared Access Wavelength 133 Availability TLV to be consistent with [WSON-Encode] and editorial 134 changes. 136 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 137 2012 139 From 04 to 05: Add a new section that discusses OSPF scalability and 140 timeliness and editorial changes. 142 From 05 to 06: Change the title of the draft to "GMPLS OSPF 143 Enhancement" from "OSPF Enhancement" to make sure the changes apply 144 to the GMPLS OSPF rather than the base OSPF. Add specific OSPF 145 procedures on how sub-TLVs are packaged per [RFC3630] and editorial 146 changes. 148 From 06 to 07: Add clarifying texts on how to sub-divide the Optical 149 Node TLV in case it exceeds the IP MTU fragmentation limit. Delete 150 Section 3.2. to avoid multiple rules so as to avoid confusion. 152 From 07 to 08: Clean some old texts in Section 3. Align with [WSON- 153 Encode] on the modulation and FEC type. 155 2. The Optical Node Property TLV 157 [RFC3630] defines OSPF TE LSA using an opaque LSA. This document 158 adds a new top level TLV for use in the OSPF TE LSA: the Optical 159 Node Property TLV. The Optical Node property TLV describes a single 160 node. It is constructed of a set of sub-TLVs. There are no ordering 161 requirements for the sub-TLVs. Only one Optical Node TLV shall be 162 advertised in each LSA. 164 The Optical Node Property TLV contains all WSON-specific node 165 properties and signal compatibility constraints. The detailed 166 encodings of these properties are defined in [WSON-Encode]. 168 The following sub-TLVs of the Optical Node Property TLV are defined: 170 Value Length Sub-TLV Type 172 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 173 2012 175 TBA variable Resource Block Information 176 TBA variable Resource Pool Accessibility 177 TBA variable Resource Block Wavelength Constraints 178 TBA variable Resource Pool State 179 TBA variable Block Shared Access Wavelength Availability 181 The detail encodings of these sub-TLVs are found in [WSON-Encode] as 182 indicated in the table below. 184 Sub-TLV Type Section [WSON-Encode] 186 Resource Block Information 4.1 187 Resource Pool Accessibility 3.1 188 Resource Block Wavelength Constraints 3.2 189 Resource Pool State 3.3 190 Block Shared Access Wavelength Availability 3.4 192 All sub-TLVs defined here may occur at most once in any given 193 Optical Node TLV. "At most once" means that if there is sub-TLV 194 related information, it should be always included. These 195 restrictions need not apply to future sub-TLVs. Unrecognized sub- 196 TLVs are ignored. 198 2.1. Sub-TLV Details 200 Among the sub-TLVs defined above, the Resource Pool State sub-TLV 201 and Block Shared Access Wavelength Availability are dynamic in 202 nature while the rest are static. As such, they can be separated out 203 from the rest and be advertised with multiple TE LSAs per OSPF 204 router, as described in [RFC3630] and [RFC5250]. Resource Block 205 Information 207 Resource Block Information sub-TLVs are used to convey relatively 208 static information about individual resource blocks including the 209 resource block properties and the number of resources in a block. 211 There are five nested sub-TLVs defined in the Resource Block 212 Information sub-TLV. 214 Value Length Sub-TLV Type 216 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 217 2012 219 TBA variable Modulation Format List 220 TBA variable FEC Type List 221 TBA variable Input Bit Range List 222 TBA variable Input Client Signal List 223 TBA variable Processing Capability List 225 The detail encodings of these sub-TLVs are found in [WSON-Encode] as 226 indicated in the table below. 228 Name Section [WSON-Encode] 230 Modulation Format List 4.2 231 FEC Type List 4.3 232 Input Bit Range List 4.4 233 Input Client Signal List 4.5 234 Processing Capability List 4.6 236 2.1.1. Resource Pool Accessibility 238 This sub-TLV describes the structure of the resource pool in 239 relation to the switching device. In particular it indicates the 240 ability of an ingress port to reach a resource block and of a 241 resource block to reach a particular egress port. 243 2.1.2. Resource Block Wavelength Constraints 245 Resources, such as wavelength converters, etc., may have a limited 246 input or output wavelength ranges. Additionally, due to the 247 structure of the optical system not all wavelengths can necessarily 248 reach or leave all the resources. Resource Block Wavelength 249 Constraints sub-TLV describe these properties. 251 2.1.3. Resource Pool State 253 This sub-TLV describes the usage state of a resource that can be 254 encoded as either a list of 16 bit integer values or a bit map 255 indicating whether a single resource is available or in use. This 256 information can be relatively dynamic, i.e., can change when a 257 connection is established or torn down. 259 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 260 2012 262 2.1.4. Block Shared Access Wavelength Availability 264 Resources blocks may be accessed via a shared fiber. If this is the 265 case then wavelength availability on these shared fibers is needed 266 to understand resource availability. 268 3. WSON Specific Scalability and Timeliness 270 This document has defined five sub-TLVs specific to WSON. The 271 examples given in [WSON-Encode] show that very large systems, in 272 terms of channel count, ports, or resources, can be very efficiently 273 encoded. 275 There has been concern expressed that some possible systems may 276 produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In 277 a typical node configuration, the optical node property TLV will not 278 exceed the IP MTU. In a rare case where the TLV exceed the IP MTU, 279 IP fragmentation/reassembly can be used, which is an acceptable 280 method. 282 If the size of this LSA is greater than the MTU, then these sub-TLVs 283 can be packed into separate LSAs. From the point of view of path 284 computation, the presence of the Resource Block Information sub-TLV 285 indicates that resources exist in the system and may have signal 286 compatibility or other constraints. The other four sub-TLVs indicate 287 constraints on access to, and availability of those resources. 289 Hence the "synchronization" procedure from a path computation point 290 of view is quite simple. Until a Resource Block Information sub-TLV 291 is received for a system path cannot make use of the other four sub- 292 TLVs since it does not know the nature of the resources, e.g., are 293 the resources wavelength converters, regenerators, or something 294 else. Once this sub-TLV is received path computation can proceed 295 with whatever of the additional types of sub-TLVs it may have 296 received (there use is dependent upon the system type). If path 297 computation proceeds with out of date or missing information from 298 these sub-TLVs then there is the possibility of either (a) path 299 computation computing a path that does not exist in the network, (b) 300 path computation failing to find a path through the network that 301 actually exists. Both situations are currently encountered with 302 GMPLS, i.e., out of date information on constraints or resource 303 availability. 305 Note that the connection establishment mechanism (signaling or 306 management) is ultimately responsible for the establishment of the 308 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 309 2012 311 connection, and this implies that such mechanisms must insure signal 312 compatibility. 314 4. Security Considerations 316 This document does not introduce any further security issues other 317 than those discussed in [RFC3630], [RFC4203]. 319 5. IANA Considerations 321 This document introduces a new Top Level Node TLV (Optical Node 322 Property TLV) under the OSPF TE LSA defined in [RFC3630]. 324 Value TLV Type 326 TBA Optical Node Property 328 IANA is to allocate a new TLV Type and its Value for this Top Level 329 Node TLV. 331 This document also introduces the following sub-TLVs associated with 332 the Optical Node Property TLV as defined in Section 2.1 as follows: 334 Value Length Sub-TLV Type 336 TBA variable Resource Block Information 337 TBA variable Resource Pool Accessibility 338 TBA variable Resource Block Wavelength Constraints 339 TBA variable Resource Pool State 340 TBA variable Block Shared Access Wavelength Availability 342 IANA is to allocate new sub-TLV Types and their Values for these 343 sub-TLVs defined under the Optical Node Property TLV. 345 There are five nested sub-TLVs defined in the Resource Block 346 Information sub-TLV as follows: 348 Value Length Sub-TLV Type 350 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 351 2012 353 TBA variable Modulation Format List 354 TBA variable FEC Type List 355 TBA variable Input Bit Range List 356 TBA variable Input Client Signal List 357 TBA variable Processing Capability List 359 IANA is to allocate new Sub-TLV Types and their Values for these 360 Sub-TLVs defined under the Resource Block Information Sub-TLV. 362 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 363 2012 365 6. References 367 6.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 373 Engineering (TE) Extensions to OSPF Version 2", RFC 374 3630, September 2003. 376 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 377 applications: DWDM frequency grid", June, 2002. 379 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 380 in Support of Generalized Multi-Protocol Label Switching 381 (GMPLS)", RFC 4203, October 2005. 383 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 384 Wavelength Assignment Information Encoding for Wavelength 385 Switched Optical Networks", draft-ietf-ccamp-rwa-wson- 386 encode, work in progress. 388 [Gen-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General 389 Network Element Constraint Encoding for GMPLS Controlled 390 Networks", draft-ietf-ccamp-general-constraint-encode, 391 work in progress. 393 6.2. Informative References 395 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 396 Wavelength Assignment Information Model for Wavelength 397 Switched Optical Networks", draft-ietf-ccamp-rwa-info, 398 work in progress. 400 [RFC6250] T. Otani, Ed., D. Li, Ed., "Generalized Labels for G.694 401 Lambda-Switching Capable Label Switching Routers", RFC 402 6250, March 2011. 404 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 405 2012 407 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 408 and PCE Control of Wavelength Switched Optical Networks", 409 RFC 6163, April 2011. 411 [RFC5250] Berger, L., et al., "The OSPF Opauqe LSA option", RFC 412 5250, July 2008. 414 7. Authors and Contributors 416 Authors' Addresses 418 Young Lee (ed.) 419 Huawei Technologies 420 1700 Alma Drive, Suite 100 421 Plano, TX 75075 422 USA 424 Phone: (972) 509-5599 (x2240) 425 Email: ylee@huawei.com 427 Greg M. Bernstein (ed.) 428 Grotto Networking 429 Fremont California, USA 431 Phone: (510) 573-2237 432 Email: gregb@grotto-networking.com 434 Internet-Draft OSPF Enhancement for WSON Signal Compatibility April 435 2012 437 Intellectual Property Statement 439 The IETF Trust takes no position regarding the validity or scope of 440 any Intellectual Property Rights or other rights that might be 441 claimed to pertain to the implementation or use of the technology 442 described in any IETF Document or the extent to which any license 443 under such rights might or might not be available; nor does it 444 represent that it has made any independent effort to identify any 445 such rights. 447 Copies of Intellectual Property disclosures made to the IETF 448 Secretariat and any assurances of licenses to be made available, or 449 the result of an attempt made to obtain a general license or 450 permission for the use of such proprietary rights by implementers or 451 users of this specification can be obtained from the IETF on-line 452 IPR repository at http://www.ietf.org/ipr 454 The IETF invites any interested party to bring to its attention any 455 copyrights, patents or patent applications, or other proprietary 456 rights that may cover technology that may be required to implement 457 any standard or specification contained in an IETF Document. Please 458 address the information to the IETF at ietf-ipr@ietf.org. 460 Disclaimer of Validity 462 All IETF Documents and the information contained therein are 463 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 464 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 465 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 466 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 467 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 468 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 469 FOR A PARTICULAR PURPOSE. 471 Acknowledgment 473 Funding for the RFC Editor function is currently provided by the 474 Internet Society.