[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 rfc2688                            
INTERNET-DRAFT                     Steve Jackowski/Deterministic Networks
Expires: August 1999                David Putzolu/Intel Architecture Labs
                                                         February 3, 1999

        Network Element Service Specification for Low Speed Networks

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. 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 draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress".

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   A set of companion documents describe an architecture for providing
   integrated services over low-bitrate links, such as modem lines,
   ISDN B-channels, and sub-T1 links [1, 2, 3, 4]. The main components
   of the architecture are: a set of real-time encapsulation formats for
   asynchronous and synchronous low-bitrate links, a header compression
   architecture optimized for real-time flows, elements of negotiation
   protocols used between routers (or between hosts and routers), and
   announcement protocols used by applications to allow this negotiation
   to take place.

   This document defines the service mappings for controlled load [5] and
   guaranteed [6] services for use with the real-time encapsulation part
   of the architecture.  The approach takes the form of a set of guidelines
   and considerations for implementing these services, along with
   evaluation criteria for elements providing these services.

Jackowski/Putzolu              Expires 8/99                     [Page 1]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt    Feb 1999

Table of Contents

1.  Introduction                                                  3
1.1 Specification Language                                        3
2.  End to End Behavior                                           3
3.  Motivation                                                    4
4.  Network Element Data Handling Requirements                    5
4.1    Rate and Delay                                             5
4.2    Link Aggregation                                           6
4.3    Controlled Load Versus Guaranteed Service                  6
4.4    Controlled Load and Guaranteed Service Data Handling       7
4.5    Controlled Load and Guaranteed Service Class Mapping       7
5.  Invocation Information                                       10
6.  Exported Information                                         10
7.  Ordering and Merging                                         10
8.  Guidelines for Implementors                                  10
8.1    PPP Bit and Byte Stuffing Effects on Admission Control    10
8.2    Compression Considerations                                11
8.3    Admission Control                                         11
8.4    Fragment Scheduling Considerations                        13
9. Evaluation Criteria                                           14
10. Security Considerations                                      14
11. References                                                   15
12. Authors' Addresses                                           16
Acknowledgements                                                 16
Appendix A. Admission Control Considerations for POTS Modems     16

Jackowski/Putzolu                 Expires 8/99                  [Page 2]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt           Feb 1999

1. Introduction

   In addition to the ``best-effort'' services the Internet is well-known
   for, other types of services (``integrated services'') are being
   developed and deployed in the Internet. These services support special
   handling of traffic based on bandwidth, latency, and other requirements
   that cannot usually be met using ``best-effort'' service.

   This document defines how to map integrated services ``controlled
   load'' [5] and ``guaranteed'' [6] services on to low-
   bandwidth links.  The architecture and mechanisms used to implement
   these services on  such links are defined in a set of companion
   documents. The mechanisms defined in these documents include both
   compression of flows (for bandwidth savings) [4] and a set of
   extensions to the PPP protocol which permit fragmentation [2]
   or suspension [3] of large packets in favor of packets from flows
   with more stringent service requirements.

1.1.  Specification Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

2. End-to-end Behavior

   Unlike other link layers  the links referred to in this document operate
   only over low speed point to point links or connections.  Examples
   of the kinds of links addressed here include dial-up lines, ISDN
   channels, and leased lines.  In this context,  'end to end' simply means
   between two points.  In typical inter/intranet environments, this will

   - host to directly connected host.
   - host to/from network access device (router or switch).
   - Edge device (subnet router or switch) to/from router or switch.
   - In rare circumstances, the link may run from backbone router to
     backbone router.

   Thus, the endpoints are two network elements as described above.  The
   Controlled Load and Guaranteed services for the links addressed here
   are applied between these elements and often represent the first or last
   wide area hop in a true end to end service.  It is important to note
   that these links can be the most ``bandwidth constrained'' along the

   The services utilized in mapping integrated services to these links
   are only provided if both endpoints on the link support the architecture

Jackowski/Putzolu              Expires 8/99                     [Page 3]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   and mechanisms referenced above. Support for these mechanisms is
   determined during the PPP negotiation.  Because of the unique
   characteristics of a point to point link with both endpoints
   supporting these mechanisms, traffic is automatically shaped.
   That is, incoming traffic will be TSpec conformant and the
   admission control function can make decisions based on local state:
   it does not need to coordinate with the network element on the other
   end of the link. Furthermore, since the context that these services
   is implemented in is a point to point link,  when rate control and
   delay bounds are provided for individual flows, the link inherently
   acts like a leased circuit (that is, it is not shared with any other
   sources of traffic). The non-shared nature of these links, along with
   the fact that point-to-point links are typically dual simplex
   (i.e., the send and receive channels are separate) is what allows all
   admission control decisions to be made locally.

3. Motivation

   Many applications are now beginning to make more and more use of such
   services. As this use grows, the likelihood of a low bandwidth link of
   some sort being present in the end to end connection grows.  In order to
   meet the service requirements of these applications, it will be necessary
   to provide these enhanced services on the low bandwidth links in the
   end to end connection.  The presence of integrated services on low
   bandwidth links is critical to providing a good end to end service
   because it is precisely on these links that traffic is most likely to
   experience undesirable effects on latency, jitter, and bandwidth.

   The negative effects on service can stem both from traditional causes
   of poor service as well as low bandwidth link specific causes. The
   traditional cause of poor service is multiple packet queuing effects,
   and is alleviated by intelligent ordering of outgoing packets on
   links supporting enhanced services.  Low bandwidth links introduce an
   additional cause for latency - the time for a MTU-sized packet to
   transit such a link is often large enough to be a significant
   component in the end to end latency and jitter requirements of
   flows requiring enhanced services. As such, mechanisms for allowing
   packets to be suspended or fragmented so as to allow transmission of
   packets with more stringent service requirements are necessary,
   along with guidelines for mapping the enhanced services defined in
   integrated services onto these mechanisms. It is the particular
   considerations specific to low bandwidth links in providing a good
   end to end service that this document focuses on.

Jackowski/Putzolu              Expires 8/99                     [Page 4]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

4. Network Element Data Handling Requirements

   The Network Service element may be implemented in hardware or
   the available bandwidth by minimizing header overhead associated with
   software.  As described in [2] and [3], for systems which can perform
   bit-oriented transmission control, the suspend/resume approach optimizes
   MLPPP fragmentation. For systems which provide frame-oriented
   transmission control, the fragmentation approach can be implemented with
   no hardware changes.  Choice of suspend/resume versus fragmentation
   should be made based on the hardware's capability to handle the new HDLC
   framing described in [2] and the system overhead associated with byte by
   byte scanning (required by suspend/resume).

   To provide controlled load or guaranteed service with the suspend/resume
   approach, when a packet for an admitted flow (QoS packet) arrives
   during transmission of a best effort packet and continued
   transmission of the best effort packet would violate delay constraints
   of the QoS service flows, the best effort packet is preempted, the QoS
   packet/fragments are added to the transmission, and the best effort
   packet transmission is then resumed: usually all in one transmission.
   The receiving station separates the best effort packet from the embedded
   QoS packet's fragments.  It is also conceivable that one QoS flow's packet
   might suspend another flow's packet if the delivery deadline of the new
   packet is earlier than the current packet.

   For systems which use fragmentation where suspend/resume is not
   possible, any packets longer than the maximum tolerable delay for packets
   from enhanced service flows are fragmented prior to transmission so that
   a short  packet for another flow can be interleaved between fragments of
   a larger packet and still meet the transmission deadline for the
   flow requiring enhanced services.

   Note that the fragmentation discussed in this document refers to
   multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications
   as described in [2], not IP or other layer 3 fragmentation.  MLPPP
   fragmentation is local to the PPP link, and does not affect end-to-end
   (IP) MTU.

4.1. Rate and Delay

   One assumption made about the nature of point to point links is that
   rate, transmission time and delay are fixed and consistent.  The rate
   of the link is assumed to be determined at connection time, and the
   devices on the link (adapters, modems, DSU/CSUs, etc) traditionally
   exhibit fixed delay  characteristics.  Unfortunately these assumptions
   do not always hold true. Certain link types (e.g., POTS modems) can
   vary both in terms of data rates and in terms of delay characteristics.
   Implementations of these services on such links need to adjust their
   admission control policies to reflect these characteristics.  Refer
   to Appendix A for more considerations on specific link characteristics.

Jackowski/Putzolu              Expires 8/99                     [Page 5]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

4.2. Link Aggregation

   Although certain link types, like ISDN, permit dynamic allocation of
   bandwidth across multiple links, it is assumed that the Admission
   Control service will consider the impact of multiple physical links over
   the point to point logical connection.
   Note that because of the load balancing effect of Multilink PPP (MLPPP),
   two 64 Kbps links should exhibit the delay and transmission
   characteristics of a single 128 Kbps link.  However, MLPPP
   implementations may approach load balancing and fragmentation
   differently.  The mechanism used should be taken into consideration when
   implementing the scheduler (especially token bucket) for packets,
   fragments, and suspend/resume on top of existing MLPPP services to
   ensure that adequate rate and delay characteristics are maintained.

4.3. Controlled Load versus Guaranteed Service

   With most link layers, Guaranteed Service (GS) requires more tightly
   controlled service by the Network Element, and in most cases, acceptance
   of a Guaranteed Service request results in over-provisioning of link
   level resources.  Controlled Load (CL) Service is usually less
   constrained and permits more flexibility in scheduling of packets for
   the link.  However, due to the characteristics of  some types of
   point to point links (e.g., low bandwidth links such as ISDN, POTS,
   etc.), providing Controlled Load service may actually be equally or
   more difficult than Guaranteed Service for certain kinds of traffic.

   Controlled Load requires that the delay associated with packet
   transmission be 'closely approximating unloaded best effort service.'
   Because the links being discussed are not shared (i.e., point-to-point)
   links, unloaded best effort service means that best effort packets
   will incur no more than burst packet delay: M/r where M is the maximum
   packet size and r is the transmission rate.   Thus, the maximum permitted
   delay for a Controlled Load packet (CLmDELAY) is bounded by M/r + P/r
   where P is the size of the outgoing packet.

   In the case where the transmission rate is relatively high, the
   difference in queuing delay between a packet being sent on a
   totally unloaded link & a lightly loaded link is relatively small.
   Consider a scenario wherein a 10MBit/s link is being used to carry
   CL traffic with a burst size of 30 bytes. If the link is totally
   unloaded, the time to transmit a burst will be 0.024ms.  If BE traffic
   is also being carried on the link, perhaps with a packet size of
   1000 bytes, and a CL packet is queued after a BE packet, the time
   before it is transmitted grows to 0.824ms. While this is a 3400%
   increase, it actually only changes the overall delay for the QoS
   packet by less than a millisecond - a relatively small amount in the
   end-to-end latency expected for a large fraction of CL flows. In
   contrast to this, consider the same traffic being carried over a
   relatively slow link with a 56Kbit/s data rate. The burst transmit
   time for a CL packet on an unloaded link would be approximately 4ms.
   If a single BE packet was queued before a CL packet, the transmit time
   for the CL packet would grow to 147ms - an increase in transmission

Jackowski/Putzolu              Expires 8/99                     [Page 6]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

time of over 140ms.  This change is quite significant in the timescales
   used for many CL reservations.

   Given the special considerations associated with scheduling CL flows on
   low bandwidth links,  "standard" assumptions and implementations of
   controlled load service may not result in expected performance.
   Implementors must careful review all assumptions and parameters in
   order to ensure correct functioning.

4.4. Controlled Load and Guaranteed Service Data Handling

   Upon arrival of a QoS flow's packet, the Network Element determines
   if the packet is conformant.  If it is not, Policing is applied
   (see Policing).  Conformant means:

   1) The flow does not exceed the associated TSpec peak rate (RSpec rate
      for Guaranteed Service: rT+b with T=time period).
   2) The packet does not cause a token bucket overflow.

   If the packet is conformant, it is compressed as required, fragmented
   (if necessary), and scheduled.  If there is no conflicting best effort
   traffic, the packet is queued along with the rest of conformant QoS
   traffic and scheduled with respect to any other enhanced services flows
   such that its transmission deadline is met.

   For the suspend/resume implementation to achieve controlled load, any
   packets being transmitted whose transmission would violate
   the CLmDELAY are suspended.  Otherwise, the QoS packet/fragments are
   scheduled ahead of any queued best effort traffic.

   For CL Fragmentation implementations, the packet/fragment is scheduled
   ahead of any best effort packets.  Note that all best effort packets
   must be divided into fragments less than or equal to the smallest MRU
   (or associated fragment size) of all the QoS flows.  This incurs at
   most one fragment delay for the QoS traffic: closely equivalent to
   unloaded best effort service.

   For Guaranteed Service for both fragmentation and suspend/resume, the
   scheduler determines if continued transmission of the best effort packet
   being transmitted would cause delay greater than the acceptable delay.
   If so, the best effort packet is preempted or, in the case of
   fragmentation, the QoS packet is scheduled ahead of the rest of the
   best effort packets' fragments.

4.5. Controlled Load and Guaranteed Service Class Mapping

   Supporting integrated services over PPP links which implement MCML or
   RTF can be accomplished in several ways.  Guidelines for mapping these
   services to PPP links, and specifically, to the classes provided by the
   suspend/resume and fragmentation mechanisms mentioned above, are
   presented below. Note that these guidelines assume that some sort
   of signaling is used to indicate desired quality of service to both
   the sender and receiver of a flow over a PPP link.  These guidelines

Jackowski/Putzolu              Expires 8/99                     [Page 7]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   also assume that it is unlikely that a series of PPP links be
   connected to each other. It is noted that even if a series of PPP
   links were to be connected together, it is likely that each link
   would have different characteristics, and further, that frames would
   have to be reassembled at the terminus of each link for error
   correction purposes, requiring that class assignment be performed on
   each hop of the link, rather than just forwarding frames with
   identical segmentation or fragmentation. These assumptions remove any
   requirement on the service-mapping implementation that quality of
   service information be implicit in the class selection applied to
   particular flows, allowing the sender of an integrated services flow on
   a PPP link complete freedom in assigning classes to flows (or to
   packets within flows).

   One important observation that must be made is 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 consideration is very important, in that it offers
   implementers with a large degree of flexibility in providing integrated
   services over PPP links. This observation implies that the queuing
   discipline used to differentiate different flows does not have any ties
   to the class numbers used. 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 four 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.

   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)

Jackowski/Putzolu              Expires 8/99                     [Page 8]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   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)

   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 a each
   packet, when fragmented, must have the same class value assigned to all

   One suggestion to implementers of integrated services on MCML and RTF
   links is that all BE traffic may 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), it
   is possible to recommend use of class number 0 for BE traffic.

   Treatment of non-conformant QoS traffic is a policy and implementation
   issue.  It is recommended that policing of flows containing non-
   conformant traffic always be done at the level of granularity of
   individual packets rather than at a finer grained level.  In
   particular,  network elements scheduling flows for transmission
   that drop non-conformant traffic should drop entire packets rather
   than dropping individual fragments of packets belonging to non-
   conformant traffic.  For those network elements whose implementation
   allows forwarding of non-conformant traffic when link bandwidth is
   available rather than dropping the traffic,  the implementation should
   fragment packets of such traffic to the smallest MTU of all
   admitted CL flows so as to ensure that CLmDELAY targets are met.

   Whether BE and 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 implementation

   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 can be used for those classes
   to achieve a small bandwidth savings.

Jackowski/Putzolu              Expires 8/99                     [Page 9]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

5. Invocation Information

   To invoke Controlled Load and Guaranteed Services, both traffic
   characteristics and the flow itself must be identified to the Network
   Element.  Several methods can be employed to identify the flows. For
   RSVP, classification can be used to identify the flows.  For non-RSVP
   implementations, other mechanisms have been described such as the
   FlowID field in IP Version 6 and the TOS field in IP version 4.

   If the Network Service Element is running on a system that doesn't
   support application or proxy use of the TOS or FlowID fields, then
   classification must be applied and:

   As described in [4], Controlled Load Service is invoked by specifying
   the flow's traffic characteristics through a TSpec (see [5]).

   As described in [5], Guaranteed Service is invoked by specifying the
   flow's TSpec and a requested reservation via an RSpec (see [6]).

6. Exported Information

   For Controlled Load Service, there is no requirement to export

   For Guaranteed service, both C and D terms for delay computations must
   be made available for export through the Adspec or other means.  See
   Sections 9.1 (Admission Control) for guidelines on computing the C and D

   See [4] and [5] for additional information on Exported Information.

7. Ordering and Merging

   Refer to [4] and [5] for TSpec and RSpec ordering and merging

8. Guidelines for Implementors

8.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 in 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

Jackowski/Putzolu              Expires 8/99                  [Page 10]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   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 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.

8.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].  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.
   Prefix Elision.
   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.

8.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.

Jackowski/Putzolu              Expires 8/99                  [Page 11]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   CMTU is the maximum size of the MTU after compression is applied.
   eMTU is the maximum effective size of the MTU after fragmentation.
   FRAG is the fragment size including MLPPP header/trailers.
   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
   pDelay is the delay associated with suspend/resume packets.
   b is the bucket depth in bytes
   R is the requested Rate.
   D is the fixed overhead delay for the link (Modem, DSU, etc).
   C is the delay associated with transmission and fragmentation.
   eRate is the effective rate after compression and fragmentation.

   The D term may be configured by an administrative tool once the network
   is installed; it may be computed using the Adspec or other 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 C for Guaranteed

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

   #_of_Fragments = (CMTU + FRAG)/(FRAG-Header)

   eMTU = (#_of_Fragments) * FRAG

   eRate = eMTU/CMTU * R

   Admission Control should compare the eRate of the request against the
   remaining bandwidth available to determine if the requested rate can be

   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.

   Guaranteed Service requires  delay computations.  These computation are
   based on the standard formula for delay:

   Delay = b/R + C/R + D

Jackowski/Putzolu              Expires 8/99                  [Page 12]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   Note that for suspend/resume, an additional term is required:

   pDelay = b/R + C/R + D + pHeader/R.

   This term exists because of the additional overhead associated with the
   suspend/resume headers created when suspending a packet.  In the worse
   case, every transmission of a QoS packet could require suspension of a
   best effort packet and thus incur the overhead.  In most networks, this
   term will be nominal at most.  However, on some low-bitrate links, the
   overhead may be worth computing.

   Since MLPPP includes fragmentation, the C term is not fixed and must be
   represented by the worse case fragmentation as computed in the effective
   MTU size:

   C = eMTU.

   Note that because the links under consideration are point to point,
   Guaranteed Service can be offered over a link without any
   negotiated agreement from the next hop.  However, if these services
   are used in conjunction with RSVP, the C and D values above should be
   used in the Adspec.

8.4. Fragment Scheduling Considerations

   As described in Section 4, large packets should be fragmented to a size
   sufficiently small to allow higher priority flows to get a hold of the
   line quickly enough to not violate their reservation constraints.  As
   such, the upper bound for fragment sizes should be no larger than the
   smallest MTU of all QoS flows.  While a very small fragment size
   is desirable from the point of view of meeting QoS deadlines, the
   overhead associated with highly granular fragmentation makes it
   necessary to strike a balance between these considerations. While this
   document will not specify a particular scheduling algorithm, the
   following example should help illustrate the issue:

   Assume we have three different priority flows, A, B, and C.
   Packets from flow C take 100ms, flow B takes 30ms, and flow A takes 30ms
   to transmit. B's required maximum latency is 70ms, while A's is 50ms.
   The above scenario results in flows B and C needing to be segmented
   into 20ms long fragments - that way a lower priority frame will hold
   the link at most 20ms before A gets to the link, taking another
   30ms to transit,  totaling 50ms - all well and good.   B has a
   problem, however - in the scenario where a fragment from C is just
   starting to transmit the link when packets from A and B arrive (call
   this time 0). The fragment from C will transmit until time 20ms.
   After that, the A packet will transmit - finishing by time 50ms,
   just in time. At this point, the fragment from B starts to
   transmit - taking 30ms more, finishing by time 80ms (thus violating
   its reservation).

Jackowski/Putzolu              Expires 8/99                  [Page 13]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   The important point above the scenario is not that it is possible
   to overcommit a link, but that a link can be underutilized
   by using too large a fragment size - in the above case, a 10ms
   fragment size would have allowed both A and B to honor their
   reservations, a 20ms size does not.

9. Evaluation Criteria

   For Controlled Load Service, the network element must ensure that
   the service requested via the TSpec is delivered to the requesting QoS
   flow such that the PPP link appears to be a lightly loaded link.

   As a baseline, it is suggested that performance measurements on
   throughput, delay, and packet error measurements be performed on an
   unloaded link with just the QoS flow using various packet sizes.  The
   baseline should measure performance for both conformant and non-
   conformant traffic when for  overloading the link with a single flow.
   Once these measurements are complete, measurements of the
   Controlled Load Service should be performed as follows:

   1) Request QoS flows in the presence of best effort traffic and ensure
   that the QoS flows' performance approximate the unloaded baseline

   2) Request QoS flows whose aggregate throughput would exceed the link
   capacity.  Admission Control should deny these service requests or admit
   them as best effort only.

   3) Generate traffic on a QoS flow which exceeds its TSpec commitment.
   Ensure recovery of the flow once the traffic becomes conformant.

   For Guaranteed Service:

   1) Ensure that Admission Control will deny service requests or convert
   them to best effort when link capacity or delay bounds would be

   2) On a best-efforts loaded link, ensure that the number of lost packets
   does not exceed those established in the baseline measurements.

   3) On a best-efforts loaded link, ensure that delay and rate commitments
   can be met for QoS flows.

   4) With multiple QoS flows, ensure that an admission of additional QoS
   flows does not cause a violation in rate, error rate, or delay
   constraints of any QoS flow.

10. Security Considerations

   General security considerations for MLPPP and PPP links are

Jackowski/Putzolu              Expires 8/99                  [Page 14]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   addressed in RFC 1990 and RFC 1661, respectively.  Security
   considerations relevant to RSVP, used as the signaling protocol
   for integrated services, are discussed in RFC 2209.

   A specific security consideration relevant to providing quality
   of service over PPP links appears when relying on either observed
   or theoretical average packet expansion during admission control
   due to bit- or byte-stuffing.  Implementations based on these
   packet-expansion values contain a potential vulnerability to
   denial of service attacks.  An adversary could intentionally send
   traffic that will result in worst case bit- or byte stuffing
   packet expansion. This in turn could result in quality of service
   guarantees not being met for other flows due to overly permissive
   admission control. This potential denial of service attack
   argues strongly for using a worst case expansion factor in
   admission control calculations, even for controlled load service.

   Beyond the considerations documented above, this document introduces
   no new security issues on top of those discussed in the companion
   ISSLL documents [5] and [10].  Any use of these service mappings
   assumes that all requests for service are authenticated

11. References

   [1] C. Bormann, ``Providing integrated services over low-bitrate
          links'', Work in Progress (draft-ietf-issll-isslow-04.txt),
          August 1998.

   [2] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'',
       Work in Progress (draft-ietf-issl-isslow-mcml-04.txt),
       August 1998.

   [3] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'',
       Work in Progress (draft-ietf-issl-isslow-rtf-03.txt),
       August 1998.

   [4] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for
       Low-Speed Serial Links'', Work in Progress (draft-ietf-avt-
       crtp-05.txt), July 1998.

   [5] J. Wroclawski, ``Specification of the Controlled-Load Network
       Element Service'', RFC 2211, September 1997.

   [6] C. Partridge, R. Guerin, ``Specification of Guaranteed Quality
       of Service'', RFC 2212, September 1997.

   [7] S. Shenker, J. Wroclawski, ``General Characterization Parameters
       for Integrated Service Network Elements'', RFC 2215,
       September 1997.

   [8] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links,"
       RFC 1144.

Jackowski/Putzolu              Expires 8/99                  [Page 15]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

12. Authors' Addresses:

   Steve Jackowski
   Deterministic Networks, Inc.
   245M Mt Hermon Rd, #140
   Scotts Valley, CA  95060

   David Putzolu
   Intel Architecture Labs (IAL)
   2111 NE 25th Avenue
   Hillsboro, OR 97124-5961
   (503) 264-4510


   This document draws heavily on the work of the ISSLL WG of the IETF.

Appendix A. Admission Control Considerations for POTS Modems

   The protocols used in current implementations of POTS modems can
   exhibit significant changes in link rate and delay over the duration of
   a connection. Admission control and link scheduling algorithms used
   with these devices must be prepared to compensate for this variability
   in order to provide a robust implementation of integrated services.

   Link rate on POTS modems is typically reported at connection time. This
   value may change over the duration of the connection. The v.34
   protocol, used in most POTS modems, is adaptive to link conditions, and
   is able to recalibrate transmission rate multiple times over the
   duration of a connection. Typically this will result in a small (~10%)
   increase in transmission rate over the initial connection within the
   first minute of a call. It is important to note, however, that other
   results are possible as well, including decreases in available
   bandwidth. Admission control algorithms must take such changes into
   consideration as they occur, and implementations must be able to
   gracefully handle the pathological case where link rate actually drops
   below the currently reserved capacity of a link.

   Delay experienced by traffic over POTS modems can vary significantly
   over time.  Unlike link rate, the delay often does not converge to a
   stable value.  The v.42 protocol is used in most POTS modems to provide
   link-layer reliability. This reliability, which is implemented via
   retransmission, can cause frames to experience significant delays.
   Retransmissions also implicitly steal link bandwidth from other

Jackowski/Putzolu              Expires 8/99                  [Page 16]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-05.txt       Feb 1999

   traffic. These delays and reductions in link bandwidth make it
   extremely difficult to honor a guaranteed service reservation. On a
   link that is actually lightly or moderately loaded, a controlled load
   service can to some extent accept such events as part of the behavior
   of a lightly loaded link. Unfortunately, as actual link utilization
   increases, v.42 retransmissions have the potential of stealing larger
   and larger fractions of available link bandwidth; making even
   controlled load service difficult to offer at high link utilization
   when retransmissions occur.

 Jackowski/Putzolu              Expires 8/99                 [Page 17]