rfc2688.txt

RFC 的详细文档！

Network Working Group                                       S. Jackowski
Request for Comments: 2688                        Deterministic Networks
Category: Standards Track                                     D. Putzolu
                                                 Intel Architecture Labs
                                                              E. Crawley
                                                          Argon Networks
                                                                B. Davie
                                                           Cisco Systems
                                                          September 1999


          Integrated Services Mappings for Low Speed Networks

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   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 of the IETF Integrated
   Services for low-bitrate links, specifically the controlled load [5]
   and guaranteed [6] services.  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, et al.           Standards Track                     [Page 1]

RFC 2688      Integrated Services Mappings Low Speed Nets September 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 the mapping of 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,10] 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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [11].

2. Issues for Providing Controlled and Guaranteed Service

   Unlike other link layers, the links referred to in this document
   operate only over low speed point to point connections.  Examples of
   the kinds of links addressed here include dial-up lines, ISDN
   channels, and low-speed (1.5Mbps or less) leased lines.  Such links
   can occur at different positions within the end-to-end path:

   - 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, a link from backbone router to backbone
     router.

   These links often represent the first or last wide area hop in a true
   end to end service.  Note that these links may be the most bandwidth
   constrained along the path between two hosts.

   The services utilized in mapping integrated services to these links
   are only provided if both endpoints on the link support the
   architecture and mechanisms referenced above. Support for these
   mechanisms is determined during the PPP negotiation.  The non-shared





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


   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) allows all admission control decisions to be made locally.

   As described in [2] and [3], for systems that can exert real time
   control of their transmission at a finer grain than entire HDLC
   frames, the suspend/resume approach optimizes the available bandwidth
   by minimizing header overhead associated with MLPPP pre-fragmentation
   and can provide better delay.  However, this comes at the expense of
   preparing all outgoing data and scanning all incoming data for
   suspend/resume control information.  The fragmentation approach can
   be implemented without additional scanning of the data stream (beyond
   bit-/byte-stuffing, which may be in hardware) and is applicable to
   systems which provide only frame-oriented transmission control.
   Choice of suspend/resume versus fragmentation should be made based on
   the level of transmission control, the element's capability to handle
   the HDLC-like 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, 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.







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


2.1 Calculating "Acceptable Delay" for Int-serv flows

   A router which provides Controlled Load or Guaranteed Service over a
   low speed serial link needs to have some notion of the "acceptable
   delay" for packets that belong to int-serv flows. If using
   fragmentation, a router needs to know what size to fragment packets
   to; if using suspend/resume, it needs to know when it is appropriate
   to suspend one packet to meet the delay goals of another.

   Unfortunately, there is no hard and fast way for a single delay bound
   to be determined for a particular flow; while the end-points of a
   flow have enough information to determine acceptable end-to-end delay
   bounds and to make reservation requests of the network to meet those
   bounds, they do not communicate a "per-hop" delay to routers.

   In the case of Guaranteed Service [6], one approach is to let the
   network operator configure parameters on the router that will
   directly affect its delay performance. We observe that guaranteed
   service allows routers to deviate from the ideal fluid flow model and
   to advertise the extent of the deviation using two error terms C and
   D, the rate-dependent and rate-independent error terms, defined in
   [6]. A network operator can configure parameters of the low speed
   link in such a way that D is set to a value of her choice.

   If link-level fragmentation is used, the router controlling a low-
   speed link can be configured with a certain fragment size. This will
   enable a component of the error term D to be calculated based on the
   time to send one fragment over the link. (Note that D may have other
   components such as the speed of light delay over the link.)  Details
   of the calculation of D are described below. Similarly, if
   suspend/resume is used, the router may be configured with a delay
   parameter, which would enable it to decide when it was appropriate to
   suspend a packet.

   For Controlled Load, there are no error terms, and the router must
   decide how best to meet the requirements of the admitted reservations
   using only the information in their TSpecs. Since the definition of
   Controlled Load states that a CL flow with Tspec rate r should
   receive treatment similar to an unloaded network of capacity r, CL
   packets should not generally experience end-to-end delays
   significantly greater than b/r + propagation delays. Clearly a router
   connected to a low speed link should not introduce a delay greater
   than b/r due to transmission of other fragments; ideally it should
   introduce substantially less delay than b/r, since other hops on the
   end-to-end path may introduce delay as well. However, this may be
   difficult for flows with very small values of b.





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


   It is expected that implementers will make their own tradeoffs as to
   how low to make the delay for Controlled Load flows. Similarly, it
   may not be possible or desirable to configure the parameters
   affecting D to arbitrarily small values, since there is a cost in
   overhead in fragmenting packets to very small sizes. Conversely, if D
   is too large, some applications may find that they cannot make a
   reservation that will meet their delay objectives.

   For the remainder of this document, we assume that a router has some
   notion of the acceptable delay that it may introduce before beginning
   transmission of a packet. This delay is in addition to any delay that
   a packet might be subjected to as a result of the "ideal" queuing
   algorithm that the router uses to schedule packets.

3. 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 to the classes provided by the
   suspend/resume and fragmentation mechanisms are presented below.
   Note that these guidelines assume that some sort of signaling
   protocol is used to indicate desired quality of service to both the
   sender and receiver of a flow over a PPP link.

3.1 Predefined Class Mappings

   A relatively simple method of class mapping that MAY be used is one
   where class values correspond to predefined levels of service.  In
   this arrangement, all admitted flows are grouped into one of several
   buckets, where each bucket roughly corresponds to the level of
   service desired for the flows placed in it. An example set of
   mappings appears below:

   MCML Short   MCML Long  RTF     Service

     0b00        0b0000    0b000   Best Effort
     NA          0b0001    0b001   Reserved
     0b01        0b0010    0b010   Delay Sensitive, no bound
     NA          0b0011    0b011   Reserved
     NA          0b0100    0b100   Reserved
     0b10        0b0101    0b101   Delay Sensitive, 500ms bound
     NA          0b0110    0b110   Delay Sensitive, 250ms bound
     0b11        0b0111    0b111   Network Control

   Table 1: Example Mappings of Classes to Services






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


   Note that MCML has two formats, short sequence numbers, and long
   sequence numbers, that allow for 2 and 4 bits of class identification.
   RTF allows for 3 bits of class identification in all formats.

   Using a default-mapping method of assigning classes to flows in a
   fixed fashion comes with certain limitations. In particular, all flows
   which fall within a particular bucket (are assigned to a particular
   class) will be scheduled against each other at the granularity of
   packets, rather than at the finer grained level of fragments.  This
   can result in overly conservative admission control when the number of
   available classes is small such as in MCML short sequence number
   format.

3.2 Predefined Class Mappings and Prefix Elision