idnits 2.17.1 draft-ietf-ccamp-wson-signal-compatibility-ospf-16.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 54 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 26, 2015) is 3163 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: 'RFC2328' is mentioned on line 346, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 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 2016 Grotto Networking 6 August 26, 2015 8 GMPLS OSPF Enhancement for Signal and Network Element Compatibility 9 for Wavelength Switched Optical Networks 11 draft-ietf-ccamp-wson-signal-compatibility-ospf-16.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 26,2016. 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 Block Information................................5 78 2.2. Resource Accessibility....................................5 79 2.3. Resource Wavelength Constraints...........................5 80 2.4. Resource Block Pool State.................................5 81 2.5. Resource Block Shared Access Wavelength Availability......5 82 3. Interface Switching Capability Descriptor (ISCD) Format 83 Extensions........................................................5 84 3.1. Switching Capability Specific Information.................6 85 4. WSON Specific Scalability and Timeliness.......................7 86 5. Security Considerations........................................8 87 6. IANA Considerations............................................9 88 6.1. Optical Node Property TLV.................................9 89 6.1.1. Optical Node Property Sub-TLV........................9 90 6.2. WSON-LSC Switching Type TLV..............................10 91 6.2.1. WSON-LSC SCSI Sub-TLVs..............................10 92 7. References....................................................11 93 7.1. Normative References.....................................11 94 7.2. Informative References...................................11 95 8. Authors' Addresses............................................12 97 1. Introduction 99 The documents [RFC6163, RFC7446, RFC7581] explain how to extend the 100 Wavelength Switched Optical Network (WSON) control plane to support 101 both multiple WSON signal types and common hybrid electro optical 102 systems as well hybrid systems containing optical switching and 103 electro-optical resources. In WSON, not all of the optical signals 104 in the network are compatible with all network elements 105 participating in the network. Therefore, signal compatibility is an 106 important constraint in path computation in a WSON. 108 This document provides GMPLS OSPF routing enhancements to support 109 signal compatibility constraints associated with general WSON 110 network elements. These routing enhancements are applicable in 111 common optical or hybrid electro-optical networks where not all of 112 the optical signals in the network are compatible with all network 113 elements participating in the network. 115 This compatibility constraint model is applicable to common optical 116 or hybrid electro optical systems such as OEO switches, 117 regenerators, and wavelength converters since such systems can be 118 limited to processing only certain types of WSON signals. 120 Related to this document is [RFC7580] which provides GMPLS OSPF 121 routing enhancements to support the generic routing and label 122 assignment process that can be applicable to a wider range of 123 technologies beyond WSON. 125 2. The Optical Node Property TLV 127 [RFC3630] defines OSPF Traffic Engineering (TE) Link State 128 Advertisement (LSA) using an opaque LSA. This document adds a new 129 top level TLV for use in the OSPF TE LSA: the Optical Node Property 130 TLV. The Optical Node Property TLV describes a single node. It is 131 comprised of a set of optional sub-TLVs. There are no ordering 132 requirements for the sub-TLVs. 134 When using the extensions defined in this document, at least one 135 Optical Node Property TLV MUST be advertised in each LSA. To allow 136 for fine granularity changes in topology, more than one Optical Node 137 Property TLV MAY be advertised in a single LSA. Implementations MUST 138 support receiving multiple Optical Node Property TLVs in an LSA. 140 The Optical Node Property TLV contains all WSON-specific node 141 properties and signal compatibility constraints. The detailed 142 encodings of these properties are defined in [RFC7581]. 144 The following sub-TLVs of the Optical Node Property TLV are defined: 146 Value Length Sub-TLV Type 148 TBA1 variable Resource Block Information 149 TBA2 variable Resource Accessibility 150 TBA3 variable Resource Wavelength Constraints 151 TBA4 variable Resource Block Pool State 152 TBA5 variable Resource Block Shared Access Wavelength 153 Availability 155 The detailed encodings of these sub-TLVs are found in [RFC7581] as 156 indicated in the table below. 158 Sub-TLV Type Section [RFC7581] 160 Resource Block Information 4.1 161 Resource Accessibility 3.1 162 Resource Wavelength Constraints 3.2 163 Resource Block Pool State 3.3 164 Resource Block Shared Access Wavelength Availability 3.4 166 All sub-TLVs defined here may occur at most once in any given 167 Optical Node TLV under one TE LSA. If more than one copy of the sub- 168 TLV is received in the same LSA, the redundant sub-TLV SHOULD be 169 ignored. In case where the same sub-TLV is advertised in different 170 TE LSA (which would take place only by a packaging error), then the 171 sub-TLV with the largest LSA ID (Sec 2.2 of RFC 3630) SHOULD be 172 picked. These restriction need not apply to future sub-TLVs. 173 Unrecognized sub-TLVs are ignored. 175 Among the sub-TLVs defined above, the Resource Block Pool State sub- 176 TLV and Resource Block Shared Access Wavelength Availability are 177 dynamic in nature while the rest are static. As such, they can be 178 separated out from the rest and be advertised with multiple TE LSAs 179 per OSPF router, as described in [RFC3630] and [RFC5250]. 181 2.1. Resource Block Information 183 As defined in [RFC7446], this sub-TLV is used to represent resource 184 signal constraints and processing capabilities of a node. 186 2.2. Resource Accessibility 188 This sub-TLV describes the structure of the resource pool in 189 relation to the switching device. In particular, it indicates the 190 ability of an ingress port to reach a resource block and of a 191 resource block to reach a particular egress port. 193 2.3. Resource Wavelength Constraints 195 Resources, such as wavelength converters, etc., may have limited 196 input or output wavelength ranges. Additionally, due to the 197 structure of the optical system, not all wavelengths can necessarily 198 reach or leave all the resources. The Resource Wavelength 199 Constraints sub-TLV describes these properties. 201 2.4. Resource Block Pool State 203 This sub-TLV describes the usage state of a resource that can be 204 encoded as either a list of integer values or a bit map indicating 205 whether a single resource is available or in use. This information 206 can be relatively dynamic, i.e., can change when a connection is 207 established or torn down. 209 2.5. Resource Block Shared Access Wavelength Availability 211 Resource blocks may be accessed via a shared fiber. If this is the 212 case, then wavelength availability on these shared fibers is needed 213 to understand resource availability. 215 3. Interface Switching Capability Descriptor (ISCD) Format Extensions 217 The ISCD describes switching capability of an interface [RFC4202]. 218 This document defines a new Switching Capability value for WSON as 219 follows: 221 Value Type 222 ----- ---- 223 151 (TBA by IANA) WSON-LSC capable (WSON-LSC) 225 Switching Capability and Encoding values MUST be used as follows: 227 Switching Capability = WSON-LSC 229 Encoding Type = Lambda [as defined in RFC3471] 231 When Switching Capability and Encoding fields are set to values as 232 stated above, the Interface Switching Capability Descriptor MUST be 233 interpreted as in [RFC4203] with the optional inclusion of one or 234 more Switching Capability Specific Information sub-TLVs. 236 3.1. Switching Capability Specific Information (SCSI) 238 The technology specific part of the WSON ISCD may include a variable 239 number of sub-TLVs called Bandwidth sub-TLVs. Two types of 240 Bandwidth sub-TLV are defined: 242 - Type 1 - Available Labels 244 - Type 2 - Shared Backup Labels 246 A SCSI may contain multiple Available Label sub-TLVs and multiple 247 Shared Backup Label sub-TLVs. The following figure shows the format 248 for a SCSI that contains these sub-TLVs. The order of the sub-TLVs 249 in the SCSI is arbitrary. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type = 1 (Available) | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 | Available Label Sub-TLV | 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 ~ ... ~ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type = 2 (Shared backup) | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 | Shared Backup Label Sub-TLV | 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 1: SCSI format 271 Where the Available Label Sub-TLV and Shared Backup Label sub-TLV 272 are defined in [RFC7579]. In case where duplicated sub-TLVs are 273 advertised, the router/node will ignore the duplicated labels which 274 are identified by the Label format defined in [RFC6205]. 276 The label format defined in [RFC6205] MUST be used when advertising 277 interfaces with a WSON-LSC type Switching Capability. 279 4. WSON Specific Scalability and Timeliness 281 This document has defined five sub-TLVs specific to WSON. The 282 examples given in [RFC7581] show that very large systems, in terms 283 of channel count, ports, or resources, can be very efficiently 284 encoded. 286 There has been concern expressed that some possible systems may 287 produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In 288 a typical node configuration, the optical node property TLV will not 289 exceed the IP MTU. A typical node configuration refers to a system 290 with several hundreds of channels with an OEO element in the node. 291 This would give optical node property TLV less than 350 bytes. In 292 addition, [RFC7581] provides mechanisms to compactly encode required 293 information elements. In a rare case where the TLV exceed the IP 294 MTU, IP fragmentation/reassembly can be used, which is an acceptable 295 method. For IPv6, a node may use the IPv6 Fragment header to 296 fragment the packet at the source and have it reassembled at the 297 destination(s). 299 If the size of this LSA is greater than the MTU, then these sub-TLVs 300 can be packed into separate LSAs. From the point of view of path 301 computation, the presence of the Resource Block Information sub-TLV 302 indicates that resources exist in the system and may have signal 303 compatibility or other constraints. The other four sub-TLVs indicate 304 constraints on access to, and availability of those resources. 306 Hence the "synchronization" procedure from a path computation point 307 of view is quite simple. Until a Resource Block Information sub-TLV 308 is received for a system, path computation cannot make use of the 309 other four sub-TLVs since it does not know the nature of the 310 resources, e.g., are the resources wavelength converters, 311 regenerators, or something else. Once this sub-TLV is received, path 312 computation can proceed with whatever sub-TLVs it may have received 313 (there use is dependent upon the system type). 315 If path computation proceeds with out of date or missing information 316 from these sub-TLVs, then there is the possibility of either (a) 317 path computation computing a path that does not exist in the 318 network, (b) path computation failing to find a path through the 319 network that actually exists. Both situations are currently 320 encountered with GMPLS, i.e., out of date information on constraints 321 or resource availability. 323 In case where the new sub-TLVs or their attendant encodings are 324 malformed, the proper action SHOULD log the problem and MUST stop 325 sending the LSA in which to contain malformed TLVs or sub-TLVs. 327 Errors of this nature SHOULD be logged for the local operator. 328 Implementations MUST provide a rate limit on such logs, and that 329 rate limit SHOULD be configurable. 331 Note that the connection establishment mechanism (signaling or 332 management) is ultimately responsible for the establishment of the 333 connection, and this implies that such mechanisms must insure signal 334 compatibility. 336 5. Security Considerations 338 This document does not introduce any further security issues other 339 than those discussed in [RFC3630], [RFC4203]. 341 As with [RFC4203], it specifies the contents of Opaque LSAs in 342 OSPFv2. As Opaque LSAs are not used for Shortest Path First (SPF) 343 computation or normal routing, the extensions specified here have no 344 direct effect on IP routing. Tampering with GMPLS TE LSAs may have 345 an effect on the underlying Transport. [RFC3630] notes that the 346 security mechanisms described in [RFC2328] apply to Opaque LSAs 347 carried in OSPFv2. 349 For general security aspects relevant to Generalized Multiprotocol 350 Label Switching (GMPLS)-controlled networks, please refer to 351 [RFC5920]. 353 6. IANA Considerations 355 6.1. Optical Node Property TLV 357 This document introduces a new Top Level Node TLV (Optical Node 358 Property TLV) under the OSPF TE LSA defined in [RFC3630]. 360 IANA is asked to register a new TLV for "Optical Node Property". The 361 new TLV will be registered in the "Top Level Types in TE LSAs" 362 registry in "OSPF Traffic Engineering TLVs", located at 363 http://www.iana.org/assignments/ospf-traffic-eng-tlvs, as follows: 365 Value TLV Type Reference 367 6 (suggested) Optical Node Property [This.ID] 369 6.1.1. Optical Node Property Sub-TLV 371 Additionally, a new IANA registry will be created for sub-TLVs of 372 the Optical Node Property TLV to create a new section named "Types 373 of sub-TLVs of Optical Node Property TLV (Value TBA)" in the "OSPF 374 Traffic Engineering TLVs" registry located at 375 http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic- 376 eng-tlvs.xml, and allocate new sub-TLV Types and their Values for 377 these sub-TLVs defined under the Optical Node Property TLV as 378 follows: 380 Value Length Sub-TLV Type Reference 381 0 Reserved 382 1 (suggested) variable Resource Block Information [This.ID] 383 2 (suggested) variable Resource Accessibility [This.ID] 384 3 (suggested) variable Resource Wavelength 385 Constraints [This.ID] 386 4 (suggested) variable Resource Block Pool State [This.ID] 387 5 (suggested) variable Resource Block Shared 388 Access Wavelength Availability [This.ID] 389 6-65535 Unassigned 391 Types are to be assigned via Standards Action as defined in 392 [RFC5226]. 394 6.2. WSON-LSC Switching Type TLV 396 IANA is asked to register a new switching type for "WSON-LSC 397 capable" in the Switching Types registry in "GMPLS Signaling 398 Parameters", located at http://www.iana.org/assignments/gmpls-sig- 399 parameters/, as follows: 401 Switching capability Description Reference 402 ---------------------- -------------------------- ---------- 403 151 (suggested) WSON-LSC capable (WSON-LSC) [This.ID] 405 6.2.1. WSON-LSC SCSI Sub-TLVs 407 Additionally, a new IANA registry will be created for sub-TLVs of 408 the WSON-LSC SCSI sub-TLV to create a new section/sub-registry named 409 "Types for sub-TLVs of WSON-LSC SCSI (Switch Capability-Specific 410 Information)" section under the "OSPF Traffic Engineering TLVs" 411 registry, with the following sub-TLV types: 413 Value Sub-TLV Reference 414 0 Reserved 415 1 (suggested) Available Labels [This.ID] 416 2 (suggested) Shared Backup Labels [This.ID] 417 3-65535 Unassigned 419 Types are to be assigned via Standards Action as defined in 420 [RFC5226]. 422 7. References 424 7.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 430 Engineering (TE) Extensions to OSPF Version 2", RFC 431 3630, September 2003. 433 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 434 in Support of Generalized Multi-Protocol Label Switching 435 (GMPLS)", RFC 4203, October 2005. 437 [RFC6205] T. Otani, Ed. and D. Li, Ed., "Generalized Labels for 438 Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 439 6205, March 2011. 441 [RFC7581] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 442 Wavelength Assignment Information Encoding for Wavelength 443 Switched Optical Networks", RFC 7581, June 2015. 445 [RFC7579] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General Network 446 Element Constraint Encoding for GMPLS Controlled 447 Networks", RFC 7579, June 2015. 449 [RFC7580] F. Zhang, Y. Lee, J. Han, G, Bernstein and Y. Xu, "OSPF-TE 450 Extensions for General Network Element Constraints", RFC 451 7580, June 2015. 453 7.2. Informative References 455 [RFC7446] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 456 Wavelength Assignment Information Model for Wavelength 457 Switched Optical Networks", RFC 7446, February 2015. 459 [RFC4202] K. Kompella, Ed., and Y. Rekhter, Ed., "Routing Extensions 460 in Support of Generalized Multi-Protocol Label Switching 461 (GMPLS)", RFC 4202, October 2005. 463 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and 464 PCE Control of Wavelength Switched Optical Networks", RFC 465 6163, April 2011. 467 [RFC5250] Berger, L., et al., "The OSPF Opauqe LSA option", RFC 468 5250, July 2008. 470 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 471 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 472 May 2008. 474 [RFC5920] Luyuan Fang(Ed.), "Security Framework for MPLS and GMPLS N 475 Networks", RFC5920, July 2010. 477 8. Authors' Addresses 479 Young Lee (ed.) 480 Huawei Technologies 481 5340 Legacy Drive, Building 3 482 Plano, TX 75024 483 USA 485 Phone: (469)277-5838 486 Email: leeyoung@huawei.com 488 Greg M. Bernstein (ed.) 489 Grotto Networking 490 Fremont California, USA 492 Phone: (510) 573-2237 493 Email: gregb@grotto-networking.com