rfc1755.txt

中、英文RFC文档大全打包下载完全版 .

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


                 Combinations of Traffic Related Paramenters
                 that MUST be supported in the SETUP message

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

   S = Specified
   & = 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
        is absent; these three codings are treated as equivalent

   Use of other allowable combinations of traffic parameters listed in
   the large table in Appendix C may work, since they are allowed by
   [ATMF94], but this will depend on the the calling endsystem, the
   network, and the called endsystem.



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


   If Best Effort service is not use, link rate SHOULD not be requested
   as the peak cell rate. Without any knowledge of the application, it
   is RECOMMENDED that a fraction, such as 1/10th, of the the link
   bandwidth be requested.

   [ATMF93] does not provide any capability for negotiation of the ATM
   traffic descriptor paramenters.  This means that:

     a) the calling endsystem SHOULD have some prior knowledge as to
        the traffic contract that will be acceptable to both the
        called endsystem and the network.

     b) if, in response to a SETUP message, a calling endsystem
        receive a RELEASE COMPLETE message, or a CALL PROCEEDING
        message followed by a RELEASE COMPLETE message, with cause
        #37, User Cell Rate Unavailable, it MAY examine the
        diagnostic field of the Cause IE and reattempt the call after
        selecting smaller values for the parameter(s) indicated.  If
        the RELEASE COMPLETE or RELEASE message is received with cause
        #73, Unsupported combination of traffic parameter, it MAY
        try other combinations from table 5-7 and 5-8 of [ATMF93].

     c) the called endsystem SHOULD examine the ATM traffic descriptor
        IE in the SETUP message.  If it is unable to process cells at
        the Forward PCR indicated, it SHOULD clear the call with cause
        #37, User Cell Rate Unavailable.

























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


7.2.  Broadband Bearer Capability

   Broadband Bearer Connection Oriented Service Type X (BCOB-X) or Type
   C (BCOB-C) are both applicable for multiprotocol interconnection,
   depending on the service(s) provided by the ATM network and the
   capabilities (e.g., for traffic shaping) of the ATM endsystem. The
   table in the previous section showed the use of BCOB-X and BCOB-C
   with other parameters.  The figure below shows format and field
   values for a BCOB-X when the Traffic Descriptor IE indicates Best
   Effort.

          Format and field values of Broadband Bearer Capability IE

          ----------------------------------------------------------
          | bb_bearer_capability                                   |
          ----------------------------------------------------------
          |  spare                       0                         |
          |  bearer_class                16      (BCOC-X)          |
          |  spare                       0                         |
          |  traffic_type                0       (no indication)   |
          |  timing_reqs                 0       (no indication)   |
          |  susceptibility_to_clipping  0       (not suscept)     |
          |  spare                       0                         |
          |  user_plane_configuration    0       (point_to_point)  |
          ----------------------------------------------------------

   IP over ATM signaling MUST permit BCOB-C and BCOB-X, in the
   combinations shown in the previous section.  It MAY also permit one
   of the allowable combinations shown in Appendix C.

   Currently, there is no capability for negotiation of the broadband
   bearer capability.  This means that:

     a) the calling endsystem SHOULD have some prior knowledge as to
        the broadband bearer capability that will be acceptable to
        both the called endsystem and the network.

     b) if, in response to a SETUP message, a calling endsystem
        receives a RELEASE COMPLETE message, or a CALL PROCEEDING
        message followed by a RELEASE COMPLETE message, with cause
        #57, bearer capability not authorized or #58 bearer capability
        not presently available, it MAY reattempt the call after
        selecting another bearer capability.








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


7.3.  QoS Parameter

   The Unspecified QoS class (Class 0) is the only QoS class that must
   be supported by all networks and the only QoS class allowed when
   using the Best Effort service. The Specified QoS Class for Connection
   Oriented Data Transfer (Class 3) or the Specified QoS Class for
   Connectionless Data Transfer (Class 4) may be applicable to
   multiprotocol over ATM, but their use has to be negotiated with the
   network provider.  The combinations of QoS parameters with the ATM
   Traffic Descriptor and the Broadband Bearer Capability are detailed
   in the Traffic Descriptor section and in Appendix C.

          Format and field values of QoS Parameters IE

          ----------------------------------------------------------
          | qos_parameter                                          |
          ----------------------------------------------------------
          |  qos_class_fwd              0         (class 0)        |
          |  qos_class_bkw              0         (class 0)        |
          ----------------------------------------------------------

   [ATMF93] does not provide any capability for negotiation of Quality
   of Service parameters.  This means that:

     a) the calling endsystem SHOULD have some prior knowledge as to
        the QoS classes offered by the ATM network in conjunction with
        the requested Broadband Bearer Service and Traffic Descriptor.

     b) if, in response to a SETUP message, a calling endsystem
        receives a RELEASE COMPLETE message, or a CALL PROCEEDING
        message followed by a RELEASE COMPLETE message, with cause
        #49, Quality of Service Unavailable, it MAY reattempt the call
        after selecting another QoS class.

   Note: The two-bit 'coding standard' field of the General Information
   octet in the IE header, SHOULD be set to '00' now that the ITU-T has
   standardized QoS class 0. Endsystems SHOULD treat either value ('11'
   or '00') as requesting the ITU-T QoS class.

7.4.  ATM Addressing Information

   ATM addressing information is carried in the Called Party Number,
   Calling Party Number, and, under certain circumstance, Called Party
   Subaddress, and Calling Party Subaddress IE. Section 5.8 of [ATMF93]
   provides the procedure for an ATM endsystem to learn its own ATM
   address from the ATM network, for use in populating the Calling Party
   Number IE.  Section 5.4.5.14 [ATMF94] describes the syntax and
   semantics of the calling party subaddress IE.



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


   RFC 1577 RECOMMENDS that a router be able to provide multiple LIS
   support with a single physical ATM interface that may have one or
   more individual ATM endsystem addresses.  Use of the Selector field
   in the NSAPAs and E.164 addresses (in the NSAP format) is identified
   as a way to differentiate up to 256 different LISs for the same ESI.
   Therefore, an IP router MAY associate the IP addresses of the various
   LISs it supports with distinct ATM addresses differentiated only by
   the SEL field. If an IP router does this association, then its
   signaling entity MUST carry in the SETUP message the ATM addresses
   corresponding to the particular IP entity requesting the call, and
   the IP entity it is requesting a call to. These ATM addresses are
   carried in the Calling and Called Party Number IEs respectively.
   Native E.164 addresses do not support a SEL field.  For IP routers
   residing in a Public UNI where native E.164 addresses are used it is
   RECOMMENDED that multiple E.164 addresses be used to support multiple
   LISs.  Note: multiple LIS support is the only recommended use of the
   SEL field. Use of this field is not recommended for selection of
   higher level applications.

   Resolution of IP addresses to ATM addresses is required of hosts and
   routers which are ATM endsystems that use ATM SVCs. RFC 1577 provides
   a mechanism for doing IP to ATM address resolution in the classical
   IP model.

          Format and field values of Called and Calling Party Number IE

          ----------------------------------------------------------
          | called_party_number                                    |
          ----------------------------------------------------------
          |  type_of_number      (international number / unknown)  |
          |  addr_plan_ident     (ISDN / ATM Endsystem Address)    |
          |  addr_number         (E.164 / ATM Endsystem Address)   |
          ----------------------------------------------------------


          ----------------------------------------------------------
          | calling_party_number                                   |
          ----------------------------------------------------------
          |  type_of_number      (international number / unknown)  |
          |  addr_plan_ident     (ISDN / ATM Endsystem Address)    |
          |  presentation_indic  (presentation allowed)            |
          |  spare               0                                 |
          |  screening_indic     (user provided verified & passed) |
          |  addr_number         (E.164 / ATM Endsystem Address    |
          ----------------------------------------------------------






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


8.  Dealing with Failure of Call Establishment

   If an ATM call attempt fails with any of the following causes, the
   situation SHOULD be treated as Network Unreachable (if the called ATM
   endsystem is a router) or Host Unreachable (if the called ATM
   endsystem is a host).  See the treatment of Network and Host
   Unreachable conditions in RFC 1122 [BRAD89].

        #  1  unallocated (unassigned) number
        #  3  no route to destination
        # 17  user busy
        # 18  no user reponding
        # 27  destination out of order
        # 38  network out of order
        # 41  temporary failure
        # 47  resource unavailable, unspecified

   If an ATM call attempt fails with any of the following causes, the
   ATM endsystem MAY retry the call, changing (or adding) the IE(s)
   indicated by the cause code and diagnostic.

           #  2  no route to specified transit network
           # 21  call rejected