L2TPv3 circuit status: Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values
More bits in the L2TPv3 status field, so a fault says which direction and which end failed.
McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", RFC 5641, DOI 10.17487/RFC5641, August 2009, <https://www.rfc-editor.org/info/rfc5641>.
@misc{rfc5641,
series = {Request for Comments},
number = 5641,
howpublished = {RFC 5641},
publisher = {RFC Editor},
doi = {10.17487/RFC5641},
url = {https://www.rfc-editor.org/info/rfc5641},
author = {N. McGill and C. Pignataro},
title = {{Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values}},
pagetotal = 11,
year = 2009,
month = aug,
} RFC text
Contents
Network Working Group N. McGill
Request for Comments: 5641 C. Pignataro
Updates: 3931, 4349, 4454, 4591, 4719 Cisco Systems
Category: Standards Track August 2009
Layer 2 Tunneling Protocol Version 3 (L2TPv3)
Extended Circuit Status Values
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 finer-grained error states for
Attachment Circuits (ACs) and pseudowires (PWs). It also generalizes
the Active bit and deprecates the use of the New bit in the Circuit
Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC
4719.
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) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . 2
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. L2TPv3 Extended Circuit Status Values . . . . . . . . . . . . 3
3. Circuit Status Usage and Clarifications . . . . . . . . . . . 7
4. Updates to Existing RFCs . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
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 is used in the
pseudowire control protocol using the Label Distribution Protocol
(LDP); see Section 3.5 of [RFC4446] and Section 5.4.2 of [RFC4447].
Additionally, it is useful (in session-level redundancy scenarios) to
be able to indicate if a pseudowire is in a standby state, where it
is fully established by signaling and allows Operations,
Administration, and Maintenance, but is not switching data. Again,
such functionality is available for MPLS-based pseudowires using LDP,
see [PREF-FWD].
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
pseudowire 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].
1.2. Abbreviations
The following abbreviations are used in this document and in the
documents that it updates. L2TPv3 Control Message Types are listed
in Section 6 of [RFC3931].
AC Attachment Circuit
AVP Attribute Value Pair
LCCE L2TP Control Connection Endpoint
NNI Network-Network Interface
PE Provider Edge
PSN Packet Switched Network
PW Pseudowire
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] and replicated in [RFC4349],
[RFC4454], [RFC4591], and [RFC4719], the two bits have the following
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
(see also Section 4):
The A (Active) bit indicates whether the local pseudowire endpoint
(including the local Attachment Circuit (AC) and local Packet
Switched Network (PSN)-facing pseudowire termination) 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 Network-
Network Interface (NNI) signaling between Provider Edge (PE) routers,
e.g., Frame Relay NNI. 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 set on sending. For reference, see
Section 3.4 of [RFC4591], which does not specify any additional usage
beyond the setting of the N bit in the ICRQ, ICRP (and OCRQ, OCRP)
and the clearing of it in all other control messages.
This document also extends this bitmap of values to allow for finer
granularity of local pseudowire (i.e., Attachment Circuit or PSN-
facing endpoint) status reporting.
The Attribute Value field for the Circuit Status AVP, including the
new values, has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|E|I|T|R|N|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 bit 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.
(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,
Bidirectional Forwarding Detection (BFD), or other methods.
(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 (during setup of the PW) and is
operational, it is NOT switching user traffic. Any received user
traffic SHOULD be dropped. User traffic MUST NOT be transmitted.
A standby pseudowire also allows for means to check its data plane
liveness in order to ensure its ability to switch data packets
end-to-end. This is achieved, for example, as detailed in
[RFC5085] or [VCCV-BFD]. However, data is not forwarded from an
Attachment Circuit (AC) into the L2TPv3 session, or from the
L2TPv3 session out to the AC.
3. Circuit Status Usage and Clarifications
In implementations prior to this specification, bits 0-13 MUST be set
to zero (see Section 5.4.5 of [RFC3931]). This allows for legacy
implementations to interwork properly with new implementations.
The following are clarifications regarding the usage of the Circuit
Status AVP bits as defined in this specification:
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 document 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 ORed
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 ORing 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 one or more of the fault status bits (R, T, I, E) 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. Updates to Existing RFCs
This document updates existing RFCs that define (either generically
or in the context of a specific set of PW Types) the Active and New
bits of the Circuit Status AVP. The Active and New bits of the
Circuit Status AVP are specified in Section 5.4.5 of [RFC3931].
Those definitions are adapted to specific Attachment Circuits and
replicated in Section 3.4 of [RFC4349] (High-Level Data Link Control
Frames over L2TPv3), Section 8 of [RFC4454] (Asynchronous Transfer
Mode over L2TPv3), Section 3.4 of [RFC4591] (Frame Relay over
L2TPv3), and Section 2.3.3 of [RFC4719] (Ethernet Frames over
L2TPv3). This document updates the definitions in all five of these
references to say:
The A (Active) bit indicates whether the local pseudowire endpoint
(including the local Attachment Circuit and local PSN-facing
pseudowire termination) 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 usage is deprecated; it SHOULD be ignored on
receipt and is OPTIONAL to set on sending.
This document also updates Section 2.2 (bullet c) of [RFC4719],
removing the following two sentences:
For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the
circuit status is for a new circuit (refer to N bit in Section
2.3.3).
For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP
MUST indicate that the circuit status is for an existing circuit
(refer to N bit in Section 2.3.3) and reflect the current status
of the link (refer to A bit in Section 2.3.3).
And finally, this document updates Section 3.1 of [RFC4349], Section
3.1 of [RFC4454], Section 3.1 of [RFC4591], and Section 2.2 of
[RFC4719] with the following paragraph addition:
The usage of the N bit in the Circuit Status AVP is deprecated.
Therefore, for ICRQ and ICRP, the Circuit Status AVP need not
indicate on sending (nor check on receipt) that the circuit status
is for a new circuit, and for ICCN and SLI, the Circuit Status AVP
need not indicate on sending (nor check on receipt) that the
circuit status is for an existing circuit.
5. Security Considerations
Security considerations for the Circuit Status AVP are covered in the
base L2TPv3 specification (see Section 8 of [RFC3931]). No
additional security considerations exist with extending this
attribute.
6. IANA Considerations
The Circuit Status Bits number space [IANA-l2tp] is managed by IANA
as per Section 10.7 of [RFC3931]. Five new bits (bits 9 through 13)
and one updated bit (bit 14) have been assigned as follows:
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]
7. Acknowledgements
The authors wish to thank Muhammad Yousuf, Mark Townsley, George
Wilkie, Prashant Jhingran, Pawel Sowinski, and Ignacio Goyret for
useful comments received.
8. References
8.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.
[RFC4349] Pignataro, C. and M. Townsley, "High-Level Data Link
Control (HDLC) Frames over Layer 2 Tunneling Protocol,
Version 3 (L2TPv3)", RFC 4349, February 2006.
[RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous
Transfer Mode (ATM) over Layer 2 Tunneling Protocol
Version 3 (L2TPv3)", RFC 4454, May 2006.
[RFC4591] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J.
Lau, "Frame Relay over Layer 2 Tunneling Protocol
Version 3 (L2TPv3)", RFC 4591, August 2006.
[RFC4719] Aggarwal, R., Townsley, M., and M. Dos Santos,
"Transport of Ethernet Frames over Layer 2 Tunneling
Protocol Version 3 (L2TPv3)", RFC 4719, November 2006.
8.2. Informative References
[IANA-l2tp] Internet Assigned Numbers Authority, "Layer Two
Tunneling Protocol 'L2TP'", <http://www.iana.org>.
[PREF-FWD] Muley, P., Bocci, M., and L. Martini, "Preferential
Forwarding Status bit definition", Work in Progress,
September 2008.
[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.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[VCCV-BFD] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", Work in Progress,
July 2009.
Authors' Addresses
Neil McGill
Cisco Systems
7025-4 Kit Creek Road
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
ISO Plain Language
On this page
§1Why a Finer Circuit Status
The L2TPv3 Circuit Status AVP can already report whether an access circuit is up or down. The RFC says a finer granularity is often useful, because it tells an operator which direction the fault is in. The same idea has already been added for MPLS-based pseudowires, where the pseudowire control protocol using the Label Distribution Protocol carries it.
A second case is session-level redundancy. There it is useful to be able to indicate that a pseudowire is in a standby state: fully established by signalling and available for operations, administration and maintenance, but not switching data. That function is available for MPLS-based pseudowires using LDP as well.
This document provides extended circuit status bit values for L2TPv3 and adds them in a way that stays backwards compatible with the current Circuit Status AVP. The new bits apply to all pseudowire types that use the Circuit Status AVP.
L2TPv3 could already say whether a circuit was up or down. This RFC adds bits that say where the fault is and whether the circuit is a standby that is ready but not carrying traffic.
§1.2Abbreviations
The RFC uses a short set of names for the parts of an L2TPv3 setup: AC for the attachment circuit, AVP for the attribute value pair, LCCE for the L2TP control connection endpoint, NNI for the network-network interface, PE for the provider edge, PSN for the packet switched network and PW for the pseudowire. The L2TPv3 control message types are listed in Section 6 of RFC 3931.
The document then works with the two sides of a tunnel. The local pseudowire endpoint is described as including the local attachment circuit and the local PSN-facing pseudowire termination, so a fault can be placed either on the customer-facing circuit or in the direction of the packet switched network, and the status bits say which.
The short names matter because the status bits distinguish the customer-facing circuit from the network-facing end of the tunnel.
§2The Extended Status Bitmap
The Circuit Status AVP, Attribute Type 71, appears in the ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN and SLI control messages. It indicates the initial status of the circuit the session is bound to, or a change in that status. Its Attribute Value field is two bytes. RFC 3931 defined it with a Reserved field and two bits: bit 15, value 0x0001, the Active bit, which said whether the circuit was up, active or ready (1) or down, inactive or not ready (0), and bit 14, value 0x0002, the New bit, which said whether the status indication was for a new circuit (1) or an existing circuit (0).
The Active bit
The Active bit now indicates whether the local pseudowire endpoint, which includes the local attachment circuit and the local PSN-facing pseudowire termination, has no faults present and is up, active or ready (1), or has faults present and is down, inactive or not ready (0).
The New bit
The New bit keeps its meaning but is deprecated. It was provided to emulate network-network interface signalling between provider edge routers, for example Frame Relay NNI. It MAY be used to convey that a circuit has been re-provisioned or newly provisioned at the provider edge, which can already be inferred from the type of the L2TP control message, so the RFC says it is uncertain what the receiving provider edge can make of the bit, although it MAY include logging. The bit SHOULD be ignored on receipt and is OPTIONAL to set on sending.
The four fault bits
Four new bits say where a fault is. Together they are called the fault status bits.
- R, bit 13, value 0x0004, local attachment circuit (ingress) receive fault: an alarm or fault has occurred at the local attachment circuit such that it is unable to receive traffic. It can still transmit traffic.
- T, bit 12, value 0x0008, local attachment circuit (egress) transmit fault: a fault has occurred at the local attachment circuit such that it is unable to transmit traffic. It can still receive traffic.
- I, bit 11, value 0x0010, local PSN-facing pseudowire (ingress) receive fault: a fault has occurred in the receive direction between the local endpoint and the remote L2TP endpoint.
- E, bit 10, value 0x0020, local PSN-facing pseudowire (egress) transmit fault: a fault has occurred in the transmit direction between the local endpoint and the remote L2TP endpoint.
For the two bits that describe the direction between the endpoints, the RFC notes that a fault at session level would not necessarily trigger an L2TP control connection timeout. How such a fault is detected is out of scope; it might be by pseudowire type-specific means, by Bidirectional Forwarding Detection, or by other methods.
The standby bit
The last new bit, S, bit 9, value 0x0040, says the pseudowire is in Standby mode. That means it was signalled during setup of the pseudowire and is operational, but it is not switching user traffic. Any received user traffic SHOULD be dropped, and user traffic MUST NOT be transmitted.
A standby pseudowire also allows the data plane liveness to be checked, so that it is known to be able to switch data packets end to end. This can be done as described in RFC 5085, or with Bidirectional Forwarding Detection for the pseudowire virtual circuit connectivity verification. Even so, data is not forwarded from an attachment circuit into the L2TPv3 session, or from the L2TPv3 session out to the attachment circuit.
The status is a two-byte field of bits. This RFC gives one bit a wider meaning, adds four bits for the four possible fault directions, adds a bit for standby, and marks the old New bit as no longer worth using.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
RESERVED | Reserved | 9 bits | Unused. Implementations before this specification set bits 0 to 13 to zero. | |
STANDBY | S | 1 bits | The pseudowire is in Standby mode: signalled and operational, but not switching user traffic. | |
PSN-EGRESS-TX-FAULT | E | 1 bits | Local PSN-facing PW (egress) Transmit Fault. | |
PSN-INGRESS-RX-FAULT | I | 1 bits | Local PSN-facing PW (ingress) Receive Fault. | |
AC-EGRESS-TX-FAULT | T | 1 bits | Local Attachment Circuit (egress) Transmit Fault. | |
AC-INGRESS-RX-FAULT | R | 1 bits | Local Attachment Circuit (ingress) Receive Fault. | |
NEW | N | 1 bits | New. Deprecated: ignore on receipt, optional to set on sending. | |
ACTIVE | A | 1 bits | Pseudowire has no faults: the local endpoint is up, active and ready. |
| Bit | Where the fault is | Effect |
|---|---|---|
| R | Local attachment circuit, receive direction | Cannot receive traffic, can still transmit |
| T | Local attachment circuit, transmit direction | Cannot transmit traffic, can still receive |
| I | Local and remote endpoint, receive direction | A fault in the receive direction |
| E | Local and remote endpoint, transmit direction | A fault in the transmit direction |
§3How the Bits Combine
In implementations that predate this specification, bits 0 to 13 MUST be set to zero, as Section 5.4.5 of RFC 3931 requires. That is what allows a legacy implementation to interwork properly with a new one.
The RFC then clarifies how the bits are used.
- The R, T, I and E bits are collectively referred to as the fault status bits.
- RFC 3931 defined the Active bit as pertaining to the local access circuit state only. This document redefines it as meaning that no faults are present on the local pseudowire endpoint.
- If multiple faults occur, all the fault status bits corresponding to each fault MUST be set, that is, they MUST be bitwise ORed together.
- The Active bit MUST NOT be set until all the fault status bits are cleared. That behaviour lets an endpoint stay compatible with a remote endpoint that does not understand the new status bits.
- If any of the fault status bits are set, the Active bit MUST be cleared. The fault status bits are a more granular definition of the Active bit, so that ORing them gives an inverted Active.
- If the Active bit is clear and the fault status bits are clear, there is no extended circuit status: the circuit is down, inactive or not ready, without a finer indication.
- The Standby bit can be set in conjunction with any other bit, including Active. A pseudowire endpoint in standby can be up, active or ready, or it can be experiencing a fault.
- Leaving standby mode is indicated by the clearing of the Standby bit.
- The usage of the New bit has been deprecated.
The rules keep old and new equipment working together. When something goes wrong the fault bits are set and the Active bit is cleared; when everything is fine again the fault bits are cleared first and only then is Active set. The standby bit can sit alongside any of the others.
- Faults come firstThe Active bit MUST NOT be set until every fault status bit is cleared.
- Several faults at onceAll the fault status bits for each fault are set together, bitwise ORed.
- No detailActive clear and all fault bits clear means down, with no finer reason.
- Standby is independentThe Standby bit can be set together with any other bit, including Active.
- New is deprecatedThe New bit should be ignored on receipt and is optional to set on sending.
§4Updates to Existing RFCs
The document updates five existing RFCs that define, either generically or for a specific set of pseudowire types, the Active and New bits of the Circuit Status AVP. Section 5.4.5 of RFC 3931 defines them, and the definitions are replicated in Section 3.4 of RFC 4349 (High-Level Data Link Control frames over L2TPv3), Section 8 of RFC 4454 (Asynchronous Transfer Mode over L2TPv3), Section 3.4 of RFC 4591 (Frame Relay over L2TPv3) and Section 2.3.3 of RFC 4719 (Ethernet frames over L2TPv3). All five now carry the new wording for the Active bit and the deprecation of the New bit.
Two sentences are removed from Section 2.2 of RFC 4719. They said that for ICRQ and ICRP the Circuit Status AVP MUST indicate that the circuit status is for a new circuit, and that for ICCN and SLI it MUST indicate that the circuit status is for an existing circuit and reflect the current status of the link.
Finally, Section 3.1 of RFC 4349, Section 3.1 of RFC 4454, Section 3.1 of RFC 4591 and Section 2.2 of RFC 4719 receive an added paragraph, saying that because the use of the New bit is deprecated, the AVP need not indicate on sending, nor check on receipt, that the circuit status is for a new circuit or for an existing circuit.
Five earlier documents defined the same two bits, so this RFC changes all five at once. The practical effect for an operator is that the new and the old bits now mean the same thing everywhere.
§5Security Considerations
Security considerations for the Circuit Status AVP are covered in the base L2TPv3 specification, in Section 8 of RFC 3931. The RFC states that no additional security considerations exist with extending this attribute.
Nothing new here. The security rules for the L2TPv3 base protocol already cover this attribute.
§6IANA Considerations
The Circuit Status Bits number space is managed by IANA as set out in Section 10.7 of RFC 3931. Five new bits, bits 9 through 13, and one updated bit, bit 14, have been assigned. Bit 9 is the S (Standby) bit, bit 10 the E bit for a local PSN-facing pseudowire egress transmit fault, bit 11 the I bit for a local PSN-facing pseudowire ingress receive fault, bit 12 the T bit for a local attachment circuit egress transmit fault, bit 13 the R bit for a local attachment circuit ingress receive fault, and bit 14 the N (New) bit, whose use is deprecated.
The bits were given fixed places in the two-byte field, so that every implementation reads them in the same positions.
- 9S — Pseudowire is in Standby mode.
- 10E — Local PSN-facing PW (egress) Transmit Fault.
- 11I — Local PSN-facing PW (ingress) Receive Fault.
- 12T — Local AC (egress) Transmit Fault.
- 13R — Local AC (ingress) Receive Fault.
- 14N — New. Use deprecated.