GENWiki

Network Working Group M. Maher Request for Comments: 2331 USC/ISI Category: Standards Track April 1998

 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update

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.

Copyright Notice

 Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

 This memo describes how to efficiently use the ATM call control
 signalling procedures defined in UNI Signalling 4.0 [SIG40] to
 support IP over ATM environments as described in RFC 2225 [LAUB98]
 and in RFC 2332 [LUC98].  Among the new features found in UNI
 Signalling 4.0 are Available Bit Rate signalling and traffic
 parameter negotiation.  This memo highlights the features of UNI
 Signalling 4.0 that provide IP entities capabilities for requesting
 ATM service in sites with SVC support, whether it is private ATM or
 publicly provisioned ATM, in which case the SVC support is probably
 configured inside PVPs.

 This document is only relevant to IP when used as the well known
 "best effort" connectionless service. In particular, this means that
 this document does not pertain to IP in the presence of implemented
 IP Integrated Services.  The topic of IP with Integrated Services
 over ATM will be handled by a different specification or set of
 specifications being worked on in the ISSLL WG.

 This specification is a follow-on to RFC 1755, "ATM Signaling Support
 for IP over ATM", which is based on UNI 3.1 signalling [UNI95].
 Readers are assumed to be familiar with RFC 1755.

Maher Standards Track [Page 1]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

Table of Contents

 1.  Conventions ...............................................   2
 2.  Overview ..................................................   2
 3.  Use of Protocol Procedures ................................   3
     3.1  VC Teardown...........................................   3
 4.  Overview of Call Establishment Message Content ............   3
 5.  Description of Information Elements .......................   4
     5.1  ATM Adaptation Layer Parameters ......................   4
     5.2  Broadband Low Layer Information  .....................   5
     5.3  Traffic Management Issues and Related IEs.............   5
          5.3.1  ATM Traffic Descriptor ........................   6
                 5.3.1.1  Tagging vs. Dropping .................   7
          5.3.2  Traffic Parameter Negotiation ..................  7
          5.3.3  Broadband Bearer Capability ....................  8
          5.3.4  QoS Parameter ..................................  8
                 5.3.4.1  Signalling of Individual QoS Parameters  8
     5.4  ATM Addressing Information ...........................   9
 6.  ABR Signalling In More Detail  ............................   9
 7.  Frame Discard Capability ..................................  10
 8.  Security Considerations ...................................  10
 9.  Acknowledgements...........................................  10
 10. References ................................................  10
 11. Author's Address ..........................................  12
 Appendix A  Sample Signalling Messages ........................  13
 Appendix B  ABR and nrt-VBR Signalling Guidelines for IP Routers 15
 Appendix C  Combinations of Traffic Related Parameters ........  18
 Full Copyright Statement ......................................  26

1. Conventions

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [BRA97].

2. Overview

 UNI Signalling version 4.0 (SIG 4.0) is the ATM Forum follow-on
 specification to UNI 3.1 signalling (UNI 3.1). Among the new features
 in SIG 4.0, those of particular interest to IP over ATM environments
 are:

      o Available Bit Rate (ABR) Signalling for Point-to-Point Calls
      o Traffic Parameter Negotiation
      o Frame Discard Support
      o Leaf Initiated Join (LIJ) Capability
      o ATM Anycast Capability
      o Switched Virtual Path (VP) Service

Maher Standards Track [Page 2]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 This memo highlights the first three capabilities listed above. The
 last three capabilities are not discussed because models for their
 use in IP over ATM environments have not yet been defined.  The ION
 WG is considering the applicability of LIJ and Group Addressing to
 the RFC2022 problem space.  Furthermore, Anycast addressing is being
 explored as a technique for supporting server discovery in ATM
 networks.

3. Use of Protocol Procedures

 Section 3 in RFC 1755 introduces requirements of virtual circuit (VC)
 management intended to prevent VC thrashing, excessive VC
 consumption, and other related problems. This section updates RFC
 1755's requirements related to VC teardown.

3.1. VC Teardown

 In environments running layer 3 (L3) signalling protocols, such as
 RSVP [RSVP], over ATM, data VCs might correspond to L3 reserved flows
 (even if the VC is a 'best effort' VC). In such environments it is
 beneficial for VCs to be torn down only when the L3 reservation has
 expired. In other words, it is more efficient for the sender of a L3
 reserved flow to initiate VC tear-down when the receiver(s) has
 ceased refreshing the reservation.  To support such L3 behavior,
 systems implementing a Public ATM UNI interface and serving as the
 _called_ party of a VCC MUST NOT use an inactivity timer on such a
 VCC by default.  A system MAY use an inactivity timer on such a VCC
 if configured to do so.

4. Overview of Call Establishment Message Content

 Signalling messages are structured to contain mandatory and optional
 variable length information elements (IEs).  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:

Maher Standards Track [Page 3]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

      Calling Party Subaddress
      Called Party Subaddress
      Transit Network Selection

      (New in SIG 4.0:)
      Minimum Acceptable ATM Traffic Descriptor
      Alternative ATM Traffic Descriptor
      ABR Setup Parameters
      ABR Additional Parameters
      Connection Scope Selection
      Extended QoS Parameters
      End-to-End Transit Delay

 In SIG 4.0, like 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 a sample setup message.

5. Description of Information Elements

 This section describes the coding of, and procedures surrounding,
 information elements in SETUP and CONNECT messages. The first two IEs
 described, ATM Adaptation Layer Parameters and Broadband Low Layer
 Information, are categorized as having significance only to the end-
 points of an ATM call supporting IP. That is, the network does not
 process these IEs.

5.1. ATM Adaptation Layer (AAL) Parameters

 The AAL Parameters IE carries information about the ATM adaptation
 layer to be used on the connection. The parameters specified in this
 IE are the same as specified in [PER95].

     Format and field values of AAL Parameters IE

1. ———————————————————

| aal_parameters |

1. ———————————————————

| 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)      |
     ----------------------------------------------------------

Maher Standards Track [Page 4]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 This shows maximum size MTUs.  In practice, most sites have used 9180
 IP MTUs for ATM [RFC1626].

5.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.  B-LLI
 negotiation is described in [PER95] in Appendix D. The procedures
 remain the same for this SIG 4.0 based specification.

     Format of B-LLI IE indicating LLC/SNAP encapsulation

1. ———————————————————

| bb_low_layer_information |

1. ———————————————————

| layer_2_id 2 |

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

5.3. Traffic Management Issues and Related IEs

 The ATM Forum Traffic Management Sub-working group has completed
 version 4.0 of their specification [TMGT40]. This latest version
 focuses primarily on the definition of the ABR service category. As
 opposed to the Unspecified Bit Rate (UBR) traffic class, ABR uses a
 rate-based flow control mechanism to assure certain traffic
 guarantees (bandwidth and delay).  There has been much debate on
 whether IP benefits from ABR, and if so, how IP should use ABR. The
 IP Integrated Services (IIS) and RSVP models in IP add complexity to
 this issue because mapping IIS traffic classes to ATM traffic classes
 is not straightforward.

 This document attempts only to present the required IP to ATM
 signaling interface for IP over ATM systems that do not support IIS
 as yet.  It is an attempt to cause IP over ATM vendors to support
 enough options for signalling the traffic characteristics of VCs
 serving non-IIS IP datagrams. This specification also aims to give
 guidance to ATM system administrators so that they can configure
 their IP over ATM entities to conform to the varied services that
 their ATM provider may have sold to them.  By definition, IP without
 IIS cannot be expected to provide a signalling interface that is
 flexible and allows application specific traffic descriptors. The
 topic of IP over ATM signalling for IP _with_ IIS is to be presented
 in other specifications being produced by the ISSLL WG of the IETF.

 An IP over ATM interface may be configured to support all the defined
 ATM Service Categories (ASC). They are:

Maher Standards Track [Page 5]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

1. CBR
2. CBR with CLR specified (loss-permitting CBR)
3. ABR
4. UBR
5. real time VBR
6. non-real time VBR

 The ATM Traffic Descriptor IE, Broadband Bearer Capability IE, and
 the QoS Parameter IE together define the signalling view of ATM
 traffic management. Additionally, the Extended QoS parameters IE and
 the End-to-end Transit Delay IE may be used to provide more specifics
 about traffic requirements, however this note does not provide
 explicit recommendations on their use.  Annex 9 of [SIG40] describes
 a set of allowable combinations of traffic and QoS related
 paramenters defined for SIG 4.0.  This set includes all forms of
 non-IIS IP signaling configurations that MUST be implemented in ATM
 endsystems to accommodate varied sites' needs. The principle is that
 IP over ATM service may be available in different sites by different
 types of procured ATM service; for one site, a CBR PVP might be
 cost-effective and then the SVCs that IP over ATM without IIS must
 establish must be CBR.  Similarly, VBR or ABR PVPs could be
 provisioned.  The intent of this document is to specify the use of
 the most sensible parameters within this non-IIS configuration.  For
 instance, for non-IIS VBR, the SCR value may need to be hand-
 configured for IP users, or for ABR, the PCR value may be link-rate
 with a 0 MCR.

 For the reader's convenience, we have replicated the tables found in
 Annex 9 of [SIG40] in Appendix C of this document. Ideally this
 document could recommend specific values for the various table
 parameters that would offer the most sensible IP over ATM service.
 Nevertheless, it is not possible to mandate specific values given the
 varied scenarios of procured ATM service.

5.3.1. ATM Traffic Descriptor

 Even with the newly defined ABR ASC, the most convenient model for
 supporting IP still corresponds to the best effort capability, the
 UBR ASC. The rationale for this assertion stems from the fact that a
 non-IIS IP service has no notion of the performance requirements of
 the higher layers it supports. Therefore, if a site's configuration
 allows use of UBR, users SHOULD signal for it using the IE's and
 parameters pertaining to the UBR ATC.  See Appendix C for the list of
 those IE's and parameters.

 Although we consider the UBR ASC the most natural ASC for best-effort
 IP, ATM vendors that implement VBR and ABR services could possibly
 create hooks for convenient use of these services. If this is the

Maher Standards Track [Page 6]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 case, IP routers may perhaps have the most to gain from use of VBR or
 ABR services because of the large aggregated traffic volume they are
 required to forward. See Appendix B for detailed suggestions on VBR
 and ABR signalling for IP routers.  We simply note here that, in
 support of ABR service, two new subfields have been added in SIG 4.0
 to the Traffic Descriptor IE. These fields are the forward and
 backward 'Minimum Cell Rate' fields.

5.3.1.1. Tagging vs. Dropping

 The Traffic Descriptor IE contains a 'tagging' subfield used for
 indicating whether the network is allowed to tag the source's data
 cells. Tagging in the network may occur during periods of congestion
 or when the source's traffic has violated the traffic contract for
 the connection. See Section 4 of [TMGT40] for an explanation of ATM
 connection conformance and the Usage Parameter Control (UPC)
 function.

 SIG 4.0 and TMGT 4.0 define two modes of UBR, UBR.1 which disables
 tagging and UBR.2 which enables tagging (see Appendix C).  In some
 network environments there is no potential for UBR traffic sources to
 violate the connection traffic contract because, either the user's
 terminal equipment supports traffic shaping, or the network does not
 enforce PCR.  In such environments, the user SHOULD specify 'no
 tagging' in the SETUP message (UBR.1).  Specifying 'no tagging'
 indicates to the network that cells should be dropped during periods
 of congestion instead of being randomly marked/tagged as low
 priority.  Cells of packets that the source itself has marked as low
 priority are dropped first, thereby preserving the source's
 characterization of the traffic.

 On the other hand, when the network applies PCR to the UPC function,
 meaning it enforces PCR, and traffic shaping is not enabled at the
 source, the source has the potential to violate the traffic contract
 and SHOULD therefore signal for tagging (UBR.2). Tagging allows the
 source's non-conforming cells to be tagged and forwarded instead of
 dropped.

5.3.2. Traffic Parameter Negotiation

 SIG 4.0 allows certain traffic parameters to be negotiated during the
 call establishment phase Traffic parameters cannot be 'renegotiated'
 after the call is active. Two new IEs make negotiation possible:

1. the Minimum Acceptable ATM Traffic Descriptor IE allows

negotiation of PCR parameters

Maher Standards Track [Page 7]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

1. the Alternative ATM Traffic Descriptor IE allows negotiation of

other traffic parameters

 A SETUP or CONNECT message may include ONLY one of the above IEs.
 That is, the calling party may only offer an 'alternative' or
 'minimum' to the requested traffic parameters. (See Section 8 of
 [SIG40].) IP over ATM entities SHOULD take advantage of this
 capability whenever possible. In order to do so, IP over ATM entities
 SHOULD specify PCR _equal_ to the link rate in the ATM Traffic
 Descriptor IE of the SETUP message and a minimum of zero PCR in the
 Minimum Acceptable ATM Traffic Descriptor IE.

5.3.3. Broadband Bearer Capability

 A new field in UNI signalling 4.0 called, 'ATM Transfer Capability'
 (ATC), has been defined in the Broadband Bearer Capability IE for the
 purpose of explicitly specifying the desired ATM traffic category.
 The figure below shows the allowable ATC values.

     Format and field values of Broadband Bearer Capability IE

1. ————————————————————

| bb_bearer_capability |

1. ———————————————————–|

| spare 0 |

     |  bearer_class                bcob-x,c,a or VP             |
     |  transfer_capability         cbr, rt-vbr, nrt-vbr, abr    |
     |  susceptibility_to_clipping  0     (not suscept)          |
     |  spare                       0                            |
     |  user_plane_configuration    pt-to-pt, pt-to-mpt          |
     -------------------------------------------------------------

5.3.4. QoS Parameter

 Inclusion of the QoS Parameter IE is not mandatory in SIG 4.0.  It
 may be omitted from a SETUP message _if and only if_ the Extended QoS
 Parameters IE is included (see next section). This specification
 makes no explicit recommendation on the use of the QoS related IEs.

5.3.4.1. Two IEs for Signalling of Individual QoS Parameters

 SIG 4.0 allows for signalling of individual QoS parameters for the
 purpose of giving the the network and called party a more exact
 description of the desired delay and cell loss characteristics. The
 two individual QoS related IEs, Extended QoS Parameters IE and End-
 to-End Transit Delay IE, can be used in the SETUP and CONNECT
 signaling messages in place of the 'generic' QoS Parameter IE. Note
 that inclusion of these two IEs depends on the type of ATM service

Maher Standards Track [Page 8]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 category requested (see Annex 9 in [SIG40]).

5.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. The ATM Forum ILMI
 Specification 4.0 [ILMI40] 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.

     Format and field values of Called Party Number IE

1. ———————————————————

| called_party_number |

1. ———————————————————

| type_of_number (international number / unknown) |

     |  addr_plan_ident     (ISDN / ATM Endsystem Address)    |
     |  addr_number         (E.164 / ATM Endsystem Address)   |
     ----------------------------------------------------------

6. ABR Signaling In More Detail

 The IEs and procedures pertaining to ABR signalling are briefly
 described in this section. Nevertheless, this document makes no
 specific recommendation on when to use the ABR service category for
 IP VCCs or give suggestions on appropriate values for the various
 parameters in the ABR related IEs.

 Two new IEs have been defined for ABR signaling:

   o ABR Setup Parameters
   o ABR Additional Parameters

 These IEs may be optionally included in a SETUP or CONNECT message.
 The ABR Setup Parameters IE contains the following subfields:

1. Forward/Backward ABR Initial Cell Rate
2. Forward/Backward ABR Transient Buffer Exposure
3. Cumulative RM Fixed Round Trip Time
4. Forward/Backward Rate Increment Factor
5. Forward/Backward Rate Decrease Factor

 The ABR Additional Parameters IE contains one subfield:

1. Forward/Backward Additional Parameters Record

Maher Standards Track [Page 9]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 The Additional Parameters Record value is a compressed encoding of a
 set of ABR parameters (see [SIG40] and [ABRS]).

7. Frame Discard Capability

 The frame discard capability in SIG 4.0 is primarily based on the
 'Partial and Early Packet Discard' strategy [ROM94]. Its use is
 defined for any of the ATM services, except for loss-less CBR.  Frame
 discard signaling MUST be supported by all IP over ATM entities and
 it is RECOMMENDED that frame discard be signaled for all IP SVCs
 because it has been proven to increase throughput under network
 congestion. Signaling for frame discard is done by setting the frame
 discard bit in the 'Traffic Management Options' subfield in the
 Traffic Descriptor IE.  It is possible that not all network entities
 in the SVC path support frame discard, but it is required that they
 all forward the signaling.

8. Security Considerations

 The ATM Forum Security sub-working group is currently defining
 security mechanisms in ATM. The group has yet to produce a
 specification, therefore it is premature to begin defining IP over
 ATM signalling's use of ATM security.  The ATM Forum is working on
 authentication mechanisms for signalling and on mechanisms for
 providing data integrity and confidentiality (e.g encryption).  Lack
 of these ATM security mechanisms prevents the authentication of the
 originator of signalling messages, such as, connection setup request
 or connection teardown request. IP Security (RFC1825) can be applied
 to IP datagrams over ATM VCs to overcome the lack of security at the
 ATM layer.

9. Acknowledgements

 The authors would like to thank the members of the ION working group
 for their input. Special thanks to K.K. Ramakrishnan and Kerry
 Fendick who contributed Appendix B of this document.

REFERENCES

 [ABRS] ATM Forum, "Addendum to UNI Signalling v4.0 for ABR Parameter
 Negotiation", af-sig-0076.000; available at
 ftp://ftp.atmforum.com/pub.

 [ABRT] ATM Forum, "Addendum to Traffic Management v4.0 for ABR
 Parameter Negotiation", af-tm-0077.000; available at
 ftp://ftp.atmforum.com/pub.

Maher Standards Track [Page 10]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 [RFC1122] Braden, R., Editor, "Requirements for Internet Hosts --
 Communication Layers", STD 3, RFC 1122, October 1989.

 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Service
 in the Internet Architecture: An Overview", RFC 1633, June 1994.

 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 Requirement Levels", BCP 14, RFC 2119, March 1997.

 [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
 Adaptation Layer 5", RFC 1483, July 1993.

 [ILMI40] ATM Forum, "Integrated Local Management Interface (ILMI)
 Specification Version 4.0", af-ilmi-0065.000, finalized September
 1996; available at ftp://ftp.atmforum.com/pub.

 [ISO8473] ISO/IEC 8473, Information processing systems - Data
 communications - Protocol for providing the connectionless-mode
 network service, 1988.

 [ISO9577] Information Technology - Telecommunication and information
 exchange between systems - Protocol identification in the network
 layer ISO/IEC TR9577 (International Standards Organization: Geneva,
 1990)

 [LAUB98] Laubach, M., and J. Halpern, "Classical IP and ARP over
 ATM", RFC 2225, April 1998.

 [LUC98] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
 Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332,
 April 1998.

 [RFC1755] Perez*, M., et. al., "ATM Signaling Support for IP over
 ATM", RFC 1755, February 1995. (* see author's information below)

 [ROM94] Romanow, A., and Floyd, S., Dynamics of TCP Traffic over ATM
 Networks.  IEEE JSAC, V. 13 N. 4, May 1995, p. 633-641. Abstract.  An
 earlier version appeared in SIGCOMM '94, August 1994, pp. 79-88.

 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
 Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional
 Specification", RFC 2205, September 1997.

 [SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signalling
 Specification Version 4.0", af-sig-0061.000, finalized July 1996;
 available at ftp://ftp.atmforum.com/pub.

Maher Standards Track [Page 11]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 [TMGT40] ATM Forum, "Traffic Management Specification Version 4.0",
 af-tm-0056.000, finalized April 1996; available at
 ftp://ftp.atmforum.com/pub.

 [UNI95] ATM Forum, "ATM User-Network Interface Specification Version
 3.1", Prentice Hall, Upper Saddle River, NJ, 1995.

Author's Address

 Maryann P. Maher (formerly Maryann Perez)
 USC/ISI
 4350 N. Fairfax Drive, Suite 620
 Arlington VA 22203

 EMail: maher@isi.edu

Maher Standards Track [Page 12]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

Appendix A. A Sample SIG 4.0 SETUP Message

+——————————————————————–+

                           SETUP

Information Elements/

 Fields                         Value/(Meaning)

——————– —————

aal_parameters

 aal_type                         5        (AAL 5)
 fwd_max_sdu_size_ident         140
 fwd_max_sdu_size               (xmit IP MTU value)
 bkw_max_sdu_size_ident         129
 bkw_max_sdu_size      (recv IP MTU, 0 for disallowing return traffic)
 sscs_type identifier           132
 sscs_type                        0        (null SSCS)

traffic_descriptor

 fwd_peak_cell_rate_0_1_ident   132
 fwd_peak_cell_rate_0_1         (link rate)
 bkw_peak_cell_rate_0_1_ident   133
 bkw_peak_cell_rate_0_1         (link rate)
 traff_mngt_options_ident       191
 fwd_frame_discard                1   (on)
 bkw_frame_discard                1   (on if return traffic indicated)
 spare                            0
 tagging_bkw                      1   (on)
 tagging_fwd                      1   (on if return traffic indicated)
 best_effort_indication         190   (on)

minimum_acceptable_traffic_descriptor

 fwd_peak_cell_rate_0_1_ident   132
 fwd_peak_cell_rate_0_1           0
 bkw_peak_cell_rate_0_1_ident   133
 bkw_peak_cell_rate_0_1           0

bb_bearer_capability /* a coding for specifying UBR like service */

 spare                            0
 bearer_class                    16      (BCOC-X)
 spare                            0
 atm_transfer_capability         10      (nrt-vbr)
 susceptibility_to_clipping       0      (not susceptible to clipping)
 spare                            0
 user_plane_configuration         0      (point_to_point)

Maher Standards Track [Page 13]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

bb_low_layer_information

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

qos_parameter

 qos_class_fwd                    0        (class 0)
 qos_class_bkw                    0        (class 0)

called_party_number

 type_of_number                   (international number / unknown)
 addr_plan_ident                  (ISDN / ATM Endsystem Address)
 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 and passed)
 number                           (E.164 / ATM Endsystem Address)

+——————————————————————–+

                             Figure 1.
                  Sample contents of SETUP message

Maher Standards Track [Page 14]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

Appendix B. ABR and VBR Signaling Guidelines for IP Routers

 When ATM is used to interconnect routers that are supporting a best
 effort service, the ATM connection typically carries an aggregation
 of IP flows, e.g., all best effort IP traffic between a pair of
 routers. With the efforts undertaken by ATM to be more "packet
 friendly" (e.g., frame discard), it is useful to examine ways that a
 VC can provide service comparable to or better than that of a
 dedicated or leased "link" in terms of performance and packet loss.

 For ATM connections used to interconnect routers, a non-zero
 bandwidth reservation may be required to achieve consistently
 adequate performance for the aggregate set of flows.  The support of
 bandwidth commitments for an ATM connection carrying IP traffic helps
 to assure that a certain fraction of each link's capacity is reserved
 for the total IP traffic between the routers.  Reserving bandwidth
 for the aggregation of best-effort traffic between a pair of routers
 is analogous to provisioning a particular link bandwidth between the
 routers. There are at least 3 service classes defined in the ATM
 Traffic Management specification that provide varying degrees of
 capability that are suitable for interconnecting IP routers: UBR, ABR
 and VBR non-real-time.  Although the use of best-effort service (UBR)
 at the ATM layer is the most straightforward and uncomplicated, it
 lacks the capability to enforce bandwidth commitments.

 Note that we are talking of providing a "virtual link" between
 routers, for the aggregate traffic. The provisioning is for the
 aggregate. It is therefore distinct from the per-flow bandwidth
 reservations that might be appropriate for Integrated Services.

 Even best-effort IP flows, when supported on an aggregate basis, have
 some broad service goals. The primary one is that of keeping packet
 loss rate reasonably small. A service class that strives to achieve
 this, keeping in mind the tradeoff between complexity and adequate
 service, is desirable. It has been recommended in this memo that UBR
 be the default service for this. UBR with (some form of) packet
 discard has the desirable goal of being simple in function, and it
 appears that vendors will be supporting it. However, when available,
 it may be quite worthwhile to consider ABR and VBR non-real-time
 service classes.

 Because AAL5 frames with missing cells are discarded by the receiver,
 ATM bandwidth commitments are most useful if supported in the form of
 a committed rate of cell delivery in complete, non-errored AAL5
 frames delivered to the receiver. In addition, it is desirable for
 the ATM connection to deliver additional complete frames, beyond this
 commitment, on a best-effort basis.

Maher Standards Track [Page 15]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 These characteristics can be achieved through the ABR service
 category through the use of a Minimum Cell Rate, if the ABR service
 is supported by the ATM endpoints and if efficient frame discard is
 supported at the ABR source. The mechanisms put in place for the ABR
 service strive to keep loss quite low within the ATM network.

 The parameters that should be specified by the end system are (i) the
 Peak Cell Rate (likely the link rate), (ii) the Minimum Cell Rate
 (the committed rate), and (iii) the Cumulative RM Fixed Round-Trip
 Time.  The remaining parameter values, if left unspecified by the
 calling party, are selected by the network or are chosen from the
 default values specified in the ATM Forum Traffic Management
 specification.

 Parameters (i) and (ii) are contained in the mandatory Traffic
 Descriptor IE, whereas parameter (iii) is contained in the mandatory
 ABR Setup Parameters IE. Other paramenters in the ABR Setup
 Parameters IE may be omitted. (Note that the third IE which pertains
 to ABR signalling, the ABR Additional Parameters IE, is an optional
 IE and therefore need not be included.) Parameter (iii) is dependent
 on the hardware of the end system, so that the default value
 specified for that hardware should be used. In the absense of such a
 default, a value of zero MAY be specified by the end system. Entities
 using ABR connections for IP over ATM SHOULD take advantage of
 parameter negotiation by specifying Peak Cell Rate equal to the link
 rate in the ATM Traffic Descriptor IE of the SETUP message. The value
 selected for the Minimum Cell Rate is implementation specific. Note
 that the MCR also MAY be negotiated if an MCR parameter is included
 by the end system in the Minimum Acceptable ATM Traffic Descriptor
 IE.  The use of MCR negotiation by the end system is implementation
 specific.  Also, note that Frame Discard MAY be requested for ABR
 connections as well as for UBR connections. Although the ABR service
 attempts to minimize cell loss, the use of Frame Discard may improve
 throughput when cell loss is not eliminated.

 ATM recognizes in addition to the service class (UBR, ABR, etc.), a
 notion of a QoS class. The QoS class specifies the type of guarantee
 requested of the network when the call is setup. This is distinct
 from the service class requested for the connection, and the
 specification of the traffic parameters (which specify what the
 source's traffic will look like).  QoS class 0 is the "simplest", and
 is called the Unspecified QoS class.  In the context of ABR (and VBR
 non-realtime below), we are only concerned with the QoS class
 providing an assurance of acceptable loss behavior for the
 connection.

Maher Standards Track [Page 16]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

 The Unspecified QoS Class (QoS Class 0) MUST be requested for ABR
 connections. In this context, QoS Class 0 corresponds to a network-
 specific objective for the cell loss ratio.  Networks in general are
 expected to support a low Cell Loss Ratio for ABR sources that adjust
 cell flow in response to control information.

 The VBR-nrt service category provides an alternate means of achieving
 these characteristics.  These characteristics may be obtained with
 VBR-nrt connections for which (i) the VBR.3 conformance definition is
 used, (ii) a Sustainable Cell Rate (SCR) and Maximum Burst Size
 (MBS), and Peak Cell Rate (PCR) are specified, and (iii) both tagging
 and frame discard are requested.  A request for tagging indicates
 that best-effort delivery is desired for traffic offered in excess of
 the SCR and MBS.  A request for frame discard indicates to the
 network that the user desires allocations of committed and excess
 bandwidth to translate into corresponding throughputs at the frame
 level.

 As with UBR connections, entities using VBR-nrt connections for IP
 over ATM should take advantage of parameter negotiation by specifying
 PCR equal to the link rate in the ATM Traffic Descriptor IE of the
 SETUP message and PCR equal to SCR in the Minimum Acceptable Traffic
 descriptor. The selection of SCR, MBS, and CLR (cell loss ratio)
 should be implementation specific. However, for IP over ATM, an MBS
 value of N*(Maximum MTU) is RECOMMENDED, where N>=1 with a default of
 2 and where Maximum MTU is equal to 192 cells (consistent with an IP
 MTU size of 9180 bytes [RFC1626]).

Maher Standards Track [Page 17]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

Appendix C. Combinations of Traffic Related Parameters

 This appendix contains a copy of the five tables found in Annex 9 of
 [SIG40] which show the allowable combinations of traffic and QoS
 related parameters in a SIG 4.0 SETUP message.

+——————————————————————–+

+——————————————————————–+

Maher Standards Track [Page 18]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

+——————————————————————–+

+——————————————————————–+

Maher Standards Track [Page 19]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

+——————————————————————–+

+——————————————————————–+

Maher Standards Track [Page 20]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

+——————————————————————–+

+——————————————————————–+

Maher Standards Track [Page 21]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

+——————————————————————–+

+——————————————————————–+

Maher Standards Track [Page 22]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

+——————————————————————–+

+——————————————————————–+

      ab, abs = absent.

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

Maher Standards Track [Page 23]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

      O = Optional. May be specified using:

1. an additional QoS parameter encoded i the Extended QoS

parameters information element or the end-to-end transit

             information element; or,

1. objectives implied from the QoS class If an Extended

QoS Parameters IE is not present in the message, then any

             value of this parameter is acceptable. If neither the
             parameter nor the Extended QoS Parameters IE is present,
             then the objective for this parameter is determined from
             the QoS class in the QoS Parameter IE.

      S = Specified.

      (blank) = Unspecified.

• = allowed QoS class values are a network option. Class 0 is

always for alignment with ITU-T.

      ^ = (note 5).

      ~ = (note 11).

      Note 1  - Values 0,1,2,4,6, and 8 are not used on transmission
                but shall be understood on reception.

      Note 2  - Maximum end-2-end transit delay objectives may only be
                specified for the forward direction.

      Note 3  - Maximum end-2-end transit delay objectives may be
                specified for the ATM Service Category of Non-real
                Time VBR for reasons of backward compatibility with
                ITU-T Recommendations.

      Note 4  - Included for reasons of backward compatibility with
                UNI 3.1and ITU-T Recommendations. With these
                conformance definitions, the CLR commitment is only
                for the CLP=0 traffic stream.

      Note 5  - Included to allow switched virtual paths to use the
                UNI 3.1 conformance definitions.

      Note 6  - Optional in the user-to-network direction. Specified
                in the network-to-user direction.

Maher Standards Track [Page 24]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

      Note 7  - This combination should be treated as if the received
                PCR (CLP=0) parameter were a SCR (CLP=0) parameter and
                a MBS (CLP=0) parameter with a value of 1.

      Note 8  - This combination should be treated as if an additional
                SCR (CLP=0) parameter were received with the same
                value as a PCR (CLP=0+1) parameter and a MBS (CLP=0)
                parameter with a value of 1.

      Note 9  - The best effort parameter applies to both the forward
                and backward directions.

      Note 10 - This combination should only be used when the CLR
                commitment on CLP=0+1 is required versus  CLR
                commitment on CLP=0 traffic, since these combinations
                are not supported by UNI 3.0/3.1 nor ITU-T Q.2931.

      Note 11 - In this table the CLR commitment is shown as two
                entries to indicated explicitly whether the CLR
                commitment is for the CLP=0 or the CLP=0+1 cells.

Maher Standards Track [Page 25]  RFC 2331 IP over ATM Signalling - SIG 4.0 Update April 1998

Full Copyright Statement

 Copyright (C) The Internet Society (1998).  All Rights Reserved.

 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.

 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.

 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Maher Standards Track [Page 26]