idnits 2.17.1 draft-boyle-tewg-ds-nop-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 the list of Shadow Directories. == 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 425 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 65 instances of lines with control characters in the document. ** The abstract seems to contain references ([RSVP-TE], [ISIS-TE], [DSTE-REQ], [OSPF-TE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 4, 2001) is 8330 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) -- Looks like a reference, but probably isn't: '0' on line 262 == Missing Reference: '250M' is mentioned on line 225, but not defined == Missing Reference: '1125M' is mentioned on line 262, but not defined == Missing Reference: '875M' is mentioned on line 262, but not defined == Missing Reference: '500M' is mentioned on line 262, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'DSTE-REQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP-TE' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jim Boyle 2 Internet Draft 3 draft-boyle-tewg-ds-nop-00.txt 4 July 4, 2001 5 Expires: December, 2001 7 Accomplishing Diffserv TE needs with Current Specifications 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The emerging requirements for differentiated service control 33 in MPLS based traffic engineered networks [DSTE-REQ] can be met 34 by existing specifications. Current implementations could be 35 adapted with a relaxed perception of semantics on the syntax 36 outlined in current specifications [OSPF-TE][ISIS-TE][RSVP-TE]. 37 This would provide for a solution that fulfills the scenarios 38 and functionality requirements called for in DSTE-REQ. 40 Comments should be sent to tewg@ops.ietf.org 42 1. Introduction 44 A common theme in the scenarios spelled out in section 2 of 45 DSTE-REQ is that current approaches to traffic engineering do not 46 allow an operator to properly control either to what extent a class 47 of traffic can use a link, or what minimal amount of traffic should 48 be held in reserve for a "lower" class of traffic to prevent total 49 starvation. This memo asserts that this is more a function of 50 current traffic engineering implementations commonly in use today 51 than it is of the current specifications governing the extensions 52 of the base protocols. Further, by rethinking the semantics 53 possible with the current specifications, it would be not only 54 possible to meet the requirements in DSTE-REQ, but it would also be 55 the most operationally optimal approach to meeting those 56 requirements. 58 The word "priority" was perhaps unfortunate, as it carries a rather 59 strong perception by most operators of the ability of one type of 60 traffic to preempt another. A more generalized term might have 61 been desirable, and general approaches have proven useful in the 62 affinities attributes where intent is not inferable from the name 63 or value seen in the signaled messages or usually in the 64 configuration. A link is colored with one or more of 32 bits, and 65 LSPs are told to stick with links thus marked, or avoid them, but 66 the reasoning is not inferable. With priority, it is natural to 67 assume that a connection at one priority should be able to preempt 68 one of lower perceived importance. In fact, this is how at least 69 two prominent implementations behave in effect today. Nonetheless, 70 even with the current objects referred to as priority, and current 71 implementations leaning heavily toward preemtability of one 72 priority to another (in direct relationship to numeric value of 73 priority), the current specifications allow for a semantic view 74 which generalizes the interrelationship of bandwidths at different 75 "priorities", as will be spelled out in this memo. 77 2. Altered Perceptions 79 2.1 Review of current specifications 81 The signaling specification RSVP-TE allows for use of setup and 82 hold priority objects which allow for "the capability to preempt an 83 established LSP tunnel under administrative policy control". 84 However, in section 4.7.3 of RSVP-TE it clearly states that what 85 determines the acceptance of a session is availability of bandwidth 86 "at the priority specified in the Setup Priority". This correlates 87 to the less semantic definitions of what is advertised in the 88 IGP. For instance section 2.5.8 of OSPF-TE states that the 89 unreserved bandwidth "not yet reserved at each of the eight 90 priorities" is advertised. There is no language in either which 91 states that the bandwidth at the highest priority (0) must be 92 higher than that at the lowest priority (7). Nor is there language 93 in RSVP-TE that states that in path computation if one can not find 94 a path at the setup priority of a to-be-established LSP, it should 95 then try lower priorities to see if it might benefit by preempting 96 traffic. Thus, what is advertised by the IGP could easily be used 97 to control what is available to higher priorities or to provide a 98 limited amount of resources to lower priority sessions. 100 2.2 Current Basis 102 Most current implementations in fact do advertise bandwidths 103 available in a manner which has a relationship of: 105 {Effect 1} 107 bw-link[n] >= bw-link[n+1] where n is the numeric priority 109 To the best knowledge of the public, current implementations 110 also follow rules during setup: 112 {Rule 1} 114 topology for bw-lsp[n] is the topology consisting of all 115 bw-link[n], not that of max(bw-link[n..7]). 117 And during call admission control: 119 {Rule 2} 121 succeed if (bw-lsp[n] <= bw-link[n]) 123 The latter is likely followed by a bandwidth update procedure which 124 propagates through bandwidths n to 7, thus causing {Effect 1} above 125 as seen by inspection of the IGP's TE database. 127 This is where some modification would be required in 128 implementations (though not in protocols or even specifications). 129 Priorities would need to be implemented in a way that doesn't 130 necessarily involve relationships with other priorities except as 131 inferred by default or direct configuration. 133 2.3 Pseudo configuration 135 In the below pseudo configurations, I hope the intent is clear. I 136 know it falls short of professional cli definition. Syntax is 137 intended to be unix shell/man like. 139 [] denotes an optional configuration 140 <> a list where selection of one parameter is 141 mandatory. For optional commands the first in the 142 list is the default. 144 2.3.1 Pseudo configuration of current implementations 146 In most network elements that have traffic engineering 147 capabilities, there is the ability to configure the maximum 148 reservable bandwidth of a link, which then propagates into the 149 unreserved bandwidths based on current state of reservations. 150 LSP configuration usually allows a wide variety of parameters 151 including the setup priority and the bandwidth. Some even allow 152 one to configure whether preemption is supported or not. 154 For discussion, suppose that there exist the capability to get the 155 desired traffic into an LSP, and that these are configured as 156 follows: 158 lsp foo priority 2 bandwidth 64k 160 link sonet1 bandwidth 2.5G 162 [mpls preempt ] 164 2.3.1 Pseudo configuration of proposed implementations 166 It is probably desirable, though not necessarily necessary, to 167 decouple the numeric priority from the class of traffic. It is 168 necessary to allow more control on what limits are now placed on a 169 link. 171 class voice use priority 2 172 class data use priority 4 173 [mpls preempt ] 174 [preempt map voice over data] 175 [class mute ] 177 lsp foo class voice bandwidth 64k 179 link sonet1 bandwidth 2.5G 180 [link sonet1 class-bandwidth voice max 1G] 181 [link sonet1 class-bandwidth voice max-percent 40] 182 [link sonet1 class-bandwidth data min 500M] 184 3. Scenario Rundown 186 The following scenarios are from DSTE-REQ. 188 3.1 Scenario 1: High Proportion of Voice 190 The scenario is one in which voice is a class of traffic at a high 191 priority. The operator would like for it to use the shortest 192 administrative path possible under the constraint that no link 193 exceed a certain threshold (ratio wise) of voice traffic. 195 class voice use priority 2 196 class data use priority 4 197 class mute 0-1,3,5-7 198 mpls preempt limited 200 lsp foo class voice bandwidth 10M 201 lsp foo class data bandwidth 40M 203 link sonet1 bandwidth 2.5G 204 link sonet1 class-bandwidth voice max-percent 50 206 At initial advertisement, the link sonet1 will advertise that it 207 has the following available: 209 [0, 0, 1.25G, 0, 2.5G, 0, 0, 0] for priorities [0..7] 211 As the voice traffic fills this link, the bandwidth advertisements 212 will be debited from voice and data, so that should no data LSPs be 213 established, the voice LSPs will be limited to 1.25G and the final 214 advertisement would have been: 216 [0, 0, 0, 0, 1.25G, 0, 0, 0] 218 One might wonder what would have been the advertisements should 219 three waves of LSPs come, in (1) 1G data, (2) another 1G data and 220 (3) 1G voice. 222 [0, 0, 1.25G, 0, 2.5G, 0, 0, 0] initially 223 [0, 0, 1.25G, 0, 1.5G, 0, 0, 0] wave (1) 224 [0, 0, 1.25G, 0, 500M, 0, 0, 0] wave (2) 225 [0, 0, 250M, 0, 0, 0, 0, 0] wave (3) 227 Wave 3 requires preemption of 500 Mbs of data LSPs. 229 3.2 Scenario 2: Rerouting on Lower Speed facilities 231 Appears to be very similar to scenario 1, except perhaps that 232 scenario 1 applies more to non-failure and scenario 2 is directly 233 in context of a failure response. In that case, the discussion 234 section 3.1 applies here as well. 236 3.3 Scenario 3: Maintain relative proportion of traffic classes 238 Or not. This scenario points out that many router implementations 239 of MPLS TE don't correlate their queuing configurations to the 240 bandwidth "reserved" on the link. The scenario states that this 241 being the case, it might be good to attempt to keep the traffic 242 proportions similar to the queuing proportions. In the case of the 243 scenario, one would have the following configuration. 245 class one use priority 1 246 class two use priority 2 247 class three use priority 3 248 class mute 4-7 249 mpls preempt limited 251 lsp foo class one bandwidth 10M 252 lsp foo class two bandwidth 20M 253 lsp foo class three bandwidth 30M 255 link sonet1 bandwidth 2.5G 256 link sonet1 class-bandwidth one max-percent 45 257 link sonet1 class-bandwidth two max-percent 35 258 link sonet1 class-bandwidth three max-percent 20 260 Initial link advertisement would be: 262 [1125M, 875M, 500M, 0, 0, 0, 0, 0] 264 This is likely to not be the most efficient way to operate a 265 network so it would be probable that one would notch up the 266 efficiency by systematically overstating the link bandwidths or 267 understating the LSP bandwidths. 269 This scenario hints at directly coupling the bandwidth reserved at 270 a given priority/class to the parameters used in queuing. That's 271 probably worth a try. A configuration might look like: 273 class one use priority 1 274 class two use priority 2 275 class three use priority 3 277 queues 1 by mpls-class one # queue parameters associated with 278 queues 2 by mpls-class two # reserved bandwidth 279 queues 3 by mpls-class three 281 [mpls queue by ] # queue by cos bits, or by lsp class 283 lsp foo class one bandwidth 10M 284 lsp foo class two bandwidth 20M 285 lsp foo class three bandwidth 30M 287 link sonet1 bandwidth 2.5G 289 3.4 Scenario 4: Guaranteed Bandwidth Services 291 This appears to be related to the above scenarios, particularly in 292 that it requires limiting the amount of traffic ultimately 293 available at a given class (as in Scenario 1) and the interaction 294 this has with queuing (scenario 3). The additional pieces include 295 that this class is likely best served with some form of priority 296 queuing and that traffic entering an LSP would be policed. So: 298 queues 1 by mpls-class 1 299 queues 1 priority 301 lsp foo class one bandwidth 10M police 303 4. Functionality Rundown 305 These correlate to the functionality requirements in DSTE-REQ section 2. 307 4.1 DS-TE Compatibility 309 If there is a network with a mix of routers where some have the 310 legacy implementations and some the implementations outlined in 311 this memo, there is a potential for implementation compatibility 312 problems. Areas of concern might include the following: 314 - a router's inability to accept TE IGP advertisements that do not 315 follow {Effect 1} of section 2.2 above. This is not specified in 316 OSPF-TE nor ISIS-TE. Any "sanity checks" of this sort should not 317 be done. 319 - a router which does not follow {Rule 1} above might attempt to 320 signal an bw-lsp[n] against an insufficient bw-link[n] because it 321 found sufficient bw-link[n+1..7] This should fail for routers 322 which follow {Rule 2} above, in accordance with RSVP-TE. 324 Implementation nuances aside, there should be no compatibility 325 issues between routers with legacy and new implementations. 327 The most difficult part of the transition would be that of router 328 syntax reconfiguration. However, as the on-the-wire signaling 329 would be indistinguishable between the two implementations, it 330 would be possible to even migrate a small portion of a network and 331 try out the reconfiguration and code stability. If successful, 332 migration through the rest of the network could proceed. 334 This approach carries no additional information in the IGP nor are 335 any new or additional objects required in the signaling or routing 336 protocol. It is suspected that the allowed variability of 337 configuration is not without any additional implementation 338 complexity, and that single solution approaches can be coded more 339 optimally than general approaches. So it is assumed that there 340 would likely be some impact to stability or scalability with this 341 approach. However, assuming some typical configurations, it is 342 likely that coding and testing could be optimized for speed and 343 robustness around those configurations. 345 That said, current implementations can not accomplish the scenarios 346 outlined in DSTE-REQ, and this memo is an attempt to meet those in 347 a way that is with minimal impact on coding, scalability, stability 348 and operations. 350 4.2 Separate Bandwidth Constraints 352 This is achievable with current specifications, as shown in the 353 above examples. 355 4.3 Number of Class-Types 357 Eight classes are currently supported, and these may be grouped 358 together in sets, or Class-Types, as required and supported by 359 implementations. 361 4.4 Number of Classes 363 See 4.3. 365 4.5 Preemption 367 4.5.1 Preemption Within a Class-Type 369 This is achievable. It is expected that implementations would 370 allow one to follow current (original) approach which can be 371 thought of as 8 classes in one Class-Type. Additional approaches 372 would include original approach with limits on higher priorities as 373 well as arbitrary associations as shown above. 375 4.5.2 Preemption across Class-Types 377 This is achievable. Also see 4.5.1, though this might be a 378 non-requirement. 380 4.6 Resource Class Affinity 382 This appears to be a requirement for no new requirement. Current 383 encoding specification allows for Resource Class Affinity. 385 4.7 Traffic Mapping 387 This is achievable. It is not precluded by current specifications. 389 4.8 Dynamic Adjustment of Diff-serv PHBs 391 This is achievable. This could potentially be a key approach in 392 diffserv enabled networks taking advantage of traffic engineering 393 technologies. 395 4.9 Multiple TE Metrics 397 No requirements are specified. 399 5. Acknowledgments 401 This idea has benefitted from private discussions with many of the 402 usual suspects. Namely Francois, William, Don, Luca, Vijay, 403 Kireeti and most especially Dave. Thanks. 405 6. References 407 [DSTE-REQ] draft-ietf-tewg-diff-te-reqts-01.txt 409 [ISIS-TE] draft-ietf-isis-traffic-03.txt 411 [OSPF-TE] draft-katz-yeung-ospf-traffic-05.txt 413 [RSVP-TE] draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 415 7. Author's Address 417 Jim Boyle 418 email: jimpb@nc.rr.com