rfc1755.txt

RFC 的详细文档！

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


   In IP over ATM environments the inclusion of the "AAL parameters" IE
   is *mandatory* to allow for MTU size negotiation between the source
   and destination. The "Broadband Low Layer Information" IE is also
   mandatory for specifying the IP encapsulation scheme.

  +--------------------------------------------------------------------+
                                CONNECT

    Information Elements/
      Fields                         Value
    --------------------             -----
    aal_parameters
      aal_type                       5        (AAL 5)
      fwd_max_sdu_size_ident         140
      fwd_max_sdu_size               (send IP MTU value)
      bkw_max_sdu_size_ident         129
      bkw_max_sdu_size               (recv IP MTU value)
      sscs_type identifier           132
      sscs_type                      0        (null SSCS)

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

    connection identifier
      spare                          0
      vp_assoc_signaling             1        (explicit indication of VPCI)
      preferred_exclusive            0        (exclusive vpci/vci)
      vpci                           (assigned by network)
      vci                            (assigned by network)
  +--------------------------------------------------------------------+
                               Figure 2.
                    Sample contents of CONNECT message

   As in the SETUP message, IP over ATM environments demand the
   inclusion of the "AAL parameters" IE so that the destination may
   specify the MTU size that it is willing to receive.

   2.  Hints on Use of CALL PROCEEDING Message

   Use of the CALL PROCEEDING message is beneficial in implementations
   where the called party's ATM signaling entity and AAL Users are
   decoupled. An arriving SETUP may result in an immediate CALL
   PROCEEDING response from the called party's ATM signaling entity,
   while it locally queries the called IP-ATM entity to see if the
   SETUP's conditions are acceptable. The acceptance of the SETUP's
   conditions would then cause the ATM signaling entity to issue a
   CONNECT back to the switch. The two possible refusal modes at the



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


   called party then become:

           a) Called party has no IP-ATM entity resident. Issue RELEASE
              COMPLETE in response to SETUP.

           b) Called party has a resident IP-ATM entity, so CALL PROCEEDING
              was issued. The IP-ATM entity rejects the call request, so a
              RELEASE is issued instead (to be acknowledged by the network
              with RELEASE COMPLETE).

Appendix B. IP over ATM using UNI 3.0 Signaling

   This appendix describes how to support IP over ATM using UNI 3.0
   signalling.  Differences in the coding or semantics of each relevant
   IE is given.

   1. AAL parameter

   Values for maximum SDU size may range from one (not zero) to 64K.

   A 'mode' field is an allowable field in UNI 3.0. Nevertheless, this
   'mode' field SHOULD be omitted from the AAL Parameters IE and MUST be
   ignored by the destination endsystem.

   2. Traffic Management Related IEs

   In UNI 3.0 issues of traffic management were less understood than in
   UNI 3.1. UNI 3.0 does not contain a guide to coordinating the use of
   the User Cell Rate IE (Traffic Descriptor IE in UNI 3.1), Broadband
   Bearer Capability IE, and QoS parameters IE. Therefore, the
   recommendation for specifying parameters in these IEs is the same as
   that given above when using UNI 3.1.  The following section merely
   describes relevant differences in names and code values.

   2.1 ATM User Cell Rate (instead of ATM Traffic Descriptor)

   The ATM Traffic Descriptor IE is refered to as 'ATM User Cell Rate'
   IE in UNI 3.0. Also, the value for the cause 'user cell rate
   unavailable' is #51.

   2.3 QoS parameters

   The two-bit 'coding standard' field of the General Information octet
   in the IE header, should be set to '11' inidicating that the IE is a
   standard defined for the network (as opposed to an ITU-TS standard)
   present on the network side of the interface.





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


   3. ATM Addressing Information

   In UNI 3.1, the 'ATM Endsystem Address' type was introduced to
   differentiate ATM addresses from OSI NSAPs. In UNI 3.0, 'ATM
   Endsystem Address' is not a valid type. Therefore, in the called and
   calling party subaddress IEs the three-bit 'type of subaddress' field
   MUST specify 'NSAP' (value = 001) when using the subaddress IE to
   carry ATM addresses.

   4. Dealing with Failure of Call Establishment

   In UNI 3.0 the there are certain cause values which are different
   than UNI 3.1. Two relevant differences are the following:

      'AAL Parameter Cannot Be Supported' is #93 (#78 in UNI 3.1), and

      'User Cell Rate Unavailable' is #51 (#37 in UNI 3.1).


































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


Appendix C.

                 Combinations of Traffic Related Parameters
                 tha MAY be supported in the SETUP message

    |-----------------------------------------------------------------|
    |Broadband Bearer                                                 |
    |Capability                                                       |
    |-----------------------------------------------------------------|
    |Broadband Bearer     |A,C| X |X  |C  | X |C| X |A,C| X | X |C| X |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |Traffic Type         |   |   |   |   |   | |   |   |   |   | |   |
    |(CBR,VBR)            |   |CBR| & |   |&  | |&  |   |CBR|&  |&| & |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |Timing Required      |   | Y |&& |   |&& | |&& |   | Y |&& | |&& |
    |-----------------------------------------------------------------|
    |Traffic Descriptor                                               |
    |Parameter                                                        |
    |-----------------------------------------------------------------|
    |PCR (CLP=0)          | S | S | S |   |   | |   |   |   |   | |   |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |PCR (CLP=0+1)        | S | S | S | S | S |S| S | S | S | S |S| S |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |SCR (CLP=0)          |   |   |   |   | S |S|   |   |   |   | |   |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |SCR (CLP=0+1)        |   |   |   |   |   | | S | S |   |   | |   |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |MBS (CLP=0)          |   |   |   |   | S |S|   |   |   |   | |   |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |MBS (CLP=0+1)        |   |   |   |   |   | | S | S |   |   | |   |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |Best Effort          |   |   |   |   |   | |   |   |   |   |S| S |
    |---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
    |Tagging              |Y/N|Y/N|Y/N|Y/N|Y/N|N| N | N | N | N |N| N |
    |-----------------------------------------------------------------|
    |-----------------------------------------------------------------|
    |QOS Classes          | * | * | * | * | * |*| * | * | * | * |0| 0 |
    |-----------------------------------------------------------------|

    (Table 2 is a reproduction of Table F-1 of Appendix F in [ATMF 94].)


    PCR = Peak Cell Rate, SCR = Sustainable Cell Rate,
    MBS = Maximum Burst Size

    Y = Yes, N = No, S = Specified

    Y/N = either "Yes" or "No" is allowed



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


    * = allowed QoS class values are a network option. Class 0 is
        always supported for alignment with ITU-T

    & = parameter is coded to either "no indication" or VBR or
        octet 5a(Traffic Type/Timing Required) is absent; these three
        codings are treated as equivalent

    && = parameter is coded to either "no indication" or "No" or
        octet 5a(Traffic Type/Timing Required) is absent; these three
        codings are treated as equivalent

    A blank entry in the table indicates that the parameter is not
    present.

Appendix D.  Frame Relay Interworking

1.  RFC 1490 over FR-SSCS vs. RFC 1483 over null-SSCS

   Procedures for Frame Relay to ATM signaling interworking have not yet
   been specified by ITU-T, the ATM Forum, or the Frame Relay Forum. If
   an ATM endsystem wishes to use FR-SSCS, FR-SSCS and RFC 1490
   encapsulation must both be be specified in the SETUP message.
   Nevertheless, since neither LLC encapsulation nor VC-multiplexing
   will interoperate when used over FR-SSCS, these two encapsulations
   cannot be negotiated as alternatives to RFC 1490 encapsulation (see
   Section 4, Encapsulation Negotiation).

   In ATM environments the SSCS layer is part of the AAL functionality.
   The SSCS serves to coordinate the needs of a protocol above with the
   requirements of next lower layer, the Common Part Convergence
   Sublayer (CPCS). For example, the UNI ATM signaling protocol runs on
   top of a signaling SSCS which among other things provides an assured
   transfer service for signaling messages. Since the SSCS is considered
   part of the AAL, the SSCS type is specified as one of the parameters
   in the AAL Parameters IE.  To date there has not been an SSCS defined
   for data transmission in ATM and this type field is usually set to
   'null'.

   The exception occurs when doing FR interworking where an ATM
   endsystem may choose to use the FR-SSCS over AAL 5 in order to
   communicate with a FR endsystem.  In that case the SSCS type in the
   AAL Parameters IE of the SETUP message is set to 'FR-SSCS'.

   Also included in a SETUP message is an indication in the B-LLI IE of
   the protocol layers to be used above the AAL. In particular, ATM
   connections established to carry connectionless network interconnect
   traffic require a layer above the AAL for multiplexing multiple
   protocols over a single VC [HEIN 93]. As mentioned above, RFC 1577



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


   defines LLC as default multiplexing layer for IP over AAL5.

   Specification of the SSCS restricts the encapsulation protocol used
   over it, since RFC 1483 (in addition to applicable ITU standards)
   defines the use of RFC 1490 encapsulation over the FR-SSCS, and LLC
   or null encapsulation otherwise.  The fact that it is not possible,
   in the UNI 3.0 signaling specification, to negotiate between the FR-
   SSCS and null-SSCS can result in interoperability restrictions
   between stations that implement and wish to use the FR-SSCS and those
   that do not, even though they both are using IP. The guidelines in
   the following section were developed to decrease the chance that such
   interoperability restrictions occur.

2.  Scenarios for Interworking

   The following discussion uses the terms "network interworking" and
   "service interworking".  "Network interworking" uses FR-SSCS over
   AAL5 between the InterWorking Unit (IWU) and the ATM endsystem, and
   the ATM endsystem is aware that the other endpoint is a FR/ATM
   Network IWU.  "Service interworking" aims to make the operation
   transparent to the ATM endsystem by adding encapsulatio