📄 rfc3301.txt
字号:
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]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -