idnits 2.17.1 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.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 == Line 250 has weird spacing: '...ability infor...' == Line 494 has weird spacing: '... of these ...' == Line 495 has weird spacing: '...cluding thos...' == Line 496 has weird spacing: '... not be cons...' == Line 505 has weird spacing: '... and shall...' == (1 more instance...) -- The document date (June 26, 2013) is 3951 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: 'Gen-Encode' is mentioned on line 257, but not defined == Missing Reference: 'RFC 3630' is mentioned on line 308, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 308, but not defined == Unused Reference: 'RFC6205' is defined on line 373, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 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: December 26, 2013 June 26, 2013 12 OSPF-TE Extensions for General Network Element Constraints 14 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.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 December 26, 2013. 39 Copyright Notice 41 Copyright (c) 2013 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 can be used to control a 57 wide variety of technologies including packet switching (e.g., MPLS), 58 time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and 59 spatial switching (e.g., incoming port or fiber to outgoing port or 60 fiber). In some of these technologies network elements and links may 61 impose additional routing constraints such as asymmetric switch 62 connectivity, non-local label assignment, and label range 63 limitations on links. This document describes OSPF routing protocol 64 extensions to support these kinds of constraints under the control 65 of Generalized MPLS (GMPLS). 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 RFC-2119 [RFC2119]. 73 Table of Contents 75 1. Introduction...................................................3 76 2. Node Information...............................................3 77 2.1. Connectivity Matrix.......................................4 78 3. Link Information...............................................5 79 3.1. Port Label Restrictions...................................5 80 4. Routing Procedures.............................................6 81 5. Scalability and Timeliness.....................................6 82 5.1. Different Sub-TLVs into Multiple LSAs.....................7 83 5.2. Decomposing a Connectivity Matrix into Multiple Matrices..7 84 6. Security Considerations........................................7 85 7. IANA Considerations............................................8 86 7.1. Node Information..........................................8 87 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 wish to make use of a GMPLS 98 control plane contain additional constraints on switching capability 99 and label assignment. In addition, some of these technologies should 100 be capable of performing non-local label assignment based on the 101 nature of the technology, e.g., wavelength continuity constraint in 102 WSON [RFC6163]. Such constraints can lead to the requirement for 103 link by link label availability in path computation and label 104 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. 111 This document defines extensions to the OSPF routing protocol based 112 on [GEN-Encode] to enhance the Traffic Engineering (TE) properties 113 of GMPLS TE which are defined in [RFC3630], [RFC4202], and [RFC4203]. 114 The enhancements to the Traffic Engineering (TE) properties of GMPLS 115 TE links can be announced in OSPF TE LSAs. The TE LSA, which is an 116 opaque LSA with area flooding scope [RFC3630], has only one top- 117 level Type/Length/Value (TLV) triplet and has one or more nested 118 sub-TLVs for extensibility. The top-level TLV can take one of three 119 values (1) Router Address [RFC3630], (2) Link [RFC3630], (3) Generic 120 Node Attribute defined in Section 2. In this document, we enhance 121 the sub-TLVs for the Link TLV and define a new top-level TLV 122 (Generic Node Attribute TLV) in support of the general network 123 element constraints under the control of GMPLS. 125 The detailed encoding of OSPF extensions are not defined in this 126 document. [GEN-Encode] provides encoding detail. 128 2. Node Information 130 According to [GEN-Encode], the additional node information 131 representing node switching asymmetry constraints includes Node ID, 132 connectivity matrix. Except for the Node ID which should comply with 133 Routing Address described in [RFC3630], the other pieces of 134 information are defined in this document. 136 This document defines a new top TLV named the Generic Node Attribute 137 TLV which carries attributes related to a general network element. 138 This Generic Node Attribute TLV contains one or more sub-TLVs 140 Per [GEN-Encode], we have identified the following new Sub-TLVs to 141 the Generic Node Attribute TLV. Detail description for each newly 142 defined Sub-TLV is provided in subsequent sections: 144 Sub-TLV Type Length Name 146 TBD variable Connectivity Matrix 148 In some specific technologies, e.g., WSON networks, Connectivity 149 Matrix sub-TLV may be optional, which depends on the control plane 150 implementations. Usually, for example, in WSON networks, 151 Connectivity Matrix sub-TLV may appear in the LSAs because WSON 152 switches are asymmetric at present. It is assumed that the switches 153 are symmetric switching, if there is no Connectivity Matrix sub-TLV 154 in the LSAs. 156 2.1. Connectivity Matrix 158 It is necessary to identify which ingress ports and labels can be 159 switched to some specific labels on a specific egress port, if the 160 switching devices in some technology are highly asymmetric. 162 The Connectivity Matrix is used to identify these restrictions, 163 which can represent either the potential connectivity matrix for 164 asymmetric switches (e.g. ROADMs and such) or fixed connectivity for 165 an asymmetric device such as a multiplexer as defined in [WSON- 166 Info]. 168 The Connectivity Matrix is a sub-TLV (the type is TBD by IANA) of 169 the Generic Node Attribute TLV. The length is the length of value 170 field in octets. The meaning and format of this sub-TLV are defined 171 in Section 5.3 of [GEN-Encode]. One sub-TLV contains one matrix. The 172 Connectivity Matrix sub-TLV may occur more than once to contain 173 multi-matrices within the Generic Node Attribute TLV. In addition a 174 large connectivity matrix can be decomposed into smaller separate 175 matrices for transmission in multiple LSAs as described in Section 5. 177 3. Link Information 179 The most common link sub-TLVs nested to link top-level TLV are 180 already defined in [RFC3630], [RFC4203]. For example, Link ID, 181 Administrative Group, Interface Switching Capability Descriptor 182 (ISCD), Link Protection Type, Shared Risk Link Group Information 183 (SRLG), and Traffic Engineering Metric are among the typical link 184 sub-TLVs. 186 Per [GEN-Encode], we add the following additional link sub-TLVs to 187 the link-TLV in this document. 189 Sub-TLV Type Length Name 191 TBD variable Port Label Restrictions 193 Generally all the sub-TLVs above are optional, which depends on the 194 control plane implementations. If it is default no restrictions on 195 labels, Port Label Restrictions sub-TLV may not appear in the LSAs. 197 3.1. Port Label Restrictions 199 Port label restrictions describe the label restrictions that the 200 network element (node) and link may impose on a port. These 201 restrictions represent what labels may or may not be used on a link 202 and are intended to be relatively static. More dynamic information 203 is contained in the information on available labels. Port label 204 restrictions are specified relative to the port in general or to a 205 specific connectivity matrix for increased modeling flexibility. 207 For example, Port Label Restrictions describes the wavelength 208 restrictions that the link and various optical devices such as OXCs, 209 ROADMs, and waveband multiplexers may impose on a port in WSON. 210 These restrictions represent what wavelength may or may not be used 211 on a link and are relatively static. The detailed information about 212 Port label restrictions is described in [WSON-Info]. 214 The Port Label Restrictions is a sub-TLV (the type is TBD by IANA) 215 of the Link TLV. The length is the length of value field in octets. 216 The meaning and format of this sub-TLV are defined in Section 5.4 of 217 [GEN-Encode]. The Port Label Restrictions sub-TLV may occur more 218 than once to specify a complex port constraint within the link TLV. 220 4. Routing Procedures 222 All the sub-TLVs are nested to top-level TLV(s) and contained in 223 Opaque LSAs. The flooding of Opaque LSAs must follow the rules 224 specified in [RFC2328], [RFC5250], [RFC3630], [RFC4203]. 226 Considering the routing scalability issues in some cases, the 227 routing protocol should be capable of supporting the separation of 228 dynamic information from relatively static information to avoid 229 unnecessary updates of static information when dynamic information 230 is changed. A standard-compliant approach is to separate the dynamic 231 information sub-TLVs from the static information sub-TLVs, each 232 nested to top-level TLV ([RFC3630 and RFC5876]), and advertise them 233 in the separate OSPF TE LSAs. 235 For node information, since the Connectivity Matrix information is 236 static, the LSA containing the Generic Node Attribute TLV can be 237 updated with a lower frequency to avoid unnecessary updates. 239 For link information, a mechanism MAY be applied such that static 240 information and dynamic information of one TE link are contained in 241 separate Opaque LSAs. For example, the Port Label Restrictions 242 information sub-TLV could be nested to the top level link TLVs and 243 advertised in the separate LSAs. 245 Note that as with other TE information, an implementation SHOULD 246 take measures to avoid rapid and frequent updates of routing 247 information that could cause the routing network to become swamped. 248 A threshold mechanism MAY be applied such that updates are only 249 flooded when a number of changes have been made to the label 250 availability information (e.g., wavelength availability) within a 251 specific time. Such mechanisms MUST be configurable if they are 252 implemented. 254 5. Scalability and Timeliness 256 This document has defined four sub-TLVs for describing generic 257 routing contraints. The examples given in [Gen-Encode] show that 258 very large systems, in terms of label count or ports can be very 259 efficiently encoded. However there has been concern expressed that 260 some possible systems may produce LSAs that exceed the IP Maximum 261 Transmission Unit (MTU) and that methods be given to allow for the 262 splitting of general constraint LSAs into smaller LSA that are under 263 the MTU limit. This section presents a set of techniques that can be 264 used for this purpose. 266 5.1. Different Sub-TLVs into Multiple LSAs 268 Two sub-TLVs are defined in this document: 270 1. Connectivity Matrix (Generic Node Attribute TLV) 271 2. Port Label Restrictions (Link TLV) 273 Except for the Connectivity Matrix all these are carried in an Link 274 TLV of which there can be at most one in an LSA [RFC3630]. Of these 275 sub-TLVs the Port Label Restrictions are relatively static, i.e., 276 only would change with hardware changes or significant system 277 reconfiguration. 279 5.2. Decomposing a Connectivity Matrix into Multiple Matrices 281 In the highly unlikely event that a Connectivity matrix sub-TLV by 282 itself would result in an LSA exceeding the MTU, a single large 283 matrix can be decomposed into sub-matrices. Per [GEN-Encode] a 284 connectivity matrix just consists of pairs of input and output ports 285 that can reach each other and hence such this decomposition would be 286 straightforward. Each of these sub-matrices would get a unique 287 matrix identifier per [GEN-Encode]. 289 From the point of view of a path computation process, prior to 290 receiving an LSA with a Connectivity Matrix sub-TLV, no connectivity 291 restrictions are assumed, i.e., the standard GMPLS assumption of any 292 port to any port reachability holds. Once a Connectivity Matrix sub- 293 TLV is received then path computation would know that connectivity 294 is restricted and use the information from all Connectivity Matrix 295 sub-TLVs received to understand the complete connectivity potential 296 of the system. Prior to receiving any Connectivity Matrix sub-TLVs 297 path computation may compute a path through the system when in fact 298 no path exists. In between the reception of an additional 299 Connectivity Matrix sub-TLV path computation may not be able to find 300 a path through the system when one actually exists. Both cases are 301 currently encountered and handled with existing GMPLS mechanisms. 302 Due to the reliability mechanisms in OSPF the phenomena of late or 303 missing Connectivity Matrix sub-TLVs would be relatively rare. 305 6. Security Considerations 307 This document does not introduce any further security issues other 308 than those discussed in [RFC 3630], [RFC 4203]. 310 7. IANA Considerations 312 [RFC3630] says that the top level Types in a TE LSA and Types for 313 sub-TLVs for each top level Types must be assigned by Expert Review, 314 and must be registered with IANA. 316 IANA is requested to allocate new Types for the TLV or sub-TLVs as 317 defined in Sections 2 and 3 as follows: 319 7.1. Node Information 321 This document introduces a new Top Level Node TLV (Generic Node 322 Attribute TLV) under the OSPF TE LSA defined in [RFC3630]. 324 Value TLV Type 326 TBA Generic Node Attribute 328 This document also introduces the following sub-TLVs of Generic Node 329 Attribute TLV: 331 Type sub-TLV 333 TBD Connectivity Matrix 335 7.2. Link Information 337 This document introduces the following sub-TLV of TE Link TLV (Value 338 2): 340 Type sub-TLV 342 TBD Port Label Restrictions 344 8. References 346 8.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 353 [RFC5250] L. Berger, I. Bryskin, A. Zinin, R. Coltun "The OSPF 354 Opaque LSA Option", RFC 5250, July 2008. 356 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 357 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 358 September 2003. 360 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 361 Extensions in Support of Generalized Multi-Protocol Label 362 Switching (GMPLS)", RFC 4202, October 2005 364 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 365 in Support of Generalized Multi-Protocol Label Switching 366 (GMPLS)", RFC 4203, October 2005. 368 [GEN-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, " General 369 Network Element Constraint Encoding for GMPLS Controlled 370 Networks", work in progress: draft-ietf-ccamp-general- 371 constraint-encode. 373 [RFC6205] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, " Generalized 374 Labels for Lambda-Switching Capable Label Switching 375 Routers", RFC 6205, January 2011. 377 8.2. Informative References 379 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and 380 PCE Control of Wavelength Switched Optical Networks 381 (WSON)", RFC 6163, February 2011. 383 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 384 Wavelength Assignment Information Model for Wavelength 385 Switched Optical Networks", work in progress: draft-ietf- 386 ccamp-rwa-info. 388 9. Authors' Addresses 390 Fatai Zhang 391 Huawei Technologies 392 F3-5-B R&D Center, Huawei Base 393 Bantian, Longgang District 394 Shenzhen 518129 P.R.China 396 Phone: +86-755-28972912 397 Email: zhangfatai@huawei.com 399 Young Lee 400 Huawei Technologies 401 1700 Alma Drive, Suite 100 402 Plano, TX 75075 403 USA 405 Phone: (972) 509-5599 (x2240) 406 Email: ylee@huawei.com 408 Jianrui Han 409 Huawei Technologies Co., Ltd. 410 F3-5-B R&D Center, Huawei Base 411 Bantian, Longgang District 412 Shenzhen 518129 P.R.China 414 Phone: +86-755-28977943 415 Email: hanjianrui@huawei.com 417 Greg Bernstein 418 Grotto Networking 419 Fremont CA, USA 421 Phone: (510) 573-2237 422 Email: gregb@grotto-networking.com 424 Yunbin Xu 425 China Academy of Telecommunication Research of MII 426 11 Yue Tan Nan Jie Beijing, P.R.China 427 Phone: +86-10-68094134 428 Email: xuyunbin@mail.ritt.com.cn 430 Guoying Zhang 431 China Academy of Telecommunication Research of MII 432 11 Yue Tan Nan Jie Beijing, P.R.China 433 Phone: +86-10-68094272 434 Email: zhangguoying@mail.ritt.com.cn 436 Dan Li 437 Huawei Technologies Co., Ltd. 438 F3-5-B R&D Center, Huawei Base 439 Bantian, Longgang District 440 Shenzhen 518129 P.R.China 442 Phone: +86-755-28973237 443 Email: danli@huawei.com 445 Ming Chen 446 European Research Center 447 Huawei Technologies 448 Riesstr. 25, 80992 Munchen, Germany 450 Phone: 0049-89158834072 451 Email: minc@huawei.com 453 Yabin Ye 454 European Research Center 455 Huawei Technologies 456 Riesstr. 25, 80992 Munchen, Germany 458 Phone: 0049-89158834074 459 Email: yabin.ye@huawei.com 461 Acknowledgment 463 We thank Ming Chen and Yabin Ye from DICONNET Project who provided 464 valuable information for this document. 466 Intellectual Property 467 The IETF Trust takes no position regarding the validity or scope of 468 any Intellectual Property Rights or other rights that might be 469 claimed to pertain to the implementation or use of the technology 470 described in any IETF Document or the extent to which any license 471 under such rights might or might not be available; nor does it 472 represent that it has made any independent effort to identify any 473 such rights. 475 Copies of Intellectual Property disclosures made to the IETF 476 Secretariat and any assurances of licenses to be made available, or 477 the result of an attempt made to obtain a general license or 478 permission for the use of such proprietary rights by implementers or 479 users of this specification can be obtained from the IETF on-line 480 IPR repository at http://www.ietf.org/ipr 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 any standard or specification contained in an IETF Document. Please 486 address the information to the IETF at ietf-ipr@ietf.org. 488 The definitive version of an IETF Document is that published by, or 489 under the auspices of, the IETF. Versions of IETF Documents that are 490 published by third parties, including those that are translated into 491 other languages, should not be considered to be definitive versions 492 of IETF Documents. The definitive version of these Legal Provisions 493 is that published by, or under the auspices of, the IETF. Versions 494 of these Legal Provisions that are published by third parties, 495 including those that are translated into other languages, should 496 not be considered to be definitive versions of these Legal 497 Provisions. 499 For the avoidance of doubt, each Contributor to the IETF Standards 500 Process licenses each Contribution that he or she makes as part of 501 the IETF Standards Process to the IETF Trust pursuant to the 502 provisions of RFC 5378. No language to the contrary, or terms, 503 conditions or rights that differ from or are inconsistent with the 504 rights and licenses granted under RFC 5378, shall have any effect 505 and shall be null and void, whether published or posted by such 506 Contributor, or included with or in such Contribution. 508 Disclaimer of Validity 510 All IETF Documents and the information contained therein are 511 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 512 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 513 SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 514 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 515 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN 516 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 517 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 519 Full Copyright Statement 521 Copyright (c) 2010 IETF Trust and the persons identified as the 522 document authors. All rights reserved. 524 This document is subject to BCP 78 and the IETF Trust's Legal 525 Provisions Relating to IETF Documents 526 (http://trustee.ietf.org/license-info) in effect on the date of 527 publication of this document. Please review these documents 528 carefully, as they describe your rights and restrictions with 529 respect to this document. Code Components extracted from this 530 document must include Simplified BSD License text as described in 531 Section 4.e of the Trust Legal Provisions and are provided without 532 warranty as described in the Simplified BSD License.