rfc1755.txt

RFC 的详细文档！

                 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.
   If a call cannot be accepted, by the network or destination ATM end-
   point, a RELEASE COMPLETE is sent.  At the destination ATM endpoint,
   the network offers the call using the SETUP message.  If the
   destination endpoint is able to accept the call, it responds with a
   CONNECT message (which MAY be preceded by a CALL PROCEEDING);
   otherwise, it sends a RELEASE COMPLETE message.  See Appendix A,
   Section 2 for guidance on the use of the CALL PROCEEDING message.



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


   Call release can be initiated by either endpoint or (rarely) by the
   network.  When an endpoint wishes to release a call, it sends a
   RELEASE message to the network. The network responds with a RELEASE
   COMPLETE message, frees up resources associated with the call, and
   initiates clearing toward the other endpoint. The network initiates
   clearing by sending a RELEASE message to the ATM endpoint, which
   reponds by sending a RELEASE COMPLETE message.  Upon receipt of the
   RELEASE COMPLETE message, the network frees any resources associated
   with the call.

5.  Overview of Call Establishment Message Content

   Signaling messages are structured to contain mandatory and optional
   variable length information elements (IEs).  IEs are further
   subdivided into octet groups, which in turn are divided into fields.
   IEs contain information related to the call, which is relevant to the
   network, the peer endpoint or both.  Selection of optional IEs and
   the content of mandatory and optional IEs in a call establishment
   message determines the parties to and nature of the communication
   over the ATM connection. For example, the call establishment message
   for a call which will be used for constant bitrate video over AAL 1
   will have different contents than a call which will be used for IP
   over AAL 5.

   A SETUP message which establishes an ATM connection to be used for IP
   and multiprotocol interconnection calls MUST contain the following
   IEs:

        AAL Parameters
        ATM Traffic Descriptor
        Broadband Bearer Capability
        Broadband Low Layer Information
        QoS Parameter
        Called Party Number
        Calling Party Number

   and MAY, under certain circumstance contain the following IEs:

        Calling Party Subaddress
        Called Party Subaddress
        Transit Network Selection

   In UNI 3.1, the AAL Parameters and the Broadband Low Layer
   Information IEs are optional in a SETUP message.  However, in support
   of IP over ATM these two IEs MUST be included. Appendix A shows an
   example SETUP message coded in the manner indicated in this memo.





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


6.  Information Elements with Endpoint to Endpoint Significance

   This section describes the coding of, and procedures surrounding,
   information elements in a SETUP message with significance only to the
   endpoints of an ATM call supporting IP.

6.1.  ATM Adaptation Layer Parameters

   The AAL Parameters IE (see section 5.4.5.5 and Annex F of [ATMF93])
   carries information about the ATM Adaptation Layer (AAL) to be used
   on the connection. RFC 1483 specifies encapsulation of IP over AAL 5.
   Thus, AAL 5 MUST be indicated in the "AAL type" field.

   Coding and procedure related to the 'Forward and Backward Maximum
   CPCS-SDU Size' fields are discussed in [ATKI94]. Values may range
   from zero to 65,535. Although the default IP over AAL 5/ATM is 9188
   bytes, endstations are encouraged to support MTU sizes up to and
   including 64k.

   Ordinarily, no Service Specific Convergence Sublayer (SSCS) will be
   used for multiprotocol interconnect over AAL5.  Therefore, the SSCS
   'type' field SHOULD be absent or, if present, coded to Null SSCS.

          Format and field values of AAL Parameters IE

          ----------------------------------------------------------
          | aal_parameters                                         |
          ----------------------------------------------------------
          |  aal_type                    5        (AAL 5)          |
          |  fwd_max_sdu_size_identifier 140                       |
          |  fwd_max_sdu_size            65,535   (desired IP MTU) |
          |  bkw_max_sdu_size_identifier 129                       |
          |  bkw_max_sdu_size            65,535   (desired IP MTU) |
          |  sscs_type identifier        132                       |
          |  sscs_type                   0        (null SSCS)      |
          ----------------------------------------------------------

6.2.  Broadband Low Layer Information

   Selection of an encapsulation to support IP over an ATM VCC is done
   using the Broadband Low Layer Information (B-LLI) IE, along with the
   AAL Parameters IE, and the B-LLI negotiation procedure.

   RFC 1577 specifies LLC/SNAP as the default encapsulation.  This
   encapsulation MUST be implemented by all endstations.  LLC
   encapsulation MUST be signaled in the B-LLI as shown below.
   Signaling indication of other encapsulations is discussed in Appendix
   D, Section 4.  Note that only LLC is indicated in the B-LLI. It is up



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


   to the LLC layer to look into the encapsulation header of the packets
   following call setup. A B-LLI specifying both LLC and a layer_3_id
   SNAP layer is not recommended.  If in those packets, the SNAP header
   indicates IP, it is the LLC layer's job to hand the packets up to IP.

          Format of B-LLI IE indicating LLC/SNAP encapsulation

          ----------------------------------------------------------
          | bb_low_layer_information                               |
          ----------------------------------------------------------
          |  layer_2_id                 2                          |
          |  user_information_layer     12  (lan_llc - ISO 8802/2) |
          ----------------------------------------------------------

6.2.1.  Framework for Protocol Layering

   The support of connectionless services from a connection oriented
   link layer exposes general problems of connection management,
   specifically the problems of connection acceptance, assignment of
   quality of service, and connection shutdown. For a connection to be
   associated with the correct protocol on the called host, it is
   necessary for information about one or more layers of protocol
   identification to be associated with a connection "management entity"
   or "endpoint".  This association is what we call a binding in this
   memo.  In this section we attempt to describe a framework for a
   usable binding or service architecture given the available IEs in the
   ATM call control messages.

   It is important to distinguish between two basic uses of protocol
   identification elements present in the UNI setup message. The first
   is the description of the protocol encapsulation that will be used on
   the data packet over the virtual connection, the second is the entity
   that will be responsible for managing the call. All protocols present
   in various IEs MUST be used to encapsulate the call, but the most
   specific, or highest, layer specified SHOULD manage the call. This
   defines a hierarchy of services and provides a framework for
   applications, including LLC and IP, to terminate calls. This
   hierarchy provides a clear mechanism for support of higher level
   protocol and application bindings, when their use and specification
   is defined in the appropriate standards bodies.

   In general, it would be desirable to allow data packets to be stored
   directly into an application's address space after connection is
   established.  This is possible only if we have both encapsulation and
   managing entity indications in the signaling message.






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


   The B-LLI is the only information element currently available in UNI
   3.1 for designating protocol endpoints. It contains codepoints that
   describe layer 2 and layer 3 protocol entities associated with the
   call. There are other information elements under consideration in the
   ATM Forum and ITU, which could come to play a significant role in the
   description of application to connection binding, but their use is
   not yet defined, and they are not part of the framework described by
   RFC 1577. They include B-HLI, for containing information for a higher
   layer protocol, Network Layer Information (NLI) to contain
   information for the network layer, and UUI, which is meant to carry
   information for use by the top level application.

   The following figure shows a B-LLI that MAY be used for specifying in
   call setup that IP will manage the call and that this VC will be used
   only for IP traffic. Called parties MUST accept this B-LLI.  The
   caller using VC MUST use LLC-SNAP encapsulation on all IP datagrams,
   despite the fact that the caller views the VC as dedicated to IP.
   The reason for this requirement is that while we require receivers to
   accept this form of call setup, they may choose whether or not to
   multiplex the call through LLC, in other words to ignore the Layer 3
   information.  This choice is dependent on the receiver's
   implementation's  protocol architecture and is local to the receiver.

           Format of B-LLI IE indicating VC ownership by IP
             (NOTE: LLC/SNAP encapsulation is still used)

          ----------------------------------------------------------
          | bb_low_layer_information                               |
          ----------------------------------------------------------
          |  layer_2_id                 2                          |
          |  user_information_layer     12  (lan_llc - ISO 8802/2) |
          |  layer_3_id                 3                          |
          |  ISO/IEC TR 9577 IPI        204 (0xCC)                 |
          ----------------------------------------------------------

   Null-encapsulated VCs are described in RFC 1483. Such a VC would
   result in the most direct form of binding a VC to IP.  However, the
   method of signaling for this type of VC has not yet been integrated
   into the IP over ATM context.  For completeness, we mention that the
   signaling would use a B-LLI containing the layer 3 identifier with
   the ISO/IEC TR-9577 protocol codepoint and omitting the layer 2
   identifier [ATMF93].  Since no layer 2 is specified, frames produced
   by AAL processing would be given directly to IP.  Processing of this
   B-LLI is not required at this time.







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


7.  Information Elements with Significance to the ATM Network

   This section describes the coding of, and procedures surrounding,
   information elements with significance to the ATM network, as well as
   the endpoints of an ATM call supporting multiprotocol operation.

   The standards, implementation agreements, research and experience
   surrounding such issues as traffic management, quality of service and
   bearer service description are still evolving.  Much of this material
   is cast to give the greatest possible latitude to ATM network
   implementation and service offerings.  ATM endsystems need to match
   the traffic contract and bearer service they request from the network
   to the capabilities offered by the network.  Therefore, this memo can
   only offer what, at the present time, are the most appropriate and
   efficient coding rules to follow for setting up IP and ATMARP VCCs.
   Future revisions of this memo may take advantage of ATM services and
   capabilities that are not yet available.

7.1.  ATM Traffic Descriptor

   The ATM traffic descriptor characterizes the ATM virtual connection
   in terms of peak cell rate (PCR), sustainable cell rate (SCR), and
   maximum burst size.  This information is used to allocate resources
   (e.g., bandwidth, buffering) in the network.  In general, the ATM
   traffic descriptor for supporting multiprotocol interconnection over
   ATM will be driven by factors such as the capacity of the network,
   conformance definition supported by the network, performance of the
   ATM endsystem and (for public networks) cost of services.

   The most convenient model of IP behavior corresponds to the Best
   Effort Capability (see section 3.6.2.4 of [ATMF93]). If this
   capability is offered by the ATM network(s), it MAY be requested by
   including the Best Effort Indicator, the peak cell rate forward
   (CLP=0+1) and peak cell rate backward (CLP=0+1) fields in the ATM
   Traffic Descriptor IE. When the Best Effort Capability is used, no
   guarantees are provided by the network, and in fact, throughput may
   be zero at any time.  This type of behavior is also described by RFC
   1633 [BRAD94].













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


          Format and field values of ATM Traffic Descriptor IE

          ----------------------------------------------------------
          | traffic_descriptor                                     |
          ----------------------------------------------------------
          |  fwd_peak_cell_rate_0+1_identifier    132              |
          |  fwd_peak_cell_rate_0+1               (link rate)      |
          |  bkw_peak_cell_rate_0+1_identifier    133              |
          |  bkw_peak_cell_rate_0+1               (link rate)      |
          |  best_effort_indication               190              |
          ----------------------------------------------------------

   When the network does not support Best Effort Capability or more
   predictable ATM service is desired for IP, more specific traffic
   parameters MAY be specified and the Best Effort capability not used.
   Doing so includes use of two other traffic-related IEs and is