One document matched: draft-ietf-diffserv-precedence-00.txt
Draft IP Precedence in Differentiated Services April 1998 IP Precedence in Differentiated Services Using the Assured Service draft-ietf-diffserv-precedence-00.txt This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Comments should be made on the list diff-serv@baynetworks.com Abstract This document describes the use of a set of Diff-Serv Per-Hop Behaviors (PHBs) to implement a service similar to the Precedence service described in [IP], providing also the Assured Service model described by [ASSURED]. 1. Introduction In short, this memo is intended to describe a way to implement IP Precedence in the Differentiated Services Architecture. By way of an existence proof and argument for the definition of this service, we first discuss IP Precedence, its history, intent, and present day use. 1.1. IP Precedence History IP Precedence, and the IP Precedence Field, were first defined in [IP], as a way to convey end to end an expectation that a given IP datagram should be placed in a given link layer queue. The various values that the three bit IP Precedence Field might take were assigned to various uses, including network control traffic, routing traffic, and various levels of privilege. The least level of privilege was deemed "routine traffic". Although early BBN IMPs implemented the service, early commercial routers and UNIX IP forwarding code generally did Baker et alia Expiration: October 1998 [Page 1] Draft IP Precedence in Differentiated Services April 1998 not. As networks became more complex and customer requirements grew, commercial routers developed ways to implement various kinds of queuing services including Priority Queuing, which were generally based on policies encoded in filters in the routers, which looked at IP Addresses, IP Protocol numbers, TCP or UDP ports, and the like. IP Precedence was and is among the options such filters can look at, but just one. In more recent years, however, at least five common uses of the IP Precedence Field have developed. These include: (1) As a drop preference in a receiving router. Routing and network control traffic is marked on transmission as being of high precedence. If a router receives the packet at a time that it deems difficult to service random traffic, such as during a bad route flap, the router may drop lower precedence traffic in order to assure the ability to receive higher precedence traffic. It does so in the belief that conserving buffer space and other resources during times of stress will help routing converge more quickly, improving overall network service. This is, at this time, an important stability issue for certain routers located in sensitive places in the internet. An example of such a behavior is Cisco's SPD feature. (2) As a drop preference in a transit router. In this case, traffic of various sorts may be marked, either by the originating host or by a router. When the packet is enqueued to subsequent congested router interfaces, the traffic is more or less subject to drop depending on its precedence setting. The predominant current use is to support routing traffic (such as BGP) across a local routing domain which may use an IGP to route between the routers, but many instances exist where traffic is marked by the first hop router and treated in this manner across a network. This may be done using strict drop priorities, or using such techniques as Cisco's Weighted RED or Clark's RIO. The latter two implement Random Early Detection, and provide a way to select differing min-threshold and max- threshold values; in the case of WRED, the selector is IP Baker et alia Expiration: October 1998 [Page 2] Draft IP Precedence in Differentiated Services April 1998 Precedence. (3) As a queue selector, whether a strict priority queue, a round robin load sharing queue, or a VC in a multiplexed interface such as Frame Relay or ATM. Such mechanisms assume that the queue that higher precedence traffic is placed in has a higher probability of delivering the traffic in a timely manner, whether due to absolute priority or due to rates assigned to queues. This may be done using facilities such as Cisco's Priority, Custom, or Distributed Class-based Fair Queuing services, or the Newbridge 36000's classification facilities. (4) As a selector for the weight of a packet in a Weighted Fair Queuing System. In such a case, when a packet is enqueued in its flow's sub-queue, the weight assigned to the packet is taken from a table which is indexed by the value of the IP Precedence field. In this manner, higher precedence traffic gains a larger proportion of the link without having to configure policy for specific classes of traffic. Examples of such include Newbridge, ACC, and Cisco Weighted Fair Queuing services. (5) IP Precedence is used to index a min-threshold and max- threshold array on an interface configured for an extended Random Early Detection algorithm. This is similar to Clark's RIO, except that it it provides for the possibility of several levels of "in profile" and "out of profile". One could imagine using this as seven levels of "in profile" and a single "out" penalty box, as pairs of "in" and "out" precedences, or in other ways. An example of this is Cisco's Committed Access Rate service. In short, IP Precedence is widely deployed and widely used, if not in exactly the manner intended in [IP]. This was recognized in [HOSTREQ], which states that while the use of the IP Precedence field is valid, the specific assignment of the priorities in [IP] were merely historical. Baker et alia Expiration: October 1998 [Page 3] Draft IP Precedence in Differentiated Services April 1998 1.2. The Assured Service Clark's Assured Service [ASSURED] suggests that a contract might exist between a service provider and its peer, or between two service providers, which guarantees a certain level of service, and offers the opportunity to overload this on a best effort basis. The expectation is that traffic which is within the contracted rate, as measured by a token bucket, has a very much reduced probability of being lost, while traffic which is excess has a less sanguine prognosis. Inherent in the model is the supposition that a boundary device, probably a router, is measuring traffic and marking it either "in" or "out". This model is being tested by many service providers today, with a view to offering a layered usage-based service level agreement. Such an agreement might include several layers of drop or delay preference, and associated rates. For example, it might offer the following four-tiered service: (1) Routing traffic, marked with IP Precedence six or seven, may be exchanged at will and as much as necessary, but there is a charge per route flap. There is no excess traffic, so all is marked in profile. (2) IP Telephony or similar real time services, marked with the PHB 101100, which is to say precedence five and in profile, may be exchanged up to a certain rate. Traffic which is in profile experiences very low probability of loss, apart from unplanned outages. Excess traffic is marked with the same precedence but out of profile, and is subject to random loss. The contracted bandwidth is charged at a flat rate, and there is a usage charge for excess traffic. One might imagine the use of RSVP to the edge router, or a bandwidth broker protocol as envisioned by [BROKER], to manage this contract level. (3) Traffic to specific CIDR Prefixes (such as a VPN, marked with the PHB 100100, which is to say precedence four and in profile, may be exchanged up to a certain rate. Traffic which is in profile experiences very low probability of loss, apart from unplanned outages. Excess traffic is marked with the same precedence but out of profile, and is subject to random loss. The contracted bandwidth is charged at a flat rate, and there is a usage charge for excess traffic. Baker et alia Expiration: October 1998 [Page 4] Draft IP Precedence in Differentiated Services April 1998 (4) Other traffic, marked with the PHB 010100, which is to say precedence two and in profile, may be exchanged up to a certain rate. Traffic which is in profile experiences low probability of loss, apart from unplanned outages, but a greater probability than traffic in the categories previously mentioned, due to the fact that this traffic is harder to engineer for. Excess traffic is marked with the same precedence but out of profile, and is subject to random loss. The contracted bandwidth is charged at a flat rate, and there is a usage charge for excess traffic. The above is obviously but one of many possible examples. A minor variation on the theme might permit excess traffic to customers of the same service provider but drop excess traffic rather than forward it to other providers. Many other varieties of service level agreements are also possible. One issue that we are told is important is that at least some service providers would like to be able to offer similar contracts to different customers with different cost structures. A corporate customer, for example, might obtain a contract similar to the above, while an educational customer might simply contract for precedence three service on a usage basis. The various precedence levels now map not only to in/out flags and drop preferences, but to price points in the tariff structure. This argues for additional precedence values that can be charged at different rates. 1.3. Differentiated Services Overview Differentiated Services, as described in [FRAMEWORK], re- allocates the most significant six bits of the TOS byte as a PHB. These are, by definition, cases in a case statement rather than being comparable numbers, as [IP]'s Precedence field was. These can clearly be used, however, to implement structured services like IP Precedence if care is taken to define the matter clearly. Specifically, these PHB selectors may be modified according to a set of rules. One expectation that clearly differs from that in [IP] is that the exact implementation of the PHB may vary from system to system. Rather than specifying a simple priority service, as [IP] does, the PHB might select one of several queues in a Class Based Queuing system, some of which have different rates than others. In such a case, the fact that the queue has a higher rate than some other queue is considered equivalent to Baker et alia Expiration: October 1998 [Page 5] Draft IP Precedence in Differentiated Services April 1998 having higher priority, even though a strict priority model is not being followed. 1.4. The End to End Argument [Principles] details the premises on which the Internet community has built its protocols for the past thirty years; among these premises is the end to end argument, which suggests that a network service which is useful to an application is by definition a service which the application can use at the edge to achieve a purpose all the way from itself to its peer, and in each system en route. This argument concludes that concentrating intelligence at the end or edge point is superior to embedding unnecessary intelligence in the network, because it is the end or edge that understands what needs to be achieved. Differentiated Services modifies that model somewhat, seeing the edge as the boundary router of a service provider's network rather than or perhaps in addition to the end system itself. We agree that this clarification is necessary, in that service provider boundary routers invoke vast quantities of routing and other policy, and implementing policies such as described previously in this memo is a logical function of that boundary router. But we also observe that the edge or end system may have specific expectations that map to the contracts that its owners write. If Voice on IP is to work well, it needs some form of "Low Delay Low Loss" service, for example, and it needs it in every service provider network that it passes. The implementation of the service may vary in each network, but the effect of the implementation must be that the relevant datagrams must experience low delay, low variation in delay, and a low loss rate. If some service provider en route fails to provide that service, the fact that the others supported it may be cold comfort; the application will not work anywhere near as well end to end as it otherwise would. We therefore argue that a set of Per-Hop Behaviors that implement an IP Precedence service are useful end-to-end, and universal definition of a set of Per-Hop Behaviors to support IP Precedence is useful to essentially all service providers. Baker et alia Expiration: October 1998 [Page 6] Draft IP Precedence in Differentiated Services April 1998 2. IP Precedence Proposal With that context, we now proceed to define an IP Precedence service, using Per-Hop Behaviors as the vehicle, and incorporating the Assured Service for the purpose of contract management. 2.1. Intended Semantics Intuitively, we wish to provide a set of queue or class selectors, each with drop preference according to Clark's Assured Service Model. We want, therefore, to provide pairs of PHBs for each queue or class; one PHB for the class marks the traffic "in profile", and one marks it "out". Traffic with different queue selector values may be relatively reordered without concern, but the "in/out" bit should not cause traffic reordering among traffic marked with the same queue selector. The number of queues or classes that are specifiable must, in the immortal words of Mike O'Dell, be "more than three, less than nine, and probably a power of two." We believe that eight classes are required in order to support service providers' marketing of similar contracts at varying prices, or specific traffic engineering models. In addition, in this set of PHBs, one bit is used as the "in/out" bit. We also note that 802.1p is said to be an important service coming out Real Soon Now, and having three bits of IP layer queue selector to map to three bits of link layer queue selector is a good match. 2.2. Proposed Service Identifiers The Differentiated Services proposal suggests that the DS byte is structured in this way: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | PHB |CU | +-+-+-+-+-+-+-+-+ We note that the existing IP Precedence field is located in bits zero through two of that octet, and that current implementations exist that perform services similar to this proposal using those bits; a simple prototype of the proposal can therefore be quickly deployed using configuration parameters using such implementations. We also note that IP systems today understand the location of the IP Precedence Baker et alia Expiration: October 1998 [Page 7] Draft IP Precedence in Differentiated Services April 1998 field, and observe that if the bits associated with this variation on IP Precedence are in the same place, significant failures are not likely during deployment of the facility. In other words, the code need not be ubiquitous even in a single service provider's network if we are careful in our selection of bits. This argues that the bits we would like to use for this service are exactly the same set as [IP]'s Precedence bits, or a set subsuming that set with similar semantics. We therefore propose that the following PHB numbers be selected: 111 1 00 precedence 7, in profile 111 0 00 precedence 7, out of profile 110 1 00 precedence 6, in profile 110 0 00 precedence 6, out of profile 101 1 00 precedence 5, in profile 101 0 00 precedence 5, out of profile 100 1 00 precedence 4, in profile 100 0 00 precedence 4, out of profile 011 1 00 precedence 3, in profile 011 0 00 precedence 3, out of profile 010 1 00 precedence 2, in profile 010 0 00 precedence 2, out of profile 001 1 00 precedence 1, in profile 001 0 00 precedence 1, out of profile 000 1 00 precedence 0, in profile 000 0 00 precedence 0, out of profile In essence, a higher precedence (queue or class number) should afford a higher probability of timely delivery than a lower precedence packet, and in-profile traffic of any precedence should have a higher probability of delivery than out of profile traffic of the same precedence. If there is comparison among classes, as in a simple drop preference or simple priority queuing model, in-profile traffic of any precedence should have a greater probability of timely delivery than out of profile traffic of any precedence, without loss of sequence within a precedence. In the implementation, one could expect this to be implemented as some combination of drop preference (emphasis being on the probability of delivery), and queue characteristics (emphasis on timeliness of delivery). Other PHBs, those whose two least significant bits are non- zero, are outside the scope of this specification and are not further discussed in this memo. Baker et alia Expiration: October 1998 [Page 8] Draft IP Precedence in Differentiated Services April 1998 It can be argued that, since the PHBs are in fact indices in a case statement, there is no substantive reason that the exact values chosen above need be chosen. These specific values are chosen so as to be backward compatible with [IP]'s IP Precedence enumeration, and so that the in/out bit selected is contiguous with the other numbers. The reason an in/out bit is selected, rather than letting there be some number of of "in" values and a common "out of profile" PHB, relates to cases where precedence is selecting a queue. If all traffic is in the same queue, a single PHB is clearly sufficient to mark that traffic which is out of profile. With multiple queues, however, one could imagine assigning different WFQ weights to traffic in the same queue which is in or out of profile, as well as providing different drop probabilities. The astute reader will note that the default PHB, whose value is zero, is relegated to "routine, out of profile" traffic status; this is consistent with current IP practice, and makes any other setting of the field a desirable improvement, encouraging deployment. 2.3. Intended PHB Modifications This memo contemplates two algorithms for setting or changing the PHB value. One algorithm, typically executed in the originating host application or its first-hop router, sets the PHB to a given precedence, in or out of profile, according to a policy set by the network administration. The other, typically executed in the first hop router of a routing domain (next to the host, at ingress to a service provider, etc.), may change it from "in profile" to "out of profile" according to the service level agreement in force. Clearly, there is nothing to stop a service provider from setting it to another PHB, including changing the effective precedence or using some other service. If the service provider does so, however, he gives up whatever semantic was intended by the originator, losing information and perhaps losing the benefit of the service on an end to end basis. Such policies therefore call for wisdom on the part of the network administration. Baker et alia Expiration: October 1998 [Page 9] Draft IP Precedence in Differentiated Services April 1998 3. Potential Implementation Strategies We now discuss a number of possible implementation strategies. These are each examples: no one approach is mandated, and these are not the only possible implementations. 3.1. Simple Drop Preference The simplest implementation of this service is simple drop preference in a simple FIFO queue. In this case, "higher probability of timely delivery" translates directly as "higher probability of delivery", with "out of profile" traffic making way for "in profile" traffic, and lower precedence for higher. Among these PHBs, we assume that the interface implements a Random Early Detection algorithm, and that the min-threshold and max-threshold values associated with various PHBs rise in this sequence: 111 1 00 precedence 7, in profile (Highest probability 110 1 00 precedence 6, in profile of delivery) 101 1 00 precedence 5, in profile 100 1 00 precedence 4, in profile 011 1 00 precedence 3, in profile 010 1 00 precedence 2, in profile 001 1 00 precedence 1, in profile 000 1 00 precedence 0, in profile 111 0 00 precedence 7, out of profile 110 0 00 precedence 6, out of profile 101 0 00 precedence 5, out of profile 100 0 00 precedence 4, out of profile 011 0 00 precedence 3, out of profile 010 0 00 precedence 2, out of profile 001 0 00 precedence 1, out of profile (Lowest probability 000 0 00 precedence 0, out of profile of delivery) The strength of this approach is that it maintains order as specified, and drops the lowest precedence traffic first. The weakness of the approach is that no way is afforded to make a demonstrable difference in the variation in queuing delay experienced by the various precedences, only the difference in drop probability. 3.2. Priority Queues with Drop Preference Another approach employs a queue per precedence, using one bit of the PHB as a drop preference within the queue. RED is used Baker et alia Expiration: October 1998 [Page 10] Draft IP Precedence in Differentiated Services April 1998 within the queues according to its usual parameters, but with in-profile traffic having a higher min-threshold and max- threshold than out of profile traffic, and therefore experiencing a higher probability of timely delivery. Queues are ranked in priority order so that each queue, from the perspective of the next lower priority queue, implements a "low loss low delay" service. Out of profile traffic should consider the presence of lower precedence in-profile traffic in the calculation of drop probability. The strength of this approach is that order is maintained within each precedence queue, but higher precedence traffic may be sent before lower precedence traffic. It has a weakness, however, in that apart from admission and policing, it affords lower precedence traffic no assurance of eventual transmission. 3.3. Round Robin Queuing with Drop Preference Like the previous one, this approach employs a queue per precedence, using the one bit of the PHB as a drop preference within the queue. RED is used within the queues according to its usual parameters, but with in-profile traffic having a higher min-threshold and max-threshold than out of profile traffic. However, each queue is emptied at some rate, in round-robin order, rather than being given simple priority service. The strength of this approach is that order is maintained within each precedence queue, but higher precedence traffic may be sent before lower precedence traffic. It also avoids the lockout issue that priority queuing systems experience. A counter-intuitive scenario can occur, however, if a high rate queue is heavily utilized while a lower rate queue is under- utilized; a packet directed to the lower rate queue can actually be better protected from loss and variation in delay when placed in an empty or very short queue. 3.4. Virtual Circuit or Virtual Channel Selection The difference between this approach and Round Robin Queuing with Drop Preference is somewhat academic. If one has a serial line to a routing neighbor, and manages using a load sharing algorithm, the load sharing algorithm in some sense emulates the way the line would behave if it were in reality a number of different lines, or if it were one channelized line. In a virtual circuit selection model, the emulation becomes reality Baker et alia Expiration: October 1998 [Page 11] Draft IP Precedence in Differentiated Services April 1998 - one deploys a set of rate-limited VCs to a routing neighbor, and uses them in the same way one would otherwise have used queues. The strengths and weaknesses are very similar to those of Round Robin Queuing, except that this allows one to capitalize on the capabilities of a link layer such as ATM or Frame Relay. 3.5. IEEE 802.1d (previously 802.1p) Service Marks The difference between this approach and Round Robin Queuing with Drop Preference is also somewhat academic; an 802.1d switch employs round robin queuing within itself, so the queue management is again deployed through the link layer network. It is worth noting, however, that the bits must be mapped: 802.1d traffic classes are a three bit number, which has an interesting set of rules. If the switch implements eight classes, the number selects the class. If it implements four classes, the two most significant bits of the number select the class and the least significant bit has no defined utility. If it implements two classes, the most significant bit selects that class. We therefore suggest this mapping algorithm: (1) If an 802.1d switch implements eight classes, the mapping from IP Precedence to 802.1d traffic class is to place the precedence number (bits zero through two of the PHB) into the traffic class field. (2) If an 802.1d switch implements one, two, or four classes, the mapping from IP Precedence to 802.1d traffic class is to place the two most significant bits of the precedence number (bits zero and one of the PHB) into the traffic class field's most significant bits, and copy the in/out bit (bit three) into the least significant bit of the traffic class. In this manner, it is available should the switch decide to consider it a drop preference bit. A corollary suggestion is being submitted to IEEE 802.1. 4. Acknowledgments The authors note that there were a number of reviewers even of the first drafts of this note, whose inputs are very much appreciated. Baker et alia Expiration: October 1998 [Page 12] Draft IP Precedence in Differentiated Services April 1998 5. References [IP] RFC 791, "Internet Protocol". J. Postel. Sep-01-1981. [HOSTREQ] RFC 1122, "Requirements for Internet hosts - communication layers". R.T. Braden. Oct-01-1989. [FRAMEWORK] Nichols, "Differentiated Services Operational Model and Definitions", 02/11/1998, draft-nichols-dsopdef-00.txt [PRINCIPLES] RFC 1958, "Architectural Principles of the Internet". B. Carpenter. June 1996. [ASSURED] Clark and Wroclawski, "An Approach to Service Allocation in the Internet", 08/04/1997, draft-clark-diff-svc- alloc-00.txt [BROKER] Nichols and Zhang, "A Two-bit Differentiated Services Architecture for the Internet", 12/23/1997, draft- nichols-diff-svc-arch-00.txt Baker et alia Expiration: October 1998 [Page 13] Draft IP Precedence in Differentiated Services April 1998 6. Security Considerations The Differentiated Services Architecture explicitly requires each network to guard its own doors; if a system behaves in a manner inappropriate to its contracts, the intended behavior is that the system's communications will experience greater unreliability and may be shut down entirely, by way of a punishment. This proposal changes this in no way - it makes the situation no better and no worse. This said, there is a backwards compatibility consideration which is one of the primary motivations for the submission of this idea, which can behave like a security issue. This is that RFC 791 reserves IP Precedence values 6 and 7 for router-to-router traffic, and many routers in the internet use this fact to isolate network control traffic during outage recovery and route changes. To insure continued stability, it is vital that a domain with legacy routers carefully allocate their PHB's to avoid overloading the drop preference controls on the legacy equipment. Thus, we recommend that domains use PHBs with the pattern 11XXXX, when legacy routers are in the path, only for critical routing traffic such as inter-router keep-alive and route update messages. 7. Author's Addresses Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Phone: (408) 526-4257 Email: fred@cisco.com Scott Brim Newbridge Networks Inc. 146 Honness Lane Ithaca, New York 14850 Phone: (607) 273-5472 Email: swb@newbridge.com Tony Li Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 Phone: (650) 526-8000 Baker et alia Expiration: October 1998 [Page 14] Draft IP Precedence in Differentiated Services April 1998 Email: tli@juniper.net Frank Kastenholz Argon Networks 25 porter rd Littleton ma 01460 Phone: (978) 386-0665 Email: kasten@argon.com Shantigram Jagannath Bay Networks 3 Federal Street, Billerica, MA -01821 Phone: (978) 916-8598 Email: jagan@baynetworks.com John K. Renwick Ascend Communications High-Performance Networking Division 10250 Valley View Rd Eden Prairie, MN 55344 Phone: (612) 996-6847 Email: jkr@min.ascend.com Baker et alia Expiration: October 1998 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 05:03:20 |