IP over ATM WG M.Maher,A.Mankin Category: internet-draft February 1996 ATM Signaling Support for IP over ATM - UNI 4.0 Update Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI 4.0 [ATMF96] to support IP over ATM environments as described in RFC 1577 [LAUB94] and in [KATZ96]. Among the new features found in UNI 4.0 signalling are negotiation of traffic parameters and procedures for Available Bit Rate (ABR) signalling. This initial draft highlights the features of UNI 4.0 Signalling that provide IP entities capabilities for requesting ATM service in sites with SVC support, whether it is private ATM or publicly provision ATM, in which case the SVC support is probably configured inside PVPs. This document is not for IP in the presence of implemented IP Integrated Services and RSVP. That will be handled by a different specification or set of specifications. This document is follow-on to RFC 1755, "ATM Signaling Support for IP over ATM", which is based on UNI signalling 3.1. Readers are assumed to be familiar with RFC 1755. Maher,Mankin [Page 1] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 1. Overview UNI Signalling version 4.0 is the ATM Forum follow-on specification to UNI Signalling 3.1. Among the new features in UNI 4.0, those of particular interest to IP over ATM enviroments are: o ABR Signalling for Point-to-Point Calls o Traffic Parameter Negotiation o Frame Discard Support o Leaf Initiated Join (LIJ) Multipoint Capability o ATM Anycast Capability o Switched Virtual Path (VP) Service This draft highlights the first three capabilities listed above. The last three capabilities are not discussed mainly because models for their use in IP over ATM environments have not yet been defined. 2. 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 : Calling Party Subaddress Called Party Subaddress Transit Network Selection (New in UNI 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 Maher,Mankin [Page 2] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 In UNI 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 will later show a sample setup message for reference] 3. Description of Information Elements This section describes the coding of, and procedures surrounding, information elements in a SETUP message. The first two IEs described, ATM Adaptation Layer Parameters and Broadband Low Layer Information, are categorized as having significance only to the endpoints of an ATM call supporting IP. That is, the network does not process these IEs. 3.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 [PER94]. 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) | ---------------------------------------------------------- This shows maximum size MTUs. In practice, most sites have used 9180 IP MTUs for ATM [RFC1626]. 3.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 nego- tiation is described in [PER94] in Appendix D. The procedures remain the same for this UNI 4.0 based specification. Format of B-LLI IE indicating LLC/SNAP encapsulation Maher,Mankin [Page 3] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 ---------------------------------------------------------- | bb_low_layer_information | ---------------------------------------------------------- | layer_2_id 2 | | user_information_layer 12 (lan_llc - ISO 8802/2) | ---------------------------------------------------------- 3.3. Traffic Management Issues The ATM Forum Traffic Management Sub-working group is nearing comple- tion of version 4.0 of their specification [TMGT96]. This latest ver- sion focuses primarily on the definition of the ABR traffic category. As opposed to the Unspecified Bit Rate (UBR) traffic class, ABR uses a rate-based flow control mechanism to assure certain traffic guaran- tees (bandwidth and delay). There has been much debate on whether IP benefits from ABR, and if so, how IP should use ABR. The Integrated Internet 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 draft attempts only to present the required IP to ATM signalling 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 so that sites can configure their IP over ATM 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 signal- ling interface that is flexible and allows application specific traffic descriptors. The potential services that an IP over ATM interface may be config- ured for are: - CBR - CBR with CLR specified (loss-permitting CBR) - ABR - UBR - non-real time VBR [We don't think it's likely that realtime VBR would be a provisioned service to a site, but we expect to discuss this with the WG] The topic of IP over ATM signalling for IP _with_ IIS/RSVP is to be presented in another specification [and a BOF is occurring to work on the elements of it at the LA IETF]. Maher,Mankin [Page 4] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 The Traffic Descriptor IE, Broadband Bearer Capability IE, and the QoS Parameter IE together define the signalling view of ATM traffic management. In this memo, we present an agreed-on, required subset of traffic management capabilities, as specified by using these three IEs. The table below shows a set of the allowable combinations of traffic parameters. This subset includes all forms of non-IIS IP signalling configurations that must be implemented to accomodate varied sites' needs. The list of the subsetted forms is above. The principle is that IP over ATM service may be provided by 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. We want to fill in the table parameters to offer the most sensible parameters within this non-IIS configuration. For instance, for non-IIS VBR, the SCR value may need to be hand-configured on IP users. Or for ABR, the PCR value may be link-rate with a 0 MCR. Completing this table will be iterated in WG discussion. All IP over ATM endsystems MUST support this minimal set of combina- tions in their ATM signalling. [Below you will find a handy summary of the ATM Forum 4.0 signalling subset for all TM and then a table of traffic descriptor parameters for the subsets for IP without IIS, however these will both be filled in in the next draft of this memo] [Handy Summary] Combinations of Traffic Related Parameters that MAY be supported in the SETUP message [To be added later] (This table will be a reproduction of Table 9-1 of Annex 9 in [ATMF96]) Maher,Mankin [Page 5] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 3.3.1. ATM Traffic Descriptor Disregarding IIS and RSVP, the most convenient model of IP behavior corresponds to the Best Effort Capability. Best effort service MAY be requested by including the forward and backward peak cell rate (CLP=0+1) and the Best Effort Indicator fields in the ATM Traffic Descriptor IE. As stated above, this may not be the choice that a site's configuration allows. In support of ABR service two new subfields have been added to the Traffic Descriptor IE, forward and backward 'Minimum Cell Rate' fields. 3.3.2. Traffic Parameter Negotiation UNI 4.0 allows certain traffic parameters to be negotiated during the call establishment phase (see section 8 of UNI 4.0). Traffic parame- ters cannot be 'renegotiated' after the call is active. Two specific capabilities are defined: - negotiation of PCR parameters (using the Minimum Acceptable ATM Traffic Descriptor IE) - negotiation of other traffic parameters (using the Alternative ATM Traffic Descriptor IE) 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. In order to take advantage of these negotiation procedures, IP over ATM entities SHOULD specify PCR _equal_ to the link rate in the ATM Traffic Descriptor IE and a known minimum in the Minimum Acceptable ATM Traffic Descriptor IE. 3.3.3. Frame Discard Capability The frame discard capabilty in UNI 4.0 is primarily based on the any of the ATM services, except for loss-less CBR. Frame discard signal- ling MUST be supported by all IP over ATM entities and it is RECOM- MENDED that frame discard be signalled for all IP SVCs because it has been proven to increase throughput under network congestion. Signal- ling 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 requiered that they all forward the signalling. Maher,Mankin [Page 6] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 3.4. ABR Signalling In More Detail [This is VERY DRAFTY] Two new IEs have been defined for ABR signal- ling: 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: - Forward/Backward ABR Initital Cell Rate - Forward/Backward ABR Transient Buffer Exposure - Cumulative RM Fixed Round Trip Time - Forward/Backward Rate Increment Factor - Forward/Backward Rate Decrease Factor The ABR Additional Parameters IE contains one subfield: - Forward/Backward Additional Parameters Record The Additional Parameters Record value is a compressed encoding of a set of ABR parameters (see TMGT96). 3.5. 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 capa- bilities (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. Maher,Mankin [Page 7] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 Format and field values of Broadband Bearer Capability IE ---------------------------------------------------------- | bb_bearer_capability | ---------------------------------------------------------- | spare 0 | | bearer_class 16 (BCOC-X) | | traffic_type cbr, rt-vbr, nrt-vbr, abr | | spare 0 | | user_plane_configuration 0 (point_to_point) | ---------------------------------------------------------- IP over ATM signaling MUST permit BCOB-C and BCOB-X, in the combina- tions shown in the previous section. It MAY also permit one of the allowable combinations shown in Appendix XX. 3.6. 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 Con- nectionless Data Transfer (Class 4) may be applicable to multiproto- col 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 will be fleshed out later -- this section is drafty as yet] Format and field values of QoS Parameters IE ---------------------------------------------------------- | qos_parameter | ---------------------------------------------------------- | qos_class_fwd 0 (class 0) | | qos_class_bkw 0 (class 0) | ---------------------------------------------------------- 3.7. Signalling of Individual QoS Parameters [Drafty] UNI 4.0 allows for signalling of individual QoS parameters for the purpose of explicitly informing the network and called party of certain desired delay and cell loss characterics. The two indivi- dual QoS parameter IEs, Extended QoS Parameters IE and End-to-End Transit Delay, can be used in the SETUP and CONNECT signalling Maher,Mankin [Page 8] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 messages in place of the 'generic' QoS Parameter IE. Nevertheless, inclusion of these two IEs depends on the type of ATM service category requested. (see Annex 9 in [ATMF96]) 3.8. 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 seman- tics of the calling party subaddress IE. 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 | ---------------------------------------------------------- 4. Security Considerations The ATM Forum recently established an ATM Security sub-working group in for the purpose of defining seurity mechanisms in ATM. It is therefore premature to begin defining IP over ATM signalling's use of ATM security. IP Security (RFC1825) can be applied to IP datagrams over any medium. Maher,Mankin [Page 9] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 5. Open Issues Description of Leaf Initiated Join (LIJ) signalling is not discussed because the use of LIJ in IP over ATM has not been defined. [Plus issues associated with those various drafty bits] REFERENCES [LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett-Packard Laboratories, December 1993 [ATMF94] ATM Forum, "ATM User-Network Interface Specification Version 3.1", (Englewood Cliffs, NJ: Prentice Hall, 1994) [ATMF96] ATM Forum, "ATM User-Network Interface Specification Version 4.0", 1996 Work in Progress. [TMGT96] ATM Forum, "ATM Forum Traffic Management Specification Ver- sion 4.0", 1996, Work in Progress. [KAT96] "NBMA Next Hop Resolution Protocol (NHRP)", Katz, Piscitello, Cole, Luciani, draft-ietf-rolc-nhrp-07.txt. [BRAD89] Braden, R., Editor, "Requirements for Internet Hosts -- Com- munication Layers", RFC 1122, USC/Information Science Institute, October 1989. [BRAD94] Braden, R., Clark, D, Shenker, S., "Integrated Service in the Internet Architecture: An Overview", RFC 1633, USC/Information Science Institute, June 1994. [BRAD96] Braden, R., et al, "RSVP Protocol Function Specification", Work in Progress. [HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM Adapta- tion Layer 5", RFC 1483, Telecom Finland, July 1993. [ISO8473] ISO/IEC 8473, Information processing systems - Data commun- ications - 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) [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. Maher,Mankin [Page 10] RFC IP over ATM Signalling - UNI 4.0 Update February 1996 [PART92] Partridge, C., "A Proposed Flow Specification", RFC1363, BBN, September 92 [Q.2931] Broadband Integrated Service Digital Network (B-ISDN) Digi- tal Subscriber Signaling System No.2 (DSS2) User Network Inter- face Layer 3 Specification for Basic Call/Connection Control ITU-T Recommendation Q.2931, (International Telecommunication Union: Geneva, 1994) Authors' Information Maryann Perez Maher maher@isi.edu Allison Mankin mankin@isi.edu USC/Information Sciences Institute 4350 N. Fairfax Drive, Suite 620 Arlington VA 22203 703-807-0133 Maher,Mankin [Page 11]