idnits 2.17.1 draft-ietf-l2tpext-atmext-rfc3301-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 4 instances of too long lines in the document, the longest one being 340 characters in excess of 72. ** The abstract seems to contain references ([RFC2661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (June 2002) is 7986 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNI' -- Possible downref: Non-RFC (?) normative reference: ref. 'AESA' -- Possible downref: Non-RFC (?) normative reference: ref. '10646' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Submitted to L2TP Working Group Yves T'Joens 3 INTERNET DRAFT Bernard Sales 4 Alcatel 6 Paolo Crivellari 7 Belgacom 8 June 2002 9 Expires December, 2002 11 Layer Two Tunneling Protocol : ATM Access Network Extensions 13 Status of this memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Distribution of this memo is unlimited. 36 Abstract 38 L2TP [RFC2661] specifies a protocol for tunnelling PPP packets over 39 packet based networks and over IP networks in particular. L2TP 40 [RFC2661] supports remote access by ISDN and PSTN networks. This 41 document augments the procedures described in [RFC2661] to further 42 support ATM SVC or PVC based access networks. The extensions defined 43 within this document allow for asymmetric bi-directional call 44 establishment and service selection in the ATM access network. 46 Table Of Contents 47 1. Introduction 48 1.1 Conventions 49 2. Assumptions 50 2.1 Topology 51 2.2 Connection Establishment 52 2.3 LCP Negotiation 53 3. ATM access enhanced procedures 54 3.1 ATM connectivity 55 3.2 Tunnel establishment 56 3.3 Call establishment 57 3.3.1 Incoming Call Establishment 58 3.3.2 Outgoing Call Establishment 59 3.4 Framing 60 4. Service model issues 61 4.1 Authentication 62 4.2 Authorization 63 5. New and extended AVPs 64 5.1 New AVP Summary 65 5.2 New AVP definition 66 5.3 Changed AVP Definition 67 6. IANA considerations 68 7. Security considerations 69 8. Acknowledgements 70 9. References 71 10. Contacts 72 11. Full copyright statement 74 1. Introduction 76 L2TP [RFC2661] defines the procedures for tunneling PPP sessions 77 between a so called L2TP Access Concentrator (LAC) and an L2TP 78 Network Server (LNS). The main focus of [RFC2661] is on supporting 79 HDLC based ISDN/PSTN access networks. 81 This document augments the procedures described in [RFC2661] to 82 further support ATM SVC or PVC based access networks. Support for ATM 83 access networks requires extensions to the present L2TP procedures so 84 as to cope with : 86 (a) the traffic management aspects of ATM connections (e.g. 87 assymetric bandwidth allocation and service category selection 88 capabilities), 90 (b) the addressing format to be used in switched ATM networks [AESA] 91 and 93 (c) the limititations imposed on LCP negotiation by transporting PPP 94 over AAL5 over the access network segment of the PPP connection 96 [RFC2364]. 98 Within this draft, the necessary extensions to [RFC2661] are defined 99 to cope with issues (a) and (b), issue (c) which is not specific to 100 ATM may be solved as described in [L2TP_link]. 102 1.1 Conventions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Assumptions 110 In this section we describe some assumptions that have lead to the 111 extensions described in this draft. 113 2.1 Topology 115 The procedures as defined in [RFC2661] apply mainly to access network 116 technology such as PSTN and ISDN, which may be respectively 117 asynchronous HDLC and synchronous HDLC based. The aim of this 118 document is to extend L2TP support to allow for user / LAC 119 communication based on ATM access network technology. 121 2.2 Connection Establishment 123 Due to the wide variety of existing signalling protocols and ATM 124 service categories, and their support or non-support within ATM based 125 access networks, this document takes as approach to provide for a 126 flexible identification of ATM connection characteristics while 127 establishing outgoing and incoming L2TP calls. The procedures as 128 defined within this document allow the allocation of asymmetric 129 bandwidth and service category selection in terms of real or non-real 130 time requirements on the ATM portion of the access network. 132 As such, the detailed signalling protocol specific information 133 elements that are necessary for switched VC service, are explicitly 134 not negotiated during call establishment over the L2TP tunnel. 136 In order to identify the endpoint of the ATM connection within the 137 ATM access network, SVCs can be established on the basis of the ATM 138 end system addressing format [AESA]. For PVC based services, the PVC 139 can either be referred to by using the ATM end system addressing 140 procedure (Called/Calling Number), or by making use of a textual name 141 (Service Name). The latter is inspired by the procedures defined 142 within [Auto_PVC]. 144 2.3 LCP negotiation 146 The procedures described within this document may be combined with 147 the procedures described in [L2TP_link] to limit LCP negotiation 148 between LNS and user, so as to enforce PPP over AAL5 specific LCP 149 negotiation [RFC2364]. 151 3. ATM access enhanced procedures 153 In order to illustrate the procedures specified within this document, 154 this section will provide an operational description of Virtual 155 dial-up access through an ATM based access network (e.g., ADSL). Note 156 that the emphasis is on the changes proposed within this document 157 relative to [RFC2661]. 159 3.1 ATM connectivity 161 Prior to initiating the PPP protocol layer, a Virtual Connection (VC) 162 MUST be established between the user and the Network Access Server 163 (LAC). This virtual connection MAY either be a preconfigured 164 Permanent VC(PVC), where the access network provider, NAS and user 165 agree beforehand on the characteristics of the PVC, or MAY be an on- 166 demand switched VC(SVC), where the negotiation between user, network 167 and NAS takes place by means of an ATM signalling protocol. Note that 168 for establishing PVCs, alternative use may be made of the procedures 169 as described in [Auto_PVC]. 171 In both cases, the user is referred to as the virtual dial-in user. 173 Prior to accepting the switched connection from the virtual dial-in 174 user, the LAC MAY check with the LNS whether the call should be 175 accepted. In the latter situation, the LAC MAY determine based upon 176 parameters available within the call establishment message that this 177 concerns a virtual dial in user, or MAY undertake a partial 178 authentication of the end system/user, in order to bind the end 179 system/user with a specific LNS. 181 For PVC based users, the LAC MAY be triggered by the arrival of an 182 LCP Configure Request, or PPP Authentication request message from the 183 virtual dial-in user to initiate conversation with the LNS. Note that 184 the exact timing of triggering communication between LAC and LNS is 185 outside the scope of this document. 187 3.2 Tunnel establishment 189 If no tunnel connection currently exists to the desired LNS, one is 190 initiated. During the tunnel establishment, LNS and LAC indicate 191 bearer and framing capabilities to each other, according to normal 192 procedures. 194 The bearer capability is extended to allow the LAC to indicate its 195 support of ATM bearer devices. Positive receipt of this indication, 196 allows both LAC and LNS to use the extensions as defined within this 197 document to support ATM based incoming and outgoing calls. 199 3.3 call establishment 201 During incoming and outgoing broadband call establishment, the 202 following extensions are defined to existing procedures. 204 3.3.1 Incoming Call Establishment 206 The ATM connection between the virtual Dial-in user and LAC MAY 207 either be dynamically or statically established. When the VC 208 connection is dynamically established (Switched VC), the LAC will 209 receive a SETUP message over the interface that connects it to the 210 ATM network. This specification does not assume any specific 211 interface type (UNI or NNI). Permanent VC connections MAY either be 212 manually configured, or configured by use of the extensions to the 213 ILMI procedures as defined by [Auto_PVC]. 215 For switched VC connections, the LAC MAY select the peer LNS on the 216 basis of connection establishment information, or by allowing partial 217 PPP authentication of the virtual Dial-in user. The connection 218 establishment information that can be used by the LAC include Called 219 Party AESA, Called Party AESA Subaddress, Calling Party AESA or 220 Calling Party AESA Subaddress. 222 For Permanent VC connections, the LAC MAY be triggered by (a) the 223 establishment of the PVC, (b) by an LCP configure request, (c) by 224 partially authenticating the virtual Dial-in user, or (d) by means 225 outside the scope of this specification. 227 Within the ICRQ, the LAC connected to a compliant LNS MUST indicate a 228 broadband bearer in the Bearer Type AVP (B bit set to 1), MAY include 229 the Service Category AVP, and MAY include the Service Name AVP. 230 Further, the ICRQ message MAY contain the VPI/VCI identifier AVP. 231 This identifier can further be used at the LNS for management 232 purposes next to or alternative to the Physical Channel ID AVP. 234 In case the LAC is connected to a non-compliant LNS, it MAY use 235 Digital bearer in the Bearer Type AVP (D bit set to 1) for session 236 set up. Procedure for session set up continues as defined for digital 237 calls. 239 Within the ICCN, both Tx Connect Speed AVP and Rx Connect Speed 240 SHOULD be used if an assymetric connection has been established. 242 3.3.2 Outgoing Call Establishment 244 Within an OCRQ, the LNS MUST indicate to the LAC minimum and maximum 245 speeds for receive and transmit traffic (from the LAC perspective). 246 This is to allow for the bi-directional asymmetric nature of ATM 247 traffic contracts. Note that in order to support UBR connections 248 between LAC and user, the Minimum BPS MUST be set to zero. 250 Further during OCRQ, the LNS MAY include the required Service 251 Category AVP, i.e., indicating real time (rt) or non-real time (nrt) 252 transport services. The combination of minimum and maximum receive 253 and transmit speed, and the indication of the required service 254 category allows the LAC to establish an ATM connection according to 255 its own capabilities, and the ATM access network capabilities, 256 however within the service requirement for the PPP layer. 258 Real time connectivity can be provided by either CBR or rt-VBR ATM 259 service categories, non-real time connectivity can be provided by 260 UBR, nrt-VBR, ABR or GFR ATM service categories. 262 Further the LNS MUST indicate to the LAC in OCRQ message the called 263 number according to the format described in this document (NSAP 264 format). When the called number carries an all zero payload, the LAC 265 SHOULD look at the Service Name AVP to bind the tunnel call to an ATM 266 VC connection. 268 Next to the normal AVPs, the OCRP message MAY contain the VPI/VCI 269 identifier AVP. This identifier can further be used at the LNS for 270 management purposes next to or alternative to the Physical Channel ID 271 AVP. 273 3.4 Framing 275 Within this document the PPP PDU refers to the concatenation of PPP 276 protocol ID, PPP Information and PPP padding fields. 278 In the direction of user to LNS, the PPP PDU will be carried on top 279 of an AAL5 connection between user and LAC. The LAC MUST strip off 280 the AAL5 specific fields based on the encapsulation mechanism in use 281 on the ATM connection, i.e. VC multiplexed or LLC encapsulated 282 [RFC2364], and MUST encapsulate the PPP PDU with address and control 283 field, as per HDLC procedures, on the L2TP tunnel. 285 In the direction of LNS to user, the PPP PDU will be carried on top 286 of an AAL5 connection between LAC and user. The LAC MUST strip the 287 PPP PDU from the address and control field on the L2TP tunnel, and 288 insert the AAL5 specific fields based on the encapsulation mechanism 289 in use on the ATM connection, i.e. VC multiplexed or LLC 290 encapsulated. 292 4. Service model issues 294 4.1 Authentication 296 In case of ATM switched VC establishment, calling party number 297 information may be used for first level authentication much in the 298 same way as for PSTN or ISDN access. In case of permanent VC 299 establishment, authentication may not be an issue from the LAC side, 300 because of the permanent character of the VC. Bilateral agreement 301 between LAC and LNS providers may eliminate the authentication phase 302 in the latter case. 304 4.2 Authorization 306 Because of the flexibility of establishing ATM connections with 307 varying parameters, some authorization may be required prior to 308 accepting the establishment of a switched ATM connection from the 309 user with certain ATM traffic parameters. This authorization may be 310 performed against the ATM specific authentication information (e.g. 311 calling line id), or may be performed after partial authentication of 312 the user at the PPP level. Non authorized access requests result in 313 connection release. 315 5. New and extended AVPs 317 5.1 New AVP Summary 319 The following table lists the extra AVPs that are defined within this 320 document. The "attr" column indicates the integer value assigned to 321 this attribute. Note that the attribute value is relative compared 322 to the vendor ID. The "M" column indicates the setting of the 323 "Mandatory" bit of the AVP header for each attribute. The "LEN" 324 column indicates the size of the AVP including the AVP header. A "+" 325 in this column indicates that the length varies depending upon the 326 length of the actual contents of the value field. 328 The usage list for each entry indicates the message types that 329 utilize each AVP. An abbreviation shown in mixed or upper case 330 letters indicates that the corresponding AVP MUST be present in this 331 message type. All lower case indicates that the AVP MAY optionally 332 appear in this message type. Some AVPs MAY be present only when a 333 corresponding optional AVP or specific setting within the AVP is 334 present, these AVPs are shown in lower case as well. 336 Attr M Len Attribute Name (usage) 338 tbd 0 10 Rx Minimum BPS (ocrq) 339 32-bit integer indicating the lowest acceptable line speed for the 340 call in the receive direction. Rx indicates the user to LAC 341 direction. 342 tbd 0 10 Rx Maximum BPS (ocrq) 343 32-bit integer indicating the highest acceptable line speed for 344 call in the receive direction. Rx indicates the user to LAC 345 direction. 346 tbd 0 8 Service Category (ocrq, icrq) 347 The Service Category indicates the service expected for the call, 348 e.g., real time or non-real time. 349 tbd 0 6+ Service Name (ocrq, icrq) 350 The Service Name indicates the service name linked to a 351 preestablished PVC. 352 tbd 0 26 Calling Sub-Address(icrq) 353 20 octet binary encoded NSAP subaddress indicating the Calling 354 Party Sub-Address. 355 tbd 0 10 VPI/VCI identifier (icrq, ocrp) 356 10 octet binary encoded identification of VPI/VCI values used for 357 incoming calls. 359 5.2 New AVP definition 361 The following lists the new AVPs defined within this document, and 362 describes the expected behaviour when this AVP would be present 363 within a message. 365 Rx Minimum BPS (OCRQ) 367 The Rx Minimum BPS, Attribute Type tbd, encodes the lowest 368 acceptable line speed for this call in the receive direction, 369 for these cases where asymmetric transmission is required. 371 The Attribute Value field for this AVP has the following format: 373 0 1 2 3 374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Rx Minimum BPS | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 The Rx Minimum BPS is a 32 bit value indicating the speed in 380 bits per second. 382 This AVP MAY be included within the OCRQ, and SHOULD only be 383 included when the LAC indicated broadband bearer support in the 384 bearer capabilities AVP during tunnel establishment. 386 This AVP may be hidden (the H-bit may be set to 0 or 1). The M- 387 bit for this AVP must be set to 0. The Length (before hiding) of 388 this AVP is 10. 390 Rx Maximum BPS 392 The Rx Maximum BPS, Attribute Type tbd, encodes the highest 393 acceptable line speed for this call in the receive direction, 394 for these cases where asymmetric transmission is required. 396 The Attribute Value field for this AVP has the following format: 398 0 1 2 3 399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Rx Maximum BPS | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 The Rx Maximum BPS is a 32 bit value indicating the speed in 405 bits per second. 407 This AVP MAY be included within the OCRQ, and SHOULD only be 408 included when the LAC indicated broadband bearer support in the 409 bearer capabilities AVP during tunnel establishment. 411 This AVP may be hidden (the H-bit may be set to 0 or 1). The M- 412 bit for this AVP must be set to 0. The Length (before hiding) of 413 this AVP is 10. 415 Service Category 417 The Service Category AVP, Attribute type tbd, indicates optional 418 extra information on the Quality of Service expected for the 419 call establishment on the broadband bearer medium. 421 The Attribute Value field for this AVP has the following format: 423 0 1 425 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Resvd for future QoS ind. |S| 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 The Attribute Value field is a 16-bit mask, with one bit 432 defined. The S bit indicates either non real time (S bit set to 433 0) or real time (S bit set to 1) service requirement. The other 434 bit fields are reserved for future use. 436 The Service Category AVP MAY be present in OCRQ and ICRQ 437 messages, and SHOULD only be included when the LAC indicated 438 broadband bearer support in the bearer capabilities AVP during 439 tunnel establishment. 441 This AVP may be hidden (the H-bit may be set to 0 or 1). The M- 442 bit for this AVP must be set to 0. The Length (before hiding) of 443 this AVP is 8. 445 Service Name 447 The Service Name AVP, Attribute Type tbd, provides the peer with 448 an textual name for referring to an ATM VC connection. 450 The Attribute Value field for this AVP has the following format: 452 0 1 2 3 453 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Service Name (arbitrary number of octets) .... 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 The Service Name is of arbitrary length, but must be at least 1 459 octet. The Service Name is UTF-8 encoded. [10646] 461 The Service Name should be unique at least to the LNS/LAC 462 combination. 464 The Service Name AVP MAY only be provided when the Called Number 465 field is encoded as all zeros in OCRQ. The Service Name AVP MAY 466 be present in OCRQ and ICRQ messages, and SHOULD only be 467 included when the LAC indicated broadband bearer support in the 468 bearer capabilities AVP during tunnel establishment. 470 This AVP may be hidden (the H-bit may be set to 0 or 1). The M- 471 bit for this AVP must be set to 0. The length of this attribute 472 is arbitrary, however at least 7. 474 Calling Sub-Address (ICRQ) 476 The Calling Sub-Address AVP, Attribute Type tbd, encodes 477 additional Calling Party subaddress information. 479 The Attribute Value field for this AVP has the following format: 481 0 1 2 3 482 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | NSAP | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | NSAP (cont'd) | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | NSAP (cont'd) | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | NSAP (cont'd) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | NSAP (cont'd) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 The Calling Sub-Address AVP MUST be encoded as a 20 octet binary 496 encoded NSAP address when the B bit is set in the Bearer Type 497 AVP. The NSAP binary encoded address provides a broader range of 498 address encapsulation methods than an ASCII field. The structure 499 of the NSAP address (e.g., E.164, ICD, DCC) is defined in 500 [AESA]. 502 The Calling Sub-Address number AVP MAY be present in ICRQ, and 503 SHOULD only be available if the Calling Party number is also 504 within the message. 506 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 507 this AVP MUST be set to 0. The Length (before hiding) of this 508 AVP is 26. 510 VPI/VCI identifier(icrq, ocrp) 511 The VPI/VCI identifier, Attribute Type tbd, encodes the VPI/VCI 512 value used at the ATM interface at the LAC. 514 The Attribute Value field for this AVP has the following format: 516 0 1 2 3 517 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |resvd | VPI | VCI | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 The VPI/VCI identifier is a 32 bit value encoding the VPI(12 523 bits) and VCI (16 bits) value. 525 This AVP MAY be included within the ICRQ and OCRP, and SHOULD 526 only be included when the LAC indicated broadband bearer support 527 in the bearer capabilities AVP during tunnel establishment. 529 This AVP may be hidden (the H-bit may be set to 0 or 1). The M- 530 bit for this AVP must be set to 0. The Length (before hiding) of 531 this AVP is 10. 533 5.3 Changed AVP Definition 535 The following AVPs see their contents changed relative to [RFC2661] 536 in order to support the procedures described in this document. 538 Bearer Capabilities 540 0 1 2 3 541 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Resvd for future bearer capability definitions |B|A|D| 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 The bearer Capabilities AVP within a SCCRQ or SCCRP indicates 547 the bearer capabilities that the sender of this message can 548 provide for outgoing calls. This document extends the existing 549 AVP with the B bit. If bit B is set, broadband access is 550 supported (ATM). 552 Attempts to establish an outgoing call with the bearer type set 553 to B, while the bearer capability did not indicate this 554 capability will result in the call being rejected with Result 555 Code 5 'Call failed due to lack of appropriate facilities being 556 available (permanent condition)'. 558 (Tx) Minimum BPS 560 The (Tx) Minimum BPS AVP encodes the lowest acceptable line 561 speed for this call in the transmit direction. The (Tx) Minimum 562 BPS AVP MAY be used in OCRQ. If the Rx Minimum BPS AVP, as 563 defined within this document, is not available in the message, 564 then symmetric transmission is implied, with both minimum 565 receive and transmit bit-rates equal to Minimum BPS. 567 (Tx) Maximum BPS 569 (Tx) Maximum BPS AVP encodes the highest acceptable line speed 570 for this call in the transmit direction. The (Tx) Maximum BPS 571 AVP MAY be used in OCRQ. If the Rx Maximum BPS AVP, as defined 572 within this document, is not available in the message, then 573 symmetric transmission is implied, with both maximum receive and 574 transmit bitrates equal to Maximum BPS. 576 Bearer Type 578 0 1 2 3 579 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Resvd for future bearer types definitions |B|A|D| 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 The bearer type AVP encodes the bearer type for the requested 585 call. This document extends the bearer types with an indication 586 of ATM bearer support (B-bit). If bit B is set, broadband access 587 is requested (ATM). 589 Q.931 Cause Code 590 0 1 2 3 591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Cause Code | Cause Msg | Advisory Msg... 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 The Cause code is not changed from [RFC2661], except for the 597 fact that it can also carry Cause Codes specific to ATM 598 signalling messages, these cause codes can be found in ATM Forum 599 UNI 4.0 [UNI] and the references thereof. The Cause code should 600 be interpreted relative to the Bearer Type in use for the 601 specific call. 603 Called Number 605 The Called Number AVP, Attribute Type 21, encodes the AESA 606 number to be called for an OCRQ, and the Called number at the 607 LAC for an ICRQ. 609 The Attribute Value field for this AVP has a changed encoding 610 from [RFC2661]: 612 0 1 2 3 613 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | NSAP | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | NSAP (cont'd) | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | NSAP (cont'd) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | NSAP (cont'd) | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | NSAP (cont'd) | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 The Called Number AVP MUST be encoded as a 20 octet binary 627 encoded NSAP address when the B bit is set in the Bearer Type 628 AVP. The NSAP binary encoded address provides a broader range of 629 address encapsulation methods than an ASCII field. The structure 630 of the NSAP address (e.g., E.164, ICD, DCC) is defined in 631 [AESA]. 633 The Called number AVP MUST be present in OCRQ, and MAY be 634 present in ICRQ. 636 If the Called Number AVP in an OCRQ carries an all zero NSAP 637 address, the Service Name AVP SHOULD provide further information 638 to bind the L2TP call to a specific VC connection. See also 639 [Auto_PVC]. 641 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 642 this AVP MUST be set to 0. The Length (before hiding) of this 643 AVP is 26. 645 Calling Number 647 The Calling Number AVP, Attribute Type 22, encodes the Calling 648 Party AESA as received from the Virtual Dial-in User. 650 The Attribute Value field for this AVP has a changed encoding 651 from [RFC2661]: 653 0 1 2 3 654 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | NSAP | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | NSAP (cont'd) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | NSAP (cont'd) | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | NSAP (cont'd) | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | NSAP (cont'd) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 The Calling Number AVP MUST be encoded as a 20 octet binary 668 encoded NSAP address when the B bit is set in the Bearer Type 669 AVP. The NSAP binary encoded address provides a broader range of 670 address encapsulation methods than an ASCII field. The structure 671 of the NSAP address (e.g., E.164, ICD, DCC) is defined in 672 [AESA]. 674 The Calling number AVP MAY be present in ICRQ. 676 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 677 this AVP MUST be set to 0. The Length (before hiding) of this 678 AVP is 26. 680 Sub-Address 681 The Sub-Address AVP, Attribute Type 23, encodes additional 682 Called Party subaddress information. 684 The Attribute Value field for this AVP has a changed encoding 685 from [RFC2661]: 687 0 1 2 3 688 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | NSAP | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | NSAP (cont'd) | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | NSAP (cont'd) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | NSAP (cont'd) | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | NSAP (cont'd) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 The Sub-Address AVP MUST be encoded as a 20 octet binary encoded 702 NSAP address when the B bit is set in the Bearer Type AVP. The 703 NSAP binary encoded address provides a broader range of address 704 encapsulation methods than an ASCII field. The structure of the 705 NSAP address (e.g., E.164, ICD, DCC) is defined in [AESA]. 707 The Sub-Address number AVP MAY be present in ICRQ and OCRQ, and 708 SHOULD only be available if the Called Party number is also 709 within the message. 711 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 712 this AVP MUST be set to 0. The Length (before hiding) of this 713 AVP is 26. 715 6. IANA Considerations 717 This document requires IANA to allocate 6 new type values for the 718 following AVPs (see section 5.2) : 720 - Rx Minimum BPS 722 - Rx Maximum BPS 724 - Service Category 726 - Service Name 727 - Calling Sub-Address 729 - VPI/VCI Identifier 731 This document further defines a new bit (B) in the bearer 732 capabilities and bearer type AVPs (section 5.3). 734 This document defines a flag field in the Service Category AVP, only 735 one bit in this flag has been assigned within this document (S). 736 Further assignments fall under the rule of "Specification Required", 737 i.e. Values and their meaning must be documented in an RFC or other 738 permanent and readily available reference, in sufficient detail so 739 that interoperability between independent implementations is 740 possible. 742 7. Security Considerations 744 No extra security risk outside these specified by [RFC2661] are 745 foreseen. 747 8. Acknowledgements 749 The authors would like to thank Laurent Hermans for his work on 750 earlier versions of this document, Juha Heinanen (Telia) and David 751 Allen (Nortel Networks) for their constructive discussion on the 752 document during the Minneapolis IETF meeting, Mark Townsley (cisco) 753 for his hint on the use of the VPI/VCI identifier AVP. 755 9. References 757 [RFC2661] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, 758 G. Zorn, B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661, 759 August 1999 761 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC2364] G. Gross, M. Kaycee, A. Lin, A. Malis, J. Stephens, 765 "PPP over AAL5", RFC 2364, July 1998 767 [UNI] User-Network Interface (UNI) Specification, Version 4.0, 768 ATM Forum, July, 1996 770 [AESA] ATM Forum Addressing : Reference Guide, version 1.0, ATM 771 Forum, Final Ballot, January 1999 773 [L2TP_link] M. Townsley, W. Palter, "L2TP Link Extensions", Internet 774 Draft, November 1998, 776 [Auto_PVC] ATM Forum, "Auto-configuration of PVCs", af-nm-0122.000, 777 March 1999 779 [10646] ISO/IEC, Information Technology - Universal Multiple-Octet 780 Coded Character Set (UCS) - Part 1: Architecture and Basic 781 Multilingual Plane, May 1993, with amendments 783 10. Contacts 785 Yves T'joens 786 Alcatel Network Strategy Group 787 Francis Wellesplein 1, 2018 Antwerp, Belgium 788 Phone : +32 3 240 7890 789 E-mail : yves.tjoens@alcatel.be 791 Bernard Sales 792 Alcatel Network Strategy Group 793 Francis Wellesplein 1, 2018 Antwerp, Belgium 794 Phone : +32 3 240 9574 795 E-mail : bernard.sales@alcatel.be 797 Paolo Crivellari 798 Belgacom 799 BOULEVARD DU ROI ALBERT II 27 1030 SCHAERBEEK 800 Phone : +32 2 202 9698 801 E-mail : paolo.crivellari@belgacom.be 803 11. Full copyright statement 805 Copyright (C) The Internet Society (1999). All Rights Reserved. 807 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. 809 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 811 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 813 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.