diff options
Diffstat (limited to 'doc/rfc/rfc3301.txt')
| -rw-r--r-- | doc/rfc/rfc3301.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc3301.txt b/doc/rfc/rfc3301.txt new file mode 100644 index 0000000..b3a700f --- /dev/null +++ b/doc/rfc/rfc3301.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group Y. T'Joens +Request for Comments: 3301 B. Sales +Category: Standards Track Alcatel + P. Crivellari + Belgacom + June 2002 + + + Layer Two Tunnelling Protocol (L2TP): + ATM access network extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document augments the procedures described in RFC 2661 to + further support ATM SVC (Switched Virtual Circuits) or PVC (Permanent + Virtual Circuits) based access networks. L2TP (Layer 2 Tunneling + Protocol) specifies a protocol for tunnelling PPP packets over packet + based networks and over IP networks in particular. L2TP supports + remote access by ISDN and PSTN networks. The extensions defined + within this document allow for asymmetric bi-directional call + establishment and service selection in the ATM access network. + +Table Of Contents + + 1. Introduction .................................................. 2 + 1.1 Conventions .................................................. 2 + 2. Assumptions ................................................... 3 + 2.1 Topology ..................................................... 3 + 2.2 Connection Establishment ..................................... 3 + 2.3 LCP Negotiation .............................................. 3 + 3. ATM access enhanced procedures ................................ 3 + 3.1 ATM connectivity ............................................. 4 + 3.2 Tunnel establishment ......................................... 4 + 3.3 Call establishment ........................................... 5 + 3.3.1 Incoming Call Establishment ................................ 5 + 3.3.2 Outgoing Call Establishment ................................ 6 + + + +T'Joens, et al. Standards Track [Page 1] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + 3.4 Framing ...................................................... 6 + 4. Service model issues .......................................... 7 + 4.1 Authentication ............................................... 7 + 4.2 Authorization ................................................ 7 + 5. New and extended AVPs ......................................... 7 + 5.1 New AVP Summary .............................................. 7 + 5.2 New AVP definition ........................................... 8 + 5.3 Changed AVP Definition ....................................... 12 + 6. IANA considerations ........................................... 16 + 7. Security considerations ....................................... 17 + 8. Acknowledgements .............................................. 17 + 9. References .................................................... 17 + 10. Authors Addresses ............................................ 18 + 11. Full Copyright Statement ..................................... 19 + +1. Introduction + + L2TP [RFC2661] defines the procedures for tunneling PPP sessions + between a so called L2TP Access Concentrator (LAC) and an L2TP + Network Server (LNS). The main focus of [RFC2661] is on supporting + HDLC based ISDN/PSTN access networks. + + This document augments the procedures described in [RFC2661] to + further support ATM SVC or PVC based access networks. Support for + ATM access networks requires extensions to the present L2TP + procedures so as to cope with : + + (a) the traffic management aspects of ATM connections (e.g. + asymmetric bandwidth allocation and service category selection + capabilities), + + (b) the addressing format to be used in switched ATM networks [AESA] + and + + (c) the limitations imposed on LCP negotiation by transporting PPP + over AAL5 over the access network segment of the PPP connection + [RFC2364]. + + Within this document, the necessary extensions to [RFC2661] are + defined to cope with issues (a) and (b), issue (c) which is not + specific to ATM may be solved as described in [L2TP_link]. + +1.1 Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + +T'Joens, et al. Standards Track [Page 2] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + +2. Assumptions + + In this section we describe some assumptions that have lead to the + extensions described in this document. + +2.1 Topology + + The procedures as defined in [RFC2661] apply mainly to access network + technology such as PSTN and ISDN, which may be respectively + asynchronous HDLC and synchronous HDLC based. The aim of this + document is to extend L2TP support to allow for user / LAC + communication based on ATM access network technology. + +2.2 Connection Establishment + + Due to the wide variety of existing signalling protocols and ATM + service categories, and their support or non-support within ATM based + access networks, this document takes as approach to provide for a + flexible identification of ATM connection characteristics while + establishing outgoing and incoming L2TP calls. The procedures as + defined within this document allow the allocation of asymmetric + bandwidth and service category selection in terms of real or non-real + time requirements on the ATM portion of the access network. + + As such, the detailed signalling protocol specific information + elements that are necessary for switched VC service, are explicitly + not negotiated during call establishment over the L2TP tunnel. + + In order to identify the endpoint of the ATM connection within the + ATM access network, SVCs can be established on the basis of the ATM + end system addressing format [AESA]. For PVC based services, the PVC + can either be referred to by using the ATM end system addressing + procedure (Called/Calling Number), or by making use of a textual name + (Service Name). The latter is inspired by the procedures defined + within [Auto_PVC]. + +2.3 LCP negotiation + + The procedures described within this document may be combined with + the procedures described in [L2TP_link] to limit LCP negotiation + between LNS and user, so as to enforce PPP over AAL5 specific LCP + negotiation [RFC2364]. + +3. ATM access enhanced procedures + + In order to illustrate the procedures specified within this document, + this section will provide an operational description of Virtual + dial-up access through an ATM based access network (e.g., ADSL). + + + +T'Joens, et al. Standards Track [Page 3] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + Note that the emphasis is on the changes proposed within this + document relative to [RFC2661]. + +3.1 ATM connectivity + + Prior to initiating the PPP protocol layer, a Virtual Connection (VC) + MUST be established between the user and the Network Access Server + (LAC). This virtual connection MAY either be a preconfigured + Permanent VC(PVC), where the access network provider, NAS and user + agree beforehand on the characteristics of the PVC, or MAY be an on- + demand switched VC(SVC), where the negotiation between user, network + and NAS takes place by means of an ATM signalling protocol. Note + that for establishing PVCs, alternative use may be made of the + procedures as described in [Auto_PVC]. + + In both cases, the user is referred to as the virtual dial-in user. + + Prior to accepting the switched connection from the virtual dial-in + user, the LAC MAY check with the LNS whether the call should be + accepted. In the latter situation, the LAC MAY determine based upon + parameters available within the call establishment message that this + concerns a virtual dial in user, or MAY undertake a partial + authentication of the end system/user, in order to bind the end + system/user with a specific LNS. + + For PVC based users, the LAC MAY be triggered by the arrival of an + LCP Configure Request, or PPP Authentication request message from the + virtual dial-in user to initiate conversation with the LNS. Note + that the exact timing of triggering communication between LAC and LNS + is outside the scope of this document. + +3.2 Tunnel establishment + + If no tunnel connection currently exists to the desired LNS, one is + initiated. During the tunnel establishment, LNS and LAC indicate + bearer and framing capabilities to each other, according to normal + procedures. + + The bearer capability is extended to allow the LAC to indicate its + support of ATM bearer devices. Positive receipt of this indication, + allows both LAC and LNS to use the extensions as defined within this + document to support ATM based incoming and outgoing calls. + + If no compatibility between LNS and LAC exists according to the + extensions defined within this document, no tunnel establishment can + take place. This would be because the LAC does not support any + bearer capability which is expected by the LNS (e.g., an ATM based + LAC, that only signals the "Broadband" Bearer Capability), or vice + + + +T'Joens, et al. Standards Track [Page 4] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + versa. It is however encouraged that LAC or LNS implementations + would allow for seamless interworking with peer devices which do not + implement the extensions defined within this document. This could be + implemented by allowing a graceful fallback to digital bearer + capability. + +3.3 call establishment + + During incoming and outgoing broadband call establishment, the + following extensions are defined to existing procedures. + +3.3.1 Incoming Call Establishment + + The ATM connection between the virtual Dial-in user and LAC MAY + either be dynamically or statically established. When the VC + connection is dynamically established (Switched VC), the LAC will + receive a SETUP message over the interface that connects it to the + ATM network. This specification does not assume any specific + interface type (UNI or NNI). Permanent VC connections MAY either be + manually configured, or configured by use of the extensions to the + ILMI procedures as defined by [Auto_PVC]. + + For switched VC connections, the LAC MAY select the peer LNS on the + basis of connection establishment information, or by allowing partial + PPP authentication of the virtual Dial-in user. The connection + establishment information that can be used by the LAC include Called + Party AESA, Called Party AESA Subaddress, Calling Party AESA or + Calling Party AESA Subaddress. + + For Permanent VC connections, the LAC MAY be triggered by (a) the + establishment of the PVC, (b) by an LCP configure request, (c) by + partially authenticating the virtual Dial-in user, or (d) by means + outside the scope of this specification. + + Within the ICRQ, the LAC MUST indicate a broadband bearer in the + Bearer Type AVP (B bit set to 1), MAY include the Service Category + AVP, and MAY include the Service Name AVP. If the LNS would not + support the B Bearer bit, it will return an error on the ICRQ + message. In such a case, the implementation MAY decide to fall back + to digital bearer capability, and SHOULD refrain from using the + extensions defined within this document. Further, the ICRQ message + MAY contain the VPI/VCI identifier AVP. This identifier can further + be used at the LNS for management purposes next to or alternative to + the Physical Channel ID AVP. + + Within the ICCN, both Tx Connect Speed AVP and Rx Connect Speed + SHOULD be used if an asymetric connection has been established. + + + + +T'Joens, et al. Standards Track [Page 5] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + +3.3.2 Outgoing Call Establishment + + Within an OCRQ, the LNS MUST indicate to the LAC minimum and maximum + speeds for receive and transmit traffic (from the LAC perspective). + This is to allow for the bi-directional asymmetric nature of ATM + traffic contracts. Note that in order to support UBR connections + between LAC and user, the Minimum BPS MUST be set to zero. + + Further during OCRQ, the LNS MAY include the required Service + Category AVP, i.e., indicating real time (rt) or non-real time (nrt) + transport services. The combination of minimum and maximum receive + and transmit speed, and the indication of the required service + category allows the LAC to establish an ATM connection according to + its own capabilities, and the ATM access network capabilities, + however within the service requirement for the PPP layer. + + Real time connectivity can be provided by either CBR or rt-VBR ATM + service categories, non-real time connectivity can be provided by + UBR, nrt-VBR, ABR or GFR ATM service categories. + + Further the LNS MUST indicate to the LAC in OCRQ message the called + number according to the format described in this document (NSAP + format). When the called number carries an all zero payload, the LAC + SHOULD look at the Service Name AVP to bind the tunnel call to an ATM + VC connection. + + Next to the normal AVPs, the OCRP message MAY contain the VPI/VCI + identifier AVP. This identifier can further be used at the LNS for + management purposes next to or alternative to the Physical Channel ID + AVP. + +3.4 Framing + + Within this document the PPP PDU refers to the concatenation of PPP + protocol ID, PPP Information and PPP padding fields. + + In the direction of user to LNS, the PPP PDU will be carried on top + of an AAL5 connection between user and LAC. The LAC MUST strip off + the AAL5 specific fields based on the encapsulation mechanism in use + on the ATM connection, i.e. VC multiplexed or LLC encapsulated + [RFC2364], and MUST encapsulate the PPP PDU with address and control + field, as per HDLC procedures, on the L2TP tunnel. + + In the direction of LNS to user, the PPP PDU will be carried on top + of an AAL5 connection between LAC and user. The LAC MUST strip the + PPP PDU from the address and control field on the L2TP tunnel, and + + + + + +T'Joens, et al. Standards Track [Page 6] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + insert the AAL5 specific fields based on the encapsulation mechanism + in use on the ATM connection, i.e. VC multiplexed or LLC + encapsulated. + +4. Service model issues + +4.1 Authentication + + In case of ATM switched VC establishment, calling party number + information may be used for first level authentication much in the + same way as for PSTN or ISDN access. In case of permanent VC + establishment, authentication may not be an issue from the LAC side, + because of the permanent character of the VC. Bilateral agreement + between LAC and LNS providers may eliminate the authentication phase + in the latter case. + +4.2 Authorization + + Because of the flexibility of establishing ATM connections with + varying parameters, some authorization may be required prior to + accepting the establishment of a switched ATM connection from the + user with certain ATM traffic parameters. This authorization may be + performed against the ATM specific authentication information (e.g. + calling line id), or may be performed after partial authentication of + the user at the PPP level. Non authorized access requests result in + connection release. + +5. New and extended AVPs + +5.1 New AVP Summary + + The following table lists the extra AVPs that are defined within this + document. The "attr" column indicates the integer value assigned to + this attribute. Note that the attribute value is relative compared + to the vendor ID. The "M" column indicates the setting of the + "Mandatory" bit of the AVP header for each attribute. The "LEN" + column indicates the size of the AVP including the AVP header. A "+" + in this column indicates that the length varies depending upon the + length of the actual contents of the value field. + + The usage list for each entry indicates the message types that + utilize each AVP. An abbreviation shown in mixed or upper case + letters indicates that the corresponding AVP MUST be present in this + message type. All lower case indicates that the AVP MAY optionally + appear in this message type. Some AVPs MAY be present only when a + corresponding optional AVP or specific setting within the AVP is + present, these AVPs are shown in lower case as well. + + + + +T'Joens, et al. Standards Track [Page 7] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + Attr M Len Attribute Name (usage) + + 40 0 10 Rx Minimum BPS (ocrq) + 32-bit integer indicating the lowest acceptable line speed for the + call in the receive direction. Rx indicates the user to LAC + direction. + 41 0 10 Rx Maximum BPS (ocrq) + 32-bit integer indicating the highest acceptable line speed for + call in the receive direction. Rx indicates the user to LAC + direction. + 42 0 8 Service Category (ocrq, icrq) + The Service Category indicates the service expected for the call, + e.g., real time or non-real time. + 43 0 6+ Service Name (ocrq, icrq) + The Service Name indicates the service name linked to a + preestablished PVC. + 44 0 26 Calling Sub-Address(icrq) + 20 octet binary encoded NSAP subaddress indicating the Calling + Party Sub-Address. + 45 0 10 VPI/VCI identifier (icrq, ocrp) + 10 octet binary encoded identification of VPI/VCI values used for + incoming calls. + +5.2 New AVP definition + + The following lists the new AVPs defined within this document, and + describes the expected behaviour when this AVP would be present + within a message. + + Rx Minimum BPS (OCRQ) + + The Rx Minimum BPS, Attribute Type 40, encodes the lowest + acceptable line speed for this call in the receive direction, + for these cases where asymmetric transmission is required. + + The Attribute Value field for this AVP has the following + format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rx Minimum BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Rx Minimum BPS is a 32 bit value indicating the speed in + bits per second. + + + + + +T'Joens, et al. Standards Track [Page 8] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + This AVP MAY be included within the OCRQ, and SHOULD only be + included when the LAC indicated broadband bearer support in the + bearer capabilities AVP during tunnel establishment. + + This AVP may be hidden (the H-bit may be set to 0 or 1). The + M- bit for this AVP must be set to 0. The Length (before + hiding) of this AVP is 10. + + Rx Maximum BPS + + The Rx Maximum BPS, Attribute Type 41, encodes the highest + acceptable line speed for this call in the receive direction, + for these cases where asymmetric transmission is required. + + The Attribute Value field for this AVP has the following + format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rx Maximum BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Rx Maximum BPS is a 32 bit value indicating the speed in + bits per second. + + This AVP MAY be included within the OCRQ, and SHOULD only be + included when the LAC indicated broadband bearer support in the + bearer capabilities AVP during tunnel establishment. + + This AVP may be hidden (the H-bit may be set to 0 or 1). The + M- bit for this AVP must be set to 0. The Length (before + hiding) of this AVP is 10. + + Service Category + + The Service Category AVP, Attribute type 42, indicates optional + extra information on the Quality of Service expected for the + call establishment on the broadband bearer medium. + + The Attribute Value field for this AVP has the following + format: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Resvd for future QoS ind. |S| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +T'Joens, et al. Standards Track [Page 9] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + The Attribute Value field is a 16-bit mask, with one bit + defined. The S bit indicates either non real time (S bit set + to 0) or real time (S bit set to 1) service requirement. The + other bit fields are reserved for future use. + + The Service Category AVP MAY be present in OCRQ and ICRQ + messages, and SHOULD only be included when the LAC indicated + broadband bearer support in the bearer capabilities AVP during + tunnel establishment. + + This AVP may be hidden (the H-bit may be set to 0 or 1). The + M- bit for this AVP must be set to 0. The Length (before + hiding) of this AVP is 8. + + Service Name + + The Service Name AVP, Attribute Type 43, provides the peer with + an textual name for referring to an ATM VC connection. + + The Attribute Value field for this AVP has the following + format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Name (arbitrary number of octets) .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Service Name is of arbitrary length, but must be at least 1 + octet. The Service Name is UTF-8 encoded. [10646] + + The Service Name should be unique at least to the LNS/LAC + combination. + + The Service Name AVP MAY only be provided when the Called + Number field is encoded as all zeros in OCRQ. The Service Name + AVP MAY be present in OCRQ and ICRQ messages, and SHOULD only + be included when the LAC indicated broadband bearer support in + the bearer capabilities AVP during tunnel establishment. + + This AVP may be hidden (the H-bit may be set to 0 or 1). The + M- bit for this AVP must be set to 0. The length of this + attribute is arbitrary, however at least 7. + + Calling Sub-Address (ICRQ) + + The Calling Sub-Address AVP, Attribute Type 44, encodes + additional Calling Party subaddress information. + + + +T'Joens, et al. Standards Track [Page 10] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + The Attribute Value field for this AVP has the following + format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Calling Sub-Address AVP MUST be encoded as a 20 octet + binary encoded NSAP address when the B bit is set in the Bearer + Type AVP. The NSAP binary encoded address provides a broader + range of address encapsulation methods than an ASCII field. + The structure of the NSAP address (e.g., E.164, ICD, DCC) is + defined in [AESA]. + + The Calling Sub-Address number AVP MAY be present in ICRQ, and + SHOULD only be available if the Calling Party number is also + within the message. + + This AVP may be hidden (the H-bit may be 0 or 1). The M-bit + for this AVP MUST be set to 0. The Length (before hiding) of + this AVP is 26. + + VPI/VCI identifier(icrq, ocrp) + + The VPI/VCI identifier, Attribute Type 45, encodes the VPI/VCI + value used at the ATM interface at the LAC. + + The Attribute Value field for this AVP has the following + format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |resvd | VPI | VCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The VPI/VCI identifier is a 32 bit value encoding the VPI(12 + bits) and VCI (16 bits) value. + + + +T'Joens, et al. Standards Track [Page 11] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + This AVP MAY be included within the ICRQ and OCRP, and SHOULD + only be included when the LAC indicated broadband bearer + support in the bearer capabilities AVP during tunnel + establishment. + + This AVP may be hidden (the H-bit may be set to 0 or 1). The + M- bit for this AVP must be set to 0. The Length (before + hiding) of this AVP is 10. + +5.3 Changed AVP Definition + + The following AVPs see their contents changed relative to [RFC2661] + in order to support the procedures described in this document. + + Bearer Capabilities + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Resvd for future bearer capability definitions |B|A|D| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The bearer Capabilities AVP within a SCCRQ or SCCRP indicates + the bearer capabilities that the sender of this message can + provide for outgoing calls. This document extends the existing + AVP with the B bit. If bit B is set, broadband access is + supported (ATM). + + Attempts to establish an outgoing call with the bearer type set + to B, while the bearer capability did not indicate this + capability will result in the call being rejected with Result + Code 5 'Call failed due to lack of appropriate facilities being + available (permanent condition)'. + + In these cases where the LAC only supports the B bit, and the + LNS would not recognize the B bit, no outgoing calls are + possible. Note that when the LAC only has ATM based devices, + it may still opt for seamless fall back to digital bearer + types. + + This specification assumes a non-compliant LNS to categorize a + Bearer Capabilities AVP where the B bit is set as unrecognized + AVP, upon which the tunnel establishment will fail. This is to + be indicated by a Result Code '2-General error - Error Code + indicates the problem', Error Code '3- Reserved field was non- + zero'. + + + + + +T'Joens, et al. Standards Track [Page 12] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + (Tx) Minimum BPS + + The (Tx) Minimum BPS AVP encodes the lowest acceptable line + speed for this call in the transmit direction. The (Tx) + Minimum BPS AVP MAY be used in OCRQ. If the Rx Minimum BPS + AVP, as defined within this document, is not available in the + message, then symmetric transmission is implied, with both + minimum receive and transmit bit-rates equal to Minimum BPS. + + (Tx) Maximum BPS + + (Tx) Maximum BPS AVP encodes the highest acceptable line speed + for this call in the transmit direction. The (Tx) Maximum BPS + AVP MAY be used in OCRQ. If the Rx Maximum BPS AVP, as defined + within this document, is not available in the message, then + symmetric transmission is implied, with both maximum receive + and transmit bitrates equal to Maximum BPS. + + Bearer Type + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Resvd for future bearer types definitions |B|A|D| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The bearer type AVP encodes the bearer type for the requested + call. This document extends the bearer types with an + indication of ATM bearer support (B-bit). If bit B is set, + broadband access is requested (ATM). If bit A is set, analogue + access is requested. If bit D is set, Digital access is + requested. + + Note that in the OCRQ all 3 bits (B,A,D) may be set indicating + that the call may be of either type. The B bit SHOULD only be + set if the Broadband capability was indicated during tunnel + establishment. + + Q.931 Cause Code + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cause Code | Cause Msg | Advisory Msg... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +T'Joens, et al. Standards Track [Page 13] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + The Cause code is not changed from [RFC2661], except for the + fact that it can also carry Cause Codes specific to ATM + signalling messages, these cause codes can be found in ATM + + Forum UNI 4.0 [UNI] and the references thereof. The Cause code + should be interpreted relative to the Bearer Type in use for + the specific call. + + Called Number + + The Called Number AVP, Attribute Type 21, encodes the AESA + number to be called for an OCRQ, and the Called number at the + LAC for an ICRQ. + + The Attribute Value field for this AVP has a changed encoding + from [RFC2661]: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Called Number AVP MUST be encoded as a 20 octet binary + encoded NSAP address when the B bit is set in the Bearer Type + AVP. The NSAP binary encoded address provides a broader range + of address encapsulation methods than an ASCII field. The + structure of the NSAP address (e.g., E.164, ICD, DCC) is + defined in [AESA]. + + The Called number AVP MUST be present in OCRQ, and MAY be + present in ICRQ. + + If the Called Number AVP in an OCRQ carries an all zero NSAP + address, the Service Name AVP SHOULD provide further + information to bind the L2TP call to a specific VC connection. + See also [Auto_PVC]. + + + + + + +T'Joens, et al. Standards Track [Page 14] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + This AVP may be hidden (the H-bit may be 0 or 1). The M-bit + for this AVP MUST be set to 0. The Length (before hiding) of + this AVP is 26. + + Calling Number + + The Calling Number AVP, Attribute Type 22, encodes the Calling + Party AESA as received from the Virtual Dial-in User. + + The Attribute Value field for this AVP has a changed encoding + from [RFC2661]: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Calling Number AVP MUST be encoded as a 20 octet binary + encoded NSAP address when the B bit is set in the Bearer Type + AVP. The NSAP binary encoded address provides a broader range + of address encapsulation methods than an ASCII field. The + structure of the NSAP address (e.g., E.164, ICD, DCC) is + defined in [AESA]. + + The Calling number AVP MAY be present in ICRQ. + + This AVP may be hidden (the H-bit may be 0 or 1). The M-bit + for this AVP MUST be set to 0. The Length (before hiding) of + this AVP is 26. + + Sub-Address + + The Sub-Address AVP, Attribute Type 23, encodes additional + Called Party subaddress information. + + The Attribute Value field for this AVP has a changed encoding + from [RFC2661]: + + + + + +T'Joens, et al. Standards Track [Page 15] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NSAP (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Sub-Address AVP MUST be encoded as a 20 octet binary + encoded NSAP address when the B bit is set in the Bearer Type + AVP. The NSAP binary encoded address provides a broader range + of address encapsulation methods than an ASCII field. The + structure of the NSAP address (e.g., E.164, ICD, DCC) is + defined in [AESA]. + + The Sub-Address number AVP MAY be present in ICRQ and OCRQ, and + SHOULD only be available if the Called Party number is also + within the message. + + This AVP may be hidden (the H-bit may be 0 or 1). The M-bit + for this AVP MUST be set to 0. The Length (before hiding) of + this AVP is 26. + +6. IANA Considerations + + This document requires IANA to allocate 6 new type values for the + following AVPs (see section 5.2) : + + - Rx Minimum BPS + + - Rx Maximum BPS + + - Service Category + + - Service Name + + - Calling Sub-Address + + - VPI/VCI Identifier + + This document further defines a new bit (B) in the bearer + capabilities and bearer type AVPs (section 5.3). + + + +T'Joens, et al. Standards Track [Page 16] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + + This document defines a flag field in the Service Category AVP, only + one bit in this flag has been assigned within this document (S). + Further assignments fall under the rule of "Specification Required", + i.e. Values and their meaning must be documented in an RFC or other + permanent and readily available reference, in sufficient detail so + that interoperability between independent implementations is + possible. + +7. Security Considerations + + No extra security risk outside these specified by [RFC2661] are + foreseen. + +8. Acknowledgements + + The authors would like to thank Laurent Hermans for his work on + earlier versions of this document, Juha Heinanen (Telia) and David + Allen (Nortel Networks) for their constructive discussion on the + document during the Minneapolis IETF meeting, Mark Townsley (cisco) + for his hint on the use of the VPI/VCI identifier AVP. + +9. References + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G., + Zorn, G. and B. Palter, "Layer Two Tunnelling Protocol + (L2TP)", RFC 2661, August 1999. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A. and J. + Stephens, "PPP over AAL5", RFC 2364, July 1998. + + [UNI] User-Network Interface (UNI) Specification, Version 4.0, + ATM Forum, July, 1996 + + [AESA] ATM Forum Addressing : Reference Guide, version 1.0, ATM + Forum, Final Ballot, January 1999 + + [L2TP_link] Townsley, M. and W. Palter, "L2TP Link Extensions", Work + in Progress. + + [Auto_PVC] ATM Forum, "Auto-configuration of PVCs", af-nm-0122.000, + March 1999 + + [10646] ISO/IEC, Information Technology - Universal Multiple- + Octet Coded Character Set (UCS) - Part 1: Architecture + and Basic Multilingual Plane, May 1993, with amendments + + + +T'Joens, et al. Standards Track [Page 17] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + +10. Authors Addresses + + Yves T'joens + Alcatel Network Strategy Group + Francis Wellesplein 1, 2018 Antwerp, Belgium + Phone : +32 3 240 7890 + EMail : yves.tjoens@alcatel.be + + Paolo Crivellari + Belgacom + bd du Roi Albert II 27 + B-1030 Bruxelles + Phone: +32 2 202 9698 + EMail: paolo.crivellari@belgacom.be + + Bernard Sales + Alcatel Network Strategy Group + Francis Wellesplein 1, 2018 Antwerp, Belgium + Phone : +32 3 240 9574 + EMail : bernard.sales@alcatel.be + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +T'Joens, et al. Standards Track [Page 18] + +RFC 3301 L2TP: ATM access network extensions June 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + 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 in 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. 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. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +T'Joens, et al. Standards Track [Page 19] + |