[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

          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]
          

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/