rfc1821.txt

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

Network Working Group                                          M. Borden
Request for Comments: 1821                                    E. Crawley
Category: Informational                                     Bay Networks
                                                                B. Davie
                                                                Bellcore
                                                              S. Batsell
                                                                     NRL
                                                             August 1995


  Integration of Real-time Services in an IP-ATM Network Architecture

Status of the Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind. Distribution of
   this memo is unlimited.

Abstract

   The IETF is currently developing an integrated service model which is
   designed to support real-time services on the Internet.
   Concurrently, the ATM Forum is developing Asynchronous Transfer Mode
   networking which similarly provides real-time networking support. The
   use of ATM in the Internet as a link layer protocol is already
   occurring, and both the IETF and the ATM Forum are producing
   specifications for IP over ATM. The purpose of this paper is to
   provide a clear statement of what issues need to be addressed in
   interfacing the IP integrated services environment with an ATM
   service environment so as to create a seamless interface between the
   two in support of end users desiring real-time networking services.

Table of Contents

   1.0 Introduction                                                2
   2.0 Problem Space Overview                                      3
   2.1 Initial Assumptions                                         3
   2.2 Topologies Under Consideration                              4
   2.3 Providing QoS in IP over  ATM - a walk-though               5
   3.0 Service Model Issues                                        6
   3.1 Traffic Characterization                                    7
   3.2 QoS Characterization                                        8
   4.0 Resource Reservation Styles                                10
   4.1 RSVP                                                       10
   4.2 ST-II                                                      13
   4.3 Mapping IP flows to ATM Connections                        15
   5.0 End System Issues                                          16
   6.0 Routing Issues                                             16



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


   6.1 Multicast routing                                          17
   6.2 QoS Routing                                                17
   6.3 Mobile Routing                                             18
   7.0 Security Issues                                            19
   8.0 Future Directions                                          20
   9.0 References                                                 22
   10.0 Authors' Addresses                                        24

1.0 Introduction

   The traditional network service on the Internet is best-effort
   datagram transmission. In this service, packets from a source are
   sent to a destination, with no guarantee of delivery. For those
   applications that require a guarantee of delivery, the TCP protocol
   will trade packet delay for correct reception by retransmitting those
   packets that fail to reach the destination. For traditional
   computer-communication applications such as FTP and Telnet in which
   correct delivery is more important than timeliness, this service is
   satisfactory. However, a new class of application which uses multiple
   media (voice, video, and computer data) has begun to appear on the
   Internet. Examples of this class of application are video
   teleconferencing, video-on-demand, and distributed simulation. While
   these applications can operate to some extent using best-effort
   delivery, trading packet delay for correct reception is not an
   acceptable trade-off. Operating in the traditional mode for these
   applications results in reduced quality of the received information
   and, potentially, inefficient use of bandwidth. To remedy this
   problem the IETF is developing a real-time service environment in
   which multiple classes of service are offered [6]. This environment
   will greatly extend the existing best-effort service model to meet
   the needs of multimedia applications with real-time constraints.

   At the same time that this effort is underway in the IETF,
   Asynchronous Transfer Mode (ATM) is being developed, initially as a
   replacement for the current telephone network protocols, but more
   recently as a link-layer protocol for computer communications. As it
   was developed from the beginning with telephone voice applications in
   mind, a real-time service environment is an integral part of the
   protocol. With the approval of UNI 3.1 by the ATM Forum, the ATM
   standards now have several categories of service. Given the wide
   acceptance of ATM by the long-line carriers, the use of ATM in the
   Internet is, if not guaranteed, highly likely. The question now
   becomes, how can we successfully interface between the real-time
   services offered by ATM and the new,integrated service environment
   soon to be available in the IP protocol suite. The current IP over
   ATM standards assume no real-time IP protocols. It is the purpose of
   this RFC to clearly delineate what the issues are in integrating
   real-time services in an IP-over-ATM network [10,15,19,20,21].



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


   In the IP-over-ATM environment, as in many others, multicast routing
   adds an additional set of challenges. While the major focus of this
   paper is quality of service (QoS) issues, it is unwise at best to
   ignore multicast when considering these issues, especially since so
   many of the applications that motivate the provision of real time QoS
   also require efficient multicast support. We will therefore try to
   keep considerations of multicast in the foreground in the following
   discussion.

   One of the primary motivations for this document is a belief by the
   authors that ATM should, if possible, be used as more than a leased
   line replacement. That is to say, while it is possible for the
   Internet to be overlaid on constant bit rate (CBR), permanent virtual
   circuits (PVCs), thus reducing IP over ATM to a previously solved
   problem, we believe that this is unlikely to be the most efficient
   way to use ATM services as they are offered by carriers or as they
   appear in LANs. For example, a carrier offering a CBR service must
   assume that the peak bit rate can be used continuously with no
   degradation in quality and so resources must be allocated to the
   connection to provide that service, even if the peak rate is in fact
   rarely used. This is likely to make a CBR service more expensive that
   a variable bit rate service of the same peak capacity.  Another way
   to view this is that the new IP service model will allow us to
   associate information about the bandwidth requirements of
   applications with individual flows; surely it is not wise to discard
   this information when we request a service from an ATM subnet.

   While we believe that there is a range of capabilities in ATM
   networks that can be effectively used by a real-time Internet, we do
   not believe that just because ATM has a capability, the Internet must
   use it. Thus, our goal in this RFC is to begin to explore how an
   Internet with real time service capability might make most effective
   use of ATM networks.  Since there are a number of problems to be
   resolved to achieve this effective use, our major goal at this point
   is to describe the scope of the problems that need to be addressed.

2.0 Problem Space Overview

   In this section we aim to describe in high level terms the scope of
   the problem that will be explored in more detail in later sections.

2.1 Initial Assumptions

   We begin by assuming that an Integrated Services Internet, i.e., an
   Internet with a range of qualities of service to support both real-
   time and non-real-time applications, will eventually happen. A number
   of working groups are trying to make this happen, notably




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


   * the Integrated Services group (int-serv), which is working to define
     a new IP service model, including a set of services suited to a
     range of real-time applications;

   * the Resource reservation Setup Protocol group (rsvp), which is
     defining a resource reservation protocol [7] by which the
     appropriate service for an application can be requested from the
     network;

   * the Internet Streams Protocol V2 group (ST-II), which is updating
     [27], a stream-oriented internet protocol that provides a range of
     service qualities.

   In addition, the IETF IP over ATM working group and the ATM Forum
   Multiprotocol over ATM group are working to define a model for
   protocols to make use of the ATM layer.

   Since these groups have not yet generated standards, we will need to
   do some amount of extrapolation to predict the problems that may
   arise for IP over ATM. We also assume that the standards being
   developed in the ATM Forum will largely determine the service model
   for ATM. Again, some extrapolation may be needed. Given these
   assumptions, this paper aims to explore ways in which a future
   Integrated Services Internet might make effective use of ATM as it
   seems likely to be deployed.

2.2 Topologies Under Consideration

   Figure 1 shows a generic internetwork that includes ATM and non-ATM
   subnetworks. This paper aims to outline the problems that must be
   addressed to enable suitable quality of service to be provided end-
   to-end across such a network. The problem space, therefore, includes

   * communication across an 'ATM-only' network between two hosts
     directly connected to the ATM network;

   * communication between ATM-connected hosts which involves traversing
     some non-ATM subnets;

   * communication between a host on a non-ATM subnet and a host directly
     connected to ATM;

   * communication between two hosts, neither of which has a direct ATM
     connection, but which may make use of one or more ATM networks for
     some part of the path.






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


                     [H]
                      |                           [H]
              ________|________________________    |
              |                                |   |
      ________|__                        ______|___|____
      |         |                        |             |
      |  ATM   [R]                      [R]  ATM       |
      |  Cloud  |                        |   Cloud     |___[H]
      |         |     Non-ATM Internet   |             |
      |         |                       [R]            |
      |________[R]                       |_____________|
       |      |                                |
       |      |                                |
      [H]     |________________________________|
                                        |
                                        |
                                       [H]

   [H] = Host
   [R] = Router
                              Figure 1

   In the last case, the entities connected to the ATM network are IP
   routers, and it is their job to manage the QoS provided by the ATM
   network(s) in such a way that the desired end-to-end QoS is provided
   to the hosts. While we wish to describe the problem space in a way
   that covers all of these scenarios, the last is perhaps the most
   general, so we will use it for most illustrative purposes. In
   particular, we are explicitly not interested in ways of providing QoS
   that are applicable only to a subset of these situations. We claim
   that addressing these four situations is sufficiently general to
   cover other situations such as those in which several ATM and non-ATM
   networks are traversed.

   It is worth mentioning that the ATM networks in this case might be
   local or wide area, private or public. In some cases, this
   distinction may be significant, e.g., because there may be economic
   implications to a particular approach to providing QoS.

2.3 Providing QoS in IP over ATM - a walk-through