rfc1821.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   To motivate the following discussion, this section walks through an
   example of what might happen when an application with a certain set
   of QoS needs starts up. For this example, we will use the fourth case
   mentioned above, i.e., two hosts connected to non-ATM networks,
   making use of an ATM backbone.





Borden, et al                Informational                      [Page 5]

RFC 1821          Real-time Service in IP-ATM Networks       August 1995


   A generic discussion of this situation is made difficult by the fact
   that the reservation of resources in the Internet may be sender or
   receiver initiated, depending on the specifics of the setup protocol.
   We will attempt to gloss over this distinction for now, although we
   will return to it in Section 4. We will assume a unicast application
   and that the traffic characteristics and the QoS requirements (such
   as delay, loss, throughput) of the application are known to at least
   one host.  That host launches a request for the desired QoS and a
   description of the expected traffic into the network; at some point
   this request hits a router at the edge of the ATM network. The router
   must examine the request and decide if it can use an existing
   connection over the ATM network to honor the request or whether it
   must establish a new connection. In the latter case, it must use the
   QoS and traffic characterizations to decide what sort of ATM
   connection to open and to describe the desired service to the ATM
   network. It must also decide where to open the connection to. Once
   the connection is opened, the request is forwarded across the ATM
   network to the exit router and then proceeds across the non-ATM part
   of the network by the normal means.

   We can see from the above description that there are several sets of
   issues to be discussed:

   * How does the IP service model, with certain service classes and
     associated styles of traffic and QoS characterization, map onto
     the ATM service model?

   * How does the IP reservation model (whatever it turns out to be) map
     onto ATM signalling?

   * How does IP over ATM routing work when service quality is added to
     the picture?

   These issues will be discussed in the following sections.

3.0 Service Model Issues

   There are several significant differences between the ways in which
   IP and ATM will provide QoS.  When IP commits to provide a certain
   QoS to an application according to the Internet service model, it
   must be able to request an appropriate QoS from the ATM network using
   the ATM service model. Since these service models are by no means the
   same, a potentially complex mapping must be performed for the IP
   layer to meet its commitments.  The details of the differences
   between ATM and IP and the problems presented by these differences
   are described below.





Borden, et al                Informational                      [Page 6]

RFC 1821          Real-time Service in IP-ATM Networks       August 1995


   We may think of a real-time service model as containing the following
   components:

   * a way to characterize traffic (sometimes called the Tspec);

   * a way to characterize the desired quality of service (the Rspec).

   We label these components as traffic characterization and QoS
   characterization.  Each of these components is discussed in turn in
   the following sections.

   As well as these aspects of the service model, both ATM and IP will
   have a number of mechanisms by which the model is implemented. The
   mechanisms include admission control, policing, and packet
   scheduling. A particularly important mechanism is the one by which
   end-nodes communicate their QoS needs and traffic characteristics to
   the network, and the network communicates admission control decisions
   to the end-nodes. This is referred to as resource reservation or
   signalling, and is the subject of Section 4. In fact, it seems to be
   the only mechanism where significant issues of IP/ATM integration
   arise. The details of admission control, policing and packet
   scheduling are largely internal to a single network element and we do
   not foresee significant problems caused by the integration of IP and
   ATM. For example, while there may be plenty of challenges in
   designing effective approaches to admission control for both IP and
   ATM, it is not apparent that there are any special challenges for the
   IP over ATM environment. As the walk-through of Section 2.3
   described, a reservation request from a host would at some point
   encounter the edge of the ATM cloud. At this point, either a new
   connection needs to be set up across the ATM cloud, or the router can
   decide to carry the requested traffic over an existing virtual
   circuit. If the ATM cloud cannot create a new connection as
   requested, this would presumably result in an admission control
   failure which would cause the router to deny the reservation request.

3.1 Traffic Characterization

   The traffic characterization provided by an application or user is
   used by the network to make decisions about how to provide the
   desired quality of service to this application and to assess the
   effect the new flow will have on the service provided to existing
   flows. Clearly this information feeds into the admission control
   decision process.

   In the Internet community, it is assumed that traffic will in general
   be bursty and that bursty traffic can be characterized by a `token
   bucket'.  While ATM does not expect all traffic to be bursty (the
   Continuous Bit Rate class being defined specifically for non-bursty



Borden, et al                Informational                      [Page 7]

RFC 1821          Real-time Service in IP-ATM Networks       August 1995


   traffic), it uses an essentially equivalent formulation for the
   characterization of traffic that is bursty, referred to as the
   Generic Cell Rate Algorithm (GCRA). However, ATM in some classes also
   requires specification of peak cell rate, whereas peak rates are not
   currently included in the IP traffic characterizations. It may be
   possible to use incoming interface speeds to determine an approximate
   peak rate.

   One of the functions that must be performed in order to carry IP
   traffic over an ATM network is therefore a mapping from the
   characterization of the traffic as supplied to IP to a
   characterization that is acceptable for ATM. While the similarity of
   the two characterizations suggests that this is straightforward,
   there is considerable flexibility in the mapping of parameters from
   IP to ATM. As an extreme example, a router at the edge of an ATM
   cloud that expects to receive bursts of IP packets on a non-ATM
   interface, with the bursts described by some token bucket parameters,
   could actually inject ATM cells at a constant rate into the ATM
   network. This may be achieved without significant buffering if the
   ATM link speed is faster than the point-to-point link speed;
   alternatively, it could be achieved by buffering out the burstiness
   of the arriving traffic. It seems more reasonable to map an IP flow
   (or a group of flows) with variable bandwidth requirements onto an
   ATM connection that accommodates variable bit rate traffic.
   Determining how best to map the IP traffic to ATM connections in this
   way is an area that warrants investigation.

   A potential complication to this process is the fact that the token
   bucket parameters are specified at the edge of the IP network, but
   that the specification of the GCRA parameters at the entry to an ATM
   network will frequently happen at a router in the middle of an IP
   network. Thus the actual burstiness that is encountered at the router
   may differ from that described by the IP token bucket parameters, as
   the burstiness changes as the traffic traverses a network. The
   seriousness of this problem needs to be understood to permit
   efficient resource utilization.

3.2 QoS Characterization

   In addition to specifying the traffic that they will submit to the
   network, applications must specify the QoS they require from the
   network. Since the goal is to carry IP efficiently over ATM networks,
   it is necessary to establish mechanisms by which QoS specifications
   for IP traffic can be translated into QoS specifications that are
   meaningful for an ATM network.






Borden, et al                Informational                      [Page 8]

RFC 1821          Real-time Service in IP-ATM Networks       August 1995


   The proposed method of QoS specification for the Internet is to
   specify a `service class' and some set of parameters, depending on
   the service class. The currently proposed service classes are

   *  guaranteed, which provides a mathematically guaranteed delay
      bound [23];

   *  predictive delay, which provides a probabilistic delay bound
      [24];and

   *  controlled delay, which merely tries to provide several levels of
      delay which applications may choose between [25].

   These are in addition to the existing `best-effort' class. More IP
   service classes are expected in the future. ATM has five service
   classes:

   *  CBR (constant bit rate), which emulates a leased line, providing
      very tightly constrained delay and designed for applications which
      can use a fixed bandwidth pipe;

   *  VBR (variable bit rate)-real-time which attempts to constrain delay
      for applications whose bandwidth requirements vary;

   *  VBR-non-real-time, intended for variable bandwidth applications
      without tight delay constraints;

   *  UBR (unspecified bit rate) which most closely approximates the best
      effort service of traditional IP;

   *  ABR (available bit rate) which uses a complex feedback mechanism
      to control loss.

   Each class requires some associated parameters to be specified, e.g.,
   CBR requires a peak rate. Observe that these classes are by no means
   in direct correspondence with the IP classes. In some cases, ATM
   classes require parameters which are not provided at the IP level,
   such as loss rate, to be specified. It may be necessary to assume
   reasonable default values in these cases.

   The major problem here is this: given traffic in a particular IP
   service class with certain QoS parameters, how should it be sent
   across an ATM network in such a way that it both meets its service
   commitments and makes efficient use of the ATM network's resources?
   For example, it would be possible to transport any class of IP
   traffic over an ATM network using the constant bit rate (CBR) ATM
   class, thus using the ATM network like a point-to-point link. This
   would allow IP to meet its service commitments, but would be an



Borden, et al                Informational                      [Page 9]

RFC 1821          Real-time Service in IP-ATM Networks       August 1995


   inefficient use of network resources in any case where the IP traffic
   was at all bursty (which is likely to be most cases). A more
   reasonable approach might be to map all IP traffic into a variable
   bit rate (VBR) class; certainly this class has the flexibility to
   accommodate bursty IP traffic more efficiently than CBR.

   At present, the IETF is not working on any service classes in which
   loss rate is considered as part of the QoS specification. As long as
   that is the case, the fact that ATM allows target loss rates to be
   specified is essentially not an issue. However, we may certainly
   expect that as the IP service model is further refined, service
   classes that include specifications of loss may be defined. At this
   point, it will be necessary to be able to map between loss rates at
   the IP level and loss rates at the ATM level. It has already been
   shown that relatively small loss rates in an ATM network can
   translate to high loss rates in IP due to the fact that each lost
   cell can cause the loss of an entire IP packet. Schemes to mitigate
   this problem, which include the proposed approach to implementing the
   ABR class, as well as other solutions [22], have been proposed. This
   is clearly likely to be an important issue in the future.

4.0 Resource Reservation Styles

   ATM uses a signalling protocol (Q.2931) both to establish virtual
   connections and to allocate resources to those connections. It has
   many of the characteristics of a 'conventional' signalling protocol,
   such as being sender-driven and relying on hard-state in switches to
   maintain connections. Some of the key characteristics are listed in
   the table below. In the current standards, the QoS associated with a
   connection at setup time cannot be changed subsequently (i.e., it is