idnits 2.17.1 draft-ietf-diffserv-precedence-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** 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 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** There are 563 instances of lines with control characters in the document. 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 (April 1998) is 9508 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? 'IP' on line 585 looks like a reference -- Missing reference section? 'ASSURED' on line 599 looks like a reference -- Missing reference section? 'HOSTREQ' on line 587 looks like a reference -- Missing reference section? 'BROKER' on line 604 looks like a reference -- Missing reference section? 'FRAMEWORK' on line 591 looks like a reference -- Missing reference section? 'Principles' on line 250 looks like a reference -- Missing reference section? 'PRINCIPLES' on line 595 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft IP Precedence in Differentiated Services April 1998 4 IP Precedence in Differentiated Services Using the Assured Service 5 draft-ietf-diffserv-precedence-00.txt 7 This document is an Internet Draft. Internet Drafts are working 8 documents of the Internet Engineering Task Force (IETF), its 9 Areas, and its Working Groups. Note that other groups may also 10 distribute working documents as Internet Drafts. 12 Internet Drafts are valid for a maximum of six months and may 13 be updated, replaced, or obsoleted by other documents at any 14 time. It is inappropriate to use Internet Drafts as reference 15 material or to cite them other than as a "work in progress". 16 Comments should be made on the list diff-serv@baynetworks.com 18 Abstract 20 This document describes the use of a set of Diff-Serv Per-Hop 21 Behaviors (PHBs) to implement a service similar to the 22 Precedence service described in [IP], providing also the 23 Assured Service model described by [ASSURED]. 25 1. Introduction 27 In short, this memo is intended to describe a way to implement 28 IP Precedence in the Differentiated Services Architecture. By 29 way of an existence proof and argument for the definition of 30 this service, we first discuss IP Precedence, its history, 31 intent, and present day use. 33 1.1. IP Precedence History 35 IP Precedence, and the IP Precedence Field, were first defined 36 in [IP], as a way to convey end to end an expectation that a 37 given IP datagram should be placed in a given link layer 38 queue. The various values that the three bit IP Precedence 39 Field might take were assigned to various uses, including 40 network control traffic, routing traffic, and various levels 41 of privilege. The least level of privilege was deemed "routine 42 traffic". 44 Although early BBN IMPs implemented the service, early 45 commercial routers and UNIX IP forwarding code generally did 46 Draft IP Precedence in Differentiated Services April 1998 48 not. As networks became more complex and customer requirements 49 grew, commercial routers developed ways to implement various 50 kinds of queuing services including Priority Queuing, which 51 were generally based on policies encoded in filters in the 52 routers, which looked at IP Addresses, IP Protocol numbers, 53 TCP or UDP ports, and the like. IP Precedence was and is among 54 the options such filters can look at, but just one. 56 In more recent years, however, at least five common uses of 57 the IP Precedence Field have developed. These include: 59 (1) As a drop preference in a receiving router. 61 Routing and network control traffic is marked on 62 transmission as being of high precedence. If a router 63 receives the packet at a time that it deems difficult to 64 service random traffic, such as during a bad route flap, 65 the router may drop lower precedence traffic in order to 66 assure the ability to receive higher precedence traffic. 67 It does so in the belief that conserving buffer space and 68 other resources during times of stress will help routing 69 converge more quickly, improving overall network service. 71 This is, at this time, an important stability issue for 72 certain routers located in sensitive places in the 73 internet. 75 An example of such a behavior is Cisco's SPD feature. 77 (2) As a drop preference in a transit router. 79 In this case, traffic of various sorts may be marked, 80 either by the originating host or by a router. When the 81 packet is enqueued to subsequent congested router 82 interfaces, the traffic is more or less subject to drop 83 depending on its precedence setting. The predominant 84 current use is to support routing traffic (such as BGP) 85 across a local routing domain which may use an IGP to 86 route between the routers, but many instances exist where 87 traffic is marked by the first hop router and treated in 88 this manner across a network. 90 This may be done using strict drop priorities, or using 91 such techniques as Cisco's Weighted RED or Clark's RIO. 92 The latter two implement Random Early Detection, and 93 provide a way to select differing min-threshold and max- 94 threshold values; in the case of WRED, the selector is IP 95 Draft IP Precedence in Differentiated Services April 1998 97 Precedence. 99 (3) As a queue selector, whether a strict priority queue, a 100 round robin load sharing queue, or a VC in a multiplexed 101 interface such as Frame Relay or ATM. 103 Such mechanisms assume that the queue that higher 104 precedence traffic is placed in has a higher probability 105 of delivering the traffic in a timely manner, whether due 106 to absolute priority or due to rates assigned to queues. 108 This may be done using facilities such as Cisco's 109 Priority, Custom, or Distributed Class-based Fair Queuing 110 services, or the Newbridge 36000's classification 111 facilities. 113 (4) As a selector for the weight of a packet in a Weighted 114 Fair Queuing System. 116 In such a case, when a packet is enqueued in its flow's 117 sub-queue, the weight assigned to the packet is taken 118 from a table which is indexed by the value of the IP 119 Precedence field. In this manner, higher precedence 120 traffic gains a larger proportion of the link without 121 having to configure policy for specific classes of 122 traffic. 124 Examples of such include Newbridge, ACC, and Cisco 125 Weighted Fair Queuing services. 127 (5) IP Precedence is used to index a min-threshold and max- 128 threshold array on an interface configured for an 129 extended Random Early Detection algorithm. This is 130 similar to Clark's RIO, except that it it provides for 131 the possibility of several levels of "in profile" and 132 "out of profile". One could imagine using this as seven 133 levels of "in profile" and a single "out" penalty box, as 134 pairs of "in" and "out" precedences, or in other ways. 136 An example of this is Cisco's Committed Access Rate 137 service. 139 In short, IP Precedence is widely deployed and widely used, if 140 not in exactly the manner intended in [IP]. This was 141 recognized in [HOSTREQ], which states that while the use of 142 the IP Precedence field is valid, the specific assignment of 143 the priorities in [IP] were merely historical. 145 Draft IP Precedence in Differentiated Services April 1998 147 1.2. The Assured Service 149 Clark's Assured Service [ASSURED] suggests that a contract 150 might exist between a service provider and its peer, or 151 between two service providers, which guarantees a certain 152 level of service, and offers the opportunity to overload this 153 on a best effort basis. The expectation is that traffic which 154 is within the contracted rate, as measured by a token bucket, 155 has a very much reduced probability of being lost, while 156 traffic which is excess has a less sanguine prognosis. 157 Inherent in the model is the supposition that a boundary 158 device, probably a router, is measuring traffic and marking it 159 either "in" or "out". 161 This model is being tested by many service providers today, 162 with a view to offering a layered usage-based service level 163 agreement. Such an agreement might include several layers of 164 drop or delay preference, and associated rates. For example, 165 it might offer the following four-tiered service: 167 (1) Routing traffic, marked with IP Precedence six or seven, 168 may be exchanged at will and as much as necessary, but 169 there is a charge per route flap. There is no excess 170 traffic, so all is marked in profile. 172 (2) IP Telephony or similar real time services, marked with 173 the PHB 101100, which is to say precedence five and in 174 profile, may be exchanged up to a certain rate. Traffic 175 which is in profile experiences very low probability of 176 loss, apart from unplanned outages. Excess traffic is 177 marked with the same precedence but out of profile, and 178 is subject to random loss. The contracted bandwidth is 179 charged at a flat rate, and there is a usage charge for 180 excess traffic. One might imagine the use of RSVP to the 181 edge router, or a bandwidth broker protocol as envisioned 182 by [BROKER], to manage this contract level. 184 (3) Traffic to specific CIDR Prefixes (such as a VPN, marked 185 with the PHB 100100, which is to say precedence four and 186 in profile, may be exchanged up to a certain rate. 187 Traffic which is in profile experiences very low 188 probability of loss, apart from unplanned outages. 189 Excess traffic is marked with the same precedence but out 190 of profile, and is subject to random loss. The contracted 191 bandwidth is charged at a flat rate, and there is a usage 192 charge for excess traffic. 194 Draft IP Precedence in Differentiated Services April 1998 196 (4) Other traffic, marked with the PHB 010100, which is to 197 say precedence two and in profile, may be exchanged up to 198 a certain rate. Traffic which is in profile experiences 199 low probability of loss, apart from unplanned outages, 200 but a greater probability than traffic in the categories 201 previously mentioned, due to the fact that this traffic 202 is harder to engineer for. Excess traffic is marked with 203 the same precedence but out of profile, and is subject to 204 random loss. The contracted bandwidth is charged at a 205 flat rate, and there is a usage charge for excess 206 traffic. 208 The above is obviously but one of many possible examples. A 209 minor variation on the theme might permit excess traffic to 210 customers of the same service provider but drop excess traffic 211 rather than forward it to other providers. Many other 212 varieties of service level agreements are also possible. 214 One issue that we are told is important is that at least some 215 service providers would like to be able to offer similar 216 contracts to different customers with different cost 217 structures. A corporate customer, for example, might obtain a 218 contract similar to the above, while an educational customer 219 might simply contract for precedence three service on a usage 220 basis. The various precedence levels now map not only to 221 in/out flags and drop preferences, but to price points in the 222 tariff structure. This argues for additional precedence values 223 that can be charged at different rates. 225 1.3. Differentiated Services Overview 227 Differentiated Services, as described in [FRAMEWORK], re- 228 allocates the most significant six bits of the TOS byte as a 229 PHB. These are, by definition, cases in a case statement 230 rather than being comparable numbers, as [IP]'s Precedence 231 field was. These can clearly be used, however, to implement 232 structured services like IP Precedence if care is taken to 233 define the matter clearly. Specifically, these PHB selectors 234 may be modified according to a set of rules. 236 One expectation that clearly differs from that in [IP] is that 237 the exact implementation of the PHB may vary from system to 238 system. Rather than specifying a simple priority service, as 239 [IP] does, the PHB might select one of several queues in a 240 Class Based Queuing system, some of which have different rates 241 than others. In such a case, the fact that the queue has a 242 higher rate than some other queue is considered equivalent to 243 Draft IP Precedence in Differentiated Services April 1998 245 having higher priority, even though a strict priority model is 246 not being followed. 248 1.4. The End to End Argument 250 [Principles] details the premises on which the Internet 251 community has built its protocols for the past thirty years; 252 among these premises is the end to end argument, which 253 suggests that a network service which is useful to an 254 application is by definition a service which the application 255 can use at the edge to achieve a purpose all the way from 256 itself to its peer, and in each system en route. This argument 257 concludes that concentrating intelligence at the end or edge 258 point is superior to embedding unnecessary intelligence in the 259 network, because it is the end or edge that understands what 260 needs to be achieved. 262 Differentiated Services modifies that model somewhat, seeing 263 the edge as the boundary router of a service provider's 264 network rather than or perhaps in addition to the end system 265 itself. We agree that this clarification is necessary, in that 266 service provider boundary routers invoke vast quantities of 267 routing and other policy, and implementing policies such as 268 described previously in this memo is a logical function of 269 that boundary router. 271 But we also observe that the edge or end system may have 272 specific expectations that map to the contracts that its 273 owners write. If Voice on IP is to work well, it needs some 274 form of "Low Delay Low Loss" service, for example, and it 275 needs it in every service provider network that it passes. The 276 implementation of the service may vary in each network, but 277 the effect of the implementation must be that the relevant 278 datagrams must experience low delay, low variation in delay, 279 and a low loss rate. If some service provider en route fails 280 to provide that service, the fact that the others supported it 281 may be cold comfort; the application will not work anywhere 282 near as well end to end as it otherwise would. 284 We therefore argue that a set of Per-Hop Behaviors that 285 implement an IP Precedence service are useful end-to-end, and 286 universal definition of a set of Per-Hop Behaviors to support 287 IP Precedence is useful to essentially all service providers. 289 Draft IP Precedence in Differentiated Services April 1998 291 2. IP Precedence Proposal 293 With that context, we now proceed to define an IP Precedence 294 service, using Per-Hop Behaviors as the vehicle, and 295 incorporating the Assured Service for the purpose of contract 296 management. 298 2.1. Intended Semantics 300 Intuitively, we wish to provide a set of queue or class 301 selectors, each with drop preference according to Clark's 302 Assured Service Model. We want, therefore, to provide pairs 303 of PHBs for each queue or class; one PHB for the class marks 304 the traffic "in profile", and one marks it "out". Traffic 305 with different queue selector values may be relatively 306 reordered without concern, but the "in/out" bit should not 307 cause traffic reordering among traffic marked with the same 308 queue selector. 310 The number of queues or classes that are specifiable must, in 311 the immortal words of Mike O'Dell, be "more than three, less 312 than nine, and probably a power of two." We believe that eight 313 classes are required in order to support service providers' 314 marketing of similar contracts at varying prices, or specific 315 traffic engineering models. In addition, in this set of PHBs, 316 one bit is used as the "in/out" bit. We also note that 802.1p 317 is said to be an important service coming out Real Soon Now, 318 and having three bits of IP layer queue selector to map to 319 three bits of link layer queue selector is a good match. 321 2.2. Proposed Service Identifiers 323 The Differentiated Services proposal suggests that the DS byte 324 is structured in this way: 326 0 1 2 3 4 5 6 7 327 +-+-+-+-+-+-+-+-+ 328 | PHB |CU | 329 +-+-+-+-+-+-+-+-+ 331 We note that the existing IP Precedence field is located in 332 bits zero through two of that octet, and that current 333 implementations exist that perform services similar to this 334 proposal using those bits; a simple prototype of the proposal 335 can therefore be quickly deployed using configuration 336 parameters using such implementations. We also note that IP 337 systems today understand the location of the IP Precedence 338 Draft IP Precedence in Differentiated Services April 1998 340 field, and observe that if the bits associated with this 341 variation on IP Precedence are in the same place, significant 342 failures are not likely during deployment of the facility. In 343 other words, the code need not be ubiquitous even in a single 344 service provider's network if we are careful in our selection 345 of bits. This argues that the bits we would like to use for 346 this service are exactly the same set as [IP]'s Precedence 347 bits, or a set subsuming that set with similar semantics. 349 We therefore propose that the following PHB numbers be 350 selected: 352 111 1 00 precedence 7, in profile 353 111 0 00 precedence 7, out of profile 354 110 1 00 precedence 6, in profile 355 110 0 00 precedence 6, out of profile 356 101 1 00 precedence 5, in profile 357 101 0 00 precedence 5, out of profile 358 100 1 00 precedence 4, in profile 359 100 0 00 precedence 4, out of profile 360 011 1 00 precedence 3, in profile 361 011 0 00 precedence 3, out of profile 362 010 1 00 precedence 2, in profile 363 010 0 00 precedence 2, out of profile 364 001 1 00 precedence 1, in profile 365 001 0 00 precedence 1, out of profile 366 000 1 00 precedence 0, in profile 367 000 0 00 precedence 0, out of profile 369 In essence, a higher precedence (queue or class number) should 370 afford a higher probability of timely delivery than a lower 371 precedence packet, and in-profile traffic of any precedence 372 should have a higher probability of delivery than out of 373 profile traffic of the same precedence. If there is 374 comparison among classes, as in a simple drop preference or 375 simple priority queuing model, in-profile traffic of any 376 precedence should have a greater probability of timely 377 delivery than out of profile traffic of any precedence, 378 without loss of sequence within a precedence. In the 379 implementation, one could expect this to be implemented as 380 some combination of drop preference (emphasis being on the 381 probability of delivery), and queue characteristics (emphasis 382 on timeliness of delivery). 384 Other PHBs, those whose two least significant bits are non- 385 zero, are outside the scope of this specification and are not 386 further discussed in this memo. 388 Draft IP Precedence in Differentiated Services April 1998 390 It can be argued that, since the PHBs are in fact indices in a 391 case statement, there is no substantive reason that the exact 392 values chosen above need be chosen. These specific values are 393 chosen so as to be backward compatible with [IP]'s IP 394 Precedence enumeration, and so that the in/out bit selected is 395 contiguous with the other numbers. 397 The reason an in/out bit is selected, rather than letting 398 there be some number of of "in" values and a common "out of 399 profile" PHB, relates to cases where precedence is selecting a 400 queue. If all traffic is in the same queue, a single PHB is 401 clearly sufficient to mark that traffic which is out of 402 profile. With multiple queues, however, one could imagine 403 assigning different WFQ weights to traffic in the same queue 404 which is in or out of profile, as well as providing different 405 drop probabilities. 407 The astute reader will note that the default PHB, whose value 408 is zero, is relegated to "routine, out of profile" traffic 409 status; this is consistent with current IP practice, and makes 410 any other setting of the field a desirable improvement, 411 encouraging deployment. 413 2.3. Intended PHB Modifications 415 This memo contemplates two algorithms for setting or changing 416 the PHB value. One algorithm, typically executed in the 417 originating host application or its first-hop router, sets the 418 PHB to a given precedence, in or out of profile, according to 419 a policy set by the network administration. The other, 420 typically executed in the first hop router of a routing domain 421 (next to the host, at ingress to a service provider, etc.), 422 may change it from "in profile" to "out of profile" according 423 to the service level agreement in force. 425 Clearly, there is nothing to stop a service provider from 426 setting it to another PHB, including changing the effective 427 precedence or using some other service. If the service 428 provider does so, however, he gives up whatever semantic was 429 intended by the originator, losing information and perhaps 430 losing the benefit of the service on an end to end basis. 431 Such policies therefore call for wisdom on the part of the 432 network administration. 434 Draft IP Precedence in Differentiated Services April 1998 436 3. Potential Implementation Strategies 438 We now discuss a number of possible implementation strategies. 439 These are each examples: no one approach is mandated, and 440 these are not the only possible implementations. 442 3.1. Simple Drop Preference 444 The simplest implementation of this service is simple drop 445 preference in a simple FIFO queue. In this case, "higher 446 probability of timely delivery" translates directly as "higher 447 probability of delivery", with "out of profile" traffic making 448 way for "in profile" traffic, and lower precedence for higher. 450 Among these PHBs, we assume that the interface implements a 451 Random Early Detection algorithm, and that the min-threshold 452 and max-threshold values associated with various PHBs rise in 453 this sequence: 455 111 1 00 precedence 7, in profile (Highest probability 456 110 1 00 precedence 6, in profile of delivery) 457 101 1 00 precedence 5, in profile 458 100 1 00 precedence 4, in profile 459 011 1 00 precedence 3, in profile 460 010 1 00 precedence 2, in profile 461 001 1 00 precedence 1, in profile 462 000 1 00 precedence 0, in profile 463 111 0 00 precedence 7, out of profile 464 110 0 00 precedence 6, out of profile 465 101 0 00 precedence 5, out of profile 466 100 0 00 precedence 4, out of profile 467 011 0 00 precedence 3, out of profile 468 010 0 00 precedence 2, out of profile 469 001 0 00 precedence 1, out of profile (Lowest probability 470 000 0 00 precedence 0, out of profile of delivery) 472 The strength of this approach is that it maintains order as 473 specified, and drops the lowest precedence traffic first. The 474 weakness of the approach is that no way is afforded to make a 475 demonstrable difference in the variation in queuing delay 476 experienced by the various precedences, only the difference in 477 drop probability. 479 3.2. Priority Queues with Drop Preference 481 Another approach employs a queue per precedence, using one bit 482 of the PHB as a drop preference within the queue. RED is used 483 Draft IP Precedence in Differentiated Services April 1998 485 within the queues according to its usual parameters, but with 486 in-profile traffic having a higher min-threshold and max- 487 threshold than out of profile traffic, and therefore 488 experiencing a higher probability of timely delivery. Queues 489 are ranked in priority order so that each queue, from the 490 perspective of the next lower priority queue, implements a 491 "low loss low delay" service. Out of profile traffic should 492 consider the presence of lower precedence in-profile traffic 493 in the calculation of drop probability. 495 The strength of this approach is that order is maintained 496 within each precedence queue, but higher precedence traffic 497 may be sent before lower precedence traffic. It has a 498 weakness, however, in that apart from admission and policing, 499 it affords lower precedence traffic no assurance of eventual 500 transmission. 502 3.3. Round Robin Queuing with Drop Preference 504 Like the previous one, this approach employs a queue per 505 precedence, using the one bit of the PHB as a drop preference 506 within the queue. RED is used within the queues according to 507 its usual parameters, but with in-profile traffic having a 508 higher min-threshold and max-threshold than out of profile 509 traffic. However, each queue is emptied at some rate, in 510 round-robin order, rather than being given simple priority 511 service. 513 The strength of this approach is that order is maintained 514 within each precedence queue, but higher precedence traffic 515 may be sent before lower precedence traffic. It also avoids 516 the lockout issue that priority queuing systems experience. A 517 counter-intuitive scenario can occur, however, if a high rate 518 queue is heavily utilized while a lower rate queue is under- 519 utilized; a packet directed to the lower rate queue can 520 actually be better protected from loss and variation in delay 521 when placed in an empty or very short queue. 523 3.4. Virtual Circuit or Virtual Channel Selection 525 The difference between this approach and Round Robin Queuing 526 with Drop Preference is somewhat academic. If one has a serial 527 line to a routing neighbor, and manages using a load sharing 528 algorithm, the load sharing algorithm in some sense emulates 529 the way the line would behave if it were in reality a number 530 of different lines, or if it were one channelized line. In a 531 virtual circuit selection model, the emulation becomes reality 532 Draft IP Precedence in Differentiated Services April 1998 534 - one deploys a set of rate-limited VCs to a routing neighbor, 535 and uses them in the same way one would otherwise have used 536 queues. 538 The strengths and weaknesses are very similar to those of 539 Round Robin Queuing, except that this allows one to capitalize 540 on the capabilities of a link layer such as ATM or Frame 541 Relay. 543 3.5. IEEE 802.1d (previously 802.1p) Service Marks 545 The difference between this approach and Round Robin Queuing 546 with Drop Preference is also somewhat academic; an 802.1d 547 switch employs round robin queuing within itself, so the queue 548 management is again deployed through the link layer network. 550 It is worth noting, however, that the bits must be mapped: 551 802.1d traffic classes are a three bit number, which has an 552 interesting set of rules. If the switch implements eight 553 classes, the number selects the class. If it implements four 554 classes, the two most significant bits of the number select 555 the class and the least significant bit has no defined 556 utility. If it implements two classes, the most significant 557 bit selects that class. We therefore suggest this mapping 558 algorithm: 560 (1) If an 802.1d switch implements eight classes, the mapping 561 from IP Precedence to 802.1d traffic class is to place 562 the precedence number (bits zero through two of the PHB) 563 into the traffic class field. 565 (2) If an 802.1d switch implements one, two, or four classes, 566 the mapping from IP Precedence to 802.1d traffic class is 567 to place the two most significant bits of the precedence 568 number (bits zero and one of the PHB) into the traffic 569 class field's most significant bits, and copy the in/out 570 bit (bit three) into the least significant bit of the 571 traffic class. In this manner, it is available should the 572 switch decide to consider it a drop preference bit. A 573 corollary suggestion is being submitted to IEEE 802.1. 575 4. Acknowledgments 577 The authors note that there were a number of reviewers even of 578 the first drafts of this note, whose inputs are very much 579 appreciated. 581 Draft IP Precedence in Differentiated Services April 1998 583 5. References 585 [IP] RFC 791, "Internet Protocol". J. Postel. Sep-01-1981. 587 [HOSTREQ] 588 RFC 1122, "Requirements for Internet hosts - 589 communication layers". R.T. Braden. Oct-01-1989. 591 [FRAMEWORK] 592 Nichols, "Differentiated Services Operational Model and 593 Definitions", 02/11/1998, draft-nichols-dsopdef-00.txt 595 [PRINCIPLES] 596 RFC 1958, "Architectural Principles of the Internet". B. 597 Carpenter. June 1996. 599 [ASSURED] 600 Clark and Wroclawski, "An Approach to Service Allocation 601 in the Internet", 08/04/1997, draft-clark-diff-svc- 602 alloc-00.txt 604 [BROKER] 605 Nichols and Zhang, "A Two-bit Differentiated Services 606 Architecture for the Internet", 12/23/1997, draft- 607 nichols-diff-svc-arch-00.txt 608 Draft IP Precedence in Differentiated Services April 1998 610 6. Security Considerations 612 The Differentiated Services Architecture explicitly requires 613 each network to guard its own doors; if a system behaves in a 614 manner inappropriate to its contracts, the intended behavior 615 is that the system's communications will experience greater 616 unreliability and may be shut down entirely, by way of a 617 punishment. This proposal changes this in no way - it makes 618 the situation no better and no worse. 620 This said, there is a backwards compatibility consideration 621 which is one of the primary motivations for the submission of 622 this idea, which can behave like a security issue. This is 623 that RFC 791 reserves IP Precedence values 6 and 7 for 624 router-to-router traffic, and many routers in the internet use 625 this fact to isolate network control traffic during outage 626 recovery and route changes. 628 To insure continued stability, it is vital that a domain with 629 legacy routers carefully allocate their PHB's to avoid 630 overloading the drop preference controls on the legacy 631 equipment. Thus, we recommend that domains use PHBs with the 632 pattern 11XXXX, when legacy routers are in the path, only for 633 critical routing traffic such as inter-router keep-alive and 634 route update messages. 636 7. Author's Addresses 638 Fred Baker 639 Cisco Systems 640 519 Lado Drive 641 Santa Barbara, California 93111 642 Phone: (408) 526-4257 643 Email: fred@cisco.com 645 Scott Brim 646 Newbridge Networks Inc. 647 146 Honness Lane 648 Ithaca, New York 14850 649 Phone: (607) 273-5472 650 Email: swb@newbridge.com 652 Tony Li 653 Juniper Networks, Inc. 654 385 Ravendale Drive 655 Mountain View, CA 94043 656 Phone: (650) 526-8000 657 Draft IP Precedence in Differentiated Services April 1998 659 Email: tli@juniper.net 661 Frank Kastenholz 662 Argon Networks 663 25 porter rd 664 Littleton ma 01460 665 Phone: (978) 386-0665 666 Email: kasten@argon.com 668 Shantigram Jagannath 669 Bay Networks 670 3 Federal Street, 671 Billerica, MA -01821 672 Phone: (978) 916-8598 673 Email: jagan@baynetworks.com 675 John K. Renwick 676 Ascend Communications 677 High-Performance Networking Division 678 10250 Valley View Rd 679 Eden Prairie, MN 55344 680 Phone: (612) 996-6847 681 Email: jkr@min.ascend.com