rfc2688.txt

RFC 的详细文档！

   In the case where fewer reservations are expected than the total
   number of classes negotiated for a PPP link, it is possible to assign
   individual flows to fixed class numbers. This assignment is useful in
   the case where the protocol identifier associated with one or more
   flows is known at LCP negotiation time and the bandwidth of the
   connection is relatively small. If these conditions hold true, then
   for those flows that are known, a specific class can optionally be
   assigned to them and the prefix elision PPP option [2] can be used for
   those classes to achieve a small bandwidth savings.

3.3 Dynamic Class Mappings

   In the case where predefined class mappings are not satisfactory, an
   implementer MAY map class values to individual packets rather than
   assigning flows to fixed classes.  This can be done due to the fact
   that the classes that MCML and RTF provide can be viewed purely as
   PPP-specific segmentation/fragmentation mechanisms. That is, while the
   class number MUST remain constant on an intra-packet basis, it MAY
   vary on an inter-packet basis for all flows transiting a PPP
   link. Actual assignment of particular flows to fixed classes is
   unnecessary, as the class numbers are NOT REQUIRED to have any meaning
   other than in the context of identifying the membership of
   fragments/segments as part of a single packet.  This point is
   sufficiently important that an example is provided below.

   Consider a PPP link using the MCML short sequence number fragment
   format (that is, four classes are provided).  Assume that in addition
   to carrying best effort traffic, this link is carrying five guaranteed
   service flows, A, B, C, D, and E. Further assume that the link
   capacity is 100kbit/s and the latency is 100ms. Finally, assume the BE
   traffic is sufficient to keep the pipe full at all times and that GS
   flows A-E are each 10kbit/s and all have delay bounds of 145ms.




Jackowski, et al.           Standards Track                     [Page 6]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


Time(ms)        Action
 0     BE traffic is queued up
 0     2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...)
 8     2kbit fragment from BE sent, cls 0 (10kbit BE packet done)
 9     8kbit packet from flow A arrives
10     2kbit fragment from A sent, cls 1 (8kbit flow A packet start)
11     8kbit packet from flow B arrives
12     2kbit fragment from B sent, cls 2 (8kbit flow B packet start)
13     8kbit packets from flows C, D, and E arrive
14     2kbit fragment from C sent, cls 3 (8kbit flow C packet start)
16     2kbit fragment from D sent, cls 0 (8kbit flow D packet start)
18     2kbit fragment from A sent, cls 1
20     2kbit fragment from B sent, cls 2
22     2kbit fragment from A sent, cls 1
24     2kbit fragment from A sent, cls 1 (8kbit flow A packet done)
26     2kbit fragment from E sent, cls 1 (8kbit flow E packet start)
27     8kbit packet from flow A arrives
28     2kbit fragment from B sent, cls 2
30     2kbit fragment from C sent, cls 3
32     2kbit fragment from E sent, cls 1
34     2kbit fragment from B sent, cls 2 (8kbit flow B packet done)
36     2kbit fragment from E sent, cls 1
38     2kbit fragment flow A sent, cls 2 (8kbit flow A packet start)
       (etc.)

   This example shows several things. First, multiple flows MAY share
   the same class, particularly in the case where there are more flows
   than classes. More importantly, there is no reason that a particular
   flow must be assigned to a fixed class - the only requirement is that
   each packet, when fragmented, MUST have the same class value assigned
   to all fragments.  Beyond this requirement the link scheduler may
   assign individual to changing class numbers as necessary to meet
   reservation requirements.

   One suggestion to implementers of integrated services on MCML and RTF
   links using dynamic mappings is that all BE traffic SHOULD be
   logically separated from QoS traffic, and mapped to a fragmentable
   (MCML classes 0-3 in short sequence number fragment format, 0-15 in
   long sequence number fragment format) or suspendable (RTF classes 0-
   6) class. Since BE traffic will in most implementations not be
   scheduled for transmission except when a link is empty (that is, no
   CL or GS traffic is ready for transmission), implementers MAY choose
   to make use of class number 0 for BE traffic.








Jackowski, et al.           Standards Track                     [Page 7]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


3.4 Non-Conformant Traffic

   Treatment of non-conformant QoS traffic is largely determined by the
   appropriate service specifications, but the detailed implementation
   in the context of this draft allows for some flexibility.  Policing
   of flows containing non-conformant traffic SHOULD always be done at
   the level of granularity of individual packets rather than at a finer
   grained level.  In particular, in those cases where a network element
   scheduling flows for transmission needs to drop non-conformant
   traffic, it SHOULD drop entire packets rather than dropping
   individual fragments of packets belonging to non-conformant traffic.
   In those cases where a network element forwards non-conformant
   traffic when link bandwidth is available rather than dropping the
   traffic, the implementation SHOULD fragment packets of such traffic
   as if it were best effort traffic.

   Whether BE and non-conformant traffic are treated differently in
   regards to transmission (e.g., BE is given priority access over non-
   conformant traffic to the link) or whether within each type of
   traffic special treatment is afforded to individual flows (e.g., WFQ,
   RED, etc.) is service dependent.

4. Guidelines for Implementers

4.1. PPP Bit and Byte Stuffing Effects on Admission Control

   An important consideration in performing admission control for PPP
   links is reductions in effective link rate due to bit stuffing.
   Typical bit stuffing algorithms can result in as much as 20%
   additional overhead. Thus, admission control implementations for
   guaranteed service over links where bit stuffing is used SHOULD take
   the RSpec rate of all flows and multiply by 1.2, to account for the
   20% overhead from bit stuffing, when determining whether a new flow
   can be admitted or not. Admission control implementations for
   controlled load reservations may use a similar algorithm using the
   TSpec peak rate or may attempt to measure the actual degree of
   expansion occurring on a link due to bit stuffing. This
   characterization can then be used to adjust the calculated remaining
   link capacity. Such measurements must be used cautiously, in that the
   degree of bit stuffing that occurs may vary significantly, both in an
   inter- and intra-flow fashion.

   Byte stuffing is also used on many PPP links, most frequently on POTS
   modems when using the v.42 protocol. Byte stuffing poses a difficult
   problem to admission control, particularly in the case of guaranteed
   service, due to its highly variable nature. In the worse case, byte
   stuffing can result in a doubling of frame sizes. As a consequence, a
   strict implementation of admission control for guaranteed load on



Jackowski, et al.           Standards Track                     [Page 8]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


   byte stuffed PPP links SHOULD double the RSpec of link traffic in
   making flow admission decisions. As with bit stuffing,
   implementations of controlled load service admission control
   algorithms for links with byte stuffing MAY attempt to determine
   average packet expansion via observation or MAY use the theoretical
   worst case values.

4.2. Compression Considerations

   The architecture for providing integrated services over low bandwidth
   links uses several PPP options to negotiate link configuration as
   described in [4, 8, 10].  When deciding whether to admit a flow,
   admission control MUST compute the impact of the following on MTU
   size, rate, and fragment size:

   Header compression: Van Jacobson or Casner-Jacobson [4,8,10].
   Prefix Elision.
   CCP.
   Fragment header option used.
   Fragmentation versus suspend/resume approach.

   If any of the compression options are implemented for the connection,
   the actual transmission rate, and thus the bandwidth required of the
   link, will be reduced by the compression method(s) used.

   Prefix elision can take advantage of mapping flows to MLPPP classes
   to elide prefixes which cannot be compressed at higher layers.  By
   establishing agreement across the link, the sender may elide a prefix
   for a certain class of traffic and upon receiving packets in that
   class, the receiver can restore the prefix.

   Both compression gain and elision gain MUST be included as described
   in the admission control section below. Note that the ability to
   perform compression at higher layers (e.g. TCP or RTP/UDP) may depend
   on the provision of a hint by the sender, as described in [9].

4.3. Admission Control

   Admission control MUST decide whether to admit a flow based on rate
   and delay.  Assume the following:

  LinkRate is the rate of the link.
  MTU is the maximum transmission unit from a protocol.
  MRU is the maximum receive unit for a particular link.
  CMTU is the maximum size of the MTU after compression is applied.
  eMTU is the effective size at the link layer of an MTU-sized packet
    after link layer fragmentation and addition of the fragment headers.
  FRAG is the fragment size including MLPPP header/trailers.



Jackowski, et al.           Standards Track                     [Page 9]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


  Header is the size of the header/trailers/framing for MLPPP/Fragments.
  pHeader is the additional header/framing overhead associated with
    suspend/resume.  This should include FSE and worst case stuffing
    overhead.
  pDelay is the time take to suspend a packet already "in flight",
    e.g. due to the delay to empty the output FIFO.
  b is the bucket depth in bytes
  R is the requested Rate.
  Dlink is the fixed overhead delay for the link (Modem, DSU,
    speed-of-light, etc).
  eRate is the effective rate after compression and fragmentation.

   The Dlink term MAY be configured by an administrative tool once the
   network is installed; it may be determined by real-time measurement
   means; or it MAY be available from hardware during link setup and/or
   PPP negotiation.  Refer to Appendix A for more considerations on PPP
   link characteristics and delays.

   Admission control MUST compute CMTU, eMTU, and eRate for Controlled
   Load Service, and it MUST compute CMTU, eMTU, eRate, and D for
   Guaranteed Service:

   To determine whether the requested rate is available, Admission
   Control MUST compute the effective rate of the request (eRate) -
   worst case - as follows:

   #_of_Fragments = CMTU div (FRAG-Header) [Integer divide]
   Last_Frag_Size = CMTU mod (FRAG-Header

   If Last_Frag_Size != 0
      eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header
   Else
      eMTU = (#_of_Fragments) * FRAG

   eRate = eMTU/CMTU * R [floating point divide]

   Admission control SHOULD compare the eRate of the request against the
   remaining bandwidth available to determine if the requested rate can
   be delivered.

   For Controlled Load Service, a flow can be admitted as long as there
   is sufficient bandwidth available (after the above computation) to
   meet the rate requirement, and if there is sufficient buffer space
   (sum of the token bucket sizes does not exceed the buffer capacity).
   While some statistical multiplexing could be done in computing
   admissibility, the nature of the low-bitrate links could make this
   approach risky as any delay incurred to address a temporary
   overcommitment could be difficult to amortize.



Jackowski, et al.           Standards Track                    [Page 10]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


4.4 Error Term Calculations

   Guaranteed Service requires the calculation of C and D error terms. C
   is a rate-dependent error term and there are no special
   considerations affecting its calculation in the low-speed link
   environment. The D term is calculated from the inherent link delay
   (Dlink) plus the potential worst case delay due to transmission of
   another fragment or suspend/resume overhead. Thus, D should be
   calculated as

   D = Dlink + FRAG/LinkRate

   in the case of a fragementing implementation and

   D = Dlink + pHeader + pDelay

   for a suspend/resume implementation.

4.5 Scheduling Considerations

   We may think of the link scheduler as having two parts, the first of
   which schedules packets for transmission before passing them to the
   second part of the scheduler -- the link level scheduler -- which is
   responsible for fragmenting packets, mapping them to classes, and
   scheduling among the classes.

   In the dynamic class mapping mode of Section 3.3, when deciding which
   class to assign a packet to, the link level scheduler should take
   account of the sizes of other packets currently assigned to the same
   class. In particular, packets with the tightest delay constraints
   should not be assigned to classes for which relatively large packets
   are in the process of being transmitted.

   In either the dynamic or the static class mapping approach, note that