rfc3246.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

         until such a trailer has been received.

   An EF-compliant node MUST be able to be characterized by the range of
   possible R values that it can support on each of its interfaces while
   conforming to these equations, and the value of E_a that can be met
   on each interface.  R may be line rate or less.  E_a MAY be specified
   as a worst-case value for all possible R values or MAY be expressed
   as a function of R.

   Note also that, since a node may have multiple inputs and complex
   internal scheduling, the j-th EF packet to arrive at the node
   destined for a certain interface may not be the j-th EF packet to
   depart from that interface.  It is in this sense that eq_1 and eq_2
   are unaware of packet identity.

   In addition, a node that supports EF on an interface I at some
   configured rate R MUST satisfy the following equations:

      D_j <= F_j + E_p for all j > 0                             (eq_3)

   where F_j is defined iteratively by

      F_0 = 0, D_0 = 0

      F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R,  for all j > 0  (eq_4)

   In this definition:

      -  D_j is the actual departure time of the individual EF packet
         that arrived at the node destined for interface I at time A_j,
         i.e., given a packet which was the j-th EF packet destined for
         I to arrive at the node via any input, D_j is the time at which
         the last bit of that individual packet actually leaves the node
         from the interface I.



Davie, et. al.              Standards Track                     [Page 6]

RFC 3246              An Expedited Forwarding PHB             March 2002


      -  F_j is the target departure time for the individual EF packet
         that arrived at the node destined for interface I at time A_j.

      -  A_j is the time that the last bit of the j-th EF packet
         destined to the output I to arrive actually arrives at the
         node.

      -  L_j is the size (bits) of the j-th EF packet to arrive at the
         node that is destined to output I. L_j is measured on the IP
         datagram (IP header plus payload) and does not include any
         lower layer (e.g. MAC layer) overhead.

      -  R is the EF configured rate at output I (in bits/second).

      -  E_p is the error term for the treatment of individual EF
         packets.  Note that E_p represents the worst case deviation
         between the actual departure time of an EF packet and the ideal
         departure time of the same packet, i.e. E_p provides an upper
         bound on (D_j - F_j) for all j.

      -  D_0 and F_0 do not refer to a real packet departure but are
         used purely for the purposes of the recursion.  The time origin
         should be chosen such that no EF packets are in the system at
         time 0.

      -  for the definitions of A_j and D_j, the "last bit" of the
         packet includes the layer 2 trailer if present, because a
         packet cannot generally be considered available for forwarding
         until such a trailer has been received.

   It is the fact that D_j and F_j refer to departure times for the j-th
   packet to arrive that makes eq_3 and eq_4 aware of packet identity.
   This is the critical distinction between the last two equations and
   the first two.

   An EF-compliant node SHOULD be able to be characterized by the range
   of possible R values that it can support on each of its interfaces
   while conforming to these equations, and the value of E_p that can be
   met on each interface.  E_p MAY be specified as a worst-case value
   for all possible R values or MAY be expressed as a function of R. An
   E_p value of "undefined" MAY be specified.  For discussion of
   situations in which E_p may be undefined see the Appendix and [6].

   For the purposes of testing conformance to these equations, it may be
   necessary to deal with packet arrivals on different interfaces that
   are closely spaced in time.  If two or more EF packets destined for
   the same output interface arrive (on different inputs) at almost the




Davie, et. al.              Standards Track                     [Page 7]

RFC 3246              An Expedited Forwarding PHB             March 2002


   same time and the difference between their arrival times cannot be
   measured, then it is acceptable to use a random tie-breaking method
   to decide which packet arrived "first".

2.3. Figures of merit

   E_a and E_p may be thought of as "figures of merit" for a device.  A
   smaller value of E_a means that the device serves the EF aggregate
   more smoothly at rate R over relatively short timescales, whereas a
   larger value of E_a implies a more bursty scheduler which serves the
   EF aggregate at rate R only when measured over longer intervals.  A
   device with a larger E_a can "fall behind" the ideal service rate R
   by a greater amount than a device with a smaller E_a.

   A lower value of E_p implies a tighter bound on the delay experienced
   by an individual packet.  Factors that might lead to a higher E_p
   might include a large number of input interfaces (since an EF packet
   might arrive just behind a large number of EF packets that arrived on
   other interfaces), or might be due to internal scheduler details
   (e.g. per-flow scheduling within the EF aggregate).

   We observe that factors that increase E_a such as those noted above
   will also increase E_p, and that E_p is thus typically greater than
   or equal to E_a.  In summary, E_a is a measure of deviation from
   ideal service of the EF aggregate at rate R, while E_p measures both
   non-ideal service and non-FIFO treatment of packets within the
   aggregate.

   For more discussion of these issues see the Appendix and [6].

2.4. Delay and jitter

   Given a known value of E_p and a knowledge of the bounds on the EF
   traffic offered to a given output interface, summed over all input
   interfaces, it is possible to bound the delay and jitter that will be
   experienced by EF traffic leaving the node via that interface.  The
   delay bound is

      D = B/R + E_p          (eq_5)

   where

      -  R is the configured EF service rate on the output interface

      -  the total offered load of EF traffic destined to the output
         interface, summed over all input interfaces, is bounded by a
         token bucket of rate r <= R and depth B




Davie, et. al.              Standards Track                     [Page 8]

RFC 3246              An Expedited Forwarding PHB             March 2002


   Since the minimum delay through the device is clearly at least zero,
   D also provides a bound on jitter.  To provide a tighter bound on
   jitter, the value of E_p for a device MAY be specified as two
   separate components such that

      E_p = E_fixed + E_variable

   where E_fixed represents the minimum delay that can be experienced by
   an EF packet through the node.

2.5. Loss

   The EF PHB is intended to be a building block for low loss services.
   However, under sufficiently high load of EF traffic (including
   unexpectedly large bursts from many inputs at once), any device with
   finite buffers may need to discard packets.  Thus, it must be
   possible to establish whether a device conforms to the EF definition
   even when some packets are lost.  This is done by performing an
   "off-line" test of conformance to equations 1 through 4.  After
   observing a sequence of packets entering and leaving the node, the
   packets which did not leave are assumed lost and are notionally
   removed from the input stream.  The remaining packets now constitute
   the arrival stream (the a_j's) and the packets which left the node
   constitute the departure stream (the d_j's).  Conformance to the
   equations can thus be verified by considering only those packets that
   successfully passed through the node.

   In addition, to assist in meeting the low loss objective of EF, a
   node MAY be characterized by the operating region in which loss of EF
   due to congestion will not occur.  This MAY be specified, using a
   token bucket of rate r <= R and burstsize B, as the sum of traffic
   across all inputs to a given output interface that can be tolerated
   without loss.

   In the event that loss does occur, the specification of which packets
   are lost is beyond the scope of this document.  However it is a
   requirement that those packets not lost MUST conform to the equations
   of Section 2.2.

2.6. Microflow misordering

   Packets belonging to a single microflow within the EF aggregate
   passing through a device SHOULD NOT experience re-ordering in normal
   operation of the device.

2.7. Recommended codepoint for this PHB

   Codepoint 101110 is RECOMMENDED for the EF PHB.



Davie, et. al.              Standards Track                     [Page 9]

RFC 3246              An Expedited Forwarding PHB             March 2002


2.8. Mutability

   Packets marked for EF PHB MAY be remarked at a DS domain boundary
   only to other codepoints that satisfy the EF PHB.  Packets marked for
   EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
   domain.

2.9. Tunneling

   When EF packets are tunneled, the tunneling packets SHOULD be marked
   as EF.  A full discussion of tunneling issues is presented in [5].

2.10.  Interaction with other PHBs

   Other PHBs and PHB groups may be deployed in the same DS node or
   domain with the EF PHB.  The equations of Section 2.2 MUST hold for a
   node independent of the amount of non-EF traffic offered to it.

   If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF traffic
   could inflict on other traffic (e.g., a token bucket rate limiter).
   Traffic that exceeds this limit MUST be discarded.  This maximum EF
   rate, and burst size if appropriate, MUST be settable by a network
   administrator (using whatever mechanism the node supports for non-
   volatile configuration).

3. Security Considerations

   To protect itself against denial of service attacks, the edge of a DS
   domain SHOULD strictly police all EF marked packets to a rate
   negotiated with the adjacent upstream domain.  Packets in excess of
   the negotiated rate SHOULD be dropped.  If two adjacent domains have
   not negotiated an EF rate, the downstream domain SHOULD use 0 as the
   rate (i.e., drop all EF marked packets).

   In addition, traffic conditioning at the ingress to a DS-domain MUST
   ensure that only packets having DSCPs that correspond to an EF PHB
   when they enter the DS-domain are marked with a DSCP that corresponds
   to EF inside the DS-domain.  Such behavior is as required by the
   Differentiated Services architecture [4].  It protects against
   denial-of-service and theft-of-service attacks which exploit DSCPs
   that are not identified in any Traffic Conditioning Specification
   provisioned at an ingress interface, but which map to EF inside the
   DS-domain.






Davie, et. al.              Standards Track                    [Page 10]

RFC 3246              An Expedited Forwarding PHB             March 2002


4. IANA Considerations

   This document allocates one codepoint, 101110, in Pool 1 of the code
   space defined by [3].

5. Acknowledgments

   This document was the result of collaboration and discussion among a
   large number of people.  In particular, Fred Baker, Angela Chiu,
   Chuck Kalmanek, and K. K. Ramakrishnan made significant contributions
   to the new EF definition.  John Wroclawski provided many helpful
   comments to the authors.  This document draws heavily on the original
   EF PHB definition of Jacobson, Nichols, and Poduri.  It was also
   greatly influenced by the work of the EFRESOLVE team of Armitage,
   Casati, Crowcroft, Halpern, Kumar, and Schnizlein.

6. References

   [1]   Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
         Forwarding PHB", RFC 2598, June 1999.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
         the Differentiated Services Field (DS Field) in the IPv4 and
         IPv6 Headers", RFC 2474, December 1998.

   [4]   Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W.
         Weiss, "An Architecture for Differentiated Services", RFC 2475,
         December 1998.

   [5]   Black, D., "Differentiated Services and Tunnels", RFC 2983,
         October 2000.