idnits 2.17.1 draft-ietf-ccamp-wson-signal-compatibility-ospf-06.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 (September 14, 2011) is 4602 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 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 2012 Grotto Networking 6 September 14, 2011 8 GMPLS OSPF Enhancement for Signal and Network Element Compatibility 9 for Wavelength Switched Optical Networks 11 draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 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 months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 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 March 14, 2007. 36 Copyright Notice 38 Copyright (c) 2011 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 2011 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 respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 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, regenerators, 65 and wavelength converters since such systems can be limited to 66 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 Block Information...........................5 81 2.1.2. Resource Pool Accessibility..........................6 82 2.1.3. Resource Block Wavelength Constraints................6 83 2.1.4. Resource Pool State..................................6 84 2.1.5. Block Shared Access Wavelength Availability..........6 85 3. WSON Specific Scalability and Timeliness.......................7 86 3.1. Different Sub-TLVs into Multiple LSAs.....................7 87 3.2. Separating a Sub-TLV into Multiple LSAs...................8 89 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 90 2011 92 3.2.1. Sub-Division by Sets.................................8 93 3.2.2. Sub-Division by Options..............................9 94 4. Security Considerations.......................................10 95 5. IANA Considerations...........................................10 96 6. References....................................................12 97 6.1. Normative References.....................................12 98 7. Authors and Contributors......................................13 99 Authors' Addresses...............................................13 100 Intellectual Property Statement..................................14 101 Disclaimer of Validity...........................................14 103 1. Introduction 105 The documents [RFC6163, WSON-Info, WSON-Encode] explain how to extend 106 the wavelength switched optical network (WSON) control plane to allow 107 both multiple WSON signal types and common hybrid electro optical 108 systems as well hybrid systems containing optical switching and 109 electro-optical resources. In WSON, not all of the optical signals in 110 the network are compatible with all network elements participating in 111 the network. Therefore, signal compatibility is an important 112 constraint in path computation in a WSON. 114 This document provides GMPLS OSPF routing enhancements to support 115 signal compatibility constraints associated with general WSON network 116 elements. These routing enhancements are required in common optical 117 or hybrid electro-optical networks where not all of the optical 118 signals in the network are compatible with all network elements 119 participating in the network. 121 This compatibility constraint model is applicable to common optical 122 or hybrid electro optical systems such as OEO switches, regenerators, 123 and wavelength converters since such systems can be limited to 124 processing only certain types of WSON signals. 126 1.1. Revision History 128 From 00 to 01: The details of the encodings for compatibility moved 129 from this document to [WSON-Encode]. 131 From 01 to 02: Editorial changes. 133 From 02 to 03: Add a new Top Level Node TLV, Optical Node Property 134 TLV to carry WSON specific node information. 136 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 137 2011 139 From 03 to 04: Add a new sub-TLV, Block Shared Access Wavelength 140 Availability TLV to be consistent with [WSON-Encode] and editorial 141 changes. 143 From 04 to 05: Add a new section that discusses OSPF scalability and 144 timeliness and editorial changes. 146 From 05 to 06: Change the title of the draft to "GMPLS OSPF 147 Enhancement" from "OSPF Enhancement" to make sure the changes apply 148 to the GMPLS OSPF rather than the base OSPF. Add specific OSPF 149 procedures on how sub-TLVs are packaged per [RFC3630] and editorial 150 changes. 152 2. The Optical Node Property TLV 154 [RFC3630] defines OSPF TE LSA using an opaque LSA. This document adds 155 a new top level TLV for use in the OSPF TE LSA: the Optical Node 156 Property TLV. The Optical Node property TLV describes a single node. 157 It is constructed of a set of sub-TLVs. There are no ordering 158 requirements for the sub-TLVs. Only one Optical Node TLV shall be 159 advertised in each LSA. 161 The Optical Node Property TLV contains all WSON-specific node 162 properties and signal compatibility constraints. The detailed 163 encodings of these properties are defined in [WSON-Encode]. 165 The following sub-TLVs of the Optical Node Property TLV are defined: 167 Value Length Sub-TLV Type 169 TBA variable Resource Block Information 170 TBA variable Resource Pool Accessibility 171 TBA variable Resource Block Wavelength Constraints 172 TBA variable Resource Pool State 173 TBA variable Block Shared Access Wavelength Availability 175 The detail encodings of these sub-TLVs are found in [WSON-Encode] as 176 indicated in the table below. 178 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 179 2011 181 Sub-TLV Type Section [WSON-Encode] 183 Resource Block Information 4.1 184 Resource Pool Accessibility 3.1 185 Resource Block Wavelength Constraints 3.2 186 Resource Pool State 3.3 187 Block Shared Access Wavelength Availability 3.4 189 All sub-TLVs defined here may occur at most once in any given Optical 190 Node TLV. These restrictions need not apply to future sub-TLVs. 191 Unrecognized sub-TLVs are ignored. 193 2.1. Sub-TLV Details 195 Among the sub-TLVs defined above, the Resource Pool State sub-TLV and 196 Block Shared Access Wavelength Availability are dynamic in nature 197 while the rest are static. As such, they can be separated out from 198 the rest and be advertised with multiple TE LSAs per OSPF router, as 199 described in [RFC3630] and [RFC5250]. 201 2.1.1. Resource Block Information 203 Resource Block Information sub-TLVs are used to convey relatively 204 static information about individual resource blocks including the 205 resource block properties and the number of resources in a block. 207 There are seven nested sub-TLVs defined in the Resource Block 208 Information sub-TLV. 210 Value Length Sub-TLV Type 212 TBA variable Input Modulation Format List 213 TBA variable Input FEC Type List 214 TBA variable Input Bit Range List 215 TBA variable Input Client Signal List 216 TBA variable Processing Capability List 217 TBA variable Output Modulation Format List 218 TBA variable Output FEC Type List 220 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 221 2011 223 The detail encodings of these sub-TLVs are found in [WSON-Encode] as 224 indicated in the table below. 226 Name Section [WSON-Encode] 228 Input Modulation Format List 4.2 229 Input FEC Type List 4.3 230 Input Bit Range List 4.4 231 Input Client Signal List 4.5 232 Processing Capability List 4.6 233 Output Modulation Format List 4.7 234 Output FEC Type List 4.8 236 2.1.2. Resource Pool Accessibility 238 This sub-TLV describes the structure of the resource pool in relation 239 to the switching device. In particular it indicates the ability of an 240 ingress port to reach a resource block and of a resource block to 241 reach a particular egress port. 243 2.1.3. 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 structure 247 of the optical system not all wavelengths can necessarily reach or 248 leave all the resources. Resource Block Wavelength Constraints sub- 249 TLV describe these properties. 251 2.1.4. 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 2.1.5. Block Shared Access Wavelength Availability 261 Resources blocks may be accessed via a shared fiber. If this is the 262 case then wavelength availability on these shared fibers is needed to 263 understand resource availability. 265 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 266 2011 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. However there has been concern expressed that some possible 274 systems may produce LSAs that exceed the IP Maximum Transmission Unit 275 (MTU) and that methods be given to allow for the splitting of WSON 276 specific LSA into smaller LSA that are under the MTU limit. This 277 section presents a set of techniques that can be used for this 278 purpose. 280 3.1. Different Sub-TLVs into Multiple LSAs 282 Five sub-TLVs are defined in this document: 284 1. Resource Block Information 285 2. Resource Pool Accessibility 286 3. Resource Block Wavelength Constraints 287 4. Resource Pool State 288 5. Block Shared Access Wavelength Availability 290 All these are carried in an Optical Node Property TLV (see Section 2 291 for detail) of which there can be at most one in an LSA. Of these 292 sub-TLVs the first three are relatively static, i.e., only would 293 change with hardware changes or significant system reconfiguration. 294 While the fourth and fifth are dynamic, meaning that they may change 295 with LSP setup or teardown through the system. The most important 296 technique for scalability and OSPF bandwidth reduction is to separate 297 the dynamic information sub-TLVs from the static information sub-TLVs 298 and advertise them in OSPF TE LSAs, each with the Optical Node 299 Property TLV at the top level ([RFC3630 and RFC5250]). 301 For LSA overhead reduction it is recommended to group as many of the 302 three static sub-TLVs into the same LSA (within the Optical Node 303 Property TLV). If the size of this LSA is greater than the MTU, then 304 these sub-TLV can be packed into separate LSAs. From the point of 305 view of path computation, the presence of the Resource Block 306 Information sub-TLV indicates that resources exist in the system and 307 may have signal compatibility or other constraints. The other four 308 sub-TLVs indicate constraints on access to, and availability of those 309 resources. 311 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 312 2011 314 Hence the "synchronization" procedure from a path computation point 315 of view is quite simple. Until a Resource Block Information sub-TLV 316 is received for a system path cannot make use of the other four sub- 317 TLVs since it does not know the nature of the resources, e.g., are 318 the resources wavelength converters, regenerators, or something else. 319 Once this sub-TLV is received path computation can proceed with 320 whatever of the additional types of sub-TLVs it may have received 321 (there use is dependent upon the system type). If path computation 322 proceeds with out of date or missing information from these sub-TLVs 323 then there is the possibility of either (a) path computation 324 computing a path that does not exist in the network, (b) path 325 computation failing to find a path through the network that actually 326 exists. Both situations are currently encountered with GMPLS, i.e., 327 out of date information on constraints or resource availability. 329 Note that the connection establishment mechanism (signaling or 330 management) is ultimately responsible for the establishment of the 331 connection, and this implies that such mechanisms must insure signal 332 compatibility. 334 3.2. Separating a Sub-TLV into Multiple OSPF TE LSAs 336 In the highly unlikely event that a WSON sub-TLV by itself would 337 result in an LSA exceeding the MTU, all five WSON specific sub-TLVs 338 in this document provide mechanisms that allow them to be subdivided 339 into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. 341 Sub-Division by Sets 343 All five sub-TLVs currently make use of one or more RB Set Fields 344 [WSON-Encode] or Link Set Fields [Gen-Encode]. Long set fields can be 345 decomposed into multiple smaller set fields resulting in multiple 346 sub-TLVs that can be sent in multiple OSPF TE LSAs. The 347 interpretation of the separate pieces is quite natural and reviewed 348 in the following: 350 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 351 2011 353 Resource Block Information 354 Information about different resources of similar types would get 355 sent separately (LSAs). Path computation would not know a resource 356 exists until it receives the instance of a sub-TLV that mentions 357 that instance. 359 Resource Pool Accessibility 360 Information about accessibility to resources to/from ports would be 361 in as separate pieces base on port or resource set separation. All 362 pieces are combined to give complete resource/port accessibility 363 view. Late/missing pieces would imply resources are not accessible 364 to/from given ports. 366 Resource Block Wavelength Constraints 367 Information about resource wavelength constraints can be sent in 368 separate pieces based on resource sub-sets. Late/missing pieces 369 (LSAs) would imply resources accessible when they might not be. 371 Resource Pool State 372 Information about resource state can be sent in separate pieces 373 based on resource sub-sets. Late/missing pieces (LSAs) could imply 374 incorrect resources availability. 376 Block Shared Access Wavelength Availability 377 Information about resource shared access wavelength can be sent in 378 separate pieces based on resource sub-sets. Late/missing pieces 379 (LSAs) could imply incorrect shared wavelength availability. 381 Due to the reliability mechanisms in OSPF the phenomena of late or 382 missing pieces for relatively static information (first three types 383 of sub-TLVs) would be relatively rare. 385 3.2.1. Sub-Division by Options 387 The Resource Block Information sub-TLV contains a number of optional 388 fields. If this sub-TLV becomes too long it may also be sub-divided 389 into multiple OSPF TE LSAs each containing a disjoint assembly of the 390 sub-TLVs optional fields [WSON-Encode]. 392 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 393 2011 395 4. Security Considerations 397 This document does not introduce any further security issues other 398 than those discussed in [RFC3630], [RFC4203]. 400 5. IANA Considerations 402 This document introduces a new Top Level Node TLV (Optical Node 403 Property TLV) under the OSPF TE LSA defined in [RFC3630]. 405 Value TLV Type 407 TBA Optical Node Property 409 IANA is to allocate a new TLV Type and its Value for this Top Level 410 Node TLV. 412 This document also introduces the following sub-TLVs associated with 413 the Optical Node Property TLV as defined in Section 2.1 as follows: 415 Value Length Sub-TLV Type 417 TBA variable Resource Block Information 418 TBA variable Resource Pool Accessibility 419 TBA variable Resource Block Wavelength Constraints 420 TBA variable Resource Pool State 421 TBA variable Block Shared Access Wavelength Availability 423 IANA is to allocate new sub-TLV Types and their Values for these sub- 424 TLVs defined under the Optical Node Property TLV. 426 There are seven nested sub-TLVs defined in the Resource Block 427 Information sub-TLV as follows: 429 Value Length Sub-TLV Type 431 TBA variable Input Modulation Format List 432 TBA variable Input FEC Type List 433 TBA variable Input Bit Range List 434 TBA variable Input Client Signal List 435 TBA variable Processing Capability List 436 TBA variable Output Modulation Format List 438 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 439 2011 441 TBA variable Output FEC Type List 443 IANA is to allocate new Sub-TLV Types and their Values for these Sub- 444 TLVs defined under the Resource Block Information Sub-TLV. 446 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 447 2011 449 6. References 451 6.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 in 464 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 6.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, work 482 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 2011 491 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and 492 PCE Control of Wavelength Switched Optical Networks", RFC 493 6163, April 2011. 495 [RFC5250] Berger, L., et al., "The OSPF Opauqe LSA option", RFC 5250, 496 July 2008. 498 7. 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 2011 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 IPR 536 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 provided 547 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 548 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 549 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.