Network Working Group N. McGill
Internet-Draft C. Pignataro
Updates: 3931 (if approved) Cisco Systems
Intended status: Standards Track November 19, 2008
Expires: May 23, 2009
L2TPv3 Extended Circuit Status Values
draft-ietf-l2tpext-circuit-status-extensions-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 23, 2009.
Abstract
This document defines additional Layer 2 Tunneling Protocol Version 3
(L2TPv3) bit values to be used within the "Circuit Status" Attribute
Value Pair (AVP) to communicate more granular error states for Access
Circuits and Pseudowires. It also deprecates the use of the New bit
in the "Circuit Status" AVP, updating RFC3931.
McGill & Pignataro Expires May 23, 2009 [Page 1]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. L2TPv3 Extended Circuit Status Values . . . . . . . . . . . . 3
3. Circuit Status Usage and Clarifications . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
McGill & Pignataro Expires May 23, 2009 [Page 2]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
1. Introduction
Currently the L2TPv3 Circuit Status AVP [RFC3931] is able to convey
the UP/DOWN status of an access circuit. However, a finer
granularity is often useful to determine the direction of the fault
as has been added for MPLS-based pseudowires and used in the
pseudowire control protocol using LDP, see Section 3.5 of [RFC4446]
and Section 5.4.2 of [RFC4447].
Additionally, it is useful (in redundancy scenarios) to be able to
indicate if a pseudowire is in a standby state, where it is fully
established but is not switching data. Again, such functionality is
available for MPLS-based pseudowires using LDP, see
[I-D.ietf-pwe3-redundancy-bit].
This document provides extended circuit status bit values for L2TPv3
and adds them in a manner such that it is backwards compatible with
the current Circuit Status AVP. These new bits are applicable to all
pseudowires types that use the Circuit Status AVP.
1.1. Specification of Requirements
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].
2. L2TPv3 Extended Circuit Status Values
The Circuit Status AVP (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI),
Attribute Type 71, indicates the initial status of or a status change
in the circuit to which the session is bound.
The Attribute Value field for this AVP currently defined in [RFC3931]
has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit Bit-Value Name
----------------------------------------------------------------
(A) 15 0x0001 Active
(N) 14 0x0002 New
As currently defined in [RFC3931], the two bits have the following
McGill & Pignataro Expires May 23, 2009 [Page 3]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
meanings:
o The A (Active) bit indicates whether the circuit is up/active/
ready (1) or down/inactive/not-ready (0).
o The N (New) bit indicates whether the circuit status indication is
for a new circuit (1) or an existing circuit (0).
This document updates the semantics of the A and N bits as follows:
The A (Active) bit indicates whether the local pseudowire endpoint
(both local attachment circuit and local PSN-facing pseudowire) has
no faults present and is up/active/ready (1) or has faults present
and is down/inactive/not-ready (0).
The N (New) bit indicates if the notification is for a new circuit
(1) or an existing circuit (0), and is provided to emulate (Frame
Relay) NNI signaling between PEs. It MAY be used to convey that a
circuit has been re-provisioned or newly provisioned at the PE, which
can already be inferred from the L2TP control message type. It is
therefore uncertain as to what use the receiving PE can make of this
bit, although it MAY include logging. This document deprecates this
bit as it is of little or no use, hence this bit SHOULD be ignored on
receipt and is OPTIONAL to send. For reference, see Section 3.4 of
[RFC4591] which does not specify any additional usage beyond the
setting of in the ICRQ, ICRP (and OCRQ, OCRP) and clearing in all
other control messages.
This document also extends this bitmap of values to allow for finer
granularity of local pseudowire (i.e., access circuit or PSN-facing
endpoint) status reporting.
The Attribute Value field for the Circuit Status AVP including the
new values has the following format:
McGill & Pignataro Expires May 23, 2009 [Page 4]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|E|I|T|R|0|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit Bit-Value Name
-----------------------------------------------------------------
(A) 15 0x0001 Active: Pseudowire has no faults
(N) 14 0x0002 New [use deprecated]
(R) 13 0x0004 Local Attachment Circuit (ingress) Receive Fault
(T) 12 0x0008 Local Attachment Circuit (egress) Transmit Fault
(I) 11 0x0010 Local PSN-facing PW (ingress) Receive Fault
(E) 10 0x0020 Local PSN-facing PW (egress) Transmit Fault
(S) 9 0x0040 Pseudowire is in Standby mode
The new bits values have the following meanings:
(R), Local Attachment Circuit (ingress) Receive Fault
Fault Here
|
|
| +----------------------+ +----------------------+
| Rx| LCCE |Egress | Peer LCCE |
--X-->| |-------->| |
| L2TPv3 | [PSN] | L2TPv3 |
Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit |
<-----| |<--------| |
+----------------------+ +----------------------+
An alarm or fault has occurred at the local attachment circuit
such that it is unable to receive traffic. It can still transmit
traffic.
McGill & Pignataro Expires May 23, 2009 [Page 5]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
(T), Local Attachment Circuit (egress) Transmit Fault
+----------------------+ +----------------------+
Rx| LCCE |Egress | Peer LCCE |
----->| |-------->| |
| L2TPv3 | [PSN] | L2TPv3 |
Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit |
<--X--| |<--------| |
| +----------------------+ +----------------------+
|
|
Fault Here
A fault has occurred at the local attachment circuit such that it
is unable to transmit traffic. It can still receive traffic.
(I), Local PSN-facing PW (ingress) Receive Fault
+----------------------+ +----------------------+
Rx| LCCE |Egress | Peer LCCE |
----->| |-------->| |
| L2TPv3 | [PSN] | L2TPv3 |
Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit |
<-----| |<---X----| |
+----------------------+ | +----------------------+
|
|
Fault Here
A fault has occurred in the receive direction between the local
endpoint and the remote L2TP endpoint.
Note that a fault at the session level would not necessarily
trigger an L2TP control connection timeout. The means of
detecting this fault are outside the scope of this document; as an
example, detection may be via PW Type-specific means, BFD, or
other methods.
McGill & Pignataro Expires May 23, 2009 [Page 6]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
(E), Local PSN-facing PW (egress) Transmit Fault
Fault Here
|
|
+----------------------+ | +----------------------+
Rx| LCCE |Egress| | Peer LCCE |
----->| |------X->| |
| L2TPv3 | [PSN] | L2TPv3 |
Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit |
<-----| |<--------| |
+----------------------+ +----------------------+
A fault has occurred in the transmit direction between the local
endpoint and the remote L2TP endpoint.
Note that a fault at the session level would not necessarily
trigger an L2TP control connection timeout. The means of
detecting this fault are outside the scope of this document; as an
example, detection may be via PW Type-specific means, BFD, or
other methods.
(S), Pseudowire is in Standby mode
Standby
|
|
+----------------------+ | +----------------------+
Rx| LCCE |Egress | Peer LCCE |
----->| |---X---->| |
| L2TPv3 | [PSN] | L2TPv3 |
Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit |
<-----| |<--X-----| |
+----------------------+ | +----------------------+
|
|
Standby
The pseudowire has been placed into a standby mode which means
that although it was signaled and is operational, it is NOT
switching traffic. Any received traffic SHOULD be dropped.
Traffic MUST NOT be transmitted.
3. Circuit Status Usage and Clarifications
The following are clarifications regarding the usage of the Circuit
Status AVP bits:
McGill & Pignataro Expires May 23, 2009 [Page 7]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
o The (R), (T), (I) and (E) bits are collectively referred to as
"fault status bits".
o [RFC3931] defined the (A) bit as pertaining to local access
circuit state only. This draft redefines it as meaning that "no
faults are present on the local pseudowire endpoint."
o If multiple faults occur, all the fault status bits corresponding
to each fault MUST be set (i.e., they MUST be bitwise-OR-d
together).
o The (A) bit MUST NOT be set until all fault status bits are
cleared. This behavior allows an endpoint to be backwards
compatible with a remote endpoint that does not understand these
new status bits.
o If any of the fault status bits are set, then the (A) bit MUST be
cleared. That is, the fault status bits (R, T, I, E) are a more
granular definition of (A), such that OR-ing the bits provides an
inverted (A).
o If (A) is clear and the fault status bits (R, T, I, E) are clear,
it means that there is no extended circuit status. That is, the
circuit is down/inactive/not-ready (from the (A) bit), without a
more granular (extended) indication.
o The (S) bit can be set in conjunction with any other bit,
including (A). A pseudowire endpoint in Standby (S bit set) can
be up/active/ready (A bit set) or experiencing a fault (A bit
cleared and (R, T, I, E) bit(s) set).
o Leaving standby mode is indicated by the clearing of the (S) bit.
o The usage of the (N) bit has been deprecated.
4. Security Considerations
No additional security considerations exist with extending this
attribute.
5. IANA Considerations
The Circuit Status Bits number space reachable at
[IANA.l2tp-parameters] is managed by IANA as per [RFC3931]. Five new
bits (bits 9 through 13) and one updated bit (bit 14) are requested
to be assigned as follows:
McGill & Pignataro Expires May 23, 2009 [Page 8]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
Circuit Status Bits - per [RFC3931]
-------------------
Bit 9 - S (Standby) bit
Bit 10 - E (Local PSN-facing PW (egress) Tx Fault) bit
Bit 11 - I (Local PSN-facing PW (ingress) Rx Fault) bit
Bit 12 - T (Local AC (egress) Tx Fault) bit
Bit 13 - R (Local AC (ingress) Rx Fault) bit
Bit 14 - N (New) bit [use deprecated]
6. Acknowledgements
The authors wish to thank Muhammad Yousuf, Mark Townsley, George
Wilkie, and Prashant Jhingran for comments received.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
7.2. Informative References
[I-D.ietf-pwe3-redundancy-bit]
Muley, P., Bocci, M., and L. Martini, "Preferential
Forwarding Status bit definition",
draft-ietf-pwe3-redundancy-bit-01 (work in progress),
September 2008.
[IANA.l2tp-parameters]
Internet Assigned Numbers Authority, "Layer Two Tunneling
Protocol "L2TP"", December 2007,
<http://www.iana.org/assignments/l2tp-parameters>.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4591] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J.
McGill & Pignataro Expires May 23, 2009 [Page 9]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
Lau, "Frame Relay over Layer 2 Tunneling Protocol Version
3 (L2TPv3)", RFC 4591, August 2006.
Authors' Addresses
Neil McGill
Cisco Systems
7025-4 Kit Creek Rd
PO Box 14987
Research Triangle Park, NC 27709
USA
Email: nmcgill@cisco.com
Carlos Pignataro
Cisco Systems
7200-12 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
USA
Email: cpignata@cisco.com
McGill & Pignataro Expires May 23, 2009 [Page 10]
Internet-Draft L2TPv3 Extended Circuit Status Values November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
McGill & Pignataro Expires May 23, 2009 [Page 11]