rfc1755.txt

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

Network Working Group                                           M. Perez
Request for Comments: 1755                                           ISI
Category: Standards Track                                        F. Liaw
                                                      FORE Systems, Inc.
                                                               A. Mankin
                                                              E. Hoffman
                                                                     ISI
                                                             D. Grossman
                                                          Motorola Codex
                                                                A. Malis
                                                    Ascom Timeplex, Inc.
                                                           February 1995


                 ATM Signaling Support for IP over 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.

Abstract

   This memo describes the ATM call control signaling exchanges needed
   to support Classical IP over ATM implementations as described in RFC
   1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services
   as specified in the ATM Forum User-Network Interface (UNI)
   Specification Version 3.1 [ATMF94]. IP over ATM implementations
   utilize the services of local ATM signaling entities to establish and
   release ATM connections. This memo should be used to define the
   support required by IP over ATM implementations from their local ATM
   signaling entities.

   This document is an implementors guide intended to foster
   interoperability among RFC 1577, RFC 1483, and UNI ATM signaling.  It
   applies to IP hosts and routers which are also ATM endsystems and
   assumes ATM networks that completely implement the ATM Forum UNI
   Specification Version 3.1. Unless explicitly stated, no distinction
   is made between the Private and Public UNI.









Perez, Liaw, Mankin, Hoffman, Grossman & Malis                  [Page 1]

RFC 1755         ATM Signaling Support for IP over ATM     February 1995


   UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has
   been produced by the ATM Forum, largely for reasons of alignment with
   Recommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are
   several changes that make the two versions incompatible. A
   description of how to support IP over ATM using UNI 3.0 is found in
   Appendix B.

Table of Contents

     1.  Conventions ...............................................   3
     2.  Overview ..................................................   3
     3.  Use of Protocol Procedures ................................   4
         3.1  VC Establishment .....................................   4
         3.2  Multiprotocol Support on VCs  ........................   4
         3.3  Support for Multiple VCs .............................   5
         3.4  VC Teardown...........................................   6
     4.  Overview of UNI Call Setup Signaling ......................   6
     5.  Overview of Call Establishment Message Content ............   7
     6.  Information Elements with Endpoint Significance ...........   8
         6.1  ATM Adaptation Layer Parameters ......................   8
         6.2  Broadband Low Layer Information  .....................   8
              6.2.1  Framework for Protocol Layering ...............   9
     7.  Information Elements with Significance to the ATM Network .  11
         7.1  ATM Traffic Descriptor ...............................  11
         7.2  Broadband Bearer Capability ..........................  15
         7.3  QoS Parameter.........................................  16
         7.4  ATM Addressing Information ...........................  16
     8.  Dealing with Failure of Call Establishment.................  18
     9. Security Considerations ....................................  18
     10. Open Issues ...............................................  19
     11. Acknowledgements...........................................  19
     12. References ................................................  19
     13. Authors' Addresses ........................................  20
     Appendix A  Sample Signaling Messages .........................  22
     Appendix B  IP over ATM using UNI 3.0 Signaling ...............  25
     Appendix C  Combinations of Traffic Related Parameters ........  27
     Appendix D  Frame Relay Interworking ..........................  28














Perez, Liaw, Mankin, Hoffman, Grossman & Malis                  [Page 2]

RFC 1755         ATM Signaling Support for IP over ATM     February 1995


1.  Conventions

The following language conventions are used in the items of
specification in this document:

   o   MUST, SHALL, or MANDATORY -- the item is an absolute requirement
       of the specification.

   o   SHOULD or RECOMMEND -- this item SHOULD generally be followed for
       all but exceptional circumstances.

   o   MAY or OPTIONAL -- the item is truly optional and MAY be followed
       or ignored according to the needs of the implementor.

2.  Overview

   In a Switched Virtual Connection (SVC) environment, ATM virtual
   channel connections (VCCs) are dynamically established and released
   as needed. This is accomplished using the ATM call/connection control
   signaling protocol, which operates between ATM endsystems and the ATM
   network.  The signaling entities use the signaling protocol to
   establish and release calls (association between ATM endpoints) and
   connections (VCCs).  Signaling procedures include the use of
   addressing to locate ATM endpoints and allocation of resource in the
   network for the connection.  It also provides indication and
   negotiation between ATM endpoints for selection of end-to-end
   protocols and their parameters.  This memo describes how the
   signaling protocol is used in support of IP over ATM, and, in
   particular, the information exchanged in the signaling protocol to
   effect this support.

   IP address to ATM address resolution and routing issues are not in
   the scope of this memo, and are treated as part of IP in figure 1.

              +--------------+     +------+     +----------+
              |              |     |      |<--->| IP / ARP |
              |              |<--->| This |     | RFC 1577 |
              |    ATM       |     | Memo |     +----------+
              |  signaling   |     |      |<--->| RFC 1483 |
              |              |     +------+     +----------+
              |              |   -------------> |  AAL 5   |
              |              |                  +----------+
              |              |   -------------> |   ATM    |
              +--------------+                  +----------+

                                  Figure 1.
                 Relationship of this memo to IP, RFC 1483,
                         ATM signaling, ATM and AAL5



Perez, Liaw, Mankin, Hoffman, Grossman & Malis                  [Page 3]

RFC 1755         ATM Signaling Support for IP over ATM     February 1995


3.  Use of Protocol Procedures

   The following requirements are motivated to provide implementation
   guidelines on how multiple ATM connections between peer systems
   SHOULD be managed, to prevent connection thrashing and related
   problems.

3.1.  VC Establishment

   The owner of an existing VCC is defined to be the entity within the
   ATM endsystem that establishes the connection.  An ATM endsystem MAY
   establish an ATM call when it has a datagram to send and either there
   is no existing VCC that it can use for this purpose, it chooses not
   to use an existing VCC, (e.g., for reasons of route optimization or
   quality of service), or the VCC owner does not allow sharing.

   To reduce the latency of the address resolution procedure at the
   called station, the following procedure MAY be used:

   If a VCC is established using the LLC/SNAP encapsulation, the calling
   endstation of the VCC MAY send an InARP_REQUEST to the called
   endstation after the connection is established (i.e. received a
   CONNECT message) and before the calling endstation sends the first
   data packet.  In addition, the calling endstation MAY send its data
   packets without waiting for the InARP_REPLY. An endstation MAY
   respond, generate, and manage its ATMARP table according to the
   procedures specified in RFC1293 [BRAD92], Section 7, "Protocol
   Operation", during the life time of the VCC.

   To avoid establishing multiple VCCs to the same endstation, a called
   endstation MAY associate the calling party number in the SETUP
   message with the established VCC. This VCC MAY be used to transmit
   data packets destined to a endstation whose ATMARP resolution results
   in an ATM address that is the same as the associated calling party
   number.  Sharing of VCCs is subject to the policies configured at the
   endstation as described in section 4.3 of this recommendation.

3.2.  Multiprotocol Support on VCs

   When two ATM endsystems run multiple protocols, an ATM connection MAY
   be shared among two or more datagram protocol entities, as long as
   the VCC owner allows sharing and if the encapsulation allows proper
   multiplexing and demultiplexing (i.e. the LLC/SNAP encapsulation).
   This indication of sharing a VCC MAY be by configuration or via an
   API.  Similarly, the Internet layer supports multiplexing of multiple
   end-to-end transport sessions.  To properly detect idle connections
   while sharing a VCC among more than one higher layer protocol
   entities, the ATM endsystem MUST monitor the traffic at the lowest



Perez, Liaw, Mankin, Hoffman, Grossman & Malis                  [Page 4]

RFC 1755         ATM Signaling Support for IP over ATM     February 1995


   multiplexing layer.

3.3.  Support for Multiple VCs

   An ATMARP server or client MAY establish an ATM call when it has a
   datagram to send and either there is no existing VCC that it can use
   for this purpose, it chooses not to use an existing VCC, or the owner
   of the VCC does not allow sharing. Note that there might be VCCs to
   the destination which are used for IP, but an ARP server might prefer
   to use a separate VCC for ARP only. The ATMARP server or client MAY
   maintain or release the call as specified in RFC 1577. However, if
   the VCC is shared among several protocol entities, the ATMARP client
   or server SHALL NOT disconnect the call as suggested in RFC 1577.

   Systems MUST be able to support multiple connections between peer
   systems (without regard to which peer system initiated each
   connection).  They MAY be configured to only allow one such
   connection at a time.

   If a receiver accepts more than one call from a single source, that
   receiver MUST then accept incoming PDUs on the additional
   connection(s), and MAY transmit on the additional connections.
   Receivers SHOULD NOT accept the incoming call, only to close the
   connection or ignore PDUs from the connection.

   Because opening multiple connections is specifically allowed,
   algorithms to prevent connection call collision, such as the one
   found in section 8.4.3.5 of ISO/IEC 8473 [ISO8473], MUST NOT be
   implemented.

   While allowing multiple connections is specifically desired and
   allowed, implementations MAY choose (by configuration) to permit only
   a single connection to some destinations.  Only in such a case, if a
   colliding incoming call is received while a call request is pending,
   the incoming call MUST be rejected.  Note that this MAY result in a
   failure to establish a connection.  In such a case, each system MUST
   wait at least a configurable collision retry time in the range 1 to
   10 seconds before retrying.  Systems MUST add a random increment,
   with exponential backoff.












Perez, Liaw, Mankin, Hoffman, Grossman & Malis                  [Page 5]

RFC 1755         ATM Signaling Support for IP over ATM     February 1995


3.4.  VC Teardown

   Either endsystem MAY close a connection. If the connection is closed
   or reset while a datagram is being transmitted, the datagram is lost.
   Systems SHOULD be able to configure a minimum holding time for
   connections to remain open as long as the endpoints are up.  (Note
   that holding time, the time the connection has been open, differs
   from idle time.)  A suggested default value for the minimum holding
   time is 60 seconds.

   Because some public networks MAY charge for connection holding time,
   and connections MAY be a scarce resource in some networks or
   endsystems, each system implementing a Public ATM UNI interface MUST
   support the use of a configurable inactivity timer to clear
   connections that are idle for some period of time.  The timer's range
   SHOULD include a range from a small number of minutes to "infinite".
   A default value of 20 minutes is RECOMMENDED. Systems which only
   implement a Private ATM UNI interface SHOULD support the inactivity
   timer.  If implemented, the inactivity timer MUST monitor traffic in
   both directions of the connection.

4.  Brief Overview of UNI Call Setup Signaling Procedures and Messages

   This section provides a summary of point-to-point signaling
   procedures. Readers are referred to [ATMF93].

   UNI signaling messages used for point-to-point call/connection
   control are the following:

               Call Setup                       Call Release
               ----------                       ------------
                 SETUP                             RELEASE
                 CALL PROCEEDING                   RELEASE COMPLETE
                 CONNECT
                 CONNECT ACKNOWLEDGE

   An ATM endpoint initiates a call request by sending a SETUP message
   to the network. The network processes the call request to determine
   if the call can be progressed. If so, the network indicates the value
   of the newly allocated VPCI/VCI in its first response to the the
   SETUP message, which is either a CALL PROCEEDING or CONNECT message.