in a TCP-friendly manner prescribed by [RFC2914]. In the presence of
services that reduce transmission rate, ATMPWs carrying CBR and VBR-
rt traffic SHOULD be halted when acute congestion is detected, in
order to allow for other traffic or the network infrastructure itself
to continue. ATMPWs carrying unspecified bit rate (UBR) traffic,
which are equivalent to best-effort IP service, need not be halted
during acute congestion and MAY have cells delayed or dropped by the
ingress PE if necessary. ATMPWs carrying variable bit rate-non real
time (VBR-nrt) services may or may not behave in a TCP-friendly
manner, depending on the end user application, but are most likely
safe to continue operating, since the end-user application is
expected to be delay-insensitive and may also be somewhat loss-
insensitive.
LCCEs SHOULD monitor for congestion (for example, by measuring packet
loss or as specified in Section 6.5 of [RFC3985]) in order to ensure
that the ATM service may be maintained. When severe congestion is
detected (for example, when enabling sequencing and detecting that
the packet loss is higher than a threshold), the ATM service SHOULD
be terminated by tearing down the L2TP session via a CDN message.
The PW may be restarted by manual intervention, or by automatic means
after an appropriate waiting time.
11. Security Considerations
ATM over L2TPv3 is subject to the security considerations defined in
[RFC3931]. There are no additional considerations specific to
carrying ATM that are not present carrying other data link types.
12. IANA Considerations
The signaling mechanisms defined in this document rely upon the
allocation of the following ATM Pseudowire Types (see Pseudowire
Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3
Pseudowire Types in 10.6 of [RFC3931]) by the IANA (number space
created as part of publication of [RFC3931]):
Pseudowire Types
----------------
0x0002 ATM AAL5 SDU VCC transport
0x0003 ATM Cell transparent Port Mode
0x0009 ATM Cell transport VCC Mode
0x000A ATM Cell transport VPC Mode
12.1. L2-Specific Sublayer Type
This number space is created and maintained per [RFC3931].
L2-Specific Sublayer Type
-------------------------
2 - ATM L2-Specific Sublayer present
12.2. Control Message Attribute Value Pairs (AVPs)
This number space is managed by IANA as per [BCP0068].
A summary of the three new AVPs follows:
Control Message Attribute Value Pairs
Attribute
Type Description
--------- ----------------------------------
86 ATM Maximum Concatenated Cells AVP
87 OAM Emulation Required AVP
88 ATM Alarm Status AVP
12.3. Result Code AVP Values
This number space is managed by IANA as per [BCP0068].
A new Result Code value for the CDN message is defined in Section 7.
Following is a summary:
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
General Error Codes
22 - Session not established due to other LCCE
cannot support the OAM Cell Emulation
12.4. ATM Alarm Status AVP Values
This is a new registry for IANA to maintain.
New Attribute values for the ATM Alarm Status AVP in the SLI message
are defined in Section 8.1. Additional values may be assigned by
Expert Review [RFC2434]. Following is a summary:
ATM Alarm Status AVP (Attribute Type 88) Values
-----------------------------------------------
Circuit Status Reason values for the SLI message are as follows:
0 - Reserved
1 - No alarm or alarm cleared (default for Active Status)
2 - Unspecified or unknown Alarm Received (default for
Inactive Status)
3 - ATM Circuit received F1 Alarm on ingress LCCE
4 - ATM Circuit received F2 Alarm on ingress LCCE
5 - ATM Circuit received F3 Alarm on ingress LCCE
6 - ATM Circuit received F4 Alarm on ingress LCCE
7 - ATM Circuit received F5 Alarm on ingress LCCE
8 - ATM Circuit down due to ATM Port shutdown on Peer LCCE
9 - ATM Circuit down due to loop-back timeout on ingress LCCE
The general ATM Alarm failures are encoded as below:
0 - Reserved
1 - No Alarm type specified (default)
2 - Alarm Indication Signal (AIS)
3 - Remote Defect Indicator (RDI)
4 - Loss of Signal (LOS)
5 - Loss of Pointer (LOP)
6 - Loss of Framer (LOF)
7 - Loopback cells (LB)
8 - Continuity Check (CC)
12.5. ATM-Specific Sublayer Bits
This is a new registry for IANA to maintain.
The ATM-Specific Sublayer contains 8 bits in the low-order portion of
the header. Reserved bits may be assigned by IETF Consensus
[RFC2434].
Bit 0 - Reserved
Bit 1 - S (Sequence) bit
Bit 2 - B (Fragmentation) bit
Bit 3 - E (Fragmentation) bit
Bit 4 - T (Transport type) bit
Bit 5 - G (EFCI) bit
Bit 6 - C (CLP) bit
Bit 7 - U (Command/Response) bit
13. Acknowledgements
Thanks for the contributions from Jed Lau, Pony Zhu, Prasad Yaditi,
Durai, and Jaya Kumar.
Many thanks to Srinivas Kotamraju for editorial review.
Thanks to Shoou Yiu and Fred Shu for giving their valuable time to
review this document.
14. References
14.1. Normative References
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References
[PWE3ATM] Martini, L., "Encapsulation Methods for Transport of ATM
Over MPLS Networks", Work in Progress, September 2005.
[L2TPFRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and
Reassembly", Work in Progress, November 2005.
[FRF8.1] "Frame Relay / ATM PVC Service Interworking Implementation
Agreement (FRF 8.1)", Frame Relay Forum 2000.
[BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA) Considerations
Update", BCP 68, RFC 3438, December 2002.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[I610-1] ITU-T Recommendation I.610 (1999): B-ISDN operation and
maintenance principles and functions
[I610-2] ITU-T Recommendation I.610, Corrigendum 1 (2000): B-ISDN
operation and maintenance principles and functions
(corrigendum 1)
[I610-3] ITU-T Recommendation I.610, Amendment 1 (2000): B-ISDN
operation and maintenance principles and functions
(Amendment 1)
[ATMSEC] ATM Forum Specification, af-sec-0100.002 (2001): ATM
Security Specification version 1.1
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
Authors’ Addresses
Sanjeev Singh
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
EMail: sanjeevs@cisco.com
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: mark@townsley.net
Carlos Pignataro
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: cpignata@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).