rfc2381.txt

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

Network Working Group                                        M. Garrett
Request for Comments: 2381                                     Bellcore
Category: Standards Track                                     M. Borden
                                                           Bay Networks
                                                            August 1998


               Interoperation of Controlled-Load Service
                    and Guaranteed Service with ATM

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 (1998).  All Rights Reserved.

Abstract

   This document provides guidelines for mapping service classes, and
   traffic management features and parameters between Internet and ATM
   technologies.  The service mappings are useful for providing
   effective interoperation and end-to-end Quality of Service for IP
   Integrated Services networks containing ATM subnetworks.

   The discussion and specifications given here support the IP
   integrated services protocols for Guaranteed Service (GS),
   Controlled-Load Service (CLS) and the ATM Forum UNI specification,
   versions 3.0, 3.1 and 4.0.  Some discussion of IP best effort service
   over ATM is also included.

   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 [1].  (Note,
   in many cases the use of "MUST" or "REQUIRED" reflects our
   interpretation of the requirements of a related standard, e.g., ATM
   Forum UNI 4.0, rsvp, etc.)









Garrett & Borden            Standards Track                     [Page 1]

RFC 2381         Interoperation of CLS and GS with ATM       August 1998


Table of Contents

1.0 Introduction ....................................................  3
    1.1 General System Architecture .................................  4
    1.2 Related Documents ...........................................  7
2.0 Major Protocol Features for Traffic Management and QoS ..........  8
    2.1 Service Category and Bearer Capability ......................  8
        2.1.1 Service Categories for Guaranteed Service .............  9
        2.1.2 Service Categories for Controlled Load ................ 10
        2.1.3 Service Categories for Best Effort .................... 11
    2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions . 11
    2.3 ATM Adaptation Layer ........................................ 13
    2.4 Broadband Low Layer Information ............................. 13
    2.5 Traffic Descriptors ......................................... 13
        2.5.1 Translating Traffic Descriptors for Guaranteed Service. 15
        2.5.2 Translating Traffic Descriptors for Controlled Load
              Service  .............................................. 18
        2.5.3 Translating Traffic Descriptors for Best Effort Service 19
    2.6 QoS Classes and Parameters .................................. 19
    2.7 Additional Parameters -- Frame Discard Mode ................. 22
3.0 Additional IP-Integrated Services Protocol Features ............. 22
    3.1 Path Characterization Parameters for IP Integrated Services . 22
    3.2 Handling of Excess Traffic .................................. 24
    3.3 Use of Guaranteed Service Adspec Parameters and Slack Term .. 25
4.0 Miscellaneous Items ............................................. 26
    4.1 Units Conversion ............................................ 26
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service ....... 27
    5.1 Encoding GS Using Real-Time VBR ............................. 28
    5.2 Encoding GS Using CBR ....................................... 29
    5.3 Encoding GS Using Non-Real-Time VBR ......................... 30
    5.4 Encoding GS Using ABR ....................................... 30
    5.5 Encoding GS Using UBR ....................................... 30
    5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ...................... 31
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service .. 32
    6.1 Encoding CLS Using Non-Real-Time VBR ........................ 32
    6.2 Encoding CLS Using ABR ...................................... 33
    6.3 Encoding CLS Using CBR ...................................... 35
    6.4 Encoding CLS Using Real-Time VBR ............................ 35
    6.5 Encoding CLS Using UBR ...................................... 35
    6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ..................... 35
7.0 Summary of ATM VC Setup Parameters for Best Effort Service ...... 36
    7.1 Encoding Best Effort Service Using UBR ...................... 37
8.0 Security Considerations ......................................... 38
9.0 Acknowledgements ................................................ 38
Appendix 1  Abbreviations ........................................... 39
References .......................................................... 40
Authors' Addresses .................................................. 42
Full Copyright Statement ............................................ 43



Garrett & Borden            Standards Track                     [Page 2]

RFC 2381         Interoperation of CLS and GS with ATM       August 1998


1.0 Introduction

   We consider the problem of providing IP Integrated Services [2] with
   an ATM subnetwork.  This document is intended to be consistent with
   the rsvp protocol [3] for IP-level resource reservation, although it
   applies also in the general case where GS and CLS services are
   supported through other mechanisms.  In the ATM network, we consider
   ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [4, 5, 6].  The
   latter uses the more complete service model of the ATM Forum's TM 4.0
   specification [7, 8].

   This is a complex problem with many facets.  In this document, we
   focus on the service types, parameters and signalling elements needed
   for service interoperation.  The resulting service mappings can be
   used to provide effective end-to-end Quality of Service (QoS) for IP
   traffic that traverses ATM networks.

   The IP services considered are Guaranteed Service (GS) [9] and
   Controlled Load Service (CLS) [10].  We also discuss the default Best
   Effort Service (BE) in parallel with these.  Our recommendations for
   BE are intended to be consistent with RFC 1755 [11], and [12], which
   define how ATM VCs can be used in support of normal BE IP service.
   The ATM services we consider are:

        CBR           Constant Bit Rate
        rtVBR         Real-time Variable Bit Rate
        nrtVBR        Non-real-time Variable Bit Rate
        UBR           Unspecified Bit Rate
        ABR           Available Bit Rate

   In the case of UNI 3.x signalling, where these service are not all
   clearly distinguishable, we identify the appropriate available
   services.

   We recommend the following service mappings, since they follow most
   naturally from the service definitions:

        Guaranteed Service    ->     CBR or rtVBR
        Controlled Load       ->     nrtVBR or ABR (with a minimum
                                     cell rate)
        Best Effort           ->     UBR or ABR

   For completeness, however, we provide detailed mappings for all
   service combinations in Sections 5, 6, 7 and identify how each meets
   or fails to meet the requirements of the higher level IP services.
   The reason for not restricting mappings to the most obvious or
   natural ones is that we cannot predict how widely available all of
   these services will be as ATM deployment evolves.  A number of



Garrett & Borden            Standards Track                     [Page 3]

RFC 2381         Interoperation of CLS and GS with ATM       August 1998


   differences in service definitions, such as the treatment of packets
   in excess of the flow traffic descriptor, make service mapping a
   relatively complicated subject.

   The remainder of this introduction provides a general discussion of
   the system configuration and other assumptions.  Section 2 considers
   the relevant ATM protocol elements and the corresponding features of
   Guaranteed, Controlled Load and Best Effort services (the latter
   being the default "service").  Section 3 discusses a number of
   remaining features of the IP services and how they can be handled on
   an ATM subnetwork.  Section 4 addresses the conversion of traffic
   descriptors to account for ATM-layer overheads.  Section 5 gives the
   detailed VC setup parameters for Guaranteed Service, and considers
   the effect of using each of the ATM service categories.  Section 6
   provides a similar treatment for Controlled Load Service.  Section 7
   considers Best Effort service.

   This document is only a part of the total solution to providing the
   interworking of IP integrated services with ATM subnetworks.  The
   important issue of VC management, including flow aggregation, is
   considered in [13, 14, 15].  We do not consider how routing, QoS
   sensitive or not, interacts with the use of ATM VCs.  We expect that
   a considerable degree of implementation latitude will exist, even
   within the guidelines presented here.  Many aspects of interworking
   between IP and ATM will depend on economic factors, and will not be
   subject to standardization.

1.1 General System Architecture

   We assume that the reader has a general working knowledge of IP, rsvp
   and ATM protocols.  The network architecture we consider is
   illustrated in Figure 1.  An IP-attached host may send unicast
   datagrams to another host, or may use an IP multicast address to send
   packets to all of the hosts which have "joined" the multicast "tree".
   In either case, a destination host may then use RSVP to establish
   resource reservation in routers along the internet path for the data
   flow.

   An ATM network lies in the path (chosen by the IP routing), and
   consists of one or more ATM switches.  It uses SVCs to provide both
   resources and QoS within the ATM cloud.  These connections are set
   up, added to (in the case of multipoint trees), torn down, and
   controlled by the edge devices, which act as both IP routers and ATM
   interfaces, capable of initiating and managing VCs across the ATM
   user-to-network (UNI) interface.  The edge devices are assumed to be
   fully functional in both the IP int-serv/RSVP protocols and the ATM
   UNI protocols, as well as translating between them.




Garrett & Borden            Standards Track                     [Page 4]

RFC 2381         Interoperation of CLS and GS with ATM       August 1998


                                 ATM Cloud
                            -----------------
        H ----\            (                 )       /------- H
        H ---- R -- R -- E-( X  --  X  --  X )-E -- R -- R -- H
        H ----/     |      (                 )       \
                    |       -----------------         \------ H
        H ----------R

            Figure 1:  Network Architecture with Hosts (H),
                       Routers (R), Edge Devices (E) and ATM
                       Switches (X).


   When considering the edge devices with respect to traffic flowing
   from source to destination, the upstream edge device is called the
   "ingress" point and the downstream device the "egress" point.  The
   edge devices may be considered part of the IP internet or part of the
   ATM cloud, or both.  They process RSVP messages, reserve resources,
   and maintain soft state (in the control path), and classify and
   schedule packets (in the data path).  They also initiate ATM
   connections by signalling, and accept or refuse connections signalled
   to them.  They police and schedule cells going into the ATM cloud.
   The service mapping function occurs when an IP-level reservation
   (RESV message) triggers the edge device to translate the RSVP service
   requirements into ATM VC (UNI) semantics.

   A range of VC management policies are possible, which determine
   whether a flow initiates a new VC or joins an existing one.  VCs are
   managed according to a combination of standards and local policy
   rules, which are specific to either the implementation (equipment) or
   the operator (network service provider).  Point-to-multipoint
   connections within the ATM cloud can be used to support general IP
   multicast flows.  In ATM, a point to multipoint connection can be
   controlled by the source (or root) node, or a leaf initiated join
   (LIJ) feature in ATM may be used.  The topic of VC management is
   considered at length in other ISSLL documents [13, 14, 15].

   Figure 2 shows the functions of an edge device, summarizing the work