idnits 2.17.1 draft-ganti-tewg-diffserv-multicos-elspreq-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 396 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 102 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([DSTEREQ]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 20 has weird spacing: '... This docum...' == Line 24 has weird spacing: '...), its areas...' == Line 25 has weird spacing: '...ups may also ...' == Line 29 has weird spacing: '...ents at any...' == Line 30 has weird spacing: '...e. It is i...' == (97 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'DSARCH' is mentioned on line 64, but not defined == Missing Reference: 'DS-TE-REQ' is mentioned on line 125, but not defined == Missing Reference: 'DSPROTO' is mentioned on line 258, but not defined == Missing Reference: 'DIFF-MPLS' is mentioned on line 288, but not defined == Unused Reference: 'RSVP-TE' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'CR-LDP' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'PHBID' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'DS-PROTO' is defined on line 341, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TEREQ') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-diff-ext-08 == Outdated reference: A later version (-08) exists of draft-ietf-diffserv-new-terms-04 ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-new-terms (ref. 'DIFFTERM') -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP-TE' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 ** Obsolete normative reference: RFC 2836 (ref. 'PHBID') (Obsoleted by RFC 3140) == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-03 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (ref. 'DSTEREQ') == Outdated reference: A later version (-08) exists of draft-ietf-tewg-diff-te-proto-00 == Outdated reference: A later version (-02) exists of draft-ganti-mpls-diffserv-elsp-01 -- Possible downref: Normative reference to a draft: ref. 'GANTI' -- Possible downref: Normative reference to a draft: ref. 'IOVANNA' Summary: 11 errors (**), 0 flaws (~~), 22 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S. Ganti 3 N. Seddigh 4 B. Nandy 5 Tropic Networks 7 N. Harrison 8 BT 10 INTERNET DRAFT S. Choudhury 11 Internet Engineering Task Force Marconi 12 Traffic Engineering Working Group 13 Expires August, 2002 February, 2002 15 DS-TE Requirements for Support of multiple-COS on an E-LSP 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 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- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Distribution of this memo is unlimited. 41 Abstract 43 The current DS-TE requirements document [DSTEREQ] focuses on 44 solutions that enable carrying a single Class of Service on an LSP. 46 This document extends the work in [DSTEREQ] by motivating the need to 47 support a DS-TE solution that enables multiple COS on an E-LSP. The 48 document further defines the requirements for such an approach. 50 The requirements are developed such that this approach would be an 51 optional extension to the existing DS-TE. 53 1.0 Introduction 55 Recently there have emerged a number of initiatives with the goal of 56 improving on the current best-effort service model delivered by IP 57 networks. Traffic Engineering (TE) is one key element in the tool-kit 58 to deliver such improved service. Initial TE solutions [TEREQ] used 59 MPLS (Multi-Protocol Label Switching) [MPLSARCH] to steer best-effort 60 traffic away from shortest-path congested links. Such an approach is 61 intended to distribute load across the network and improve overall 62 network performance. 64 At the same time, DiffServ [DSARCH] has defined a number of traffic 65 conditioning mechanisms and Per-Hop-Behaviour which can be combined 66 to provide QoS assurance and multiple classes of service in IP 67 networks. The Diff-Serv approach has recently been extended to enable 68 multiple classes of service to be carried over a single LSP 69 [DIFFMPLS]. [DIFFMPLS] defines two types of LSPs to support DiffServ 70 over MPLS: E-LSPs (EXP-inferred-LSPs) and L-LSPs (Label-Only- 71 Inferred-LSPs). The L-LSP approach is intended to carry a single 72 class of traffic per LSP. LSRs use per-LSP state information to 73 determine the PHB to apply against packets of an LSP. E-LSPs allow 74 multiple classes of traffic to be carried over a single LSP. In this 75 case, the MPLS Label-Stack-Entry EXP bits indicate the PHB to be 76 applied against a particular packet. DS-TE using E-LSPs. 78 DiffServ-Aware Traffic Engineering (DS-TE) combines Diffserv and 79 Traffic Engineering in an effort to provide end-to-end service 80 guarantees within an MPLS network. Incoming traffic is mapped to 81 paths within the network that satisfy certain engineering constraints 82 on a per-class basis. 84 The current DS-TE Requirements document [DSTEREQ] focuses on the 85 requirements to support carrying a single class of traffic on LSPs. 87 This document expands on [DSTEREQ] to discuss the DS-TE requirements 88 to carry multiple classes of traffic on an LSP. We also elaborate and 89 consider various application scenarios where it may be desirable to 90 support DS-TE with multiple classes of traffic on an LSP. It is 91 understood that not all DS-TE networks will want to support multiple 92 classes of traffic per LSP. As such the requirements defined herein 93 are intended to be optional and to co-exist with [DSTEREQ]. 95 The terms class and OA (ordered aggregate) are used inter-changeably 96 throughout this document. 98 2.0 Current DS-TE Requirements 100 [DSTEREQ] presents the service provider requirements for support of 101 Diff-serv aware traffic engineering using the LSPs. While [DSTEREQ] 102 discusses requirements for a network with multiple classes of 103 service, it focuses on using LSPs that carry essentially a single 104 class of service. In certain parts of the document it discusses use 105 of LSP with multiple classes of service however, for the purposes of 106 TE (route advertisements, MPLS signalling path computation and 107 admission control), these multiple classes are treated as a single 108 class. 110 Five possible options exist in relation to the usage of L-LSPs and 111 E-LSPs in a general DS-TE framework: 113 a) Using E-LSPs to carry traffic entirely from a single OA 114 b) Using E-LSPs to carry traffic for multiple OAs all sharing a 115 single set of traffic parameters and with single set of 116 pre-emption/protection attributes 117 c) Using E-LSPs to carry traffic from multiple OAs, each with 118 their own set of traffic parameters but with single set of 119 pre-emption/protection attributes. 120 d) Using E-LSPs to carry traffic from multiple OAs, each with 121 their own set of traffic parameters and pre-emption/protection 122 attributes. 123 e) Using L-LSP to carry traffic from a single OA 125 [DS-TE-REQ] describes mapping of single-OA traffic on to MPLS 126 tunnnels using options (a) and (e). It allows support for carrying 127 multiple-OA traffic using option (b) on an aggregate basis only. i.e 128 with a single set of constraints and thus to treat all the OAs as a 129 single class for the purposes of TE. The document does not discuss 130 options (c) and (d). 132 At the current time, it does not appear that there is any interest in 133 supporting option (d) as pre-emption priorities apply to the entire 134 LSP and not to a subset of traffic on that LSP. 136 This document therefore presents the requirements to support option 137 (c) above as an extension to [DSTEREQ]. The following section focuses 138 on various application scenarios where it may be desirable to utilize 139 the approach of (c). 141 3.0 DS-TE Application Scenarios - Multiple COS per LSP 143 There are a number of good reasons why service providers are 144 interested in using DS-TE to carry multiple classes of service on an 145 LSP. The key reaons can be summarized as follows: 147 a) Ability to carry multiple classes of a single customer 148 traffic on the same LSP 149 b) Reduction in number of LSPs in the network (one LSP instead 150 of "x" LSPs to carry "x"classes) 151 c) One DS traffic pipe that is easy to manage, apply path protection 152 and restoration capabilities. 154 The following are application scenarios where E-LSPs can be used in a 155 DS-TE framework to carry multiple classes of traffic each with their 156 own set of BW constraints. 158 3.1 Using E-LSPs based on aggregate traffic requirements: 160 An MPLS/IP network may desire to carry its VoIP data and signalling 161 on the same LSP yet treat the two traffic types as two different 162 classes. For example, it may want to map its VoIP data to be treated 163 by the EF PHB and the VoIP signaling to be treated by the AF1x PHB. 164 In such cases, the provider will likely not want to send the VoIP 165 data and signaling on different LSPs as they may have different delay 166 behaviour. 168 It can be argued that if the ratio of two different traffic types is 169 known/constant then it can be carried on multiple OAs but signalled 170 with a single traffic parameter and advertised with a single 171 advertisement. However, such a scheme is extremely inflexible. 172 Applications continually evolve as may the ratio of traffic mixes. 173 Thus, it is unwise to embed assumptions about application behaviour 174 in the DS-TE solutions. 176 3.2 Using E-LSPs with multiple class bandwidth requirements 178 A second example involves the use of Layer 2 VPNs. In this context, 179 service providers in the Metro space are looking to provide TLS 180 (Transparent LAN) services. The SP may provide Layer 2 VPNs for its 181 end customers where the key SLAs revolve around availability and QoS. 182 In such cases, the SLA may specify a single protection level for the 183 entire customer aggregate while specifying multiple classes of 184 service within the VPN aggregate. In such networks, sending different 185 classes of service on different LSPs will immensely complicate the 186 ability to offer robust and measurable availability and QoS SLAs to 187 such customers. Hence it is desirable to carry all the customer's 188 classes of traffic on a single LSP and yet to treat each class 189 differently. 191 A third example relates to an application where a service provider 192 wishes to provide bandwidth borrowing between the different classes 193 of traffic for a specific customer. Thus, service providers may want 194 to provide SLA gurantees for each of the classes carried in the E- 195 LSP. In addition, at the same time, the provider may wish to apply 196 queuing technology that allows bandwidth borrowing between the OAs of 197 a customer. Thus, if a customer is not using his allocated AF 198 capacity, he may wish to allow his BE traffic to use that capacity 199 that he has purchased from the service provider. 201 3.3 Using E-LSPs to reduce number of LSPs in the network 203 A fourth example relates to path protection and restoration which are 204 2 key requirements in next generation IP networks. Sending a single 205 customer's traffic on multiple LSPs causes a larger number of LSPs in 206 the network. It also causes issues with ensuring that the SONET like 207 restoration times are met due to the sheer volume of LSPs that have 208 to be resignalled or redialed when links go down. These mechanisms 209 are more easily applied to a single LSP than to a group of LSPs. 211 Yet another application scenario, as a fifth example could be, the 212 case of a small service provider with a simple network topology and a 213 limited set of service classes. Such a provider could be interested 214 in limited DS-TE capabilities (i.e. simple aggregate load balancing). 215 In this case, a simple path computation algorithm that routes all 216 classes together can be used to select a single LSP (e.g. a shortest 217 path applied on the pruned network). Limiting each LSP to only a 218 single OA would, at minimum, double the number of LSPs in the network 219 - which may be highly undesirable for the SP. 221 Another key benefit of E-LSPs has to do with scalability. L-LSP or 222 single OA per E-LSP will cause the number of LSPs in the network to 223 increase by a factor of at least two and in some cases, three, four 224 or larger. The number of LSPs is a scalability concern for a number 225 of reasons. Firstly, it increases the time required during hitless 226 restart. Secondly, it is of concern for RSVP state management.Another 227 important advantage of E-LSPs is in the area of network maintenance 228 and administration. When trouble-shooting issues related to a 229 customer's traffic, it is easier for the network operator to examine 230 a single LSP instead of multiple LSPs. 232 4.0 Technical Requirements To Support DS-TE with multiple COS per LSP 234 In general, the requirements to support DS-TE with multiple COS can 235 be considered as extensions to the existing requirements. To support 236 such an approach, the following are required: 238 (i) IGP extensions to advertise reserved or available 239 bandwidth on a per-OA, PSC or per-class or per-ClassType basis for 240 each link. 241 (ii) A path computation algorithm that computes a path at the LER 242 (iii) Extensions to allow signaling of per-class parameters 243 within an E-LSP 244 (iv) A Pre-emption priority (setup and hold) which is applied 245 to the whole E-LSP together (not per-OA). 246 (v) Admission Control is applied per-class per-link when the E-LSP 247 is signalled. 248 (vi) Traffic Conditioning is applied at the LER against traffic 249 mapped to the E-LSP. 250 (vii) EXP bits are used to signal the PHB treatment 251 for individual packets within the E-LSP 252 (viii) Diffserv PHB mechanisms are used in LSR routers 253 to differentially treat the traffic within a 254 single E-LSP. 256 There are no new requirements for IGP protocol extensions other than 257 the one already described in the document Protocol extensions for 258 support of DS-TE [DSPROTO]. 260 Requirement (ii) is typically satisfied by a proprietary 261 implementation by vendor devices. When setting up an E-LSP, the path 262 is computed based on the available resources in the network and the 263 path that fits best the resource requirements of all the OAs 264 together, i.e, the path computation procedure has to a take a 265 bandwidth vector of all OAs, bandwidth vector of all available link 266 bandwidths per-OA and compute the path based on certain constraints. 268 Requirement (iii) is discussed in section 4.1 below. The per-OA 269 signaling is needed for proper bandwidth accounting and to advertise 270 available resources in the node to the network. 272 Requirement (iv), (v), (vi), (vii) and (viii) are currently addressed 273 by the mechanisms specified in [DIFF-MPLS]. 275 4.1 LSP Signalling Extensions 277 The current Diffserv-MPLS extensions allow only a single set of 278 traffic parameters to be signalled per LSP. e.g in RSVP-TE, it is 279 allowable to signal only a single Tspec. To support E-LSP, the 280 signalling protocols need to be extended to allow specification of 281 multiple traffic parameters. Further, there needs to be a means of 282 mapping these traffic parameters to an OA, PSC or class. 284 There exist two current proposals to address this issue: [GANTI] and 285 [IOVANNA]. 287 This document uses the terms BA, OA, PSC, E-LSP, L-LSP, and PHB as 288 they are defined in [DIFF-MPLS] and [DIFFTERM]. 290 5.0 Other Requirements 292 The following are additional requirements for solutions to support 293 multiple COS on DS-TE: 295 (i) Any protocol extensions should be optional. 296 (ii) The solution should be an extension of the current [DSTEREQ] 297 documents 298 (iii) The solution should be backwards compatible with DS-TE, TE 299 and Diffserv 300 (iv) It should not introduce major scalability issues above and 301 beyond what is introduced by the current DS-TE 302 (v) It should allow dynamic adjustment of parameters for the 303 LSR's scheduler 304 (vi) It should satisfy the application scenarios outlined in [DSTEREQ] 306 6.0 Security Considerations 308 This document does not introduce any new security issues beyond those 309 inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms 310 proposed for those technologies. 312 7.0 References 314 [TEREQ] Awduche D et al, "Requirements for Traffic Engineering 315 Over MPLS", RFC 2702, January 2001 317 [DIFFMPLS] Rosen E et al, "MPLS Support of Differentiated Services" 318 draft-ietf-mpls-diff-ext-08.txt, February 2001. 320 [DIFFTERM] Grossman D, "New Terminology for Diffserv", Internet 321 Draft, draft-ietf-diffserv-new-terms-04.txt, March 2001 323 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for 324 LSP Tunnels", Internet draft, 325 , February 2001 327 [CR-LDP] Jamoussi et al, "Constraint-Based LSP Setup using LDP", 328 Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, 329 February 2001. 331 [PHBID] Brim S et al, "Per Hop Behaviour Identification Code", 332 RFC 2836, May 2000. 334 [MPLSARCH] Rosen E et al, "Multi-Protocol Label Switching 335 Architecture", RFC 3031, January 2001 337 [DSTEREQ] Le Faucheur F et al, "Requirements for support of Diff- 338 Serv-aware MPLS Traffic Engineering", 339 draft-ietf-tewg-diff-te-reqts-03.txt, February 2002. 341 [DS-PROTO] Le Faucheur F et al, "Protocol Extensions for support of 342 Diffserv-Aware MPLS Traffic Engineering, 343 draft-ietf-tewg-diff-te-proto-00.txt, February 2002 345 [GANTI] Ganti, Seddigh, Nandy, "MPLS Support of Differentiated 346 Services using E-LSP", 347 draft-ganti-mpls-diffserv-elsp-01.txt, November 2001. 349 [IOVANNA] Iovanna, et al, "Definition of the MPLS FlowSpec for 350 RSVP-TE", 351 draft-iovanna-rsvp-mpls-flowspec-00.txt, October 2001. 353 8.0 Author's Address 355 Sudhakar Ganti 356 Tropic Networks Inc. 357 135 Michael Cowpland Drive 358 Kanata, Ontario, Canada, K2M 2E9 359 Email: sganti@tropicnetworks.com 361 Nabil Seddigh 362 Tropic Networks Inc. 363 135 Michael Cowpland Drive 364 Kanata, Ontario, Canada, K2M 2E9 365 Email: nseddigh@tropicnetworks.com 367 Biswajit Nandy 368 Tropic Networks Inc. 369 135 Michael Cowpland Drive 370 Kanata, Ontario, Canada, K2M 2E9 371 Email: bnandy@tropicnetworks.com 373 Sanjaya Choudhury 374 Marconi 375 Email: sanjaya.choudhury@marconi.com 377 Neil Harrison 378 British Telecom 379 Heath Bank, Iugby Road, Harleston 380 South Hampton, UK 381 Email: neil.2.Harrison@bt.com