As per Relevance of the word establish, we have this rfc below:
Network Working Group Y. T'
Request for Comments: 3301 B.
Category: Standards Track
P.
June 2002
Layer Two Tunnelling Protocol (L2TP):
ATM access network
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document augments the procedures described in RFC 2661
further support ATM SVC (Switched Virtual Circuits) or PVC (
Virtual Circuits) based access networks. L2TP (Layer 2
Protocol) specifies a protocol for tunnelling PPP packets over
based networks and over IP networks in particular. L2TP
remote access by ISDN and PSTN networks. The extensions
within this document allow for asymmetric bi-directional
establishment and service selection in the ATM access network
Table Of
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.
L2TP [RFC2661] defines the procedures for tunneling PPP
between a so called L2TP Access Concentrator (LAC) and an L2
Network Server (LNS). The main focus of [RFC2661] is on
HDLC based ISDN/PSTN access networks
This document augments the procedures described in [RFC2661]
further support ATM SVC or PVC based access networks. Support
ATM access networks requires extensions to the present L2
procedures so as to cope with :
(a) the traffic management aspects of ATM connections (e.g
asymmetric bandwidth allocation and service category
capabilities),
(b) the addressing format to be used in switched ATM networks [AESA
(c) the limitations imposed on LCP negotiation by transporting
over AAL5 over the access network segment of the PPP
[RFC2364].
Within this document, the necessary extensions to [RFC2661]
defined to cope with issues (a) and (b), issue (c) which is
specific to ATM may be solved as described in [L2TP_link].
1.1
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in
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.
In this section we describe some assumptions that have lead to
extensions described in this document
2.1
The procedures as defined in [RFC2661] apply mainly to access
technology such as PSTN and ISDN, which may be
asynchronous HDLC and synchronous HDLC based. The aim of
document is to extend L2TP support to allow for user /
communication based on ATM access network technology
2.2 Connection
Due to the wide variety of existing signalling protocols and
service categories, and their support or non-support within ATM
access networks, this document takes as approach to provide for
flexible identification of ATM connection characteristics
establishing outgoing and incoming L2TP calls. The procedures
defined within this document allow the allocation of
bandwidth and service category selection in terms of real or non-
time requirements on the ATM portion of the access network
As such, the detailed signalling protocol specific
elements that are necessary for switched VC service, are
not negotiated during call establishment over the L2TP tunnel
In order to identify the endpoint of the ATM connection within
ATM access network, SVCs can be established on the basis of the
end system addressing format [AESA]. For PVC based services, the
can either be referred to by using the ATM end system
procedure (Called/Calling Number), or by making use of a textual
(Service Name). The latter is inspired by the procedures
within [Auto_PVC].
2.3 LCP
The procedures described within this document may be combined
the procedures described in [L2TP_link] to limit LCP
between LNS and user, so as to enforce PPP over AAL5 specific
negotiation [RFC2364].
3. ATM access enhanced
In order to illustrate the procedures specified within this document
this section will provide an operational description of
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
document relative to [RFC2661].
3.1 ATM
Prior to initiating the PPP protocol layer, a Virtual Connection (VC
MUST be established between the user and the Network Access
(LAC). This virtual connection MAY either be a
Permanent VC(PVC), where the access network provider, NAS and
agree beforehand on the characteristics of the PVC, or MAY be an on
demand switched VC(SVC), where the negotiation between user,
and NAS takes place by means of an ATM signalling protocol.
that for establishing PVCs, alternative use may be made of
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-
user, the LAC MAY check with the LNS whether the call should
accepted. In the latter situation, the LAC MAY determine based
parameters available within the call establishment message that
concerns a virtual dial in user, or MAY undertake a
authentication of the end system/user, in order to bind the
system/user with a specific LNS
For PVC based users, the LAC MAY be triggered by the arrival of
LCP Configure Request, or PPP Authentication request message from
virtual dial-in user to initiate conversation with the LNS.
that the exact timing of triggering communication between LAC and
is outside the scope of this document
3.2 Tunnel
If no tunnel connection currently exists to the desired LNS, one
initiated. During the tunnel establishment, LNS and LAC
bearer and framing capabilities to each other, according to
procedures
The bearer capability is extended to allow the LAC to indicate
support of ATM bearer devices. Positive receipt of this indication
allows both LAC and LNS to use the extensions as defined within
document to support ATM based incoming and outgoing calls
If no compatibility between LNS and LAC exists according to
extensions defined within this document, no tunnel establishment
take place. This would be because the LAC does not support
bearer capability which is expected by the LNS (e.g., an ATM
LAC, that only signals the "Broadband" Bearer Capability), or
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
would allow for seamless interworking with peer devices which do
implement the extensions defined within this document. This could
implemented by allowing a graceful fallback to digital
capability
3.3 call
During incoming and outgoing broadband call establishment,
following extensions are defined to existing procedures
3.3.1 Incoming Call
The ATM connection between the virtual Dial-in user and LAC
either be dynamically or statically established. When the
connection is dynamically established (Switched VC), the LAC
receive a SETUP message over the interface that connects it to
ATM network. This specification does not assume any
interface type (UNI or NNI). Permanent VC connections MAY either
manually configured, or configured by use of the extensions to
ILMI procedures as defined by [Auto_PVC].
For switched VC connections, the LAC MAY select the peer LNS on
basis of connection establishment information, or by allowing
PPP authentication of the virtual Dial-in user. The
establishment information that can be used by the LAC include
Party AESA, Called Party AESA Subaddress, Calling Party AESA
Calling Party AESA Subaddress
For Permanent VC connections, the LAC MAY be triggered by (a)
establishment of the PVC, (b) by an LCP configure request, (c)
partially authenticating the virtual Dial-in user, or (d) by
outside the scope of this specification
Within the ICRQ, the LAC MUST indicate a broadband bearer in
Bearer Type AVP (B bit set to 1), MAY include the Service
AVP, and MAY include the Service Name AVP. If the LNS would
support the B Bearer bit, it will return an error on the
message. In such a case, the implementation MAY decide to fall
to digital bearer capability, and SHOULD refrain from using
extensions defined within this document. Further, the ICRQ
MAY contain the VPI/VCI identifier AVP. This identifier can
be used at the LNS for management purposes next to or alternative
the Physical Channel ID AVP
Within the ICCN, both Tx Connect Speed AVP and Rx Connect
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
Within an OCRQ, the LNS MUST indicate to the LAC minimum and
speeds for receive and transmit traffic (from the LAC perspective).
This is to allow for the bi-directional asymmetric nature of
traffic contracts. Note that in order to support UBR
between LAC and user, the Minimum BPS MUST be set to zero
Further during OCRQ, the LNS MAY include the required
Category AVP, i.e., indicating real time (rt) or non-real time (nrt
transport services. The combination of minimum and maximum
and transmit speed, and the indication of the required
category allows the LAC to establish an ATM connection according
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
service categories, non-real time connectivity can be provided
UBR, nrt-VBR, ABR or GFR ATM service categories
Further the LNS MUST indicate to the LAC in OCRQ message the
number according to the format described in this document (
format). When the called number carries an all zero payload, the
SHOULD look at the Service Name AVP to bind the tunnel call to an
VC connection
Next to the normal AVPs, the OCRP message MAY contain the VPI/
identifier AVP. This identifier can further be used at the LNS
management purposes next to or alternative to the Physical Channel
AVP
3.4
Within this document the PPP PDU refers to the concatenation of
protocol ID, PPP Information and PPP padding fields
In the direction of user to LNS, the PPP PDU will be carried on
of an AAL5 connection between user and LAC. The LAC MUST strip
the AAL5 specific fields based on the encapsulation mechanism in
on the ATM connection, i.e. VC multiplexed or LLC
[RFC2364], and MUST encapsulate the PPP PDU with address and
field, as per HDLC procedures, on the L2TP tunnel
In the direction of LNS to user, the PPP PDU will be carried on
of an AAL5 connection between LAC and user. The LAC MUST strip
PPP PDU from the address and control field on the L2TP tunnel,
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
in use on the ATM connection, i.e. VC multiplexed or
encapsulated
4. Service model
4.1
In case of ATM switched VC establishment, calling party
information may be used for first level authentication much in
same way as for PSTN or ISDN access. In case of permanent
establishment, authentication may not be an issue from the LAC side
because of the permanent character of the VC. Bilateral
between LAC and LNS providers may eliminate the authentication
in the latter case
4.2
Because of the flexibility of establishing ATM connections
varying parameters, some authorization may be required prior
accepting the establishment of a switched ATM connection from
user with certain ATM traffic parameters. This authorization may
performed against the ATM specific authentication information (e.g
calling line id), or may be performed after partial authentication
the user at the PPP level. Non authorized access requests result
connection release
5. New and extended
5.1 New AVP
The following table lists the extra AVPs that are defined within
document. The "attr" column indicates the integer value assigned
this attribute. Note that the attribute value is relative
to the vendor ID. The "M" column indicates the setting of
"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
length of the actual contents of the value field
The usage list for each entry indicates the message types
utilize each AVP. An abbreviation shown in mixed or upper
letters indicates that the corresponding AVP MUST be present in
message type. All lower case indicates that the AVP MAY
appear in this message type. Some AVPs MAY be present only when
corresponding optional AVP or specific setting within the AVP
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
call in the receive direction. Rx indicates the user to
direction
41 0 10 Rx Maximum BPS (ocrq
32-bit integer indicating the highest acceptable line speed
call in the receive direction. Rx indicates the user to
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
preestablished PVC
44 0 26 Calling Sub-Address(icrq
20 octet binary encoded NSAP subaddress indicating the
Party Sub-Address
45 0 10 VPI/VCI identifier (icrq, ocrp
10 octet binary encoded identification of VPI/VCI values used
incoming calls
5.2 New AVP
The following lists the new AVPs defined within this document,
describes the expected behaviour when this AVP would be
within a message
Rx Minimum BPS (OCRQ
The Rx Minimum BPS, Attribute Type 40, encodes the
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
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
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
included when the LAC indicated broadband bearer support in
bearer capabilities AVP during tunnel establishment
This AVP may be hidden (the H-bit may be set to 0 or 1).
M- bit for this AVP must be set to 0. The Length (
hiding) of this AVP is 10.
Rx Maximum
The Rx Maximum BPS, Attribute Type 41, encodes the
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
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
bits per second
This AVP MAY be included within the OCRQ, and SHOULD only
included when the LAC indicated broadband bearer support in
bearer capabilities AVP during tunnel establishment
This AVP may be hidden (the H-bit may be set to 0 or 1).
M- bit for this AVP must be set to 0. The Length (
hiding) of this AVP is 10.
Service
The Service Category AVP, Attribute type 42, indicates
extra information on the Quality of Service expected for
call establishment on the broadband bearer medium
The Attribute Value field for this AVP has the
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
defined. The S bit indicates either non real time (S bit
to 0) or real time (S bit set to 1) service requirement.
other bit fields are reserved for future use
The Service Category AVP MAY be present in OCRQ and
messages, and SHOULD only be included when the LAC
broadband bearer support in the bearer capabilities AVP
tunnel establishment
This AVP may be hidden (the H-bit may be set to 0 or 1).
M- bit for this AVP must be set to 0. The Length (
hiding) of this AVP is 8.
Service
The Service Name AVP, Attribute Type 43, provides the peer
an textual name for referring to an ATM VC connection
The Attribute Value field for this AVP has the
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/
combination
The Service Name AVP MAY only be provided when the
Number field is encoded as all zeros in OCRQ. The Service
AVP MAY be present in OCRQ and ICRQ messages, and SHOULD
be included when the LAC indicated broadband bearer support
the bearer capabilities AVP during tunnel establishment
This AVP may be hidden (the H-bit may be set to 0 or 1).
M- bit for this AVP must be set to 0. The length of
attribute is arbitrary, however at least 7.
Calling Sub-Address (ICRQ
The Calling Sub-Address AVP, Attribute Type 44,
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
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
binary encoded NSAP address when the B bit is set in the
Type AVP. The NSAP binary encoded address provides a
range of address encapsulation methods than an ASCII field
The structure of the NSAP address (e.g., E.164, ICD, DCC)
defined in [AESA].
The Calling Sub-Address number AVP MAY be present in ICRQ,
SHOULD only be available if the Calling Party number is
within the message
This AVP may be hidden (the H-bit may be 0 or 1). The M-
for this AVP MUST be set to 0. The Length (before hiding)
this AVP is 26.
VPI/VCI identifier(icrq, ocrp
The VPI/VCI identifier, Attribute Type 45, encodes the VPI/
value used at the ATM interface at the LAC
The Attribute Value field for this AVP has the
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
only be included when the LAC indicated broadband
support in the bearer capabilities AVP during
establishment
This AVP may be hidden (the H-bit may be set to 0 or 1).
M- bit for this AVP must be set to 0. The Length (
hiding) of this AVP is 10.
5.3 Changed AVP
The following AVPs see their contents changed relative to [RFC2661]
in order to support the procedures described in this document
Bearer
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
the bearer capabilities that the sender of this message
provide for outgoing calls. This document extends the
AVP with the B bit. If bit B is set, broadband access
supported (ATM).
Attempts to establish an outgoing call with the bearer type
to B, while the bearer capability did not indicate
capability will result in the call being rejected with
Code 5 'Call failed due to lack of appropriate facilities
available (permanent condition)'.
In these cases where the LAC only supports the B bit, and
LNS would not recognize the B bit, no outgoing calls
possible. Note that when the LAC only has ATM based devices
it may still opt for seamless fall back to digital
types
This specification assumes a non-compliant LNS to categorize
Bearer Capabilities AVP where the B bit is set as
AVP, upon which the tunnel establishment will fail. This is
be indicated by a Result Code '2-General error - Error
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
The (Tx) Minimum BPS AVP encodes the lowest acceptable
speed for this call in the transmit direction. The (Tx
Minimum BPS AVP MAY be used in OCRQ. If the Rx Minimum
AVP, as defined within this document, is not available in
message, then symmetric transmission is implied, with
minimum receive and transmit bit-rates equal to Minimum BPS
(Tx) Maximum
(Tx) Maximum BPS AVP encodes the highest acceptable line
for this call in the transmit direction. The (Tx) Maximum
AVP MAY be used in OCRQ. If the Rx Maximum BPS AVP, as
within this document, is not available in the message,
symmetric transmission is implied, with both maximum
and transmit bitrates equal to Maximum BPS
Bearer
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
call. This document extends the bearer types with
indication of ATM bearer support (B-bit). If bit B is set
broadband access is requested (ATM). If bit A is set,
access is requested. If bit D is set, Digital access
requested
Note that in the OCRQ all 3 bits (B,A,D) may be set
that the call may be of either type. The B bit SHOULD only
set if the Broadband capability was indicated during
establishment
Q.931 Cause
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
fact that it can also carry Cause Codes specific to
signalling messages, these cause codes can be found in
Forum UNI 4.0 [UNI] and the references thereof. The Cause
should be interpreted relative to the Bearer Type in use
the specific call
Called
The Called Number AVP, Attribute Type 21, encodes the
number to be called for an OCRQ, and the Called number at
LAC for an ICRQ
The Attribute Value field for this AVP has a changed
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
encoded NSAP address when the B bit is set in the Bearer
AVP. The NSAP binary encoded address provides a broader
of address encapsulation methods than an ASCII field.
structure of the NSAP address (e.g., E.164, ICD, DCC)
defined in [AESA].
The Called number AVP MUST be present in OCRQ, and MAY
present in ICRQ
If the Called Number AVP in an OCRQ carries an all zero
address, the Service Name AVP SHOULD provide
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-
for this AVP MUST be set to 0. The Length (before hiding)
this AVP is 26.
Calling
The Calling Number AVP, Attribute Type 22, encodes the
Party AESA as received from the Virtual Dial-in User
The Attribute Value field for this AVP has a changed
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
encoded NSAP address when the B bit is set in the Bearer
AVP. The NSAP binary encoded address provides a broader
of address encapsulation methods than an ASCII field.
structure of the NSAP address (e.g., E.164, ICD, DCC)
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-
for this AVP MUST be set to 0. The Length (before hiding)
this AVP is 26.
Sub-
The Sub-Address AVP, Attribute Type 23, encodes
Called Party subaddress information
The Attribute Value field for this AVP has a changed
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
encoded NSAP address when the B bit is set in the Bearer
AVP. The NSAP binary encoded address provides a broader
of address encapsulation methods than an ASCII field.
structure of the NSAP address (e.g., E.164, ICD, DCC)
defined in [AESA].
The Sub-Address number AVP MAY be present in ICRQ and OCRQ,
SHOULD only be available if the Called Party number is
within the message
This AVP may be hidden (the H-bit may be 0 or 1). The M-
for this AVP MUST be set to 0. The Length (before hiding)
this AVP is 26.
6. IANA
This document requires IANA to allocate 6 new type values for
following AVPs (see section 5.2) :
- Rx Minimum
- Rx Maximum
- Service
- Service
- Calling Sub-
- VPI/VCI
This document further defines a new bit (B) in the
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,
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
permanent and readily available reference, in sufficient detail
that interoperability between independent implementations
possible
7. Security
No extra security risk outside these specified by [RFC2661]
foreseen
8.
The authors would like to thank Laurent Hermans for his work
earlier versions of this document, Juha Heinanen (Telia) and
Allen (Nortel Networks) for their constructive discussion on
document during the Minneapolis IETF meeting, Mark Townsley (cisco
for his hint on the use of the VPI/VCI identifier AVP
9.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G.,
Zorn, G. and B. Palter, "Layer Two Tunnelling
(L2TP)", RFC 2661, August 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to
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,
Forum, Final Ballot, January 1999
[L2TP_link] Townsley, M. and W. Palter, "L2TP Link Extensions",
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:
and Basic Multilingual Plane, May 1993, with
T'Joens, et al. Standards Track [Page 17]
RFC 3301 L2TP: ATM access network extensions June 2002
10. Authors
Yves T'
Alcatel Network Strategy
Francis Wellesplein 1, 2018 Antwerp,
Phone : +32 3 240 7890
EMail : yves.tjoens@alcatel.
Paolo
bd du Roi Albert II 27
B-1030
Phone: +32 2 202 9698
EMail: paolo.crivellari@belgacom.
Bernard
Alcatel Network Strategy
Francis Wellesplein 1, 2018 Antwerp,
Phone : +32 3 240 9574
EMail : bernard.sales@alcatel.
T'Joens, et al. Standards Track [Page 18]
RFC 3301 L2TP: ATM access network extensions June 2002
11. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
T'Joens, et al. Standards Track [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
