diff options
Diffstat (limited to 'doc/rfc/rfc1755.txt')
| -rw-r--r-- | doc/rfc/rfc1755.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc1755.txt b/doc/rfc/rfc1755.txt new file mode 100644 index 0000000..45c693a --- /dev/null +++ b/doc/rfc/rfc1755.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group M. Perez +Request for Comments: 1755 ISI +Category: Standards Track F. Liaw + FORE Systems, Inc. + A. Mankin + E. Hoffman + ISI + D. Grossman + Motorola Codex + A. Malis + Ascom Timeplex, Inc. + February 1995 + + + ATM Signaling Support for IP over ATM + +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. + +Abstract + + This memo describes the ATM call control signaling exchanges needed + to support Classical IP over ATM implementations as described in RFC + 1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services + as specified in the ATM Forum User-Network Interface (UNI) + Specification Version 3.1 [ATMF94]. IP over ATM implementations + utilize the services of local ATM signaling entities to establish and + release ATM connections. This memo should be used to define the + support required by IP over ATM implementations from their local ATM + signaling entities. + + This document is an implementors guide intended to foster + interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It + applies to IP hosts and routers which are also ATM endsystems and + assumes ATM networks that completely implement the ATM Forum UNI + Specification Version 3.1. Unless explicitly stated, no distinction + is made between the Private and Public UNI. + + + + + + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 1] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + + UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has + been produced by the ATM Forum, largely for reasons of alignment with + Recommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are + several changes that make the two versions incompatible. A + description of how to support IP over ATM using UNI 3.0 is found in + Appendix B. + +Table of Contents + + 1. Conventions ............................................... 3 + 2. Overview .................................................. 3 + 3. Use of Protocol Procedures ................................ 4 + 3.1 VC Establishment ..................................... 4 + 3.2 Multiprotocol Support on VCs ........................ 4 + 3.3 Support for Multiple VCs ............................. 5 + 3.4 VC Teardown........................................... 6 + 4. Overview of UNI Call Setup Signaling ...................... 6 + 5. Overview of Call Establishment Message Content ............ 7 + 6. Information Elements with Endpoint Significance ........... 8 + 6.1 ATM Adaptation Layer Parameters ...................... 8 + 6.2 Broadband Low Layer Information ..................... 8 + 6.2.1 Framework for Protocol Layering ............... 9 + 7. Information Elements with Significance to the ATM Network . 11 + 7.1 ATM Traffic Descriptor ............................... 11 + 7.2 Broadband Bearer Capability .......................... 15 + 7.3 QoS Parameter......................................... 16 + 7.4 ATM Addressing Information ........................... 16 + 8. Dealing with Failure of Call Establishment................. 18 + 9. Security Considerations .................................... 18 + 10. Open Issues ............................................... 19 + 11. Acknowledgements........................................... 19 + 12. References ................................................ 19 + 13. Authors' Addresses ........................................ 20 + Appendix A Sample Signaling Messages ......................... 22 + Appendix B IP over ATM using UNI 3.0 Signaling ............... 25 + Appendix C Combinations of Traffic Related Parameters ........ 27 + Appendix D Frame Relay Interworking .......................... 28 + + + + + + + + + + + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 2] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + +1. Conventions + +The following language conventions are used in the items of +specification in this document: + + o MUST, SHALL, or MANDATORY -- the item is an absolute requirement + of the specification. + + o SHOULD or RECOMMEND -- this item SHOULD generally be followed for + all but exceptional circumstances. + + o MAY or OPTIONAL -- the item is truly optional and MAY be followed + or ignored according to the needs of the implementor. + +2. Overview + + In a Switched Virtual Connection (SVC) environment, ATM virtual + channel connections (VCCs) are dynamically established and released + as needed. This is accomplished using the ATM call/connection control + signaling protocol, which operates between ATM endsystems and the ATM + network. The signaling entities use the signaling protocol to + establish and release calls (association between ATM endpoints) and + connections (VCCs). Signaling procedures include the use of + addressing to locate ATM endpoints and allocation of resource in the + network for the connection. It also provides indication and + negotiation between ATM endpoints for selection of end-to-end + protocols and their parameters. This memo describes how the + signaling protocol is used in support of IP over ATM, and, in + particular, the information exchanged in the signaling protocol to + effect this support. + + IP address to ATM address resolution and routing issues are not in + the scope of this memo, and are treated as part of IP in figure 1. + + +--------------+ +------+ +----------+ + | | | |<--->| IP / ARP | + | |<--->| This | | RFC 1577 | + | ATM | | Memo | +----------+ + | signaling | | |<--->| RFC 1483 | + | | +------+ +----------+ + | | -------------> | AAL 5 | + | | +----------+ + | | -------------> | ATM | + +--------------+ +----------+ + + Figure 1. + Relationship of this memo to IP, RFC 1483, + ATM signaling, ATM and AAL5 + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 3] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + +3. Use of Protocol Procedures + + The following requirements are motivated to provide implementation + guidelines on how multiple ATM connections between peer systems + SHOULD be managed, to prevent connection thrashing and related + problems. + +3.1. VC Establishment + + The owner of an existing VCC is defined to be the entity within the + ATM endsystem that establishes the connection. An ATM endsystem MAY + establish an ATM call when it has a datagram to send and either there + is no existing VCC that it can use for this purpose, it chooses not + to use an existing VCC, (e.g., for reasons of route optimization or + quality of service), or the VCC owner does not allow sharing. + + To reduce the latency of the address resolution procedure at the + called station, the following procedure MAY be used: + + If a VCC is established using the LLC/SNAP encapsulation, the calling + endstation of the VCC MAY send an InARP_REQUEST to the called + endstation after the connection is established (i.e. received a + CONNECT message) and before the calling endstation sends the first + data packet. In addition, the calling endstation MAY send its data + packets without waiting for the InARP_REPLY. An endstation MAY + respond, generate, and manage its ATMARP table according to the + procedures specified in RFC1293 [BRAD92], Section 7, "Protocol + Operation", during the life time of the VCC. + + To avoid establishing multiple VCCs to the same endstation, a called + endstation MAY associate the calling party number in the SETUP + message with the established VCC. This VCC MAY be used to transmit + data packets destined to a endstation whose ATMARP resolution results + in an ATM address that is the same as the associated calling party + number. Sharing of VCCs is subject to the policies configured at the + endstation as described in section 4.3 of this recommendation. + +3.2. Multiprotocol Support on VCs + + When two ATM endsystems run multiple protocols, an ATM connection MAY + be shared among two or more datagram protocol entities, as long as + the VCC owner allows sharing and if the encapsulation allows proper + multiplexing and demultiplexing (i.e. the LLC/SNAP encapsulation). + This indication of sharing a VCC MAY be by configuration or via an + API. Similarly, the Internet layer supports multiplexing of multiple + end-to-end transport sessions. To properly detect idle connections + while sharing a VCC among more than one higher layer protocol + entities, the ATM endsystem MUST monitor the traffic at the lowest + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 4] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + + multiplexing layer. + +3.3. Support for Multiple VCs + + An ATMARP server or client MAY establish an ATM call when it has a + datagram to send and either there is no existing VCC that it can use + for this purpose, it chooses not to use an existing VCC, or the owner + of the VCC does not allow sharing. Note that there might be VCCs to + the destination which are used for IP, but an ARP server might prefer + to use a separate VCC for ARP only. The ATMARP server or client MAY + maintain or release the call as specified in RFC 1577. However, if + the VCC is shared among several protocol entities, the ATMARP client + or server SHALL NOT disconnect the call as suggested in RFC 1577. + + Systems MUST be able to support multiple connections between peer + systems (without regard to which peer system initiated each + connection). They MAY be configured to only allow one such + connection at a time. + + If a receiver accepts more than one call from a single source, that + receiver MUST then accept incoming PDUs on the additional + connection(s), and MAY transmit on the additional connections. + Receivers SHOULD NOT accept the incoming call, only to close the + connection or ignore PDUs from the connection. + + Because opening multiple connections is specifically allowed, + algorithms to prevent connection call collision, such as the one + found in section 8.4.3.5 of ISO/IEC 8473 [ISO8473], MUST NOT be + implemented. + + While allowing multiple connections is specifically desired and + allowed, implementations MAY choose (by configuration) to permit only + a single connection to some destinations. Only in such a case, if a + colliding incoming call is received while a call request is pending, + the incoming call MUST be rejected. Note that this MAY result in a + failure to establish a connection. In such a case, each system MUST + wait at least a configurable collision retry time in the range 1 to + 10 seconds before retrying. Systems MUST add a random increment, + with exponential backoff. + + + + + + + + + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 5] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + +3.4. VC Teardown + + Either endsystem MAY close a connection. If the connection is closed + or reset while a datagram is being transmitted, the datagram is lost. + Systems SHOULD be able to configure a minimum holding time for + connections to remain open as long as the endpoints are up. (Note + that holding time, the time the connection has been open, differs + from idle time.) A suggested default value for the minimum holding + time is 60 seconds. + + Because some public networks MAY charge for connection holding time, + and connections MAY be a scarce resource in some networks or + endsystems, each system implementing a Public ATM UNI interface MUST + support the use of a configurable inactivity timer to clear + connections that are idle for some period of time. The timer's range + SHOULD include a range from a small number of minutes to "infinite". + A default value of 20 minutes is RECOMMENDED. Systems which only + implement a Private ATM UNI interface SHOULD support the inactivity + timer. If implemented, the inactivity timer MUST monitor traffic in + both directions of the connection. + +4. Brief Overview of UNI Call Setup Signaling Procedures and Messages + + This section provides a summary of point-to-point signaling + procedures. Readers are referred to [ATMF93]. + + UNI signaling messages used for point-to-point call/connection + control are the following: + + Call Setup Call Release + ---------- ------------ + SETUP RELEASE + CALL PROCEEDING RELEASE COMPLETE + 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 + discussed in the following paragraphs and sections. + + The Traffic Descriptor IE is accompanied by the Broadband Bearer + Capability IE and the QoS Parameter IE. Together these define the + signaling view of ATM traffic management. In this memo, we present + an agreed-on, required subset of traffic management capabilities, as + specified by using the three IEs. The figure immediately below shows + the set of the allowable combinations of traffic parameters which all + IP over ATM endsystems MUST support in their ATM signaling. The + subset includes Best Effort in the form of a non-guaranteed bitrate + combination (the rightmost column of the table below); a type of + traffic description that is intended for ATM "pipes", for example + between two routers (the middle column); and a type of traffic + description that will allow initial use of token-bucket style + characterizations of the source, as presented in RFC 1363 [PART92] + and RFC 1633, for example (the leftmost column). + + + + + + + + + + + + + + + + + + + +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 + # 22 number changed + # 23 user rejects call with CLIR + # 37 user cell rate unavailable + # 49 quality of service unavailable + # 57 bearer capability not authorized + # 58 bearer capability not presently available + # 65 bearer capability not implemented + # 73 unsupported combination of traffic parameter + # 88 incompatible destination + # 91 invalid transmit network selection + # 78 AAL parameter cannot be supported + +9. Security Considerations + + Not all of the security issues relating to IP over ATM are clearly + understood at this time, due to the fluid state of ATM + specifications, newness of the technology, and other factors. Future + revisions of this specification will address the security + capabilities that future signaling standards may offer to IP over ATM + signaling. + + + + + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 18] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + +10. Open Issues + + o This document version is specifically an RFC 1577/RFC 1483 + implementation document. Although RFC 1577 and RFC 1483 + specify an LLC/SNAP encapsulation, which is inherently a + multiprotocol encapsulation, it is beyond to scope of this + document to go into any multiprotocol specifications other than + to point out some examples (see Appendix D for an example of + NLPID encapsulation). + +11. Acknowledgments + + The authors wish to thank the work of their colleagues who attend the + IP over ATM working group; the ATM Forum Technical Committee; the ATM + Signaling Subworking Group in ANSI-Accredited Technical Subcommittee + T1S1; the ATM Access Signaling experts in ITU-T (formerly CCITT) + Study Group 11. Rao Cherukuri (IBM) and Jeff Kiel (formerly with + Bellcore, presently with BellSouth) were particularly valuable in + coordinating among T1S1, ITU-T and the ATM Forum to make sure that + the needs of multiprotocol over ATM could be expressed in the ATM + signaling protocol. + +REFERENCES + + [ATKI94] Atkinson, R., "Default IP MTU over ATM AAL5", RFC 1626, + Naval Research Laboratory, May 1994. + + [ATMF94] ATM Forum, "ATM User-Network Interface Specification Version + 3.1", 1994. + + [ATMF93] ATM Forum, "ATM User-Network Interface Specification Version + 3.0", (Englewood Cliffs, NJ: Prentice Hall, 1993). + + [BRAD89] Braden, R., Editor, "Requirements for Internet Hosts -- + Communication Layers", STD 3, RFC 1122, USC/Information Science + Institute, October 1989. + + [BRAD94] Braden, R., Clark, D., and S. Shenker, "Integrated Service + in the Internet Architecture: An Overview", RFC 1633, + USC/Information Science Institute, June 1994. + + [BRAD92] Bradley, T., and C. Brown, "Inverse Address Resolution + Protocol", RFC 1293, Wellfleet Communications, Inc., January + 1992. + + [HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM + Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993. + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 19] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + + [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). + + [LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, + Hewlett-Packard Laboratories, December 1993. + + [PART92] Partridge, C., "A Proposed Flow Specification", RFC 1363, + BBN, September 1992. + + [Q.2931] Broadband Integrated Service Digital Network (B-ISDN) + Digital Subscriber Signaling System No.2 (DSS2) User Network + Interface Layer 3 Specification for Basic Call/Connection Control + ITU-T Recommendation Q.2931, (International Telecommunication + Union: Geneva, 1994) + +Authors' Addresses + + Maryann Perez Maher + USC/Information Sciences Institute + 4350 N. Fairfax Drive Suite 400 + Arlington, VA 22203 + + Phone: 703-807-0132 + EMail: perez@isi.edu + + + Fong-Ching Liaw + FORE Systems, Inc. + 174 Thorn Hill Road + Warrendale, PA 15086-7535 + + Phone: (412) 772-8668 + EMail: fong@fore.com + + + Allison Mankin + USC/Information Sciences Institute + 4350 N. Fairfax Drive Suite 400 + Arlington, VA 22203 + + Phone: 703-807-0132 + EMail: mankin@isi.edu + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 20] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + + Eric Hoffman + USC/Information Sciences Institute + 4350 N. Fairfax Drive Suite 400 + Arlington, VA 22203 + + Phone: 703-807-0132 + EMail: hoffman@isi.edu + + + Dan Grossman + Motorola Codex + + Phone: 617-821-7333 + EMail: dan@merlin.dev.cdx.mot.com + + + Andrew G. Malis + Ascom Timeplex, Inc. + Advanced Products Business Unit + 289 Great Road Suite 205 + Acton, MA 01720 + + Phone: (508) 266-4522 + EMail: malis@maelstrom.timeplex.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 21] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + +Appendix A. Sample Signaling Messages + +1. SETUP and CONNECT messages + + This appendix shows sample codings of the SETUP and CONNECT signaling + messages. The fields in the IE header are not shown. + + +--------------------------------------------------------------------+ + SETUP + + Information Elements/ + Fields Value/(Meaning) + -------------------- --------------- + + 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) + + user_cell_rate + 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) + best_effort_indication 190 + + 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 susceptible to + clipping) + spare 0 + user_plane_configuration 0 (point_to_point) + + 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) + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 22] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + + 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 + + [* : optional, ignored if present] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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 encapsulation translation + and other payload processing in the FR/ATM Service IWU to allow the + ATM endsystem to operate as if it were talking to another ATM + endsystem. + + The most common scenario where FR-SSCS could be negotiated is between + an ATM endsystem and a FR/ATM network IWU to allow connectivity among + an ATM endsystem and a FR endsystem residing behind a FR/ATM network + IWU. + + -------- -------- + ------- | | | | ------- + | A | | FR/ATM | | ATM | | B | + | (FR) |----->| IWU |----->| switch |----->| (ATM) | + ------- | | | | ------- + -------- -------- + + | | | | + -----> ---------------------> + FR call ATM call + + A network IWU can place a call to an ATM host (on behalf of a FR + host) by signaling for FR-SSCS and assuming that the ATM endsystem + supports FR-SSCS. The B-LLI IE SHALL be encoded to indicate RFC 1490 + encapsulation and the SSCS type field of the AAL Parameters IE SHALL + be coded to indicate FR-SSCS. If the FR-SSCS negotiation fails + because the called ATM host does not support FR-SSCS, the IWU can + retry the call negotiating for LLC encapsulation or VC-multiplexing. + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 29] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + + However, the IWU can only attempt the retry if it is able to do FR- + ATM service interworking. Such service interworking adds extra + processing overhead during the call. + + The even more problematic case occurs when a call is requested in the + opposite direction, i.e. when an ATM host places a call to a host + residing behind an IWU. + + -------- -------- + ------- | | | | ------- + | B | | FR/ATM | | ATM | | A | + | (FR) |<-----| IWU |<-----| switch |<-----| (ATM) | + ------- | | | | ------- + -------- -------- + + | | | | + <----- <--------------------- + FR call ATM call + + Not knowing that the destination resides behind an IWU, the calling + host will negotiate for the default LLC encapsulation (possibly + requesting VC-multiplexing as an alternative). In this situation the + IWU can accept the call and do the necessary service interworking or + reject the call specifying 'AAL Parameters not supported'. If the IWU + rejects the call it risks the possibility that calling host does not + support FR-SSCS or simply does not retry and the call will never be + established. + +3. Possible Alternatives + + While Frame Relay interworking is possible, it is not possible to + negotiate FR-SSCS with LLC encapsulation or VC-multiplexing, which + decreases the chances of completing an ATM call. However, + interoperability can be increased using the following alternatives: + + 1. Maintaining external knowledge that a particular destination uses + FR-SSCS. This knowledge can be configured, or in the future added to + some network host database. + + 2. In the absence of such external knowledge, an ATM endsystem is + required to negotiate for the default LLC encapsulation (possibly + requesting VC-multiplexing as an alternative). There are three sub- + cases: + + 2a. The IWU supports service interworking and network interworking, + and prefers service interworking. The IWU simply accepts the call + using LLC encapsulation. + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 30] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + + 2b. The IWU supports service interworking and network interworking, + and prefers network interworking. The IWU simply accepts the call, + but attempts to open a parallel connection back to the original ATM + endsystem negotiating the FR-SSCS use. If the connection is + accepted, the IWU closes the service interworking connection. + + 2c. The IWU supports network interworking only. The IWU rejects the + call specifying 'AAL Parameters not supported', and then attempts to + open a connection back to the original ATM endsystem negotiating the + FR-SSCS use. + +4. Encapsulation negotiation + + The call/connection control signaling protocol includes a mechanism + to support negotiation of encapsulation for endsystems that support + more than one. This section describes the procedures for negotiation + of an encapsulation. + + The B-LLI negotiation procedures (see Annex C of [ATMF93]) are + initiated by the calling ATM endsystem by including up to three + instances of the B-LLI IE in the SETUP message in descending order of + preference (following the rule for repeating IE in section 5.4.5.1 of + [ATMF93]). + + The following is the list of the three possible combinations that B- + LLI IE instances MAY be included in the SETUP message. Each instance + is referred to by its encapsulation name as it appears in RFC 1483, + and corresponding section labels from Appendix D of the ATM Forum UNI + 3.0 specification. + + a) LLC/SNAP encapsulation (D.3.1) + + In this case, the calling ATM endsystem can only send and receive + packets preceded by an LLC/SNAP identification. This memo requires + that hosts and routers which are ATM endsystems implement LLC/SNAP + encapsulation. + + b) VC-multiplexing (D.3.2) and LLC/SNAP (D.3.1) + + The calling ATM endsystem prefers to use VC multiplexing, but is + willing to agree to use LLC/SNAP encapsulation instead, if the called + ATM endsytem only supports LLC/SNAP. + + c) RFC 1490 encapsulation (NLPID multiplexing) over FRSSCS + (D.3.3, omitting octets 7a and 7b and MUST have FR-SSCS in SSCS + type of AAL Parameters IE.) + + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 31] + +RFC 1755 ATM Signaling Support for IP over ATM February 1995 + + + The calling ATM endsystem can only send and receive packets using RFC + 1490 encapsulation (NLPID multiplexing) over FRSSCS. Use of RFC 1490 + encapsulation presently cannot be negotiated as an alternative to LLC + encapsulation or VC-multiplexing. If the B-LLI IE is encoded to + indicate RFC 1490 encapsulation, the SSCS type field of the AAL + Parameters IE SHALL coded to indicate FRSSCS. Note that the AAL + Parameters IE can not be coded to indicate both NULL and FR-SSCS and + neither LLC encapsulation nor VC-multiplexing will be interoperable + when used over FR-SSCS. + + The called ATM endsystem SHALL select the encapsulation method it is + able to support from the B-LLI IE present in SETUP message. If it + supports more than one of the encapsulations indicated in the SETUP + message, it MUST select the one which appears first in the SETUP + message. The called ATM endsystem then includes the B-LLI IE content + corresponding to the selected encapsulation in the CONNECT message. + If the called endsystem does not support any encapsulation indicated + in the incoming SETUP message, it SHALL clear the call with cause + #88, incompatible destination. If the received SETUP message does + not include the B-LLI IE, the call SHALL be cleared with cause #21, + "call rejected", with diagnostics indicating rejection reason = + information element missing and the B-LLI IE identifier. As + described in Annex C of [ATMF93], if the calling ATM endpoint + receives a CONNECT message that does not contain a B-LLI IE, it SHALL + assume the encapsulation indicated in the first BLLI IE that it + included in the SETUP message. + + + + + + + + + + + + + + + + + + + + + + + + + +Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 32] + |