idnits 2.17.1 draft-otani-ccamp-gmpls-cspf-constraints-01.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 boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 403), 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. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 258 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 (July 2005) is 6859 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 341 looks like a reference -- Missing reference section? 'GMPLS-routing' on line 97 looks like a reference -- Missing reference section? 'RFC2119' on line 339 looks like a reference -- Missing reference section? 'GMPLS-OSPF' on line 347 looks like a reference -- Missing reference section? 'OSPF-TE' on line 351 looks like a reference -- Missing reference section? 'GMPLS-Routing' on line 343 looks like a reference -- Missing reference section? 'RFC3477' on line 353 looks like a reference -- Missing reference section? 'LSP-HIER' on line 356 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft Tomohiro Otani 3 Proposed status: Best Current Practice Kenichi Ogaki 4 Expires: January 2006 KDDI R&D Labs 5 Arthi Ayyangar 6 Kireeti Kompella 7 Juniper Networks 8 Rajiv Papneja 9 Isocore 10 July 2005 12 GMPLS constraints consideration for CSPF path computation 14 Document: draft-otani-ccamp-gmpls-cspf-constraints-01.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. Informational - Expires January 2006 1 52 Table of Contents 54 Status of this Memo................................................1 55 Abstract...........................................................1 56 1. Introduction....................................................3 57 2. Conventions used in this document...............................3 58 3. Assumed network model...........................................3 59 4. CSPF consideration..............................................5 60 5. Security consideration..........................................8 61 6. Intellectual property considerations............................8 62 7. Informative references..........................................8 63 Author's Addresses.................................................9 64 Document expiration................................................9 65 Copyright statement................................................9 67 T. Otani et al. Informational - Expires January 2006 2 68 1. Introduction 70 A GMPLS network is, in general, controlled and managed by various 71 GMPLS specific TE attributes underlying used physical/logical 72 technologies of links as well as nodes [Arch]. To establish a GMPLS 73 LSP appropriately in such a networking environment, these TE 74 attributes (advertised from others or belonging to themselves) must 75 be dealt correctly when CSPF path computation under a certain GMPLS 76 constraint is conducted [GMPLS-routing], and GMPLS LSP must be 77 created following a feasible route. However, since these constraints 78 vary and are differently understood among such an integrated 79 environment (especially between optical transport point of view and 80 packet transport point of view), this draft proposes and provides a 81 kind of guideline to facilitate GMPLS CSPF path computation, 82 summarizing most possible cases of GMPLS constraint attributes at an 83 ingress link, transit links and an egress link to establish a GMPLS 84 LSP appropriately. 86 2. Conventions used in this document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC-2119 [RFC2119]. 92 3. Assumed network model 94 3.1 GMPLS TE attributes consideration for CSPF calculation 96 For CSPF path computation to establish GMPLS LSPs correctly, various 97 GMPLS attributes [GMPLS-routing, GMPLS-OSPF] of links as well as 98 nodes, as indicated below, must be taken into account in a GMPLS 99 network environment in addition to TE attributes of packet based 100 network [OSPF-TE]. 102 (1) Encoding-type: SONET/SDH, Lambda, Ethernet, etc. 103 (2) Switching capability: TDM, Lambda, Fiber, etc. 104 (3) Bandwidth: OC-192, OC-48, GbE, 10GbE, etc. 106 These logical attributes have a very tight relationship with 107 underlying physical technologies such as SONET/SDH, optical transport 108 network (OTN) or Ethernet in terms of links, and all-optical switches, 109 SONET/SDH-basis digital cross connect or electrical-basis optical 110 switches in terms of nodes. Therefore, the GMPLS LSPs must satisfy 111 logical constrains as well as corresponding physical constraints. 112 These constraints are sometimes differently understood among 113 different layers, and a logically computed GMPLS LSP may violate the 114 physical constraints, therefore, a consistent guideline to solve this 115 issue should be formulated. 117 T. Otani et al. Informational - Expires January 2006 3 118 3.2 Considered network model 120 Figure 1 depicts a typical GMPLS network, consisting of an ingress 121 link, a transit link as well as an egress link, to investigate a 122 consistent guideline for GMPLS CSPF path computation. Each link 123 outgoing or incoming at each interface has its own switching 124 capability, encoding-type and bandwidth. 125 The consideration here is based on a single domain GMPLS network, but 126 the analysis may be able to be applicable to an inter-domain GMPLS 127 network. 129 Ingress Transit Egress 130 +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ 131 |Node1|------------>|Node2|------------>|Node3|------------>|Node4| 132 | |<------------| |<------------| |<------------| | 133 +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ 135 Figure 1: GMPLS network model 137 For the simplicity of the analysis in CSPF consideration, the below 138 assumptions are made when the LSP is created. 140 (1) Switching capabilities (SC) of outgoing links from the 141 ingress and egress nodes (link1-2 and link4-3 in Figure 1) 142 must be consistent with each other. 143 (2) SC of all transit links including incoming links to the 144 ingress and egress nodes (link2-1 and link3-4) should be 145 consistent with switching type of a LSP to be created. 146 (3) Encoding-types of all transit links should be consistent 147 with encoding type of a LSP to be created. 149 GMPLS network is a multi-layer network, which is composed of multiple 150 nodes with different switching capability and encoding type 151 interfaces. Therefore, a hierarchical structure may be considered in 152 CSPF path computation. In such a case, the combination between the 153 switching type and encoding type of a desired LSP, and those of all 154 transit links described as the table in following section may be 155 acceptable. One of advertised multiple switching capabilities for a 156 particular link [GMPLS-Routing] should be appropriately chosen as the 157 switching capability for the link. 159 Bandwidth of each TE link is maximum LSP bandwidth in interface 160 switching capability descriptor at the priority for a desired LSP 161 [GMPLS-OSPF], and encoding-types of incoming and outgoing links on 162 same interface (for example, link1-2 and link2-1) should be 163 consistent with each other. 165 In case that the network is comprised of numbered links and 166 unnumbered links [RFC3477], an ingress node, who is able to support 168 T. Otani et al. Informational - Expires January 2006 4 169 numbered links and unnumbered links may choose both links being part 170 of the same desired LSP. 172 4. CSPF consideration 174 In this section, we consider GMPLS constrains to be satisfied in 175 different cases of link attributes. When a LSP indicated in below 176 tables is created, the CSPF path computation must choose the route so 177 as to satisfy switching capability, encoding-type and bandwidth at 178 the ingress link, transiting links and the egress link indicated in 179 columns next to the created LSP, considering underlying physical 180 constraints. Here, almost cases of GMPLS CSFP consideration are 181 summarized in this document, however, some cases will be added in a 182 future version. 184 (1) TDM-switch capable 186 +-----+---------+---------+------------+---------+------------------+ 187 |Case |LSP |Ingress |Transit |Egress |Remarks | 188 +-----+---------+---------+------------+---------+------------------+ 189 | |SC |TDM |<=TDM* |TDM |<=TDM* | | 190 |1|Enc|SONET/SDH|SONET/SDH|>=SONET/SDH*|SONET/SDH| | 191 | |BW |X |<=bw |<=bw |<=bw |Specified in G.691| 192 +-----+---------+---------+------------+---------+------------------+ 193 | |SC |TDM |<=TDM* |TDM |<=TDM* | | 194 |2|Enc|Etherner |Ethernet |>=Ethernet |Ethernet | | 195 | |BW |X |<=bw |<=bw |<=bw |Specified in IEEE | 196 +-----+---------+---------+------------+---------+------------------+ 197 | |SC |TDM |<=TDM* |TDM |<=TDM* | | 198 |3|Enc|OTN* |OTN* |>=OTN* |OTN* | | 199 | |BW |X |<=bw |<=bw |<=bw |Specified in G.709| 200 +-----+---------+---------+------------+---------+------------------+ 202 * <=TDM means that the constraint contains smaller granular switching 203 capability such as PSC or L2SC, in addition to TDM. In below cases, 204 this notation indicates the same meaning. 205 * >=SONET/SDH means the constraint contains larger granular encoding 206 types of Lambda (photonic) and Fiber, in addition to SONET/SDH. In 207 other cases, this notation indicates the same meaning. 208 *SC in LSP means a desired switching type of LSP. 209 *OTN interfaces are equivalent to digital wrapper technology. 211 Table 1: Desired GMPLS attributes in the case of TDM-SC 213 In this case, since the interface with TDM SC supports sub-rate 214 switching, BW X can be equal to or less than bw of ingress, transit 215 and egress links, and must be larger than the minimum LSP bandwidth 216 in the interface switching capability descriptor. A sub.rate 218 T. Otani et al. Informational - Expires January 2006 5 219 switching is unsuited for a hierarchical LSP, because the lower-layer 220 link usually has larger granular bandwidth than that layer except 221 PSC-x, for example a TDM LSP with the desired bandwidth of OC-12 222 should not use a lambda switching capable link with the bandwidth of 223 OC-48 as a transit link. In such a case, a lambda LSP as a forwarding 224 adjacency (FA) LSP is created on the lower (lambda) layer in advance, 225 then the FA-LSP [LSP-HIER] may be advertised as a TDM SC link. 227 (2) Lambda switch capable (LSC) 229 +-----+---------+---------+-----------+---------+------------------+ 230 |Case |LSP |Ingress |Transit |Egress |Remarks | 231 +-----+---------+---------+-----------+---------+------------------+ 232 | |SC |lambda |<=lambda |>=lambda* |<=lambda |gmpls-routing-09 | 233 |1|Enc|lambda |lambda |>=lambda |lambda |section 3.7, 3.10 | 234 | |BW |X |=bw |=bw |=bw | | 235 +-----+---------+---------+-----------+---------+------------------+ 236 | |SC |lambda |<=lambda |>=lambda* |<=lambda |gmpls-routing-09 | 237 |2|Enc|SONET/SDH|SONET/SDH|>=SONET/SDH|SONET/SDH|section 3.6, 3.9 | 238 | |BW |X |=bw |=bw |=bw |Specified in G.691| 239 +-----+---------+---------+-----------+---------+------------------+ 240 | |SC |lambda |<=lambda |>=lambda* |<=lambda | | 241 |3|Enc|Etherner |Ethernet |>=Ethernet |Ethernet | | 242 | |BW |X |=bw |=bw |=bw |Specified in IEEE | 243 +-----+---------+---------+-----------+---------+------------------+ 244 | |SC |lambda |<=lambda |>=lambda* |<=lambda | | 245 |4|Enc|OTN |OTN |>=OTN |OTN | | 246 | |BW |X |=bw |=bw |=bw |Specified in G.709| 247 +-----+---------+---------+-----------+---------+------------------+ 249 *>=lambda means the constraint contains fiber switching capability, 250 in addition to lambda. In other cases, this notation indicates the 251 same meaning. 253 Table 2: Desired GMPLS attributes in the case of LSC 255 The interface with LSC supports only optical signal switching, BW X 256 must be equal to bw. In the case of a interface with a lambda 257 encoding-type and a transparent to bit-rate and framing, BW X must be 258 equal to or less than bw. 260 T. Otani et al. Informational - Expires January 2006 6 261 (3) Fiber switch capable (FSC) 263 +-----+---------+---------+-----------+---------+------------------+ 264 |Case |LSP |Ingress |Transit |Egress |Remarks | 265 +-----+---------+---------+-----------+---------+------------------+ 266 | |SC |Fiber |<=Fiber |Fiber |<=Fiber |gmpls-routing-09 | 267 |1|Enc|lambda |lambda |>=lambda |lambda |section 3.8 | 268 | |BW |X |<=bw |<=bw |<=bw | | 269 +-----+---------+---------+-----------+---------+------------------+ 271 Table 3: Desired GMPLS attributes in the case of FSC 273 Although the interface with FSC can switch the entire contents to 274 another interface, this interface should be used for only optical 275 wavelength or waveband switching. 277 (4) Layer 2 switch capable (L2SC) 279 The guideline for the calculation must be created after the 280 definition and discussion L2SW are settled down. 282 (5) Packet switch capable (PSC) 284 +-----+---------+---------+-----------+---------+-------------------+ 285 |Case |LSP |Ingress |Transit |Egress |Remarks | 286 +-----+---------+---------+-----------+---------+-------------------+ 287 | |SC |PSC |PSC |PSC |PSC | | 288 |1|Enc|Packet |Packet |>=Packet |Packet | | 289 | |BW |X |<=bw |<=bw |<=bw | | 290 +-----+---------+---------+-----------+---------+-------------------+ 291 | |SC |PSC |PSC |PSC |PSC | | 292 |2|Enc|SONET/SDH|SONET/SDH|>=SONET/SDH|SONET/SDH| | 293 | |BW |X |<=bw |<=bw |<=bw | | 294 +-----+---------+---------+-----------+---------+-------------------+ 295 | |SC |PSC |PSC |PSC |PSC | | 296 |3|Enc|Ethernet |Ethernet |>=Ethernet |Ethernet | | 297 | |BW |X |<=bw |<=bw |<=bw | | 298 +-----+---------+---------+-----------+---------+-------------------+ 300 Table 4: Desired GMPLS attributes in the case of PSC 302 Since the interface with PSC supports only packet-by-packet switching, 303 BW X must be equal to or less than bw, and must be larger than the 304 minimum LSP bandwidth. 306 These GMPLS constraints must be considered for computing CSPF and 307 creating GMPLS LSPs. 309 T. Otani et al. Informational - Expires January 2006 7 310 6. Security consideration 312 GMPLS CSPF consideration will not change the underlying security 313 issues. 315 7. Intellectual property considerations 317 The IETF takes no position regarding the validity or scope of any 318 intellectual property or other rights that might be claimed to 319 pertain to the implementation or use of the technology described in 320 this document or the extent to which any license under such rights 321 might or might not be available; neither does it represent that it 322 has made any effort to identify any such rights. Information on the 323 IETF's procedures with respect to rights in standards-track and 324 standards-related documentation can be found in BCP-11. Copies of 325 claims of rights made available for publication and any assurances of 326 licenses to be made available, or the result of an attempt made to 327 obtain a general license or permission for the use of such 328 proprietary rights by implementers or users of this specification can 329 be obtained from the IETF Secretariat. 331 The IETF invites any interested party to bring to its attention any 332 copyrights, patents or patent applications, or other proprietary 333 rights which may cover technology that may be required to practice 334 this standard. Please address the information to the IETF Executive 335 Director. 337 8. Informative references 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [Arch] E. Mannie, "Generalized Multi-Protocol Label 342 Switching Architecture", RFC3945, October, 2004. 343 [GMPLS-Routing] K. Kompella and Y. Rekhter, "Routing Extensions in 344 Support of Generalized Multi-Protocol Label 345 Switching", draft-ietf-ccamp-gmpls-routing-09.txt, 346 October 2003. 347 [GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in 348 Support of Generalized Multi-Protocol Label 349 Switching", draft-ietf-ccamp-ospf-gmpls-extensions- 350 12.txt, October 2003. 351 [OSPF-TE] Katz, D., et al, "Traffic Engineering (TE) Extensions 352 to OSPF Version 2", RFC3630, September 2003. 353 [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumberd 354 Links in Resource ReSerVation Protocol - Traffic 355 Engineering (RSVP-TE)", RFC3477, January 2003. 356 [LSP-HIER] K.Komepella and Y. Rekhter, "LSP Hierarchy with 357 Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy- 358 08.txt, February 2002. 360 T. Otani et al. Informational - Expires January 2006 8 361 Author's Addresses 363 Tomohiro Otani 364 KDDI R&D Laboratories, Inc. 365 2-1-15 Ohara Kamifukuoka-shi 366 Saitama, 356-8502 Japan 367 Phone: +81-49-278-7357 368 Email: otani@kddilabs.jp 370 Kenichi Ogaki 371 KDDI R&D Laboratories, Inc. 372 2-1-15 Ohara Kamifukuoka-shi 373 Saitama, 356-8502 Japan 374 Phone: +81-49-278-7897 375 Email: ogaki@kddilabs.jp 377 Arthi Ayyangar 378 Juniper Networks 379 1194 N. Mathilda Ave. 380 Sunnyvale, CA 94089 US 381 Email: arthi@juniper.net 383 Rajiv Papneja 384 Isocore 385 12359 Sunrise Valley Drive 386 Suite 100, Reston, VA 20191 US 387 Email: rpapneja@isocore.com 389 Kireeti Kompella 390 Juniper Networks 391 1194 N. Mathilda Ave. 392 Sunnyvale, CA 94089 US 393 Email: kireeti@juniper.net 395 Document expiration 397 This document will be expired in January 2006, unless it is updated. 399 Copyright statement 401 Copyright (C) The Internet Society (2005). This document is subject 402 to the rights, licenses and restrictions contained in BCP 78, and 403 except as set forth therein, the authors retain all their rights. 405 This document and the information contained herein are provided on an 406 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 407 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 408 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 410 T. Otani et al. Informational - Expires January 2006 9 411 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 412 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 415 T. Otani et al. Informational - Expires January 2006 10