idnits 2.17.1 draft-ietf-pppext-l2tp-atmext-01.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: ---------------------------------------------------------------------------- ** 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 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 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. ** The abstract seems to contain references ([L2TP]), 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 193: '... MUST be established between the use...' RFC 2119 keyword, line 194: '...rtual connection MAY either be a preco...' RFC 2119 keyword, line 196: '...teristics of the PVC, or MAY be an on-...' RFC 2119 keyword, line 205: '... user, the LAC MAY check with the LN...' RFC 2119 keyword, line 206: '...tuation, the LAC MAY determine based u...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1999) is 9081 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) == Unused Reference: 'PPP' is defined on line 601, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TP' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNI' -- Possible downref: Non-RFC (?) normative reference: ref. 'AESA' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Submitted to PPP Working Group Yves T'Joens 2 INTERNET DRAFT Paolo Crivellari 3 Laurent Hermans 4 Bernard Sales 5 Alcatel 6 June 1999 7 Expires December, 1999 9 Layer Two Tunnelling Protocol : ATM access network extensions. 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet- 23 Drafts as reference material or to cite them other than as a 24 ``working draft'' or ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 35 ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), 36 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 38 Distribution of this memo is unlimited. 40 Abstract 42 [L2TP] specifies a protocol which permits the tunnelling of the link 43 layer of PPP over packet based networks, to support remote access 44 (mainly) by ISDN and PSTN networks. This document augments the 45 procedures described in [L2TP] to further support ATM SVC or PVC 46 based access networks. The extensions defined within this document 47 allow for asymmetric bi-directional call establishment and service 48 selection in the ATM access network. 50 Table Of Contents 51 1. Introduction 52 1.1 Conventions 53 2. Assumptions 54 2.1 Topology 55 2.2 Connection Establishment 56 2.3 LCP Negotiation 57 3. ATM access enhanced procedures 58 3.1 ATM connectivity 59 3.2 Tunnel establishment 60 3.3 call establishment 61 3.4 Framing 62 4. Service model issues 63 4.1 Authentication 64 4.2 Authorization 65 5. New and extended AVPs 66 5.1 New AVP Summary 67 5.2 New AVP definition 68 5.3 Changed AVP Definition 69 6. IANA considerations 70 7. Security considerations 71 8. Acknowledgements 72 9. References 73 10. Contacts 75 1. Introduction 77 [L2TP] is a tunnelling protocol that allows tunnelling of PPP 78 sessions between a so called L2TP Access Concentrator (LAC) and an 79 L2TP Network Server (LNS). The main focus of [L2TP] is on supporting 80 HDLC based ISDN/PSTN access networks. 82 This document augments the procedures described in [L2TP] to further 83 support ATM SVC or PVC based access networks. Support for ATM access 84 networks requires extensions to the present L2TP procedures along the 85 following lines : 87 (a) the traffic management aspects of ATM connections (e.g. 88 assymetric bandwidth allocation and service category selection 89 capabilities), 91 (b) the addressing format to be used in switched ATM networks [AESA] 92 and 94 (c) the limititations imposed on LCP negotiation by transporting PPP 95 over AAL5 over the access network segment of the PPP connection 96 [PPPoA]. 98 Within this draft, the necessary extensions to [L2TP] are defined to 99 cope with issues (a) and (b), issue (c) which is not specific to ATM 100 may be solved as described in [L2TP_link]. 102 1.1 Conventions 104 Throughout this document, the words that are used to define the 105 significance of particular requirements are capitalised. These words 106 are: 108 o "MUST" 110 This word or the adjective "REQUIRED" means that the item is an 111 absolute requirement of this specification. 113 o "MUST NOT" 115 This phrase means that the item is an absolute prohibition of this 116 specification. 118 o "SHOULD" 120 This word or the adjective "RECOMMENDED" means that there may exist 121 valid reasons in particular circumstances to ignore this item, but 122 the full implications should be understood and the case carefully 123 weighed before choosing a different course. 125 o "SHOULD NOT" 127 This phrase means that there may exist valid reasons in particular 128 circumstances when the listed behaviour is acceptable or even useful, 129 but the full implications should be understood and the case carefully 130 weighed before implementing any behaviour described with this label. 132 o "MAY" 134 This word or the adjective "OPTIONAL" means that this item is truly 135 optional. One vendor may choose to include the item because a 136 particular marketplace requires it or because it enhances the 137 product, for example; another vendor may omit the same item. 139 2. Assumptions 141 In this section we describe some assumptions that have lead to the 142 extensions described in this draft. 144 2.1 Topology 146 The procedures as defined in [L2TP] apply mainly to access network 147 technology such as PSTN and ISDN, which may be respectively asynch. 148 HDLC and synch HDLC based. The aim of this document is to extend L2TP 149 support to allow for user / LAC communication based on ATM access 150 network technology. 152 2.2 Connection Establishment 154 Due to the wide variety of existing signalling protocols and ATM 155 service categories, and their support or non-support within ATM based 156 access networks, this document takes as approach to provide for a 157 flexible identification of ATM connection characteristics while 158 establishing outgoing and incoming L2TP calls. The procedures as 159 defined within this document allow the allocation of asymmetric 160 bandwidth and service category selection in terms of real or non-real 161 time requirements on the ATM portion of the access network. 163 As such, the detailed signalling protocol specific information 164 elements that are necessary for switched VC service, are not 165 negotiated during call establishment over the L2TP tunnel. 167 In order to identify the endpoint of the ATM connection within the 168 ATM access network, SVCs can be established on the basis of the ATM 169 end system addressing format [AESA]. For PVC based services, the PVC 170 can either be referred to by using the ATM end system addressing 171 procedure (Dialed Number), or by making use of a textual name 172 (Service Name). The latter is inspired by the procedures defined 173 within [Auto_PVC]. 175 2.3 LCP negotiation 177 The procedures described within this draft may be combined with the 178 procedures described in [L2TP_link] to limit LCP negotiation between 179 LNS and user, so as to enforce PPP over AAL5 specific LCP negotiation 180 [PPPoA]. 182 3. ATM access enhanced procedures 184 In order to illustrate the procedures specified within this draft, 185 this section will provide a description of what might happen when a 186 Virtual dial-up client initiates access through a (switched) ATM 187 access network. Note that the emphasis is on the changes proposed 188 within this draft relative to [L2TP]. 190 3.1 ATM connectivity 192 Prior to initiating the PPP protocol layer, a Virtual Connection (VC) 193 MUST be established between the user and the Network Access Server 194 (LAC). This virtual connection MAY either be a preconfigured 195 Permanent VC(PVC), where the access network provider, NAS and user 196 agree beforehand on the characteristics of the PVC, or MAY be an on- 197 demand switched VC(SVC), where the negotiation between user, network 198 and NAS takes place by means of an ATM signalling protocol. Note that 199 for establishing PVCs, alternative use may be made of the procedures 200 as described in [Auto_PVC]. 202 In both cases, the user is referred to as the Virtual dial-in user. 204 Prior to accepting the switched connection from the Virtual dial-in 205 user, the LAC MAY check with the LNS whether the call should be 206 accepted. In the latter situation, the LAC MAY determine based upon 207 parameters available within the call establishment message that this 208 concerns a virtual dial in user, or MAY undertake a partial 209 authentication of the end system/user, in order to bind the end 210 system/user with a specific LNS. 212 3.2 Tunnel establishment 214 If no tunnel connection currently exists to the desired LNS, one is 215 initiated. During the tunnel establishment, LNS and LAC indicate 216 bearer and framing capabilities to each other, according to normal 217 procedures. 219 The bearer capability is extended to allow the identification of ATM 220 devices in the LAC. This allows the LNS to use the extensions as 221 defined within this draft to support ATM based outgoing calls. 223 If no compatibility between LNS and LAC exists according to the 224 extensions defined within this draft, no tunnel establishment can 225 take place. This would be because the LAC does not support any bearer 226 capability which is expected by the LNS, or vice versa. It is however 227 encouraged that LAC or LNS implementations would allow for seamless 228 interworking with peer devices which do not implement the extensions 229 defined within this draft. This could be implemented by allowing a 230 gracefull fallback to Digital bearer capability. 232 3.3 call establishment 234 During incoming and outgoing broadband call establishment, the 235 following extensions are defined to existing procedures. 237 During OCRQ, the LNS MUST indicate to the LAC minimum and maximum 238 speeds for receive and transmit traffic (from the LAC perspective). 239 This is to allow for the bi-directional asymmetric nature of ATM 240 traffic contracts. Note that in order to support UBR connections 241 between LAC and user, the Minimum BPS MUST be set to zero. 243 Further during OCRQ, the LNS MAY indicate to the LAC the required 244 service category, i.e., real time (rt) or non-real time (nrt) 245 transport services. The combination of minimum and maximum receive 246 and transmit speed, and the indication of the required service 247 category allows the LAC to establish an ATM connection according to 248 its own capabilities, and the ATM access network capabilities, 249 however within the service requirement for the PPP layer. 251 Real time connectivity can be provided by either CBR or rt-VBR ATM 252 service categories, non-real time connectivity can be provided by 253 UBR, nrt-VBR, ABR or GFR ATM service categories. 255 Further the LNS MUST indicate to the LAC in OCRQ message the dialed 256 number according to the format described in this document (NSAP 257 format). When the dialed number carries an all zero payload, the LAC 258 SHOULD look at the Service Name AVP to bind the tunnel call to an 259 PVC. 261 3.4 Framing 263 Within this document the PPP PDU refers to the concatenation of PPP 264 protocol ID, PPP Information and PPP padding fields. 266 In the direction of user to LNS, the PPP PDU will be carried on top 267 of an AAL5 connection between user and LAC. The LAC MUST strip off 268 the AAL5 specific fields based on the encapsulation mechanism in use 269 on the ATM connection, i.e. VC multiplexed or LLC encapsulated 270 [PPPoA], and MUST encapsulate the PPP PDU with address and control 271 field, as per HDLC procedures, on the L2TP tunnel. 273 In the direction of LNS to user, the PPP PDU will be carried on top 274 of an AAL5 connection between LAC and user. The LAC MUST strip the 275 PPP PDU from the address and control field on the L2TP tunnel, and 276 insert the AAL5 specific fields based on the encapsulation mechanism 277 in use on the ATM connection, i.e. VC multiplexed or LLC 278 encapsulated. 280 4. Service model issues 282 4.1 Authentication 284 In case of ATM switched VC establishment, calling party number 285 information may be used for first level authentication much in the 286 same way as for PSTN or ISDN access. In case of permanent VC 287 establishment, authentication may not be an issue from the LAC side, 288 because of the permanent character of the VC. Bilateral agreement 289 between LAC and LNS providers may eliminate the authentication phase 290 in the latter case. 292 4.2 Authorization 294 Because of the flexibility of establishing ATM connections with 295 varying parameters, some authorization may be required prior to 296 accepting the establishment of a switched ATM connection from the 297 user with certain ATM traffic parameters. This authorization may be 298 performed against the ATM specific authentication information (e.g. 299 calling line id), or may be performed after partial authentication of 300 the user at the PPP level. Non authorized access requests result in 301 connection release. 303 5. New and extended AVPs 305 5.1 New AVP Summary 307 The following table lists the extra AVPs that are defined within this 308 document. The "attr" column indicates the integer value assigned to 309 this attribute. Note that the attribute value is relative compared 310 to the vendor ID. The "M" column indicates the setting of the 311 "Mandatory" bit of the AVP header for each attribute. The "LEN" 312 column indicates the size of the AVP including the AVP header. A "+" 313 in this column indicates that the length varies depending upon the 314 length of the actual contents of the value field. 316 The usage list for each entry indicates the message types that 317 utilize each AVP. An abbreviation shown in mixed or upper case 318 letters indicates that the corresponding AVP MUST be present in this 319 message type. All lower case indicates that the AVP MAY optionally 320 appear in this message type. Some AVPs MAY be present only when a 321 corresponding optional AVP or specific setting within the AVP is 322 present, these AVPs are shown in lower case as well. 324 Attr M Len Attribute Name (usage) 326 x 0 10 Rx Minimum BPS (OCRQ) 327 32-bit integer indicating the lowest acceptable line speed for the 328 call in the receive direction. Rx indicates the user to LAC 329 direction. 330 x 0 10 Rx Maximum BPS (OCRQ) 331 32-bit integer indicating the highest acceptable line speed for 332 call in the receive direction. Rx indicates the user to LAC 333 direction. 334 x 0 6+ ATM Cause Code (cdn) 335 16-bit cause code, 1 octet cause message, and optional ASCII 336 advisory message. 337 x 0 8 Service Category (ocrq, icrq) 338 The Service Category indicates the service expected for the call, 339 e.g., real time or non-real time. 340 x 0 6+ Service Name (ocrq, icrq) 341 The Service Name indicates the service name linked to a 342 preestablished PVC. 344 5.2 New AVP definition 346 The following lists the new AVPs defined within this draft, and 347 describes the expected behaviour when this AVP would be present 348 within a message. 350 Rx Minimum BPS 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |0|0|0|0|0|0| 10 | 0 | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | x | BPS (H) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | BPS (L) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 The Rx Minimum BPS AVP encodes the lowest acceptable line speed 363 for this call in the receive direction, for these cases where 364 asymmetric transmission is required. This AVP MAY be included 365 within the OCRQ, and SHOULD only be included when the LAC 366 indicated ATM support in the bearer capabilities AVP during 367 tunnel establishment. 369 Rx Maximum BPS 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |0|0|0|0|0|0| 10 | 0 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | x | BPS (H) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | BPS (L) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 The Rx Maximum BPS AVP encodes the highest acceptable line speed 381 for this call in the receive direction, for these cases where 382 asymmetric transmission is required. This AVP MAY be included 383 within the OCRQ, and SHOULD only be included when the LAC 384 indicated ATM support in the bearer capabilities AVP during 385 tunnel establishment. 387 Service Category 389 0 1 2 3 391 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |0|0|0|0|0|0| 8 | 0 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | x |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|S| 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 The Service Category provides optional extra information on the 400 Quality of Service expected for the call establishment. The S 401 bit indicates either non real time (S bit set to 0) or real time 402 (S bit set to 1) service requirement. The other bit fields are 403 reserved for future use. The Service Category AVP MAY be present 404 in OCRQ and ICRQ messages, and SHOULD only be included when the 405 LAC indicated ATM support in the bearer capabilities AVP during 406 tunnel establishment. 408 Service Name 410 0 1 2 3 412 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |0|0|0|0|0|0| 6+len name | 0 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | x | name | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | name (ctd) .... 420 +-+-+-+-+-+-+-+-+-+-+-+-+- 422 The Service Name field allows for the exchange of a textual name 423 for referring to a PVC. The service name AVP MAY only be 424 provided when the Dialed Number field is encoded as all zeros. 425 The service name AVP MAY be present in OCRQ and ICRQ messages, 426 and SHOULD only be included when the LAC indicated ATM support 427 in the bearer capabilities AVP during tunnel establishment. 429 ATM Cause Code 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 |0|0|0|0|0|0| 6 + len.Cause Code| 0 | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | x | Cause Code | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Cause Code (cont'd) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 The ATM Cause code AVP indicates the Cause Code as specified in 442 [UNI], for ATM connection establishment failures. The ATM Cause 443 Code AVP MUST be present in the CDN message. 445 5.3 Changed AVP Definition 447 The following AVPs see their contents changed relative to [L2TP] in 448 order to support ATM access awareness. 450 Bearer Capabilities 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 |1|0|0|0|0|0| 10 | 0 | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | 4 | 0x00 | 0x00 | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | 0x00 |0|0|0|0|0|B|A|D| 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 The bearer Capabilities AVP within a SCCRQ or SCCRP indicates 463 the bearer capabilities that the sender of this message can 464 provide for outgoing calls. If bit B is set, broadband access is 465 supported (ATM), if bit A is set, analogue access is supported. 466 If bit D is set, Digital access is supported. 468 This AVP provides the peer with an indication of the bearer 469 device types supported by the hardware interfaces of the sender 470 for outgoing calls. An LNS SHOULD NOT initiate an outgoing call 471 specifying a value in the Bearer Type AVP for a device type not 472 advertised in the Bearer Capabilities AVP it received from the 473 LAC during control connection establishment. Attempts to do so 474 will result in the call being rejected. 476 In these cases where the LAC only supports the B bit, and the 477 LNS would not recognize the B bit, no outgoing calls are 478 possible. Note that when the LAC only has ATM based devices, it 479 may still opt for fall back to digital bearer types. 481 (Tx) Minimum BPS 483 The (Tx) Minimum BPS AVP encodes the lowest acceptable line 484 speed for this call in the transmit direction. The (Tx) Minimum 485 BPS AVP MAY be used in OCRQ. If the Rx Minimum BPS is not 486 available in the message, then symmetric transmission is 487 implied, with both minimum receive and transmit bit-rates equal 488 to Minimum BPS. 490 (Tx) Minimum BPS is set in bits/second, and may be mapped to the 491 PCR in cells/second for ATM based traffic. Note that the PCR is 492 a mandatory parameter for all service capabilities in ATM 493 signalling. The exact mapping to signalling IEs is outside the 494 scope of this draft. 496 (Tx) Maximum BPS 498 (Tx) Maximum BPS AVP encodes the highest acceptable line speed 499 for this call in the transmit direction. The (Tx) Maximum BPS 500 AVP MAY be used in OCRQ. If the Rx Maximum BPS AVP is not 501 available in the message, then symmetric transmission is 502 implied, with both maximum receive and transmit bitrates equal 503 to Maximum BPS. 505 (Tx) Maximum BPS is set in bits/second, and may be mapped to the 506 PCR in cells/second for ATM based traffic. Note that the PCR is 507 a mandatory parameter for all service capabilities in ATM 508 signalling. The exact mapping to signalling IEs is outside the 509 scope of this draft. 511 Bearer Type 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |1|0|0|0|0|0| 10 | 0 | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | 18 | 0x00 | 0x00 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | 0x00 |0|0|0|0|0|B|A|D| 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 The bearer type AVP encodes the bearer type for the requested 523 call. The bearer type AVP MUST be present in the OCRQ, and MAY 524 be present in the ICRQ. If bit B is set, broadband access is 525 requested (ATM), if bit A is set, analogue access is requested. 526 If bit D is set, Digital access is requested. 528 Note that in the OCRQ all 3 bits (B,A,D) may be set indicating 529 that the call may be of either type. The B bit SHOULD only be 530 set if the Broadband capability was indicated during tunnel 531 establishment. 533 Dialed Number 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |1|0|0|0|0|0| 26 | 0 | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | 21 | NSAP | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | NSAP (cont'd) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | NSAP (cont'd) | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | NSAP (cont'd) | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | NSAP (cont'd) | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | NSAP (cont'd) | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 The Dialed Number AVP indicates the number that should be used 554 to address the virtual dial in user. The Dialed number AVP MUST 555 be present in OCRQ, and MAY be present in ICRQ. The Dialed 556 number AVP SHOULD be interpreted as binary encoded when the B 557 bit is set in the Bearer Type AVP. The NSAP binary encoded 558 address provides a broader range of address encapsulation 559 methods than an ASCII field. In the NSAP field, which MUST have 560 the length of 20 octets, the addressing protocol used (E.164, 561 ICD, DCC) is specified as defined in [AESA]. 563 If the Dialed Number AVP carries an all zero NSAP address, the 564 Service Name AVP MAY provide further information to bind the 565 L2TP call to a specific VC connection. See also [Auto_PVC]. 567 Sub-Address 569 see Dialed Number. If the Dialed Number carries an all zero NSAP 570 address, the Sub-Address should be neglected on receipt. 572 6. IANA Considerations 574 This document requires 5 new type values for the following AVPs : - 575 Rx Minimum BPS - Rx Maximum BPS - ATM Cause Code - Service Category - 576 Service Name 578 This document further defines a new bit (B) in the bearer 579 capabilities and bearer type AVPs. 581 This document defines a flag field in the Service Category AVP, only 582 one bit in this flag has been assigned witin this document (S). 584 7. Security Considerations 586 No extra security risk outside these specified by [L2TP] are 587 foreseen. 589 8. Acknowledgements 591 The authors would like to thank Juha Heinanen (Telia) and David Allen 592 (Nortel Networks) for their constructive discussion on the draft 593 during the Minneapolis IETF meeting. 595 9. References 597 [L2TP] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. 598 Taarud, A. Valencia, A. Rubens, W.M. Townsley, B. Palter, W. Verthein 599 "Layer Two Tunnelling Protocol (L2TP)", RFC xxxx, July 1999 601 [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51, 602 RFC 1661, July 1994 604 [PPPoA] G. Gross, M. Kaycee, A. Lin, A. Malis, J. Stephens, "PPP 605 over AAL5", RFC 2364, July 1998 607 [UNI] User-Network Interface (UNI) Specification, Version 4.0, 608 ATM Forum, July, 1996 610 [AESA] ATM Forum Addressing : Reference Guide, version 1.0, ATM 611 Forum, Final Ballot, January 1999 613 [PPP_HDLC] W. Simpson, "PPP in HDLC-like Framing", STD 51, RFC 1662, 614 July 1994 616 [L2TP_link] M. Townsley, W. Palter, "L2TP Link Extensions", Internet 617 Draft, November 1998, 619 [Auto_PVC] ATM Forum, "Auto-configuration of PVCs", af-nm-0122.000, 620 March 1999 622 10. Contacts 624 Yves T'joens 625 Alcatel Corporate Research Center 626 Francis Wellesplein 1, 2018 Antwerp, Belgium 627 Phone : +32 3 240 7890 628 E-mail : yves.tjoens@alcatel.be 630 Paolo Crivellari 631 Alcatel Access Systems Division 632 Francis Wellesplein 1, 2018 Antwerp, Belgium 633 Phone : +32 3 240 3319 634 E-mail : pcri@sebb.bel.alcatel.be 636 Laurent Hermans 637 Alcatel Corporate Research Center 638 Francis Wellesplein 1, 2018 Antwerp, Belgium 639 Phone : +32 3 240 8671 640 E-mail : hermanla@rc.bel.alcatel.be 642 Bernard Sales 643 Alcatel Corporate Research Center 644 Francis Wellesplein 1, 2018 Antwerp, Belgium 645 Phone : +32 3 240 9574 646 E-mail : bernard.sales@btmaa.bel.alcatel.be