RFC 1755
ATM Signaling Support for IP over ATM
RFC 1755: ATM Signaling Support for IP over ATM 🦋
- Who wrote it: M. Perez (ISI), F. Liaw (FORE Systems, Inc.), A. Mankin (ISI), E. Hoffman (ISI), D. Grossman (Motorola Codex), and A. Malis (Ascom Timeplex, Inc.) 👑
- Working group: Network Working Group 🌸
- Category: Standards Track ✨
- Date: February 1995 📅
- Obsoletes or updates: This title block has no Obsoletes or Updates line, so it doesn't claim to replace or update anything 🙈
Status of this Memo 📜
Okay bestie, this doc specifies an Internet standards track protocol for the whole Internet community 🌐, and it's literally asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🎀.
Abstract 💖
This memo covers the ATM call control signaling exchanges you need to support Classical IP over ATM implementations, as described in RFC 1577 [LAUB94]. ATM endpoints bring in ATM signaling services as specified in the ATM Forum User-Network Interface (UNI) Specification Version 3.1 [ATMF94] 🔥. IP over ATM implementations use the services of local ATM signaling entities to set up and release ATM connections. This memo defines the support that IP over ATM implementations need from their local ATM signaling entities 🧚.
This document is an implementors guide meant to foster interoperability among RFC 1577, RFC 1483, and UNI ATM signaling 🫶. It's for IP hosts and routers that are also ATM endsystems, and it assumes ATM networks that completely implement the ATM Forum UNI Specification Version 3.1. Unless explicitly stated, there's no distinction between the Private and Public UNI 🌈.
UNI 3.1 is considered an erratum to the UNI 3.0 specification 💅. The ATM Forum produced it, mostly so it lines up with Recommendation Q.2931. Even though UNI 3.1 is based on UNI 3.0, there are several changes that make the two versions incompatible 😭. If you want to support IP over ATM using UNI 3.0, check out 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 .......................... 281. Conventions ✨
These are the language conventions used in the items of specification in this document 💕:
- MUST, SHALL, or MANDATORY: the big boss 👑. The item is an absolute requirement of the specification.
- SHOULD or RECOMMEND: an item that SHOULD generally be followed for all but exceptional circumstances 💅.
- MAY or OPTIONAL: truly optional 🦋. The item MAY be followed or ignored, depending on what the implementor needs.
2. Overview 🦋
In a Switched Virtual Connection (SVC) environment, ATM virtual channel connections (VCCs) get set up and torn down dynamically, as needed 🔄. This happens through the ATM call/connection control signaling protocol, which runs between ATM endsystems and the ATM network. The signaling entities use that protocol to set up and release calls (associations between ATM endpoints) and connections (VCCs) 📞. Signaling procedures include addressing, which is how endpoints get located, and allocating resources in the network for the connection 🗺️. It also handles indication and negotiation between ATM endpoints, so they can pick end-to-end protocols and their parameters 🤝. This memo explains how the signaling protocol gets used to support IP over ATM, and especially what information gets exchanged in the signaling protocol to make that happen ✨.
IP address to ATM address resolution and routing issues are out of scope for this memo. They're 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 AAL53. Use of Protocol Procedures 🎀
These requirements are here to give implementers guidance on how multiple ATM connections between peer systems SHOULD be managed 🧵, so that connection thrashing and related problems get prevented.
3.1. VC Establishment 💖
The owner of an existing VCC is the entity inside the ATM endsystem that set up the connection 💅. An ATM endsystem MAY establish an ATM call when it has a datagram to send, and either there's no existing VCC it can use for this purpose, it chooses not to use an existing VCC (for example, for route optimization or quality of service reasons), or the VCC owner doesn't allow sharing ✨.
To reduce the latency of address resolution at the called station, the following procedure MAY be used 🧚:
If a VCC is established using LLC/SNAP encapsulation, the calling endstation of the VCC MAY send an InARP_REQUEST to the called endstation. It does this after the connection is established (i.e. it received a CONNECT message) and before the calling endstation sends the first data packet 📨. The calling endstation MAY also send its data packets without waiting for the InARP_REPLY 🏃♀️. An endstation MAY respond to, generate, and manage its ATMARP table according to the procedures in RFC1293 [BRAD92], Section 7, "Protocol Operation", for the life time of the VCC 🗂️.
To avoid setting up 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 for an endstation whose ATMARP resolution results in an ATM address that's the same as the associated calling party number 💜. Sharing 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. This is only true if the VCC owner allows sharing, and the encapsulation allows proper multiplexing and demultiplexing (for example, LLC/SNAP encapsulation) 🎀. Sharing a VCC MAY be indicated by configuration or through an API ⚙️. Similarly, the Internet layer supports multiplexing of multiple end-to-end transport sessions 🌊. To detect idle connections properly while a VCC is shared among more than one higher layer protocol entity, the ATM endsystem MUST monitor the traffic at the lowest 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's no existing VCC it can use for this purpose, it chooses not to use an existing VCC, or the owner of the VCC doesn't allow sharing 📞. There might be VCCs to the destination that 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, no matter which peer system initiated each connection 🫂. They MAY be configured to allow only 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 it 🙅♀️.
Because opening multiple connections is specifically allowed, algorithms that prevent connection call collision, such as the one in section 8.4.3.5 of ISO/IEC 8473 [ISO8473], MUST NOT be implemented 🚫💀.
Allowing multiple connections is specifically desired and allowed 💖. Even so, implementations MAY choose (by configuration) to permit only a single connection to some destinations 🧚. Only in that case, if a colliding incoming call arrives while a call request is pending, the incoming call MUST be rejected ❌. This MAY result in a failure to establish a connection 😭. In that situation, each system MUST wait at least a configurable collision retry time, somewhere in the range of 1 to 10 seconds, before retrying ⏳. Systems MUST add a random increment, with exponential backoff 🎲.
3.4. VC Teardown ✨
okay bestie, time to close things out 🫶 Either endsystem MAY close a connection 💅 If the connection gets closed or reset while a datagram is mid-transmit, that datagram is lost 😭 Systems SHOULD be able to set a minimum holding time so connections stay open as long as both endpoints are up 🎀 (Quick reminder: holding time is how long the connection has been open, which is not the same as idle time 🙈) A suggested default for the minimum holding time is 60 seconds 🌸
Because some public networks MAY charge for holding time, and connections MAY be a scarce resource on some networks or endsystems, every system running a Public ATM UNI interface MUST support a configurable inactivity timer that clears connections that have been idle for a while 🧚 The timer's range SHOULD run from a few minutes all the way up to "infinite" ⏰ A default of 20 minutes is RECOMMENDED 💖 Systems that only run a Private ATM UNI interface SHOULD support the inactivity timer too ✨ And if you do implement it, the inactivity timer MUST watch traffic in both directions of the connection 👑
4. Brief Overview of UNI Call Setup Signaling Procedures and Messages ✨
this section is your quick tour of point-to-point signaling procedures 🦋 For the full tea, go read [ATMF93] 💜
UNI signaling messages used for point-to-point call and connection control are these:
Call Setup Call Release
---------- ------------
SETUP RELEASE
CALL PROCEEDING RELEASE COMPLETE
CONNECT
CONNECT ACKNOWLEDGEso an ATM endpoint starts a call request by sending a SETUP message to the network 📞 The network checks whether the call can go through, and if it can, it hands back the newly allocated VPCI/VCI in its very first reply to the SETUP, which is either a CALL PROCEEDING or a CONNECT message 🔥 If a call can't be accepted, whether by the network or the destination ATM endpoint, a RELEASE COMPLETE gets sent 😭 On the destination side, the network offers the call using a SETUP message 🎀 If the destination endpoint can accept it, it answers with a CONNECT message (which MAY be preceded by a CALL PROCEEDING) ✨ Otherwise it sends a RELEASE COMPLETE 💀 For guidance on when to use CALL PROCEEDING, see Appendix A, Section 2 📖
call release can be started by either endpoint or, rarely, by the network 🌈 When an endpoint wants to release a call, it sends a RELEASE message to the network 💅 The network replies with a RELEASE COMPLETE, frees up the resources tied to the call, and starts clearing toward the other endpoint 🫶 To do that, it sends a RELEASE message to the ATM endpoint, which responds with a RELEASE COMPLETE 🦋 Once the network gets that RELEASE COMPLETE, it frees any resources associated with the call 👑
5. Overview of Call Establishment Message Content ✨
signaling messages are built to hold mandatory and optional variable length information elements (IEs) 🧚 IEs are split into octet groups, and those groups are split into fields 🍓 An IE carries info about the call that's relevant to the network, the peer endpoint, or both 💜 Which optional IEs you pick, plus what goes into the mandatory and optional ones, decides who's talking and what kind of communication happens over the ATM connection 🔥 For example, a call meant for constant bitrate video over AAL 1 ends up with different contents than a call meant for IP over AAL 5 😭
A SETUP message that sets up an ATM connection for IP and multiprotocol interconnection calls MUST contain these IEs:
AAL Parameters
ATM Traffic Descriptor
Broadband Bearer Capability
Broadband Low Layer Information
QoS Parameter
Called Party Number
Calling Party Numberand it MAY, under certain circumstances, contain these IEs too:
Calling Party Subaddress
Called Party Subaddress
Transit Network Selectionin UNI 3.1, the AAL Parameters and Broadband Low Layer Information IEs are optional in a SETUP message 🙈 but for IP over ATM, these two IEs MUST be included 💅 Appendix A has an example SETUP message coded the way this memo describes 🎀
6. Information Elements with Endpoint to Endpoint Significance ✨
this section covers how to code the information elements in a SETUP message that only matter to the endpoints of an ATM call supporting IP, plus the procedures around them 🫶
6.1. ATM Adaptation Layer Parameters
The AAL Parameters IE (see section 5.4.5.5 and Annex F of [ATMF93]) carries info about the ATM Adaptation Layer (AAL) used on the connection 🧚 RFC 1483 specifies encapsulating IP over AAL 5, so AAL 5 MUST be indicated in the "AAL type" field 💖
Coding and procedures for the 'Forward and Backward Maximum CPCS-SDU Size' fields are covered in [ATKI94] 📖 Values may range from zero to 65,535 🌸 The default for IP over AAL 5/ATM is 9188 bytes, though endstations are encouraged to support MTU sizes up to and including 64k 🦋
Usually, no Service Specific Convergence Sublayer (SSCS) gets used for multiprotocol interconnect over AAL5 🍓 So the SSCS 'type' field SHOULD be absent or, if it's there, 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
picking an encapsulation for IP over an ATM VCC is done with the Broadband Low Layer Information (B-LLI) IE 🎀 You use it together with the AAL Parameters IE and the B-LLI negotiation procedure 💜
RFC 1577 names LLC/SNAP as the default encapsulation 👑 Every endstation MUST implement this encapsulation 💅 LLC encapsulation MUST be signaled in the B-LLI, as shown below 🫶 Other encapsulations get signaled differently, which Appendix D, Section 4 covers 📖 Heads up: only LLC is indicated in the B-LLI 🙈 After call setup, the LLC layer digs into the encapsulation header of the packets to figure out what's inside 🔥 A B-LLI that specifies both LLC and a layer_3_id SNAP layer is not recommended 💀 If those packets' SNAP header says IP, the LLC layer is the one that hands them 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 🧚
Okay bestie, so running connectionless services on top of a connection-oriented link layer is giving major connection management drama 😭. The big problems are connection acceptance, assigning quality of service, and connection shutdown. For a connection to land on the right protocol on the called host, some protocol identification info has to be attached to a connection "management entity" or "endpoint". This attachment is what we call a binding in this memo 🎀. This section is basically the blueprint for a usable binding or service architecture, built from the IEs that already exist in the ATM call control messages 💅.
It's super important to keep two things separate in the UNI setup message 🧠. Thing one is the protocol encapsulation, which is how the data packets get wrapped on the virtual connection. Thing two is the entity in charge of 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 creates a hierarchy of services that gives applications, including LLC and IP, a way to terminate calls 👑. It also leaves a clear path for higher-level protocol and application bindings, once the standards bodies define how their use and specification works 🦋.
Ideally, data packets could land straight in an application's address space once the connection is up 🌸. That's only possible when the signaling message carries both the encapsulation indication and the managing entity indication.
The B-LLI is the only IE in UNI 3.1 for designating protocol endpoints 🎯. It holds codepoints describing the layer 2 and layer 3 protocol entities tied to the call. The ATM Forum and ITU are cooking up other IEs that could matter a lot for binding apps to connections, but nobody has defined how they work yet, and they aren't part of the framework in RFC 1577 🙃. Those are B-HLI (info for a higher layer protocol), Network Layer Information (NLI) (info for the network layer), and UUI (info meant for the top level application).
Check out this B-LLI 👀. It MAY be used during call setup to say that IP will manage the call and that this VC is only for IP traffic. Called parties MUST accept this B-LLI 🫶. The caller using the VC MUST use LLC-SNAP encapsulation on all IP datagrams, even though the caller sees the VC as dedicated to IP 🙈. Why? Because we need receivers to accept this setup, but they get to decide whether to multiplex the call through LLC, which is basically ignoring the Layer 3 info. That choice depends on the receiver's implementation's protocol architecture and stays 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 covered in RFC 1483 🍓. They'd be the most direct way to bind a VC to IP, no cap. BUT the signaling for them hasn't been folded into the IP over ATM setup yet 😤. For completeness, the signaling would use a B-LLI with the layer 3 identifier set to the ISO/IEC TR-9577 codepoint, and with the layer 2 identifier omitted [ATMF93]. Since there's no layer 2, frames coming out of AAL processing go straight to IP 🦋. Processing of this B-LLI is not required at this time 💀.
7. Information Elements with Significance to the ATM Network 🌈
This section is all about how information elements with significance to the ATM network get coded, plus the procedures around them 💖. It also covers the endpoints of an ATM call that supports multiprotocol operation ✨.
Okay so the standards, implementation agreements, research and experience around traffic management, quality of service, and bearer service description are still evolving 🌱. It's a whole moving target rn. A lot of this material is written to give ATM network implementers and service offerings the most room to do their thing 🗽. ATM endsystems have to match the traffic contract and bearer service they request from the network with what the network can actually offer 💅. So this memo can only give the most appropriate and efficient coding rules to follow for setting up IP and ATMARP VCCs as of right now 🫶. Future revisions may take advantage of ATM services and capabilities that aren't available yet 🔮.
7.1. ATM Traffic Descriptor ✨
okay bestie, the ATM traffic descriptor is how you describe your ATM virtual connection 💅 using peak cell rate (PCR), sustainable cell rate (SCR), and maximum burst size. The network reads that info to decide how much bandwidth and buffering to set aside for you 🫶. For multiprotocol interconnection over ATM, the descriptor is usually shaped by things like the capacity of the network, which conformance definition the network supports, how well the ATM endsystem performs, and (for public networks) how much the service costs 💸.
The most chill model of IP behavior is the Best Effort Capability 🌸 (check section 3.6.2.4 of [ATMF93]). If the ATM network(s) offer it, you MAY request it 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. With Best Effort, the network doesn't guarantee anything, and throughput can literally be zero at any moment 💀. This behavior is also described in RFC 1633 [BRAD94].
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 |
----------------------------------------------------------If the network doesn't support Best Effort Capability, or you want something more predictable for IP, you MAY specify more specific traffic parameters and skip Best Effort. That means using two other traffic-related IEs, which the next paragraphs and sections cover 🎀.
The Traffic Descriptor IE comes with the Broadband Bearer Capability IE and the QoS Parameter IE. Together they make up the signaling view of ATM traffic management. In this memo we lock in an agreed-on, required subset of traffic management capabilities, specified using those three IEs 🦋. The table below shows the allowable combinations of traffic parameters that all IP over ATM endsystems MUST support in their ATM signaling. The subset includes Best Effort as a non-guaranteed bitrate combination (the rightmost column), a descriptor meant for ATM "pipes", like between two routers (the middle column), and a descriptor that lets you start using token-bucket style characterizations of the source, as in RFC 1363 [PART92] and RFC 1633 for example (the leftmost column) 🧚.
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 equivalentYou can also use other allowable combinations from the large table in Appendix C, since [ATMF94] allows them. Just know it depends on the calling endsystem, the network, and the called endsystem 🤔.
If you're not using Best Effort service, the link rate SHOULD not be requested as the peak cell rate. Without knowing anything about the application, it is RECOMMENDED to request a fraction of the link bandwidth, like 1/10th 🍓.
[ATMF93] doesn't give you any way to negotiate the ATM traffic descriptor parameters, so:
- a) the calling endsystem SHOULD have some prior knowledge of the traffic contract that will be acceptable to both the called endsystem and the network 🔥.
- b) if a calling endsystem gets a RELEASE COMPLETE message in response to a SETUP message, or a CALL PROCEEDING message followed by a RELEASE COMPLETE message, with cause #37, User Cell Rate Unavailable, it MAY look at the diagnostic field of the Cause IE and retry the call with smaller values for the parameter(s) indicated. If the RELEASE COMPLETE or RELEASE message comes back 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 can't process cells at the Forward PCR indicated, it SHOULD clear the call with cause #37, User Cell Rate Unavailable 😭.
7.2. Broadband Bearer Capability
BCOB-X (Broadband Bearer Connection Oriented Service Type X) and BCOB-C (Type C) are both applicable for multiprotocol interconnection 👑. Which one you use depends on the services the ATM network provides and on what the ATM endsystem can do, like traffic shaping. The table in the previous section showed BCOB-X and BCOB-C used 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 🧚♀️.
Right now there's no way to negotiate the broadband bearer capability, so:
- a) the calling endsystem SHOULD have some prior knowledge of the broadband bearer capability that will be acceptable to both the called endsystem and the network 🌈.
- b) if a calling endsystem gets a RELEASE COMPLETE message in response to a SETUP 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 retry the call after picking another bearer capability 🦋.
7.3. QoS Parameter
The Unspecified QoS class (Class 0) is the only QoS class that every network must support, and it's the only QoS class allowed when you use 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 apply to multiprotocol over ATM, but using them has to be negotiated with the network provider 🤝. The combinations of QoS parameters with the ATM Traffic Descriptor and the Broadband Bearer Capability are laid out 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] doesn't offer any way to negotiate Quality of Service parameters, so:
- a) the calling endsystem SHOULD have some prior knowledge of the QoS classes the ATM network offers alongside the requested Broadband Bearer Service and Traffic Descriptor 🍓.
- b) if a calling endsystem gets a RELEASE COMPLETE message in response to a SETUP message, or a CALL PROCEEDING message followed by a RELEASE COMPLETE message, with cause #49, Quality of Service Unavailable, it MAY retry the call after picking 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 ✨
okay so ATM addressing info rides along in the Called Party Number IE and the Calling Party Number IE 📇 and, under certain circumstances, the Called Party Subaddress and Calling Party Subaddress IEs too. Section 5.8 of [ATMF93] explains how an ATM endsystem can learn its own ATM address from the ATM network so it can fill in the Calling Party Number IE 🦋. Section 5.4.5.14 [ATMF94] is where the syntax and semantics of the calling party subaddress IE live 💅
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 🌈 The Selector field in the NSAPAs and E.164 addresses (in the NSAP format) is identified as a way to tell up to 256 different LISs apart for the same ESI 🔥
So an IP router MAY associate the IP addresses of the various LISs it supports with distinct ATM addresses that are 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 for the particular IP entity requesting the call, and for the IP entity it is requesting a call to 📮 Those ATM addresses ride 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 |
----------------------------------------------------------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, unspecifiedIf 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 supported9. Security Considerations 🔥
okay bestie, this one is serious 😭
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. 🔐
10. Open Issues 🌸
- 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 the 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 wanna give a huge shoutout to 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, and 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, making 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.
[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.eduFong-Ching Liaw
FORE Systems, Inc.
174 Thorn Hill Road
Warrendale, PA 15086-7535
Phone: (412) 772-8668
EMail: fong@fore.comAllison Mankin
USC/Information Sciences Institute
4350 N. Fairfax Drive Suite 400
Arlington, VA 22203
Phone: 703-807-0132
EMail: mankin@isi.eduEric Hoffman
USC/Information Sciences Institute
4350 N. Fairfax Drive Suite 400
Arlington, VA 22203
Phone: 703-807-0132
EMail: hoffman@isi.eduDan Grossman
Motorola Codex
Phone: 617-821-7333
EMail: dan@merlin.dev.cdx.mot.comAndrew 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.comAppendix A. Sample Signaling Messages 🧚
1. SETUP and CONNECT messages ✨
okay so this appendix shows sample codings of the SETUP and CONNECT signaling messages 💅 the fields in the IE header aren't shown, so don't look for them 🙈
+--------------------------------------------------------------------+
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)
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]
In IP over ATM environments, the AAL parameters IE is mandatory 🎀 because it's how the source and destination negotiate the MTU size. The Broadband Low Layer Information IE is also mandatory, since that's where the IP encapsulation scheme gets specified 🧠
+--------------------------------------------------------------------+
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 messageSame deal as SETUP 💜 IP over ATM environments need the AAL parameters IE here too, so the destination can say what MTU size it's willing to receive.
2. Hints on Use of CALL PROCEEDING Message
the CALL PROCEEDING message is lowkey so useful in setups where the called party's ATM signaling entity and the AAL Users are decoupled 🧩 like, a SETUP can get an instant CALL PROCEEDING back from the signaling entity while it quietly asks the called IP-ATM entity whether the SETUP's conditions are okay. If they are, the signaling entity sends a CONNECT back to the switch ✨ and there are two ways the called party can refuse:
- 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 is all about supporting IP over ATM with UNI 3.0 signaling 💖 it lists how the coding or meaning of each relevant IE is different.
1. AAL parameter
okay the max SDU size values can range from one (not zero!) all the way up to 64K 📏
the 'mode' field is totally allowed in UNI 3.0 🙄 but this 'mode' field SHOULD be omitted from the AAL Parameters IE, and the destination endsystem MUST ignore it if it shows up anyway 🙅♀️
2. Traffic Management Related IEs
so UNI 3.0 wasn't as clear about traffic management as UNI 3.1 was 🫠 it doesn't have a guide for how to coordinate the User Cell Rate IE (the Traffic Descriptor IE in UNI 3.1), the Broadband Bearer Capability IE, and the QoS parameters IE. So the advice for setting parameters in these IEs is the same as the UNI 3.1 advice above 🫶 and the next bit just covers the differences in names and code values.
2.1 ATM User Cell Rate (instead of ATM Traffic Descriptor)
the ATM Traffic Descriptor IE is called the 'ATM User Cell Rate' IE in UNI 3.0 🏷️ also, the cause value for 'user cell rate unavailable' is #51.
2.3 QoS parameters
the two-bit 'coding standard' field in the General Information octet of the IE header should be set to '11' 🔥 that tells everyone the IE is a standard defined for the network (not an ITU-TS standard), and it's present on the network side of the interface.
3. ATM Addressing Information
in UNI 3.1, the 'ATM Endsystem Address' type was introduced so ATM addresses could be told apart from OSI NSAPs 🌸 but in UNI 3.0, 'ATM Endsystem Address' isn't a valid type at all 💀 so, for the called and calling party subaddress IEs, the three-bit 'type of subaddress' field MUST specify 'NSAP' (value = 001) whenever you're using the subaddress IE to carry ATM addresses.
4. Dealing with Failure of Call Establishment
there are some cause values in UNI 3.0 that are different from UNI 3.1, and two of them are the big ones 👑
- 'AAL Parameter Cannot Be Supported' is #93 (#78 in UNI 3.1), and
- 'User Cell Rate Unavailable' is #51 (#37 in UNI 3.1).
Appendix C. Combinations of Traffic Related Parameters tha MAY be supported in the SETUP message 🧚
here's the cheat sheet for which traffic-related parameter combos can show up in a SETUP message 📊 read it like a group-chat screenshot 😭
|-----------------------------------------------------------------|
|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].)
here's what the symbols mean 🔑
PCR= Peak Cell Rate,SCR= Sustainable Cell Rate,MBS= Maximum Burst SizeY= Yes,N= No,S= SpecifiedY/N= either "Yes" or "No" is allowed*= allowed QoS class values are a network option. Class 0 is always supported for alignment with ITU-T&= the 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.&&= the 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 just means that parameter isn't present 🫧
Appendix D. Frame Relay Interworking 🌈
1. RFC 1490 over FR-SSCS vs. RFC 1483 over null-SSCS 💅
okay bestie, here's the tea 🫖: nobody has specified how Frame Relay to ATM signaling interworking should work yet. Not ITU-T, not the ATM Forum, not the Frame Relay Forum 😭. So if an ATM endsystem wants to use FR-SSCS, then FR-SSCS and RFC 1490 encapsulation both have to be in the SETUP message. No exceptions 🫶. BUT (this is the drama) LLC encapsulation and VC-multiplexing won't interoperate over FR-SSCS, so those two can't be negotiated as backups for RFC 1490 encapsulation. See Section 4, Encapsulation Negotiation 💖.
In ATM land, the SSCS layer is part of the AAL 🧚. Its job is to juggle what the protocol above it needs with what the Common Part Convergence Sublayer (CPCS) below it requires. For example, UNI ATM signaling runs on top of a signaling SSCS, which gives signaling messages an assured transfer service (among other things) ✨. Since the SSCS counts as part of the AAL, its type gets listed as one of the parameters in the AAL Parameters IE. Fun fact (not really fun 💀): no SSCS has been defined for data transmission in ATM yet, so that type field is usually set to 'null'.
The exception is FR interworking, where an ATM endsystem can choose to use FR-SSCS over AAL 5 so it can talk to an FR endsystem. In that case, the SSCS type in the AAL Parameters IE of the SETUP message is set to 'FR-SSCS' 🦋.
The SETUP message also has the B-LLI IE, which says which protocol layers sit above the AAL 🌸. Connections carrying connectionless network interconnect traffic need a layer above the AAL to multiplex several protocols over a single VC [HEIN 93]. And like I said, RFC 1577 makes LLC the default multiplexing layer for IP over AAL5 💜.
Here's the catch 🙈: the SSCS spec limits which encapsulation can go over it. RFC 1483 (plus the relevant ITU standards) says RFC 1490 encapsulation goes over FR-SSCS, and LLC or null encapsulation goes over everything else. Since UNI 3.0 signaling can't negotiate between FR-SSCS and null-SSCS, stations that use FR-SSCS and stations that don't can have trouble talking, even when they're both doing IP 😤. The guidelines in the following section were made to lower the odds of that happening 🎀.
2. Scenarios for Interworking
Okay, now the scenarios 🎬. This discussion uses two 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 knows the other endpoint is a FR/ATM Network IWU. "Service interworking" tries to make everything transparent to the ATM endsystem by adding encapsulation translation and other payload processing in the FR/ATM Service IWU, so the ATM endsystem thinks it's talking to another ATM endsystem 🤭.
The most common FR-SSCS situation is an ATM endsystem talking to a FR/ATM network IWU, so it can reach an FR endsystem sitting behind that IWU 💅.
-------- --------
------- | | | | -------
| A | | FR/ATM | | ATM | | B |
| (FR) |----->| IWU |----->| switch |----->| (ATM) |
------- | | | | -------
-------- --------
| | | |
-----> --------------------->
FR call ATM callOkay so a network IWU can call an ATM host on behalf of an FR host by asking for FR-SSCS and assuming the ATM endsystem supports it 🤞. 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 flops because the called ATM host doesn't support it, the IWU can retry and negotiate LLC encapsulation or VC-multiplexing instead 🔁.
BUT (plot twist 🙃) the IWU can only retry if it can do FR-ATM service interworking. And that adds extra processing overhead during the call 💀.
Now for the even messier one 😬: an ATM host calls a host sitting behind an IWU, which is the reverse direction.
-------- --------
------- | | | | -------
| B | | FR/ATM | | ATM | | A |
| (FR) |<-----| IWU |<-----| switch |<-----| (ATM) |
------- | | | | -------
-------- --------
| | | |
<----- <---------------------
FR call ATM callThe calling host doesn't know the destination is behind an IWU, so it asks for the default LLC encapsulation (maybe with VC-multiplexing as a backup) 🙈. Now the IWU has two choices: accept the call and do the necessary service interworking, or reject it with 'AAL Parameters not supported'. Rejecting is risky though 💔. The calling host might not support FR-SSCS at all, or it might just not retry, and then the call never gets established.
3. Possible Alternatives
So FR interworking is doable 🙌, but you can't negotiate FR-SSCS together with LLC encapsulation or VC-multiplexing, which makes an ATM call less likely to actually connect 📉. Good news: you can boost interoperability with these options:
- Keep outside knowledge that a particular destination uses FR-SSCS. That can be configured by hand, or added to a network host database later on 🗂️.
- If you don't have that outside 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. It simply accepts the call using LLC encapsulation ✨.
- 2b. The IWU supports service interworking and network interworking, and prefers network interworking. It simply accepts the call, but also tries to open a parallel connection back to the original ATM endsystem, negotiating FR-SSCS use. If that connection is accepted, the IWU closes the service interworking connection 🧠.
- 2c. The IWU supports network interworking only. It rejects the call specifying 'AAL Parameters not supported', then tries to open a connection back to the original ATM endsystem, negotiating FR-SSCS use 🔄.
4. Encapsulation negotiation
The call/connection control signaling protocol has a mechanism to negotiate encapsulation for endsystems that support more than one. This section explains how that negotiation works 🤝.
The B-LLI negotiation procedures (see Annex C of [ATMF93]) kick off when the calling ATM endsystem puts up to three instances of the B-LLI IE into the SETUP message, ordered from most preferred to least preferred (following the rule for repeating IE in section 5.4.5.1 of [ATMF93]) 📋.
Here are the three possible combinations that the B-LLI IE instances MAY be included in the SETUP message 🎀. Each one goes by its encapsulation name from RFC 1483, plus the matching section label 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 VC multiplexing, but is willing to agree to LLC/SNAP encapsulation instead, if the called ATM endsystem only supports LLC/SNAP 🦋.
- c) RFC 1490 encapsulation (NLPID multiplexing) over FR-SSCS (D.3.3, omitting octets 7a and 7b and MUST have FR-SSCS in SSCS type of AAL Parameters IE.)
The calling ATM endsystem can only send and receive packets using RFC 1490 encapsulation (NLPID multiplexing) over FR-SSCS. RFC 1490 encapsulation can't currently 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 be coded to indicate FR-SSCS. 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 the 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 doesn't 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 ✨.
📦 where this page comes from
- ietf: rfc1755 1995-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms