idnits 2.17.1 draft-ietf-ccamp-wson-signal-compatibility-ospf-15.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 (May 22, 2014) is 3620 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 403, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: November 2014 Grotto Networking 6 May 22, 2014 8 GMPLS OSPF Enhancement for Signal and Network Element Compatibility 9 for Wavelength Switched Optical Networks 11 draft-ietf-ccamp-wson-signal-compatibility-ospf-15.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 November 22,2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This document provides Generalized Multiprotocol Label Switching 54 (GMPLS) Open Shortest Path First (OSPF) routing enhancements to 55 support signal compatibility constraints associated with Wavelength- 56 Switched Optical network (WSON) elements. These routing enhancements 57 are applicable in common optical or hybrid electro-optical networks 58 where not all of the optical signals in the network are compatible 59 with all network elements participating in the network. 61 This compatibility constraint model is applicable to common optical 62 or hybrid electro optical systems such as Optical-Electronic-Optical 63 (OEO) switches, regenerators, and wavelength converters since such 64 systems can be limited to processing only certain types of WSON 65 signals. 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 Table of Contents 75 1. Introduction...................................................3 76 2. The Optical Node Property TLV..................................3 77 2.1. Resource Accessibility....................................4 78 2.2. Resource Wavelength Constraints...........................5 79 2.3. Resource Block Pool State.................................5 80 2.4. Resource Block Shared Access Wavelength Availability......5 81 3. Interface Switching Capability Descriptor (ISCD) Format 82 Extensions........................................................5 83 3.1. Switching Capability Specific Information.................6 84 4. WSON Specific Scalability and Timeliness.......................7 85 5. Security Considerations........................................8 86 6. IANA Considerations............................................8 87 6.1. Optical Node Property TLV.................................8 88 6.1.1. Optical Node Property Sub-TLV........................8 89 6.2. WSON-LSC Switching Type TLV...............................9 90 6.2.1. WSON-LSC SCSI Sub-TLVs...............................9 91 7. References....................................................10 92 7.1. Normative References.....................................10 93 7.2. Informative References...................................11 94 8. Authors' Addresses............................................11 95 Intellectual Property Statement..................................12 96 Disclaimer of Validity...........................................12 98 1. Introduction 100 The documents [RFC6163, WSON-Info, WSON-Encode] explain how to 101 extend the Wavelength Switched Optical Network (WSON) control plane 102 to support both multiple WSON signal types and common hybrid electro 103 optical systems as well hybrid systems containing optical switching 104 and electro-optical resources. In WSON, not all of the optical 105 signals in the network are compatible with all network elements 106 participating in the network. Therefore, signal compatibility is an 107 important constraint in path computation in a WSON. 109 This document provides GMPLS OSPF routing enhancements to support 110 signal compatibility constraints associated with general WSON 111 network elements. These routing enhancements are applicable in 112 common optical or hybrid electro-optical networks where not all of 113 the optical signals in the network are compatible with all network 114 elements participating in the network. 116 This compatibility constraint model is applicable to common optical 117 or hybrid electro optical systems such as OEO switches, 118 regenerators, and wavelength converters since such systems can be 119 limited to processing only certain types of WSON signals. 121 Related to this document is [GEN-OSPF] which provides GMPLS OSPF 122 routing enhancements to support the generic routing and label 123 assignment process that can be applicable to a wider range of 124 technologies beyond WSON. 126 2. The Optical Node Property TLV 128 [RFC3630] defines OSPF TE LSA using an opaque LSA. This document 129 adds a new top level TLV for use in the OSPF TE LSA: the Optical 130 Node Property TLV. The Optical Node Property TLV describes a single 131 node. It is comprised of a set of sub-TLVs. There are no ordering 132 requirements for the sub-TLVs. Only one Optical Node Property TLV 133 shall be advertised in each LSA. 135 The Optical Node Property TLV contains all WSON-specific node 136 properties and signal compatibility constraints. The detailed 137 encodings of these properties are defined in [WSON-Encode]. 139 The following sub-TLVs of the Optical Node Property TLV are defined: 141 Value Length Sub-TLV Type 143 TBA variable Resource Block Information 144 TBA variable Resource Accessibility 145 TBA variable Resource Wavelength Constraints 146 TBA variable Resource Block Pool State 147 TBA variable Resource Block Shared Access Wavelength 148 Availability 150 The detailed encodings of these sub-TLVs are found in [WSON-Encode] 151 as indicated in the table below. 153 Sub-TLV Type Section [WSON-Encode] 155 Resource Block Information 4.1 156 Resource Accessibility 3.1 157 Resource Wavelength Constraints 3.2 158 Resource Block Pool State 3.3 159 Resource Block Shared Access Wavelength Availability 3.4 161 All sub-TLVs defined here may occur at most once in any given 162 Optical Node TLV. If more than one copy of a sub-TLV is received, 163 only the first one of the same type is processed and the rest are 164 ignored upon receipt. These restriction need not apply to future 165 sub-TLVs. Unrecognized sub-TLVs are ignored. 167 Among the sub-TLVs defined above, the Resource Block Pool State sub- 168 TLV and Resource Block Shared Access Wavelength Availability are 169 dynamic in nature while the rest are static. As such, they can be 170 separated out from the rest and be advertised with multiple TE LSAs 171 per OSPF router, as described in [RFC3630] and [RFC5250]. 173 2.1. Resource Accessibility 175 This sub-TLV describes the structure of the resource pool in 176 relation to the switching device. In particular, it indicates the 177 ability of an ingress port to reach a resource block and of a 178 resource block to reach a particular egress port. 180 2.2. Resource Wavelength Constraints 182 Resources, such as wavelength converters, etc., may have a limited 183 input or output wavelength ranges. Additionally, due to the 184 structure of the optical system, not all wavelengths can necessarily 185 reach or leave all the resources. The Resource Wavelength 186 Constraints sub-TLV describes these properties. 188 2.3. Resource Block Pool State 190 This sub-TLV describes the usage state of a resource that can be 191 encoded as either a list of integer values or a bit map indicating 192 whether a single resource is available or in use. This information 193 can be relatively dynamic, i.e., can change when a connection is 194 established or torn down. 196 2.4. Resource Block Shared Access Wavelength Availability 198 Resources blocks may be accessed via a shared fiber. If this is the 199 case, then wavelength availability on these shared fibers is needed 200 to understand resource availability. 202 3. Interface Switching Capability Descriptor (ISCD) Format Extensions 204 The ISCD describes switching capability of an interface [RFC4202]. 205 This document defines a new Switching Capability value for WSON as 206 follows: 208 Value Type 209 ----- ---- 210 151 (TBA by IANA) WSON-LSC capable (WSON-LSC) 212 Switching Capability and Encoding values MUST be used as follows: 214 Switching Capability = WSON-LSC 216 Encoding Type = Lambda [as defined in RFC3471] 218 When Switching Capability and Encoding fields are set to values as 219 stated above, the Interface Switching Capability Descriptor MUST be 220 interpreted as in [RFC4203] with the optional inclusion of one or 221 more Switching Capability Specific Information sub-TLVs. 223 3.1. Switching Capability Specific Information 225 The technology specific part of the WSON ISCD may include a variable 226 number of sub-TLVs called Bandwidth sub-TLVs. Two types of 227 Bandwidth sub-TLV are defined (TBA by IANA): 229 - Type 1 - Available Labels 231 - Type 2 - Shared Backup Labels 233 The format of the SCSI MUST be as depicted in the following figure: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type = 1 (Available) | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 | Available Label Sub-TLV | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 ~ ... ~ 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type = 2 (Shared backup) | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 | Shared Backup Label Sub-TLV | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 1: SCSI format 255 Where the Available Label Sub-TLV and Shared Backup Label sub-TLV 256 are defined in [Gen-Encode]. 258 The label format defined in [RFC6205] MUST be used when advertising 259 interfaces with a WSON-LSC type Switching Capability. 261 4. WSON Specific Scalability and Timeliness 263 This document has defined five sub-TLVs specific to WSON. The 264 examples given in [WSON-Encode] show that very large systems, in 265 terms of channel count, ports, or resources, can be very efficiently 266 encoded. 268 There has been concern expressed that some possible systems may 269 produce LSAs that exceeds the IP Maximum Transmission Unit (MTU). In 270 a typical node configuration, the optical node property TLV will not 271 exceed the IP MTU. In a rare case where the TLV exceed the IP MTU, 272 IP fragmentation/reassembly can be used, which is an acceptable 273 method. 275 If the size of this LSA is greater than the MTU, then these sub-TLVs 276 can be packed into separate LSAs. From the point of view of path 277 computation, the presence of the Resource Block Information sub-TLV 278 indicates that resources exist in the system and may have signal 279 compatibility or other constraints. The other four sub-TLVs indicate 280 constraints on access to, and availability of those resources. 282 Hence the "synchronization" procedure from a path computation point 283 of view is quite simple. Until a Resource Block Information sub-TLV 284 is received for a system, path computation cannot make use of the 285 other four sub-TLVs since it does not know the nature of the 286 resources, e.g., are the resources wavelength converters, 287 regenerators, or something else. Once this sub-TLV is received, path 288 computation can proceed with whatever sub-TLVs it may have received 289 (there use is dependent upon the system type). 291 If path computation proceeds with out of date or missing information 292 from these sub-TLVs, then there is the possibility of either (a) 293 path computation computing a path that does not exist in the 294 network, (b) path computation failing to find a path through the 295 network that actually exists. Both situations are currently 296 encountered with GMPLS, i.e., out of date information on constraints 297 or resource availability. 299 In case where the new sub-TLVs or their attendant encodings are 300 malformed, the proper action would be to log the problem and ignore 301 just the sub-TLVs in GMPLS path computations rather than ignoring 302 the entire LSA. 304 Note that the connection establishment mechanism (signaling or 305 management) is ultimately responsible for the establishment of the 306 connection, and this implies that such mechanisms must insure signal 307 compatibility. 309 5. Security Considerations 311 This document does not introduce any further security issues other 312 than those discussed in [RFC3630], [RFC4203]. 314 For general security aspects relevant to Generalized Multiprotocol 315 Label Switching (GMPLS)-controlled networks, please refer to 316 [RFC5920]. 318 6. IANA Considerations 320 6.1. Optical Node Property TLV 322 This document introduces a new Top Level Node TLV (Optical Node 323 Property TLV) under the OSPF TE LSA defined in [RFC3630]. 325 New IANA registry will be created for the Optical Node Property TLV 326 to allocate a new TLV Type and its Value for this Top Level Node TLV 327 in the "Top Level Types in TE LSAs" section of the "OSPF Traffic 328 Engineering TLVs" registry located at 329 http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic- 330 eng-tlvs.xhtml. 332 The following TLV is allocated in this specification. 334 Value TLV Type Reference 336 6 (suggested) Optical Node Property [This.I-D] 338 6.1.1. Optical Node Property Sub-TLV 340 Additionally, new IANA registry will be created for sub-TLVs of the 341 Optical Node Property TLV to create a new section named "Types of 342 sub-TLVs of Optical Node Property TLV (Value TBA)" in the "OSPF 343 Traffic Engineering TLVs" registry located at 344 http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic- 345 eng-tlvs.xml, and allocate new sub-TLV Types and their Values for 346 these sub-TLVs defined under the Optical Node Property TLV as 347 follows: 349 Value Length Sub-TLV Type Reference 351 0 Reserved 352 1 (suggested) variable Resource Block Information [This.I-D] 353 2 (suggested) variable Resource Accessibility [This.I-D] 354 3 (suggested) variable Resource Wavelength 355 Constraints [This.I-D] 356 4 (suggested) variable Resource Block Pool State [This.I-D] 357 5 (suggested) variable Resource Block Shared 358 Access Wavelength Availability [This.I-D] 359 6-65535 Unassigned 361 Types are to be assigned via Standards Action as defined in 362 [RFC5226]. 364 6.2. WSON-LSC Switching Type TLV 366 A new IANA registry will be created to make the assignment of a new 367 value for the existing "Switching Types" TLV of the "GMPLS Signaling 368 Parameters" registry located at 369 http://www.iana.org/assignments/gmpls-sig-parameters as follows: 371 Switching capability Description Reference 372 ---------------------- -------------------------- ---------- 373 151 (suggested) WSON-LSC capable (WSON-LSC) [This.I-D] 375 6.2.1. WSON-LSC SCSI Sub-TLVs 377 Additionally, a new IANA registry will be created for sub-TLVs of 378 the WSON-LSC SCSI sub-TLV to create a new section/sub-registry named 379 "Types for sub-TLVs of WSON-LSC SCSI (Switch Capability-Specific 380 Information)" section under the "OSPF Traffic Engineering TLVs" 381 registry, with the following sub-TLV types: 383 Value Sub-TLV Refenrence 384 0 Reserved 385 1 (suggested) Available Labels [This.I-D] 386 2 (suggested) Shared Backup Labels [This.I-D] 387 3-65535 Unassigned 389 Types are to be assigned via Standards Action as defined in 390 [RFC5226]. 392 7. References 394 7.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 400 Engineering (TE) Extensions to OSPF Version 2", RFC 401 3630, September 2003. 403 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 404 applications: DWDM frequency grid", June, 2002. 406 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 407 in Support of Generalized Multi-Protocol Label Switching 408 (GMPLS)", RFC 4203, October 2005. 410 [RFC6205] T. Otani, Ed. and D. Li, Ed., "Generalized Labels for 411 Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 412 6205, March 2011. 414 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 415 Wavelength Assignment Information Encoding for Wavelength 416 Switched Optical Networks", draft-ietf-ccamp-rwa-wson- 417 encode, work in progress. 419 [Gen-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General 420 Network Element Constraint Encoding for GMPLS Controlled 421 Networks", draft-ietf-ccamp-general-constraint-encode, 422 work in progress. 424 [GEN-OSPF] F. Zhang, Y. Lee, J. Han, G, Bernstein and Y. Xu, "OSPF- 425 TE Extensions for General Network Element Constraints", 426 draft-ietf-ccamp-gmpls-general-constraints-ospf-te, work 427 in progress. 429 7.2. Informative References 431 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 432 Wavelength Assignment Information Model for Wavelength 433 Switched Optical Networks", draft-ietf-ccamp-rwa-info, 434 work in progress. 436 [RFC4202] K. Kompella, Ed., and Y. Rekhter, Ed., "Routing Extensions 437 in Support of Generalized Multi-Protocol Label Switching 438 (GMPLS), RFC 4202, October 2005. 440 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and 441 PCE Control of Wavelength Switched Optical Networks", RFC 442 6163, April 2011. 444 [RFC5250] Berger, L., et al., "The OSPF Opauqe LSA option", RFC 445 5250, July 2008. 447 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 448 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 449 May 2008. 451 [RFC5920] Luyuan Fang(Ed.), "Security Framework for MPLS and GMPLS N 452 Networks", RFC5920, July 2010. 454 8. Authors' Addresses 456 Young Lee (ed.) 457 Huawei Technologies 458 5340 Legacy Drive, Building 3 459 Plano, TX 75024 460 USA 462 Phone: (469)277-5838 463 Email: leeyoung@huawei.com 465 Greg M. Bernstein (ed.) 466 Grotto Networking 467 Fremont California, USA 469 Phone: (510) 573-2237 470 Email: gregb@grotto-networking.com 472 Intellectual Property Statement 474 The IETF Trust takes no position regarding the validity or scope of 475 any Intellectual Property Rights or other rights that might be 476 claimed to pertain to the implementation or use of the technology 477 described in any IETF Document or the extent to which any license 478 under such rights might or might not be available; nor does it 479 represent that it has made any independent effort to identify any 480 such rights. 482 Copies of Intellectual Property disclosures made to the IETF 483 Secretariat and any assurances of licenses to be made available, or 484 the result of an attempt made to obtain a general license or 485 permission for the use of such proprietary rights by implementers or 486 users of this specification can be obtained from the IETF on-line 487 IPR repository at http://www.ietf.org/ipr 489 The IETF invites any interested party to bring to its attention any 490 copyrights, patents or patent applications, or other proprietary 491 rights that may cover technology that may be required to implement 492 any standard or specification contained in an IETF Document. Please 493 address the information to the IETF at ietf-ipr@ietf.org. 495 Disclaimer of Validity 497 All IETF Documents and the information contained therein are 498 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 499 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 500 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 501 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 502 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 503 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 504 FOR A PARTICULAR PURPOSE. 506 Acknowledgment 508 Funding for the RFC Editor function is currently provided by the 509 Internet Society.