idnits 2.17.1 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-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 date (May 22, 2014) is 3619 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network work group Fatai Zhang 2 Internet Draft Young Lee 3 Intended status: Standards Track Jianrui Han 4 Huawei 5 G. Bernstein 6 Grotto Networking 7 Yunbin Xu 8 CATR 10 Expires: November 22, 2014 May 22, 2014 12 OSPF-TE Extensions for General Network Element Constraints 14 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-08.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on November 22, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 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 Generalized Multiprotocol Label Switching (GMPLS) can be used to 57 control a wide variety of technologies including packet switching 58 (e.g., MPLS), time-division (e.g., SONET/SDH, Optical Transport 59 Network (OTN)), wavelength (lambdas), and spatial switching (e.g., 60 incoming port or fiber to outgoing port or fiber). In some of these 61 technologies, network elements and links may impose additional 62 routing constraints such as asymmetric switch connectivity, non- 63 local label assignment, and label range limitations on links. This 64 document describes Open Shortest Path First (OSPF) routing protocol 65 extensions to support these kinds of constraints under the control 66 of GMPLS. 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 2. Node Information...............................................3 78 2.1. Connectivity Matrix.......................................4 79 3. Link Information...............................................4 80 3.1. Port Label Restrictions...................................5 81 4. Routing Procedures.............................................5 82 5. Scalability and Timeliness.....................................6 83 5.1. Different Sub-TLVs into Multiple LSAs.....................6 84 5.2. Decomposing a Connectivity Matrix into Multiple Matrices..7 85 6. Security Considerations........................................7 86 7. IANA Considerations............................................7 87 7.1. Node Information..........................................8 88 7.2. Link Information..........................................8 89 8. References.....................................................8 90 8.1. Normative References......................................8 91 8.2. Informative References....................................9 92 9. Authors' Addresses .............................................9 93 Acknowledgment...................................................11 95 1. Introduction 97 Some data plane technologies that require the use of a GMPLS control 98 plane impose additional constraints on switching capability and 99 label assignment. In addition, some of these technologies should be 100 capable of performing non-local label assignment based on the nature 101 of the technology, e.g., wavelength continuity constraint in 102 Wavelength Switched Optical Network (WSON) [RFC6163]. Such 103 constraints can lead to the requirement for link by link label 104 availability in path computation and label assignment. 106 [GEN-Encode] provides efficient encodings of information needed by 107 the routing and label assignment process in technologies such as 108 WSON and are potentially applicable to a wider range of 109 technologies. The encoding provided in [GEN-Encode] is protocol- 110 neutral and can be used in routing, signaling and/or Path 111 Computation Element communication protocol extensions. 113 This document defines extensions to the OSPF routing protocol based 114 on [GEN-Encode] to enhance the Traffic Engineering (TE) properties 115 of GMPLS TE which are defined in [RFC3630], [RFC4202], and [RFC4203]. 116 The enhancements to the TE properties of GMPLS TE links can be 117 advertised in OSPF TE LSAs. The TE LSA, which is an opaque LSA with 118 area flooding scope [RFC3630], has only one top-level 119 Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs 120 for extensibility. The top-level TLV can take one of three values (1) 121 Router Address [RFC3630], (2) Link [RFC3630], (3) Node Attribute 122 defined in Section 2. In this document, we enhance the sub-TLVs for 123 the Link TLV in support of the general network element constraints 124 under the control of GMPLS. 126 The detailed encoding of OSPF extensions are not defined in this 127 document. [GEN-Encode] provides encoding details. 129 2. Node Information 131 According to [GEN-Encode], the additional node information 132 representing node switching asymmetry constraints includes Node ID 133 and connectivity matrix. Except for the Node ID, which should comply 134 with Routing Address described in [RFC3630], the other pieces of 135 information are defined in this document. 137 Per [GEN-Encode], we have identified the following new Sub-TLVs to 138 the Node Attribute TLV as defined in [RFC5786]. Detailed description 139 for each newly defined Sub-TLV is provided in subsequent sections: 141 Sub-TLV Type Length Name 143 14 (Suggested) variable Connectivity Matrix 145 In some specific technologies, e.g., WSON networks, the Connectivity 146 Matrix sub-TLV may be optional, which depends on the control plane 147 implementations. Usually, for example, in WSON networks, 148 Connectivity Matrix sub-TLV may be advertised in the LSAs since WSON 149 switches are currently asymmetric. If no Connectivity Matrix sub-TLV 150 is included, it is assumed that the switches support symmetric 151 switching. 153 2.1. Connectivity Matrix 155 If the switching devices supporting certain data plane technology is 156 asymmetric, it is necessary to identify which input ports and labels 157 can be switched to some specific labels on a specific output port. 159 The Connectivity Matrix is used to identify these restrictions, 160 which can represent either the potential connectivity matrix for 161 asymmetric switches (e.g., ROADMs and such) or fixed connectivity 162 for an asymmetric device such as a multiplexer as defined in [WSON- 163 Info]. 165 The Connectivity Matrix is a sub-TLV of the Node Attribute TLV. The 166 length is the length of value field in octets. The meaning and 167 format of this sub-TLV value field are defined in Section 2.1 of 168 [GEN-Encode]. One sub-TLV contains one matrix. The Connectivity 169 Matrix sub-TLV may occur more than once to contain multiple matrices 170 within the Node Attribute TLV. In addition a large connectivity 171 matrix can be decomposed into smaller sub-matrices for transmission 172 in multiple LSAs as described in Section 5. 174 3. Link Information 176 The most common link sub-TLVs nested in the top-level link TLV are 177 already defined in [RFC3630], [RFC4203]. For example, Link ID, 178 Administrative Group, Interface Switching Capability Descriptor 179 (ISCD), Link Protection Type, Shared Risk Link Group Information 180 (SRLG), and Traffic Engineering Metric are among the typical link 181 sub-TLVs. 183 Per [GEN-Encode], we add the following additional link sub-TLVs to 184 the link TLV in this document. 186 Sub-TLV Type Length Name 188 26 (suggested) variable Port Label Restrictions 190 Generally all the sub-TLVs above are optional, which depends on the 191 control plane implementations. The Port Label Restrictions sub-TLV 192 will not be advertised when there are no restrictions on label 193 assignment. 195 3.1. Port Label Restrictions 197 Port label restrictions describe the label restrictions that the 198 network element (node) and link may impose on a port. These 199 restrictions represent what labels may or may not be used on a link 200 and are intended to be relatively static. For increased modeling 201 flexibility, port label restrictions may be specified relative to 202 the port in general or to a specific connectivity matrix. 204 For example, the Port Label Restrictions describes the wavelength 205 restrictions that the link and various optical devices such as OXCs, 206 ROADMs, and waveband multiplexers may impose on a port in WSON. 207 These restrictions represent what wavelength may or may not be used 208 on a link and are relatively static. The detailed information about 209 port label restrictions is described in [WSON-Info]. 211 The Port Label Restrictions sub-TLV is a sub-TLV of the Link TLV. 212 The length is the length of value field in octets. The meaning and 213 format of this sub-TLV value field are defined in Section 2.2 of 214 [GEN-Encode]. The Port Label Restrictions sub-TLV may occur more 215 than once to specify a complex port constraint within the link TLV. 217 4. Routing Procedures 219 All the sub-TLVs are nested in top-level TLV(s) and contained in 220 Opaque LSAs. The flooding rules of Opaque LSAs are specified in 221 [RFC2328], [RFC5250], [RFC3630], and [RFC4203]. 223 Considering the routing scalability issues in some cases, the 224 routing protocol should be capable of supporting the separation of 225 dynamic information from relatively static information to avoid 226 unnecessary updates of static information when dynamic information 227 is changed. A standards-compliant approach is to separate the 228 dynamic information sub-TLVs from the static information sub-TLVs, 229 each nested in a separate top-level TLV ([RFC3630 and RFC5876]), and 230 advertise them in the separate OSPF TE LSAs. 232 For node information, since the Connectivity Matrix information is 233 static, the LSA containing the Node Attribute TLV can be updated 234 with a lower frequency to avoid unnecessary updates. 236 For link information, a mechanism MAY be applied such that static 237 information and dynamic information of one TE link are contained in 238 separate Opaque LSAs. For example, the Port Label Restrictions 239 information sub-TLV could be nested in separate top level link TLVs 240 and advertised in the separate LSAs. 242 As with other TE information, an implementation typically takes 243 measures to avoid rapid and frequent updates of routing information 244 that could cause the routing network to become swamped. See 245 [RFC3630] Section 3 for related details. 247 5. Scalability and Timeliness 249 This document has defined two sub-TLVs for describing generic 250 routing contraints. The examples given in [GEN-Encode] show that 251 very large systems, in terms of label count or ports, can be very 252 efficiently encoded. However there has been concern expressed that 253 some possible systems may produce LSAs that exceed the IP Maximum 254 Transmission Unit (MTU) and that methods be given to allow for the 255 splitting of general constraint LSAs into smaller LSAs that are 256 under the MTU limit. This section presents a set of techniques that 257 can be used for this purpose. 259 5.1. Different Sub-TLVs into Multiple LSAs 261 Two sub-TLVs are defined in this document: 263 1. Connectivity Matrix (Node Attribute TLV) 264 2. Port Label Restrictions (Link TLV) 266 The Connectivity Matrix can be carried in the Node Attribute TLV as 267 defined in [RFC5786] while the Port Label Restrictions can be 268 carried in an Link TLV of which there can be at most one in an LSA 269 as defined in [RFC3630]. Note that the Port Label Restrictions are 270 relatively static, i.e., only would change with hardware changes or 271 significant system reconfiguration. 273 5.2. Decomposing a Connectivity Matrix into Multiple Matrices 275 In the highly unlikely event that a Connectivity Matrix sub-TLV by 276 itself would result in an LSA exceeding the MTU, a single large 277 matrix can be decomposed into sub-matrices. Per [GEN-Encode] a 278 connectivity matrix just consists of pairs of input and output ports 279 that can reach each other and hence such this decomposition would be 280 straightforward. Each of these sub-matrices would get a unique 281 matrix identifier per [GEN-Encode]. 283 From the point of view of a path computation process, prior to 284 receiving an LSA with a Connectivity Matrix sub-TLV, no connectivity 285 restrictions are assumed, i.e., the standard GMPLS assumption of any 286 port to any port reachability holds. Once a Connectivity Matrix sub- 287 TLV is received then path computation would know that connectivity 288 is restricted and use the information from all Connectivity Matrix 289 sub-TLVs received to understand the complete connectivity potential 290 of the system. Prior to receiving any Connectivity Matrix sub-TLVs 291 path computation may compute a path through the system when in fact 292 no path exists. In between the reception of an additional 293 Connectivity Matrix sub-TLV path computation may not be able to find 294 a path through the system when one actually exists. Both cases are 295 currently encountered and handled with existing GMPLS mechanisms. 296 Due to the reliability mechanisms in OSPF the phenomena of late or 297 missing Connectivity Matrix sub-TLVs would be relatively rare. 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 6. Security Considerations 306 This document does not introduce any further security issues other 307 than those discussed in [RFC3630], [RFC4203]. 309 For general security aspects relevant to Generalized Multiprotocol 310 Label Switching (GMPLS)-controlled networks, please refer to 311 [RFC5920]. 313 7. IANA Considerations 315 IANA is requested to allocate new sub-TLVs as defined in Sections 2 316 and 3 as follows: 318 7.1. Node Information 320 This document defines a new sub-TLV of the Node Attribute TLV (Value 321 5). The assignment of the following new type in the "Types for sub- 322 TLVs of TE Node Attribute TLV" portion of the "Open Shortest Path 323 First (OSPF) Traffic Engineering TLVs" registry is needed: 325 This document introduces the following sub-TLVs of Node Attribute 326 TLV (Value 5): 328 Type sub-TLV 330 14 (suggested, to be assigned by IANA) Connectivity Matrix 332 7.2. Link Information 334 This document defines a new sub-TLV of the TE Link TLV (Value 2). 335 The assignment of the following new type in the "Types for sub-TLVs 336 of TE Link TLV" portion of the "Open Shortest Path First (OSPF) 337 Traffic Engineering TLVs" registry is needed: 339 Type sub-TLV 341 26 (suggested, to be assigned by IANA) Port Label Restrictions 343 8. References 345 8.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 352 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 353 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 354 September 2003. 356 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 357 Extensions in Support of Generalized Multi-Protocol Label 358 Switching (GMPLS)", RFC 4202, October 2005 360 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 361 in Support of Generalized Multi-Protocol Label Switching 362 (GMPLS)", RFC 4203, October 2005. 364 [RFC5250] L. Berger, I. Bryskin, A. Zinin, R. Coltun "The OSPF 365 Opaque LSA Option", RFC 5250, July 2008. 367 [RFC5786] R. Aggarwal and K. Kompella,"Advertising a Router's Local 368 Addresses in OSPF Traffic Engineering (TE) Extensions", 369 RFC 5786, March 2010. 371 [GEN-Encode] G. Bernstein, Y. Lee, D.Li, W. Imajuku, "General 372 Network Element Constraint Encoding for GMPLS Controlled 373 Networks", draft-ietf-ccamp-general-constraint-encode, 374 work-in-progress. 376 8.2. Informative References 378 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and 379 PCE Control of Wavelength Switched Optical Networks 380 (WSON)", RFC 6163, February 2011. 382 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 383 Wavelength Assignment Information Model for Wavelength 384 Switched Optical Networks", draft-ietf-ccamp-rwa-info, 385 work-in-progress. 387 [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS 388 Networks", RFC 5920, July 2010. 390 9. Authors' Addresses 392 Fatai Zhang 393 Huawei Technologies 394 F3-5-B R&D Center, Huawei Base 395 Bantian, Longgang District 396 Shenzhen 518129 P.R.China 398 Phone: +86-755-28972912 399 Email: zhangfatai@huawei.com 401 Young Lee 402 Huawei Technologies 403 5360 Legacy Drive, Building 3 404 Plano, TX 75023 405 USA 406 Phone: (469)277-5838 407 Email: leeyoung@huawei.com 409 Jianrui Han 410 Huawei Technologies Co., Ltd. 411 F3-5-B R&D Center, Huawei Base 412 Bantian, Longgang District 413 Shenzhen 518129 P.R.China 415 Phone: +86-755-28977943 416 Email: hanjianrui@huawei.com 418 Greg Bernstein 419 Grotto Networking 420 Fremont CA, USA 422 Phone: (510) 573-2237 423 Email: gregb@grotto-networking.com 425 Yunbin Xu 426 China Academy of Telecommunication Research of MII 427 11 Yue Tan Nan Jie Beijing, P.R.China 428 Phone: +86-10-68094134 429 Email: xuyunbin@mail.ritt.com.cn 431 Guoying Zhang 432 China Academy of Telecommunication Research of MII 433 11 Yue Tan Nan Jie Beijing, P.R.China 434 Phone: +86-10-68094272 435 Email: zhangguoying@mail.ritt.com.cn 437 Dan Li 438 Huawei Technologies Co., Ltd. 439 F3-5-B R&D Center, Huawei Base 440 Bantian, Longgang District 441 Shenzhen 518129 P.R.China 443 Phone: +86-755-28973237 444 Email: danli@huawei.com 446 Ming Chen 447 European Research Center 448 Huawei Technologies 449 Riesstr. 25, 80992 Munchen, Germany 451 Phone: 0049-89158834072 452 Email: minc@huawei.com 454 Yabin Ye 455 European Research Center 456 Huawei Technologies 457 Riesstr. 25, 80992 Munchen, Germany 459 Phone: 0049-89158834074 460 Email: yabin.ye@huawei.com 462 Acknowledgment 464 We thank Ming Chen and Yabin Ye from DICONNET Project who provided 465 valuable information for this document. 467 Intellectual Property 469 The IETF Trust takes no position regarding the validity or scope of 470 any Intellectual Property Rights or other rights that might be 471 claimed to pertain to the implementation or use of the technology 472 described in any IETF Document or the extent to which any license 473 under such rights might or might not be available; nor does it 474 represent that it has made any independent effort to identify any 475 such rights. 477 Copies of Intellectual Property disclosures made to the IETF 478 Secretariat and any assurances of licenses to be made available, or 479 the result of an attempt made to obtain a general license or 480 permission for the use of such proprietary rights by implementers or 481 users of this specification can be obtained from the IETF on-line 482 IPR repository at http://www.ietf.org/ipr 484 The IETF invites any interested party to bring to its attention any 485 copyrights, patents or patent applications, or other proprietary 486 rights that may cover technology that may be required to implement 487 any standard or specification contained in an IETF Document. Please 488 address the information to the IETF at ietf-ipr@ietf.org. 490 The definitive version of an IETF Document is that published by, or 491 under the auspices of, the IETF. Versions of IETF Documents that are 492 published by third parties, including those that are translated into 493 other languages, should not be considered to be definitive versions 494 of IETF Documents. The definitive version of these Legal Provisions 495 is that published by, or under the auspices of, the IETF. Versions 496 of these Legal Provisions that are published by third parties, 497 including those that are translated into other languages, should not 498 be considered to be definitive versions of these Legal Provisions. 500 For the avoidance of doubt, each Contributor to the IETF Standards 501 Process licenses each Contribution that he or she makes as part of 502 the IETF Standards Process to the IETF Trust pursuant to the 503 provisions of RFC 5378. No language to the contrary, or terms, 504 conditions or rights that differ from or are inconsistent with the 505 rights and licenses granted under RFC 5378, shall have any effect 506 and shall be null and void, whether published or posted by such 507 Contributor, or included with or in such Contribution. 509 Disclaimer of Validity 511 All IETF Documents and the information contained therein are 512 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 513 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 514 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 515 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 516 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 517 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 518 FOR A PARTICULAR PURPOSE. 520 Full Copyright Statement 522 Copyright (c) 2014 IETF Trust and the persons identified as the 523 document authors. All rights reserved. 525 This document is subject to BCP 78 and the IETF Trust's Legal 526 Provisions Relating to IETF Documents 527 (http://trustee.ietf.org/license-info) in effect on the date of 528 publication of this document. Please review these documents 529 carefully, as they describe your rights and restrictions with 530 respect to this document. Code Components extracted from this 531 document must include Simplified BSD License text as described in 532 Section 4.e of the Trust Legal Provisions and are provided without 533 warranty as described in the Simplified BSD License.