idnits 2.17.1 draft-ietf-ipatm-sig-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 18) being 69 lines == It seems as if not all pages are separated by form feeds - found 16 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([ATMF93], [LAUB94]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '... VCC MAY be by configuration or via ...' RFC 2119 keyword, line 117: '...ocol entities, the ATM endsystem SHALL...' RFC 2119 keyword, line 128: '...client or server SHALL not disconnect ...' RFC 2119 keyword, line 131: '... Systems MUST be able to support mul...' RFC 2119 keyword, line 133: '...nnection). They MAY be configured to ...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 75 has weird spacing: '... on the subne...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: 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 RFC1577. However, if the VCC is shared among several protocol entities, the ATMARP client or server SHALL not disconnect the call as suggested in RFC1577. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LAUB94' is mentioned on line 33, but not defined == Missing Reference: 'Q2931' is mentioned on line 180, but not defined == Missing Reference: 'HEIN 93' is mentioned on line 768, but not defined == Unused Reference: 'HEIN93' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'ISO9577' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'LAUB93' is defined on line 727, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1626 (ref. 'ATKI94') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. 'ATMF93' -- Possible downref: Non-RFC (?) normative reference: ref. 'COLE94' ** Obsolete normative reference: RFC 1483 (ref. 'HEIN93') (Obsoleted by RFC 2684) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8473' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO9577' ** Obsolete normative reference: RFC 1577 (ref. 'LAUB93') (Obsoleted by RFC 2225) Summary: 17 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP over ATM WG M. Perez, F. Liaw, D. Grossman, 2 Internet-Draft A. Mankin, E. Hoffman, A. Malis 3 Expires in six months 5 ATM Signaling Support for IP over ATM 6 8 1. Status of this Memo 10 This memo is an internet draft. Internet Drafts are working documents 11 of the Internet Engineering Task Force (IETF), its Areas, and its 12 Working Groups. Note that other groups may also distribute working 13 documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress". Please check the lid-abstracts.txt 20 listing contained in the internet-drafts shadow directories on 21 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or 22 munnari.oz.au to learn the current status of any Internet Draft. 24 2. Abstract 26 This memo describes how implementations of IP over ATM should use ATM 27 call control signaling procedures to establish and release ATM 28 connections. It is intended to serve implementations of IP and 29 multiprotocol interconnection over ATM that use ATM signaling as 30 specified in the ATM Forum User-Network Interface (UNI) Specification 31 Version 3.0 [ATMF93]. In particular, during development of this 32 memo, the IP over ATM working group has focused its activities on the 33 Classical IP over ATM model, as described in RFC 1577 [LAUB94]; 34 therefore particular attention is given to support RFC 1577. 36 This document is an implementors guide intended to foster 37 interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It 38 serves as an intermediary role between IP and ATM call control 39 signaling which establishes and releases ATM calls/connections on 40 behalf of IP. Specifically, this memo details the coding of ATM 41 signaling messages when used to support IP. 43 This memo applies to IP hosts and routers which are also ATM 44 endsystems. It assumes ATM networks that completely implement the ATM 45 Forum UNI Specification Version 3.0. 47 Note: An erratum to the UNI 3.0 specification has been produced by 48 the ATM Forum Technical Committee, largely for reasons of alignment 49 with Recommendation Q.2931. The erratum will be published as the UNI 50 3.1 Specification in the summer of 1994. This memo does not assumes 51 the changes to the specification indicated in the erratum but 52 attempts to point out the relevant incompatibilities with UNI 3.0. 53 Once UNI 3.1 is publicly available, this I-D will be updated to 54 reflect the changes. 56 3. Overview 58 In a Switched Virtual Connection (SVC) environment, ATM virtual 59 channel connections (VCCs) are dynamically established and released 60 as needed. This is accomplished using the ATM call/connection control 61 signaling protocol, which operates between ATM endsystems and the ATM 62 network. The signaling entities use the signaling protocol to 63 establish and release calls (association between ATM endpoints) and 64 connections (VCCs). Signaling procedures include the use of 65 addressing to locate ATM endpoints and allocation of resource in the 66 network for the connection. It also provides indication and 67 negotiation between ATM endpoints for selection of end-to-end 68 protocols and their parameter. This memo describes how the signaling 69 protocol is used in support of IP over ATM, and, in particular, the 70 information exchanged in the signaling protocol to effect this 71 support. 73 IP address to ATM address resolution and routing issue are not in the 74 scope of this I-D, and is treated as part of IP in figure 1. These 75 issue depend on the subnet and end-to-end networking model being 76 used. A taxonomy of subnet and end-to-end networking models is pro- 77 vided in [COLE94]. The simplest case is the Classical IP over ATM 78 model described in RFC 1577. 80 +--------------+ +------+ +----------+ 81 | | | |<--->| IP / ARP | 82 | |<--->| This | | RFC 1577 | 83 | ATM | | I-D | +----------+ 84 | signaling | | |<--->| RFC 1483 | 85 | | +------+ +----------+ 86 | | -------------> | AAL 5 | 87 | | +----------+ 88 | | -------------> | ATM | 89 +--------------+ +----------+ 91 Figure 1. 92 Relationship of this I-D to IP, RFC 1483, 93 ATM signaling, ATM and AAL5 95 4. Use of protocol procedures 97 The following requirements are motivated to provide implementation 98 guidelines on how multiple ATM connections between peer systems 99 should be managed, to prevent connection thrashing and related 100 problems. 102 The owner of an existing VCC is defined to be the entity within the 103 ATM endsystem that establishes the connection. An ATM endsystem may 104 establish an ATM call when it has a datagram to send and either there 105 is no existing VCC that it can use for this purpose, it chooses not 106 to use an existing VCC, (e.g., for reasons of route optimization or 107 quality of service), or the VCC owner does not allow sharing. 109 When two ATM endsystems run multiple protocols, an ATM connection may 110 be shared among two or more datagram protocol entities, as long as 111 the VCC owner allows sharing, as well as if the encapsulation allows 112 proper multiplexing and demultiplexing, (i.e., the LLC/SNAP 113 encapsulation or RFC 1490 over FRSSCS). This indication of sharing a 114 VCC MAY be by configuration or via an API. Similarly, the Internet 115 layer supports multiplexing of multiple end-to-end transport session. 116 To properly detect idle connection while sharing a VCC among more 117 than one higher layer protocol entities, the ATM endsystem SHALL 118 monitor the traffic at the lowest multiplexing layer. 120 An ATMARP server or client may establish an ATM call when it has a 121 datagram to send and either there is no existing VCC that it can use 122 for this purpose, it chooses not to use an existing VCC, or the 123 owner of the VCC does not allow sharing. Note that there might be 124 VCCs to the destination which are used for IP, but an ARP server 125 might prefer to use a separate VCC for ARP only. The ATMARP server or 126 client may maintain or release the call as specified in RFC1577. 127 However, if the VCC is shared among several protocol entities, the 128 ATMARP client or server SHALL not disconnect the call as suggested in 129 RFC1577. 131 Systems MUST be able to support multiple connections between peer 132 systems (without regard to which peer system initiated each 133 connection). They MAY be configured to only allow one such 134 connection at a time. 136 If a receiver accepts more than one call from a single source, that 137 receiver MUST then accept incoming PDUs on the additional 138 connection(s), and MAY transmit on the additional connections. 139 Receivers SHOULD NOT accept the incoming call, only to close the 140 connection or ignore PDUs from the connection. 142 Because opening multiple connections is specifically allowed, 143 algorithms to prevent connection call collision, such as the one 144 found in section 8.4.3.5 of ISO/IEC 8473 [ISO8473], MUST NOT be 145 implemented. 147 While allowing multiple connections is specifically desired and 148 allowed, implementations MAY choose (by configuration) to permit only 149 a single connection to some destinations. Only in such a case, if a 150 colliding incoming call is received while a call request is pending, 151 the incoming call shall be rejected. Note that this may result in a 152 failure to establish a connection. In such a case, each system shall 153 wait at least a configurable collision retry time in the range 1 to 154 10 seconds before retrying. Systems SHOULD add a random increment, 155 with exponential backoff. 157 Either endsystem MAY close a connection. If the connection is closed 158 or reset while a datagram is being transmitted, the datagram is lost. 159 Systems SHOULD be able to configure a minimum holding time for 160 connections to remain open as long as the endpoints are up. (Note 161 that holding time, the time the connection has been open, differs 162 from idle time.) A suggested default value for the minimum holding 163 time is 60 seconds. 165 Because some public networks may charge for connection holding time, 166 and connections may be a scarce resource in some networks or 167 endsystems, each system implementing a Public ATM UNI interface MUST 168 support the use of a configurable inactivity timer to clear 169 connections that are idle for some period of time. The timer's range 170 SHOULD include a range from a small number of minutes to "infinite", 171 and the default value SHOULD be "infinite". Systems which only 172 implement a Private ATM UNI interface SHOULD, but are not required 173 to, support the inactivity timer. If implemented, the inactivity 174 timer shall monitor traffic of both receiving and transmitting 175 activities. 177 5. Brief Overview of UNI Call Setup Signaling Procedures and Messages 179 This section provides a summary of point-to-point signaling 180 procedures. Readers are referred to [ATMF93] and [Q2931]. 182 UNI signaling messages used for point-to-point call connection 183 control are the following: 185 Call Setup Call Release 186 ---------- ------------ 187 SETUP RELEASE 188 CALL PROCEEDING RELEASE COMPLETE 189 CONNECT 190 CONNECT ACKNOWLEDGE 192 An ATM endpoint initiates a call request by sending a SETUP message 193 to the network. The network processes the call request to determine 194 if the call can be progressed. If so, the network indicates the value 195 of the newly allocated VPCI/VCI in its first response to the the 196 SETUP message, which may either be a CALL PROCEEDING or CONNECT 197 message. If a call cannot be accepted, by the network or destination 198 ATM endpoint, a RELEASE COMPLETE is sent. At the destination ATM 199 endpoint, the network offers the call using the SETUP message. If 200 the destination endpoint is able to accept the call, it responds with 201 a CONNECT message; otherwise, it sends a RELEASE COMPLETE message. 203 Release can be initiated by either endpoint or (rarely) by the 204 network. When an endpoint wishes to release a call, it sends a 205 RELEASE message to the network. The network responds with a RELEASE 206 COMPLETE message, frees up resources associated with the call, and 207 initiates clearing toward the other endpoint. The network initiates 208 clearing by sending a RELEASE message to the ATM endpoint, which 209 reponds by sending a RELEASE COMPLETE message. Upon receipt of the 210 RELEASE COMPLETE message, the network frees any resources associated 211 with the call. 213 6. Overview of call establishment message content 215 Signaling messages are structured to contain mandatory and optional 216 variable length information elements (IEs). IEs are further 217 subdivided into octet groups, which in turn are divided into fields. 219 IEs contain information related to the call, which may be relevant to 220 the network, the peer endpoint or both. Selection of optional IEs 221 and the content of mandatory and optional IEs in call establishment 222 message determines the parties to and nature of the communication 223 over the ATM connection. For example, the call establishment message 224 for a call which will be used for constant bitrate video over AAL 1 225 will have different contents than a call which will be used for IP 226 over AAL 5. 228 A SETUP message which establishes an ATM connection to be used for IP 229 and multiprotocol interconnection calls SHALL contain the following 230 IE: 232 AAL Parameters 233 ATM User Cell Rate (ATM Traffic Descriptor in UNI 3.1 erratum) 234 Broadband Bearer Capability 235 Broadband Low Layer Information 236 QoS Parameter 237 Called Party Number 238 Calling Party Number 240 and may, under certain circumstance contain the following IEs : 242 Calling Party Subaddress 243 Called Party Subaddress 244 Transit Network Selection 246 In UNI 3.0 the AAL Parameters and the Broadband Low Layer Information 247 IEs are optional in a SETUP message. However, in support of IP over 248 ATM these two IEs MUST be included. Annex A shows an example SETUP 249 message coded in the manner indicated in this draft. 251 7. Information Elements with Endpoint to Endpoint Significance 253 This section describes the coding of, and procedures surrounding, 254 information elements in a SETUP message with significance only to the 255 endpoints of an ATM call supporting IP and multiprotocol operation. 257 7.1. ATM Adaption Layer Parameters 259 The AAL Parameters IE (see section 5.4.5.5 and Annex F of [ATMF93]) 260 carries information about the ATM Adaption Layer (AAL) to be used on 261 the connection. RFC 1483 specifies encapsulation of IP over AAL 5. 262 Thus, AAL 5 SHALL be indicated in the "AAL type" field. 264 Coding and procedure related to the 'Forward and Backward Maximum 265 CPCS-SDU Size' fields are discussed in [ATKI94]. 267 The 'mode' field SHOULD be omitted from the AAL Parameters IE. If 268 present it is appropriate to set it to "message" mode, as opposed to 269 "streaming" mode. Nevertheless, it SHALL be ignored by the 270 destination endsystem. 272 Ordinarily, no Service Specific Convergence Sublayer (SSCS) will be 273 used for multiprotocol interconnect over AAL5. Therefore, the SSCS 274 The exception will occur in the event that the network provides 275 interworking between ATM and Frame Relay. In this case, the ATM 276 endsystem will receive a SETUP or CONNECT message containing an AAL 277 Parameters IE with the SSCS Type field coded as Frame Relay SSCS. 278 The call SHALL be cleared with cause #93, AAL Parameters not 279 supported unless the ATM endsystem supports RFC 1490 encapsulation 280 over FRSSCS, and a Broadband Low Layer Information IE is coded to 281 indicate RFC 1490 encapsulation (see below). 283 Format and field values of AAL Parameters IE 285 ---------------------------------------------------------- 286 | aal_parameters | 287 ---------------------------------------------------------- 288 | aal_type 5 (AAL 5) | 289 | fwd_max_sdu_size_identifier 140 | 290 | fwd_max_sdu_size 9188 (default IP MTU) | 291 | bkw_max_sdu_size_identifier 129 | 292 | bkw_max_sdu_size 9188 (default IP MTU) | 293 | sscs_type identifier 132 | 294 | sscs_type 0 (null SSCS) | 295 ---------------------------------------------------------- 297 7.2. Broadband Low Layer Information 299 Selection of an encapsulation to support IP and multiprotocol 300 interconnection over an ATM VCC is done using the Broadband Low Layer 301 Information (B-LLI) IE, along with the AAL Parameters IE, and the B- 302 LLI negotiation procedure. 304 Protocol encapsulation for multiprotocol interconnection over ATM ALL 305 5 is specified in RFC 1483. Three encapsulation are provided; these 306 are: 308 (a) LLC/SNAP encapsulation 309 (b) VC-multiplexing (null encapsulation) 310 (c) Use of RFC 1490 over the Frame Relay Service Specific 311 Convergence Sublayer (FRSSCS) 313 The example codings for the B-LLI IE provided in Appendix D of the 314 ATM Forum UNI 3.0 specification were selected to correspond to the 315 RFC 1483 encapsulations. 317 RFC 1577 specifies LLC/SNAP as the default encapsulation. Therefore 318 LLC encapsulation SHOULD be indicated in the B-LLI as shown in figure 319 D.3.1 of [ATMF93]. Signaling indication of other encapsulations is 320 discussed in the next section. Note that in this case only LLC is 321 indicated in the B-LLI. It is up to the LLC layer to look into the 322 encapsulation header of the packet. If the SNAP header indicates IP, 323 it is the LLC layer's job to hand the packet up to IP. 325 Format of B-LLI IE indicating LLC/SNAP encapsulation 326 ---------------------------------------------------------- 327 | bb_low_layer_information | 328 ---------------------------------------------------------- 329 | layer_2_id 2 | 330 | user_information_layer 12 (lan_llc - ISO 8802/2) | 331 ---------------------------------------------------------- 333 7.2.1. Encapsulation negotiation 335 The call/connection control signaling protocol includes a mechanism 336 to support negotiation of encapsulation for endsystems that support 337 more than one. This section describes the procedures for negotiation 338 of an encapsulation. 340 As stated in the previous section, this I-D requires that hosts and 341 router which are ATM endsystems implement LLC/SNAP encapsulation. 342 Nevertheless, RFC 1483 also specifies VC-multiplexing and recognizes 343 use of RFC 1490 over FRSSCS. VC-multiplexing SHOULD be implemented to 344 achieve maximum interoperability. Implementation of RFC 1490 345 encapsulation over FRSSCS is also recommended for interworking with 346 Frame Relay networks. Such interworking does have its problems 347 however as discussed later. 349 The B-LLI negotiation procedures (see Annex C of [ATMF93]) are 350 initiated by the calling ATM endsystem by including up to three 351 instance of the B-LLI IE in the SETUP message in descending order of 352 preference (following the rule for repeating IE in section 5.4.5.1 of 353 [ATMF93]). 355 The following is the list of the three possible combinations that B- 356 LLI IE instances may be included in the SETUP message. Each instance 357 is referred to by its encapsulation name as it appears in RFC 1483, 358 and corresponding section labels from ATM Forum UNI 3.0 359 specification. 361 a) LLC/SNAP encapsulation (D.3.1) 363 In this case, the calling ATM endsystem can only send and receive 364 packets preceded by an LLC/SNAP identification. 366 b) VC-multiplexing (D.3.2) and LLC/SNAP (D.3.1) 368 The calling ATM endsystem prefers to use VC multiplexing, but is 369 willing to agree to use LLC/SNAP encapsulation instead, if the called 370 ATM endsytem only supports LLC/SNAP. 372 c) RFC 1490 encapsulation (MLPID multiplexing) over FRSSCS 373 (D.3.3, omitting octets 7a and 7b and MUST have FR-SSCS in SSCS 374 type of AAL Parameters IE.) 376 The calling ATM endsystem can only send and receive packets using 377 RFC 1490 encapsulation (NLPID multiplexing) over FRSSCS. Use of RFC 378 1490 encapsulation presently cannot be negotiated as an alternative 379 to LLC encapsulation or VC-multiplexing (see Appendix B). If the B- 380 LLI IE is encoded to indicate RFC 1490 encapsulation, the SSCS type 381 field of the AAL Parameters IE SHALL coded to indicate FRSSCS. Note 382 that the AAL Parameters IE can not be coded to indicate both NULL and 383 FR-SSCS and neither LLC encapsulation nor VC-multiplexing will be 384 interoperable when used over FR-SSCS. 386 The called ATM endsystem SHALL select the encapsulation method it is 387 able to support from the B-LLI IE present in SETUP message. If it 388 supports more than one of the encapsulations indicated in the SETUP 389 message, it MUST select the one which appears first in the SETUP 390 message. The called ATM endsystem then includes the B-LLI IE content 391 corresponding to the selected encapsulation in the CONNECT message. 392 If the called endsystem does not support any encapsulation indicated 393 in the incoming SETUP message, it SHALL clear the call with cause 394 #88, incompatible destination. If the received SETUP message does 395 not include the B-LLI IE, the call SHALL be cleared with cause #21, 396 "call rejected", with diagnostics indicating rejection reason = 397 information element missing and the B-LLI IE identifier. As 398 described in Annex C of [ATMF93], if the calling ATM endpoint 399 receives a CONNECT message that does not contain a B-LLI IE, it SHALL 400 assume the encapsulation indicated in the first BLLI IE that it 401 included in the SETUP message. 403 7.2.2. Framework for Protocol Layering 405 The support of connectionless services from a connection oriented 406 link layer exposes general problems of connection management, 407 specifically the problems of connection acceptance, assignment of 408 quality of service, and connection shutdown. For a connection to be 409 associated with the correct protocol on the called host, it is 410 necessary for information about one or more layers of protocol 411 identification to be associated with a connection "management entity" 412 or "endpoint". This association is what we call a binding in this 413 draft. In this section we attempt to describe a framework for a 414 usable binding or service architecture given the available IEs in the 415 ATM call control messages. 417 It is important to distinguish between two basic uses of protocol 418 identification elements present in the UNI setup message. The first 419 is the description of the protocol encapsulation that will be used on 420 the data packet over the virtual connection, the second is the entity 421 that will be responsible for managing the call. All protocols present 422 in various IEs should be used to encapsulate the call, but the most 423 specific, or highest, layer specified should manage the call. This 424 defines a hierarchy of services and provides a framework for 425 applications, including LLC and IP, to terminate calls. The hierarchy 426 provides a clear mechanism for support of higher level protocol and 427 application bindings, when their use and specification is defined in 428 the appropriate standards bodies. 430 The B-LLI is the only information element currently available in UNI 431 3.0 for designating the application endpoint. It contains codepoints, 432 which describe layer 2 and layer 3 protocols entities associated with 433 the call. There are other information elements under consideration in 434 the ATM Forum and ITU, which could come to play a significant role in 435 the description of application to connection binding, but their use 436 is not currently sanctioned by the Forum, and they are not part of 437 the framework described by RFC1577. They include B-HLI, for 438 containing information for a higher layer protocol, Network Layer 439 Information (NLI) to contain information for the network layer, and 440 UUI, which is meant to carry information for use by the top level 441 application. 443 In general, it would be desirable to allow data packets to be stored 444 directly into applications address space after connection is 445 established. This is possible only if we have both forward and 446 backward encapsulation indication in the signaling message. 448 To support multiprotocol encapsulation, the LLC protocol management 449 entity should accept all connections directed specifically to it. For 450 each connection that is terminated at LLC, all protocols that are 451 intended to be supported by this host through that interface should 452 be made available. Termination of the call is at the discretion of 453 the LLC connection management entity, based on the information it has 454 available to it, specifically the perceived packet traffic and 455 administrative policies of the host. 457 VC-multiplexed IP is specified by using only the layer 3 identifier 458 in B-LLI using an ISO-TR-9577 protocol codepoint. Since no layer 2 459 is specified, frames produced by AAL processing will be given 460 directly to IP. Since IP is highest specified protocol, it will be 461 responsible for managing the connection. 463 8. Information Elements with Significance to the ATM Network 465 This section describes the coding of, and procedures surrounding, 466 information elements with significance to the ATM network, as well as 467 the endpoints of an ATM call supporting multiprotocol operation. 469 The standards, implementation agreements, research and experience 470 surrounding such issues as traffic management, quality of service and 471 bearer service description are still evolving. Much of this material 472 is cast so as to give the greatest possible latitude to ATM network 473 implementation and service offerings. ATM endsystems need to match 474 the traffic contract and bearer service they request from the network 475 to the capabilities offered by the network. Therefore, this memo can 476 only offer what, at the present time, are the most appropriate and 477 efficient coding rules to follow for setting up IP and ATMARP VCCs. 479 8.1. ATM User Cell Rate 481 The ATM Traffic descriptor is contained in the ATM User Cell Rate IE 482 (called ATM Traffic Descriptor in UNI 3.1 erratum). It characterizes 483 the ATM virtual connection in terms of peak cell rate (PCR), 484 sustainable cell rate (SCR), and maximum burst size. This 485 information is used to allocate resources (e.g., bandwidth, 486 buffering) in the network. In general, the ATM traffic descriptor 487 for supporting multiprotocol interconnection over ATM will be driven 488 by factors such as the capacity of the network, conformance 489 definition supported by the network, performance of the ATM endsystem 490 and (for public networks) cost of services. 492 The most convenient model of IP behavior corresponds to the Best 493 Effort Capability (see section 3.6.2.4 of [ATMF93]). If this 494 capability is offered by the ATM network(s), it SHOULD be requested 495 by including the Best Effort Indicator, the peak cell rate forward 496 (CLP=0+1) and peak cell rate backward (CLP=0+1) fields in the ATM 497 User Cell Rate IE. 499 Format and field values of ATM User Cell Rate IE 501 ---------------------------------------------------------- 502 | user_cell_rate | 503 ---------------------------------------------------------- 504 | fwd_peak_cell_rate_0+1_identifier 132 | 505 | fwd_peak_cell_rate_0+1 (link rate) | 506 | bkw_peak_cell_rate_0+1_identifier 133 | 507 | bkw_peak_cell_rate_0+1 (link rate) | 508 | best_effort_indication 190 | 509 ---------------------------------------------------------- 511 [ATMF93] does not provide any capability for negotiation of the ATM 512 User Cell Rate. This means that: 514 a) the calling endsystem SHOULD have a "pretty good idea" as to the 515 traffic contract that will be acceptable to both the called endsystem 516 and the network. 518 b) if, in response to a SETUP message, a calling endsystem receive 519 a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by 520 a RELEASE COMPLETE message, with cause #51, User cell rate 521 unavailable, it MAY examine the diagnostic field of the Cause IE and 522 reattempt the call after selecting smaller values for the 523 parameter(s) indicated. If the RELEASE COMPLETE or RELEASE message 524 is received with cause #73, Unsupported combination of traffic 525 parameter, it MAY try other combinations from table 5-7 and 5-8 of 526 [ATMF93]. 528 c) the called endsystem SHOULD examine the ATM traffic descriptor 529 IE in the SETUP message. If it is unable to process cells at the 530 Forward PCR indicated, it should clear the call cause #51, User cell 531 rate unavailable. 533 8.2. Broadband Bearer Capability 535 Broadband Bearer Connection Oriented Service Type X (BCOB-X) or Type 536 C (BCOB-C) are applicable for multiprotocol interconnection, 537 depending on the service(s) provided by the ATM network and the 538 capabilities (e.g. for traffic shaping) of the ATM endsystem. The 539 example coding of Broadband Bearer Capability in figure D.2.1 of 540 [ATMF93] applies for BCOB-C. When BCOB-X is specified, the "traffic 541 type" and "timing requirements" fields SHALL both be set to "no 542 indication". The susceptibility to clipping and User plane traffic 543 configuration SHALL be set to "not susceptible to clipping" and 544 "point-to-point", respectively. 546 Format and field values of Broadband Bearer Capability IE 548 ---------------------------------------------------------- 549 | bb_bearer_capability | 550 ---------------------------------------------------------- 551 | spare 0 | 552 | bearer_class 16 (BCOC-X) | 553 | spare 0 | 554 | traffic_type 0 (no indication) | 555 | timing_reqs 0 (no indication) | 556 | susceptibility_to_clipping 0 (not suscept) | 557 | spare 0 | 558 | user_plane_configuration 0 (point_to_point) | 559 ---------------------------------------------------------- 561 [ATMF93] does not provide any capability for negotiation of the 562 broadband bearer capability. This means that: 564 a) the calling endsystem SHOULD have a "pretty good idea" as to the 565 broadband bearer capability that will be acceptable to both the 566 called endsystem and the network. 568 b) if, in response to a SETUP message, a calling endsystem receives 569 a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by 570 a RELEASE COMPLETE message, with cause #57, bearer capability not 571 authorized or #58 bearer capability not presently available, it MAY 572 reattempt the call after selecting another bearer capability. 574 8.3. QoS Parameter 576 The Unspecified QoS class (Class 0), the Specified QoS Class for 577 Connection Oriented Data Transfer (Class 3) or the Specified QoS 578 Class for Connectionless Data Transfer (Class 4) may be applicable 579 to multiprotocol over ATM. The available combination of QoS 580 parameters with the ATM User Cell Rate and the Broadband Bearer 581 Capability is specific to the ATM network. 583 Format and field values of QoS Parameters IE 585 ---------------------------------------------------------- 586 | qos_parameter | 587 ---------------------------------------------------------- 588 | qos_class_fwd 0 (class 0) | 589 | qos_class_bkw 0 (class 0) | 590 ---------------------------------------------------------- 592 [ATMF93] does not provide any capability for negotiation of Quality 593 of Service parameters. This means that: 595 a) the calling endsystem SHOULD have a "pretty good idea" as to the 596 QoS classes offered by the ATM network in conjunction with the 597 requested Broadband Bearer Service and traffic descriptor. 599 b) if, in response to a SETUP message, a calling endsystem receives 600 a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by 601 a RELEASE COMPLETE message, with cause #49, Quality of Service 602 unavailable, it MAY reattempt the call after selecting another QoS 603 class. 605 Note: In UNI 3.1 a new code point of '00' has been added to the 606 coding standard field in the IE header. This code point has been 607 added for compatibility with Q.2931 and is to be used when indicating 608 the Unspecified QoS class (class 0). Therefore, the coding standard 609 field SHALL be set to '00' when indicating QoS class 0, as is 610 suggested for IP. 612 8.4. ATM Addressing information 614 ATM addressing information is carried in the Called Party Number, 615 Calling Party Number, and, under certain circumstance, Called Party 616 Subaddress, and Calling Party Subaddress IE. Section 5.1.3 and Annex 617 A of [ATMF93] describes the syntax and semantics of ATM addressing 618 information, including use of the subaddress IE. Section 5.8 of 619 [ATMF93] provides the procedure for an ATM endsystem to learn its own 620 ATM address from the ATM network, for use in populating the Calling 621 Party Number IE. 623 Resolution of IP address to an ATM address is required of hosts and 624 router which are ATM endsystems that use ATM SVCs. RFC 1577 provides 625 a mechanism for doing IP to ATM address resolution in the classical 626 IP model. 628 Format and field values of Called Party Number IE 630 ---------------------------------------------------------- 631 | called_party_number | 632 ---------------------------------------------------------- 633 | type_of_number (international number / unknown) | 634 | addr_plan_ident (ISDN / ISO NSAPA) | 635 | number (E.164 / OSI NSAPA) | 636 ---------------------------------------------------------- 638 Format and field values of Calling Party Number IE 640 ---------------------------------------------------------- 641 | calling_party_number | 642 ---------------------------------------------------------- 643 | type_of_number (international number / unknown) | 644 | addr_plan_ident (ISDN / ISO NSAPA) | 645 | presentation_indic (presentation allowed) | 646 | spare 0 | 647 | screening_indic (user provided verified & passed) | 648 | number (E.164 / OSI NSAPA) | 649 ---------------------------------------------------------- 651 9. Dealing with Failure of Call Establishment 653 If an ATM call attempt fails with any of the following cause, the 654 situation SHALL be treated as "network unreachable" (if the called 655 ATM endsystem is a router) or "host unreachable" (if the called ATM 656 endsystem is a host). 658 # 1 unallocated (unassigned) number 659 # 3 no route to destination 660 # 17 user busy 661 # 18 no user reponding 662 # 27 destination out of order 663 # 38 network out of order 664 # 41 temporary failure 665 # 47 resource unavailable, unspecified 667 If an ATM call attempt fails with any of the following causes, the 668 ATM endpoint may retry the call, changing (or adding) the IE(s) 669 indicated by the cause code and diagnostic. 671 # 2 no route to specified transit network 672 # 21 call rejected 673 # 22 number changed 674 # 23 user rejects call with CLIR 675 # 49 quality of service unavailable 676 # 51 user cell rate unavailable 677 # 57 bearer capability not authorized 678 # 58 bearer capability not presently available 679 # 65 bearer capability not implemented 680 # 73 unsupported combination of traffic parameter 681 # 88 incompatible destination 682 # 91 invalid transmit network selection 683 # 93 AAL parameter cannot be supported 685 Any cause in the protocol error class (value 96 to 111) where the 686 location is either private network serving the local user or public 687 network serving the local user 689 10. Security Consideration 691 Security consideration are not addressed in this memo. 693 11. Acknowledgments 695 The authors wish to thank the work of their colleagues who attend the 696 IP over ATM working group; the ATM Forum Technical Committee; the 697 ATM Signaling Subworking Group in ANSI-Accredited Technical 698 Subcommittee T1S1; the ATM Access Signaling experts in ITU-T 699 (formerly CCITT) Study Group 11. Rao Cherukuri (IBM) and Jeff Kiel 700 (formerly with Bellcore, presently with BellSouth) were particularly 701 valuable in coordinating among T1S1, ITU-T and the ATM Forum to make 702 sure that the needs of multiprotocol over ATM could be expressed in 703 the ATM signaling protocol. 705 References 707 [ATKI94] Atkinson, R., "RFC 1626: IP MTU over ATM AAL5", Naval 708 Research Laboratory, May 94 710 [ATMF93] ATM Forum, "ATM User-Network Interface Specification Version 711 3.0", (Englewood Cliffs, NJ: Prentice Hall, 1993) 713 [COLE94] IP over ATM: A Framework Document Internet Draft 715 [HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption 716 Layer 5", RFC 1483, USC/Information Science Institute, July 1993. 718 [ISO8473] ISO/IEC 8473, Information processing systems - Data 719 communications - Protocol for providing the connectionless-mode 720 network service, 1988. 722 [ISO9577] Information Technology - Telecommunication and information 723 exchange between systems - Protocol identification in the network 724 layer ISO/IEC TR9577 (International Standards Organization: Geneva, 725 1990) 727 [LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC1577, 728 Hewlett-Packard Laboratories, December 1993 730 [Q.2931] Broadband Integrated Service Digital Network (B-ISDN) 731 Digital Subscriber Signaling System No.2 (DSS2) User Network 732 Interface Layer 3 Specification for Basic Call/Connection Control 733 ITU-T Recommendation Q.2931, (International Telecommunication Union: 734 Geneva, 1994) (to be published March, 1994) 736 Appendix A. Frame Relay Interworking 738 1. SSCS vs. LLC 740 Procedures for Frame Relay to ATM signaling interworking have not yet 741 been specified by ITU-T, the ATM Forum, or the Frame Relay Forum. If 742 an ATM endsystem wishes to use FR-SSCS, FR-SSCS and RFC 1490 743 encapsulation must both be be specified in the SETUP message. 744 Nevertheless, since neither LLC encapsulation nor VC-multiplexing 745 will interoperate when used over FR-SSCS, these two encapsulations 746 cannot be negotiated as alternatives to RFC 1490 encapsulation. 748 In ATM environments the SSCS layer is part of the AAL functionality. 749 The SSCS serves to coordinate the needs of a protocol above with the 750 requirements of next lower layer, the Common Part Convergence 751 Sublayer (CPCS). For example, the UNI ATM signaling protocol runs on 752 top of a signaling SSCS which among other things provides an assured 753 transfer service for signaling messages. Since the SSCS is considered 754 part of the AAL, the SSCS type is specified as one of the parameters 755 in the AAL Parameters IE. To date there has not been an SSCS defined 756 for data transmission in ATM and this type field is usually set to 757 'null'. 759 The exception occurs when doing FR interworking where an ATM 760 endsystem may choose to use the FR-SSCS over AAL 5 in order to 761 communicate with a FR endsystem. In that case the SSCS type in the 762 AAL Parameters IE of the SETUP message is set to 'FR-SSCS'. 764 Also included in a SETUP message is an indication in the B-LLI IE of 765 the protocol layers to be used above the AAL. In particular, ATM 766 connections established to carry connectionless network interconnect 767 traffic require a layer above the AAL for multiplexing multiple 768 protocols over a single VC [HEIN 93]. As mentioned above, RFC 1577 769 defines LLC as default multiplexing layer for IP over AAL5. 771 Specification of the SSCS restricts the encapsulation protocol used 772 over it, since RFC 1483 (in addition to applicable ITU standards) 773 requires the use of RFC 1490 encapsulation over the FR-SSCS, and LLC 774 or null encapsulation otherwise. The fact that it is not possible, 775 in the UNI 3.1 signaling specification, to negotiate between the FR- 776 SSCS and null SSCS can result in interoperability restrictions 777 between stations that implement and wish to use the FR-SSCS and those 778 that do not, even though they both are using IP. The guidelines in 779 the following section were developed to decrease the chance that such 780 interoperability restrictions occur. 782 2. Scenarios for Interworking 784 The following discussion uses the terms "network interworking" and 785 "service interworking". "Network interworking" uses FR-SSCS over 786 AAL5 between the InterWorking Unit (IWU) and the ATM endsystem, and 787 the ATM endsystem is aware that the other endpoint is a FR/ATM 788 Network IWU. "Service interworking" aims to make the operation 789 transparent to the ATM endsystem by adding encapsulation translation 790 and other payload processing in the FR/ATM Service IWU to allow the 792 ATM endsystem to operate as if it were talking to another ATM 793 endsystem. 795 The most common scenario where FR-SSCS could be negotiated is between 796 an ATM endsystem and a FR/ATM network IWU to allow connectivity among 797 an ATM endsystem and a FR endsystem residing behind a FR/ATM network 798 IWU. 800 -------- -------- 801 ------- | | | | ------- 802 | A | | FR/ATM | | ATM | | B | 803 | (FR) |----->| IWU |----->| switch |----->| (ATM) | 804 ------- | | | | ------- 805 -------- -------- 807 | | | | 808 -----> ---------------------> 809 FR call ATM call 811 A network IWU can place a call to an ATM host (on behalf of a FR 812 host) by signaling for FR-SSCS and assuming that the ATM endsystem 813 supports FR-SSCS. The B-LLI IE SHALL be encoded to indicate RFC 1490 814 encapsulation and the SSCS type field of the AAL Parameters IE SHALL 815 be coded to indicate FR-SSCS. If the FR-SSCS negotiation fails 816 because the called ATM host does not support FR-SSCS, the IWU can 817 retry the call negotiating for LLC encapsulation or VC-multiplexing. 818 However, the IWU can only attempt the retry if it is able to do FR- 819 ATM service interworking. Such service interworking adds extra 820 processing overhead during the call. 822 The even more problematic case occurs when a call is requested in the 823 opposite direction, i.e. when an ATM host places a call to a host 824 residing behind an IWU. 826 -------- -------- 827 ------- | | | | ------- 828 | B | | FR/ATM | | ATM | | A | 829 | (FR) |<-----| IWU |<-----| switch |<-----| (ATM) | 830 ------- | | | | ------- 831 -------- -------- 833 | | | | 834 <----- <--------------------- 835 FR call ATM call 837 Not knowing that the destination resides behind an IWU, the calling 838 host will negotiate for the default LLC encapsulation (possibly 839 requesting VC-multiplexing as an alternative). In this situation the 840 IWU can accept the call and do the necessary service interworking or 841 reject the call specifying 'AAL Parameters not supported'. If the IWU 842 rejects the call it risks the possibility that calling host does not 843 support FR-SSCS or simply does not retry and the call will never be 844 established. 846 3. Possible Alternatives 848 While Frame Relay interworking is possible, it is not possible to 849 negotiate FR-SSCS with LLC encapsulation or VC-multiplexing, which 850 decreases the chances of completing an ATM call. However, 851 interoperability can be increased using the following alternatives: 853 1. Maintaining external knowledge that a particular destination uses 854 FR-SSCS. This knowledge can be configured, or in the future added to 855 some network host database. 857 2. In the absence of such external knowledge, an ATM endsystem is 858 required to negotiate for the default LLC encapsulation (possibly 859 requesting VC-multiplexing as an alternative). There are three 860 subcases: 862 2a. The IWU supports service interworking and network interworking, 863 and prefers service interworking. The IWU simply accepts the call 864 using LLC encapsulation. 866 2b. The IWU supports service interworking and network interworking, 867 and prefers network interworking. The IWU simply accepts the call, 868 but attempts to open a parallel connection back to the original ATM 869 endsystem negotiating the FR-SSCS use. If the connection is 870 accepted, the IWU closes the service interworking connection. 872 2c. The IWU supports network interworking only. The IWU rejects the 873 call specifying 'AAL Parameters not supported', and then attempts to 874 open a connection back to the original ATM endsystem negotiating the 875 FR-SSCS use. 877 Appendix B. Sample Signaling Messages 879 This annex shows sample codings of the SETUP and CONNECT signaling messages. 880 The fields in the IE header are not shown. 882 +--------------------------------------------------------------------+ 883 SETUP 885 Information Elements/ 886 Fields Value/(Meaning) 887 -------------------- --------------- 889 aal_parameters 890 aal_type 5 (AAL 5) 891 fwd_max_sdu_size_ident 140 892 fwd_max_sdu_size 9188 (default, send IP MTU value) 893 bkw_max_sdu_size_ident 129 894 bkw_max_sdu_size 9188 (default, recv IP MTU value) 895 mode identifier 131 * 896 mode message * 897 sscs_type identifier 132 898 sscs_type 0 (null SSCS) 900 user_cell_rate 901 fwd_peak_cell_rate_0_1_ident 132 902 fwd_peak_cell_rate_0_1 (link rate) 903 bkw_peak_cell_rate_0_1_ident 133 904 bkw_peak_cell_rate_0_1 (link rate) 905 best_effort_indication 190 907 bb_bearer_capability 908 spare 0 909 bearer_class 16 (BCOC-X) 910 spare 0 911 traffic_type 0 (no indication) 912 timing_reqs 0 (no indication) 913 susceptibility_to_clipping 0 (not susceptible to clipping) 914 spare 0 915 user_plane_configuration 0 (point_to_point) 917 bb_low_layer_information 918 layer_2_id 2 919 user_information_layer 12 (lan_llc (ISO 8802/2) 921 qos_parameter 922 qos_class_fwd 0 (class 0) 923 qos_class_bkw 0 (class 0) 925 called_party_number 926 type_of_number (international number / unknown) 927 addr_plan_ident (ISDN / ISO NSAPA) 928 number (E.164 / OSI NSAPA) 930 calling_party_number 931 type_of_number (international number / unknown) 932 addr_plan_ident (ISDN / ISO NSAPA) 933 presentation_indic (presentation allowed) 934 spare 0 935 screening_indic (user_provided verified and passed) 936 number (E.164 / OSI NSAPA) 938 +--------------------------------------------------------------------+ 939 Figure 1. 940 Sample contents of SETUP message 942 [* : optional, ignored if present] 944 In IP over ATM environments the inclusion of the "AAL parameters" IE 945 is *mandatory* to allow for MTU size negotiation between the source 946 and destination. The "Broadband Low Layer Information" IE is also 947 mandatory for specifying the IP encapsualtion scheme. 949 +--------------------------------------------------------------------+ 950 CONNECT 952 Information Elements/ 953 Fields Value 954 -------------------- ----- 955 aal_parameters 956 aal_type 5 (AAL 5) 957 fwd_max_sdu_size_ident 140 958 fwd_max_sdu_size 9188 (default, send IP MTU value) 959 bkw_max_sdu_size_ident 129 960 bkw_max_sdu_size 9188 (default, recv IP MTU value) 961 mode identifier 131 * 962 mode message * 963 sscs_type identifier 132 965 bb_low_layer_information 966 layer_2_id 2 967 user_information_layer 12 (lan_llc (ISO 8802/2) 969 connection identifier 970 spare 0 971 vp_assoc_signaling 1 (explicit indication of VPCI) 972 preferred_exclusive 0 (exclusive vpci/vci) 973 vpci (assigned by network) 974 vci (assigned by network) 975 +--------------------------------------------------------------------+ 976 Figure 2. 977 Sample contents of CONNECT message 979 As in the SETUP message, IP over ATM environments demand the inclusion 980 of the "AAL parameters" IE so that the destination may specify the 981 MTU size that it is willing to receive.