idnits 2.17.1 draft-otani-ccamp-gmpls-cspf-constraints-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 446. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 438), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security consideration' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 279 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([GMPLS-OSPF], [RFC2119], [GMPLS-Routing], [RFC3477], [GMPLS-routing,GMPLS-OSPF], [GMPLS-routing], [OSPF-TE], [LSP-HIER], [Arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6740 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 section? 'Arch' on line 374 looks like a reference -- Missing reference section? 'GMPLS-routing' on line 101 looks like a reference -- Missing reference section? 'RFC2119' on line 372 looks like a reference -- Missing reference section? 'GMPLS-OSPF' on line 380 looks like a reference -- Missing reference section? 'OSPF-TE' on line 384 looks like a reference -- Missing reference section? 'GMPLS-Routing' on line 376 looks like a reference -- Missing reference section? 'RFC3477' on line 386 looks like a reference -- Missing reference section? 'LSP-HIER' on line 389 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft Tomohiro Otani 3 Proposed status: Standards Track Kenichi Ogaki 4 Expires: April 2006 KDDI R&D Labs 5 Arthi Ayyangar 6 Kireeti Kompella 7 Juniper Networks 8 Rajiv Papneja 9 Isocore 10 October 2005 12 GMPLS constraints consideration for CSPF path computation 14 Document: draft-otani-ccamp-gmpls-cspf-constraints-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 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 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 This draft provides the guideline to consider generalized multi- 44 protocol label switching (GMPLS) traffic-engineering (TE) attributes 45 for constraint-based shortest path first (CSPF) path computation at a 46 source node in a GMPLS network environment. This draft summarizes 47 most possible cases of GMPLS constraint TE attributes at an ingress 48 link, transit links and an egress link to establish a GMPLS label 49 switched path (LSP) appropriately. 51 T. Otani et al. Expires April 2006 1 52 October 2005 54 Table of Contents 56 Status of this Memo................................................1 57 Abstract...........................................................1 58 1. Introduction....................................................3 59 2. Conventions used in this document...............................3 60 3. Assumed network model...........................................3 61 4. CSPF consideration..............................................5 62 5. Security consideration..........................................8 63 6. Intellectual property considerations............................8 64 7. Informative references..........................................9 65 Author's Addresses.................................................9 66 Document expiration...............................................10 67 Copyright statement...............................................10 69 T. Otani et al. Expires April 2006 2 70 October 2005 72 1. Introduction 74 A GMPLS network is, in general, controlled and managed by various 75 GMPLS specific TE attributes underlying used physical/logical 76 technologies of links as well as nodes [Arch]. To establish a GMPLS 77 LSP appropriately in such a networking environment, these TE 78 attributes (advertised from others or belonging to themselves) must 79 be dealt correctly when CSPF path computation under a certain GMPLS 80 constraint is conducted [GMPLS-routing], and GMPLS LSP must be 81 created following a feasible route. However, since these constraints 82 vary and are differently understood among such an integrated 83 environment (especially between optical transport point of view and 84 packet transport point of view), this draft proposes and provides a 85 kind of guideline to facilitate GMPLS CSPF path computation, 86 summarizing most possible cases of GMPLS constraint attributes at an 87 ingress link, transit links and an egress link to establish a GMPLS 88 LSP appropriately. 90 2. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC-2119 [RFC2119]. 96 3. Assumed network model 98 3.1 GMPLS TE attributes consideration for CSPF calculation 100 For CSPF path computation to establish GMPLS LSPs correctly, various 101 GMPLS attributes [GMPLS-routing, GMPLS-OSPF] of links as well as 102 nodes, as indicated below, must be taken into account in a GMPLS 103 network environment in addition to TE attributes of packet based 104 network [OSPF-TE]. 106 (1) Encoding-type: SONET/SDH, Lambda, Ethernet, etc. 107 (2) Switching capability: TDM, Lambda, Fiber, etc. 108 (3) Bandwidth: OC-192, OC-48, GbE, 10GbE, etc. 110 These logical attributes have a very tight relationship with 111 underlying physical technologies such as SONET/SDH, optical transport 112 network (OTN) or Ethernet in terms of links, and all-optical switches, 113 SONET/SDH-basis digital cross connect or electrical-basis optical 114 switches in terms of nodes. Therefore, the GMPLS LSPs must satisfy 115 logical constrains as well as corresponding physical constraints. 116 These constraints are sometimes differently understood among 117 different layers, and a logically computed GMPLS LSP may violate the 118 physical constraints, therefore, a consistent guideline to solve this 119 issue should be formulated. 121 T. Otani et al. Expires April 2006 3 122 October 2005 124 3.2 Considered network model 126 Figure 1 depicts a typical GMPLS network, consisting of an ingress 127 link, a transit link as well as an egress link, to investigate a 128 consistent guideline for GMPLS CSPF path computation. Each link 129 outgoing or incoming at each interface has its own switching 130 capability, encoding-type and bandwidth. 131 The consideration here is based on a single domain GMPLS network, but 132 the analysis may be able to be applicable to an inter-domain GMPLS 133 network. 135 Ingress Transit Egress 136 +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ 137 |Node1|------------>|Node2|------------>|Node3|------------>|Node4| 138 | |<------------| |<------------| |<------------| | 139 +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ 141 Figure 1: GMPLS network model 143 For the simplicity of the analysis in CSPF consideration, the below 144 basic assumptions are made when the LSP is created. 146 (1) Switching capabilities (SC) of outgoing links from the 147 ingress and egress nodes (link1-2 and link4-3 in Figure 1) 148 must be consistent with each other. 149 (2) SC of all transit links including incoming links to the 150 ingress and egress nodes (link2-1 and link3-4) should be 151 consistent with switching type of a LSP to be created. 152 (3) Encoding-types of all transit links should be consistent 153 with encoding type of a LSP to be created. 155 GMPLS network is a multi-layer network, which is composed of multiple 156 nodes with different switching capability and encoding type 157 interfaces. Therefore, a hierarchical structure may be considered in 158 CSPF path computation. In such a case, the combination between the 159 switching type and encoding type of a desired LSP, and those of all 160 transit links described as the table in following section may be 161 acceptable. One of advertised multiple interface switching capability 162 descriptors for the same link [GMPLS-Routing] should be also 163 appropriately chosen as the attribute for the link. 165 Bandwidth of each TE link is maximum LSP bandwidth in interface 166 switching capability descriptor at the priority for a desired LSP 167 [GMPLS-OSPF], and encoding-types of incoming and outgoing links on 168 the same interface (for example, link1-2 and link2-1) should be 169 consistent with each other. 171 T. Otani et al. Expires April 2006 4 172 October 2005 174 In case that the network is comprised of numbered links and 175 unnumbered links [RFC3477], an ingress node, who is able to support 176 numbered links and unnumbered links may choose both links being part 177 of the same desired LSP. 179 4. CSPF consideration 181 In this section, we consider GMPLS constraints to be satisfied in 182 different cases of link attributes. When a LSP indicated in below 183 tables is created, the CSPF path computation must choose the route so 184 as to satisfy switching capability, encoding-type and bandwidth at 185 the ingress link, transiting links and the egress link indicated in 186 columns next to the created LSP, considering underlying physical 187 constraints. Here, almost cases of GMPLS CSPF consideration are 188 summarized in this document, however, some cases will be added in a 189 future version. 191 (1) TDM-switch capable 193 Table 1: Desired GMPLS attributes in the case of TDM-SC 195 +-------------+---------+------------+---------+------------------+ 196 |LSP attribute|Ingress |Transit |Egress |Remarks | 197 +---+---------+---------+------------+---------+------------------+ 198 | | |TDM | |TDM | | 199 | | +---------+ +---------+ | 200 |SC*|TDM |L2SC |TDM |L2SC | | 201 | | +---------+ +---------+ | 202 | | |PSC | |PSC | | 203 +---+---------+---------+------------+---------+ | 204 | |SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|Specified in G.691| 205 | +---------+---------+------------+---------+ | 206 |Enc|Ethernet |Ethernet |SONET/SDH |Ethernet |Specified in IEEE | 207 | | | |or Ethernet | | | 208 | +---------+---------+------------+---------+ | 209 | |OTN* |OTN |OTN |OTN | | 210 +---+---------+---------+------------+---------+ | 211 |BW |X |<=bw |<=bw |<=bw | | 212 +---+---------+---------+------------+---------+------------------+ 214 *SC in LSP means a desired switching type of LSP. 215 *OTN interfaces are equivalent to digital wrapper technology in this 216 draft. 218 In this case, since the interface with TDM SC supports sub-rate 219 switching, BW X can be equal to or less than bw of ingress, transit 220 and egress links, and must be larger than the minimum LSP bandwidth 222 T. Otani et al. Expires April 2006 5 223 October 2005 225 in the interface switching capability descriptor. A sub-rate 226 switching is unsuited for a hierarchical LSP, because the lower-layer 227 link usually has larger granular bandwidth than that layer except 228 PSC-x, for example a TDM LSP with the desired bandwidth of OC-12 229 should not use a lambda switching capable link with the bandwidth of 230 OC-48 as a transit link. In such a case, a lambda LSP as a forwarding 231 adjacency (FA) LSP is created on the lower (lambda) layer in advance, 232 then the FA-LSP [LSP-HIER] may be advertised as a TDM SC link. 234 (2) Lambda switch capable (LSC) 236 Table 2: Desired GMPLS attributes in the case of LSC 238 +-------------+---------+------------+---------+------------------+ 239 |LSP attribute|Ingress |Transit |Egress |Remarks | 240 +---+---------+---------+------------+---------+------------------+ 241 | | |LSC | |LSC | | 242 | | +---------+ +---------+ | 243 |SC |LSC |TDM |LSC |TDM | | 244 | | +---------+ +---------+ | 245 | | |L2SC | |L2SC | | 246 | | +---------+ +---------+ | 247 | | |PSC | |PSC | | 248 +---+---------+---------+------------+---------+gmpls-routing-09 | 249 | |lambda |lambda |lambda |lambda |section 3.7, 3.10 | 250 | +---------+---------+------------+---------+ | 251 |Enc|SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|section 3.6, 3.9 | 252 | | |or lambda|or lambda |or lambda|Specified in G.691| 253 | +---------+---------+------------+---------+ | 254 | |Ethernet |Ehernet |Ethernet |Ethernet |Specified in IEEE | 255 | | |or lambda|or lambda |or lambda| | 256 | +---------+---------+------------+---------+ | 257 | |OTN |OTN |OTN |OTN |Specified in G.709| 258 | | |or lambda|or lambda |or lambda| | 259 +---+---------+---------+------------+---------+ | 260 |BW |X |=bw |=bw |=bw | | 261 +---+---------+---------+------------+---------+------------------+ 263 The interface with LSC supports only optical signal switching, BW X 264 must be equal to bw. In the case of a interface with a lambda 265 encoding-type and a transparent to bit-rate and framing, BW X must be 266 equal to or less than bw. 268 T. Otani et al. Expires April 2006 6 269 October 2005 271 (3) Fiber switch capable (FSC) 273 Table 3: Desired GMPLS attributes in the case of FSC 275 +---+---------+---------+------------+---------+------------------+ 276 |LSP attribute|Ingress |Transit |Egress |Remarks | 277 +---+---------+---------+------------+---------+------------------+ 278 | | |FSC | |FSC | | 279 | | +---------+ +---------+ | 280 | | |LSC | |LSC | | 281 | | +---------+ +---------+ | 282 |SC |FSC |TDM |FSC |TDM | | 283 | | +---------+ +---------+ | 284 | | |L2SC | |L2SC | | 285 | | +---------+ +---------+ | 286 | | |PSC | |PSC | | 287 +---+---------+---------+------------+---------+gmpls-routing-09 | 288 | |fiber |fiber |fiber |fiber |section 3.8 | 289 | +---------+---------+------------+---------+ | 290 | |lambda |lambda |lambda |lambda |section 3.7, 3.10 | 291 | | |or fiber |or fiber |or fiber | | 292 | +---------+---------+------------+---------+ | 293 |Enc| |SONET/SDH|SONET/SDH |SONET/SDH|section 3.6, 3.9 | 294 | |SONET/SDH|, lambda |, lambda |, lambda |Specified in G.691| 295 | | |or fiber |or fiber |or fiber | | 296 | +---------+---------+------------+---------+ | 297 | | |Ehernet, |Ethernet, |Ethernet,|Specified in IEEE | 298 | |Ethernet |lambda |lambda |lambda | | 299 | | |or fiber |or fiber |or fiber | | 300 | +---------+---------+------------+---------+ | 301 | | |OTN, |OTN, |OTN, |Specified in G.709| 302 | |OTN |lambda |lambda |lambda | | 303 | | |or fiber |or fiber |or fiber | | 304 +---+---------+---------+------------+---------+ | 305 |BW |X |<=bw |<=bw |<=bw | | 306 +---+---------+---------+------------+---------+------------------+ 308 Although the interface with FSC can switch the entire contents to 309 another interface, this interface should be used for only optical 310 wavelength or waveband switching. 312 (4) Layer 2 switch capable (L2SC) 314 The guideline for the calculation must be created after the 315 definition and discussion L2SW are settled down. 317 T. Otani et al. Expires April 2006 7 318 October 2005 320 (5) Packet switch capable (PSC) 322 Table 4: Desired GMPLS attributes in the case of PSC 323 +-------------+---------+------------+---------+------------------+ 324 |LSP attribute|Ingress |Transit |Egress |Remarks | 325 +---+---------+---------+------------+---------+------------------+ 326 |SC |PSC |PSC |PSC |PSC | | 327 +---+---------+---------+------------+---------+ | 328 |Enc|Packet |Packet |Packet |Packet | | 329 +---+---------+---------+------------+---------+ | 330 |BW |X |<=bw |<=bw |<=bw | | 331 +---+---------+---------+------------+---------+------------------+ 333 Since the interface with PSC supports only packet-by-packet switching, 334 BW X must be equal to or less than bw, and must be larger than the 335 minimum LSP bandwidth. 337 These GMPLS constraints must be considered for computing CSPF and 338 creating GMPLS LSPs. 340 6. Security consideration 342 GMPLS CSPF consideration will not change the underlying security 343 issues. 345 7. Intellectual property considerations 347 The IETF takes no position regarding the validity or scope of any 348 intellectual property or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; neither does it represent that it 352 has made any effort to identify any such rights. Information on the 353 IETF's procedures with respect to rights in standards-track and 354 standards-related documentation can be found in BCP-11. Copies of 355 claims of rights made available for publication and any assurances of 356 licenses to be made available, or the result of an attempt made to 357 obtain a general license or permission for the use of such 358 proprietary rights by implementers or users of this specification can 359 be obtained from the IETF Secretariat. 361 The IETF invites any interested party to bring to its attention any 362 copyrights, patents or patent applications, or other proprietary 363 rights which may cover technology that may be required to practice 364 this standard. Please address the information to the IETF Executive 365 Director. 367 T. Otani et al. Expires April 2006 8 368 October 2005 370 8. Informative references 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 [Arch] E. Mannie, "Generalized Multi-Protocol Label 375 Switching Architecture", RFC3945, October, 2004. 376 [GMPLS-Routing] K. Kompella and Y. Rekhter, "Routing Extensions in 377 Support of Generalized Multi-Protocol Label 378 Switching", draft-ietf-ccamp-gmpls-routing-09.txt, 379 October 2003. 380 [GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in 381 Support of Generalized Multi-Protocol Label 382 Switching", draft-ietf-ccamp-ospf-gmpls-extensions- 383 12.txt, October 2003. 384 [OSPF-TE] Katz, D., et al, "Traffic Engineering (TE) Extensions 385 to OSPF Version 2", RFC3630, September 2003. 386 [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumberd 387 Links in Resource ReSerVation Protocol - Traffic 388 Engineering (RSVP-TE)", RFC3477, January 2003. 389 [LSP-HIER] K.Komepella and Y. Rekhter, "LSP Hierarchy with 390 Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy- 391 08.txt, February 2002. 393 Author's Addresses 395 Tomohiro Otani 396 KDDI R&D Laboratories, Inc. 397 2-1-15 Ohara Kamifukuoka-shi 398 Saitama, 356-8502 Japan 399 Phone: +81-49-278-7357 400 Email: otani@kddilabs.jp 402 Kenichi Ogaki 403 KDDI R&D Laboratories, Inc. 404 2-1-15 Ohara Kamifukuoka-shi 405 Saitama, 356-8502 Japan 406 Phone: +81-49-278-7897 407 Email: ogaki@kddilabs.jp 409 Arthi Ayyangar 410 Juniper Networks 411 1194 N. Mathilda Ave. 412 Sunnyvale, CA 94089 US 413 Email: arthi@juniper.net 415 Rajiv Papneja 416 Isocore 417 12359 Sunrise Valley Drive 418 Suite 100, Reston, VA 20191 US 419 Email: rpapneja@isocore.com 421 T. Otani et al. Expires April 2006 9 422 October 2005 424 Kireeti Kompella 425 Juniper Networks 426 1194 N. Mathilda Ave. 427 Sunnyvale, CA 94089 US 428 Email: kireeti@juniper.net 430 Document expiration 432 This document will be expired in April 2006, unless it is updated. 434 Copyright statement 436 Copyright (C) The Internet Society (2005). This document is subject 437 to the rights, licenses and restrictions contained in BCP 78, and 438 except as set forth therein, the authors retain all their rights. 440 This document and the information contained herein are provided on an 441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 443 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 444 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 445 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 448 T. Otani et al. Expires April 2006 10