L2VPN Working Group Mustapha Aissaoui
Internet Draft Matthew Bocci
Expiration Date: December 2006 David Watkinson
Alcatel
Hamid Ould-Brahim
Mike Loomis Himanshu Shah
David Allan Ciena
Nortel
Paul Doolan
Thomas D. Nadeau Mangrove Systems
Monique Morrow
Cisco Systems Peter Busschbach
Lucent Technologies
John Z. Yu
Hammerhead Systems Simon Delord
France Telecom
Vasile Radoaca
West Ridge Networks June 2006
OAM Procedures for VPWS Interworking
draft-ietf-l2vpn-vpws-iw-oam-01.txt
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.
This document may only be posted in an Internet-Draft.
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
Abstract
Aissaoui, et al. Expires April 2006 [Page 1]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
This draft proposes OAM procedures for the Ethernet interworking,
IP interworking and FR-ATM interworking Virtual Private
Wire Service (VPWS).
Table of Contents
Status of this Memo.............................................1
Abstract........................................................1
Table of Contents...............................................2
1 Conventions used in this document.............................3
2 Terminology...................................................3
3 Introduction..................................................5
4 General OAM Procedures........................................5
4.1 Defect Locations...........................................5
4.2 Abstract Defect States.....................................6
4.3 VPWS OAM Interworking Models...............................7
4.4 PW Status Notifications....................................9
4.5 L2TPv3 Control Connection Messages.........................9
4.6 BFD Fault Detection and Notification......................10
5 PW Entry/Exit Criteria.......................................11
5.1.1 PW Forward Defect Entry..............................11
5.1.2 PW Reverse Defect Entry..............................12
5.1.3 PW reverse defects that require PE state synchronization
...........................................................12
5.1.4 PW Forward Defect Exit...............................13
5.1.5 PW Reverse Defect Exit...............................13
6 AC Defect Entry/Exit Criteria................................13
6.1 ATM AC Defect Entry/Exit Criteria.........................13
6.1.1 Forward Defect Entry.................................13
6.1.2 Forward Defect Exit..................................14
6.1.3 Reverse Defect Entry.................................14
6.1.4 Reverse Defect Exit..................................14
6.2 FR AC Defect Entry/Exit...................................14
6.2.1 Forward Defect Entry Criteria........................14
6.2.2 Forward Defect Exit Criteria.........................14
6.3 Ethernet AC Defect Entry/Exit Criteria....................15
6.3.1 Forward Defect State Entry...........................15
6.3.2 Forward Defect State Exit............................15
7 AC Defect Entry/Exit Procedures..............................15
7.1 AC Forward defect entry:..................................15
7.1.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......15
7.1.2 Procedures for ATM cell PWs..........................15
7.1.3 Additional procedures for ATM ACs....................15
7.2 AC Reverse defect entry...................................16
7.2.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......16
7.2.2 Procedures for ATM cell PWs..........................16
7.3 AC Forward Defect Exit....................................16
Aissaoui, et al. Expires April 2006 [Page 2]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
7.3.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......16
7.3.2 Procedures for ATM cell PWs..........................16
7.3.3 Additional procedures for ATM ACs....................17
7.4 AC Reverse Defect Exit....................................17
7.4.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......17
7.4.2 Procedures for ATM cell PWs..........................17
8 PW Forward Defect Entry/Exit procedures......................17
8.1 PW Forward Defect Entry Procedures........................17
8.1.1 FR AC procedures.....................................17
8.1.2 Ethernet AC Procedures...............................18
8.1.3 ATM AC procedures....................................18
8.1.4 Additional procedures for FR, ATM AAL5, IP or Ethernet
PWs........................................................18
8.1.5 Additional procedures for ATM Cell PWs...............18
8.2 PW Forward Defect Exit Procedures.........................19
8.2.1 FR AC procedures.....................................19
8.2.2 Ethernet AC Procedures...............................19
8.2.3 ATM AC procedures....................................19
8.2.4 Additional procedures for FR, ATM AAL5, IP or Ethernet
PWs........................................................19
8.2.5 Additional procedures for ATM Cell PWs...............19
8.3 PW Reverse Defect Entry Procedures........................19
8.3.1 FR AC procedures.....................................19
8.3.2 Ethernet AC Procedures...............................20
8.3.3 ATM AC procedures....................................20
8.4 PW Reverse Defect Exit Procedures.........................20
8.4.1 FR AC procedures.....................................20
8.4.2 Ethernet AC Procedures...............................20
8.4.3 ATM AC procedures....................................20
9 Security Considerations......................................20
10 Intellectual Property Disclaimer..Error! Bookmark not defined.
11 References..................................................20
12 Authors' Addresses..........................................22
13 Full Copyright Statement....................................23
1 Conventions used in this document
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 RFC 2119.
2 Terminology
An end-to-end virtual circuit in a L2 VPN consists of a 3 segment
set: <AC, PW, AC> [L2VPN-FRMK]. Note that the AC does not need to
connect a CE directly to a PE. An intermediate L2 network may
exist.
Aissaoui, et al. Expires April 2006 [Page 3]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
A L2 VPN circuit is homogeneous if AC and PW types are the same.
E.g., ATM circuit: <ATM AC, ATM PW, ATM AC>.
A L2 VPN circuit is heterogeneous if any two segments of the
circuit are of different types. E.g., IP interworking circuit:
<ATM AC, IP PW, ATM AC>, or <ATM AC, IP PW, FR AC>.
The PW of a L2 VPN circuit can ride over three types of Packet
Switched Network (PSN). A PSN which makes use of LSPs as the
tunneling technology to forward the PW packets will be referred to
as a MPLS PSN. A PSN which makes use of MPLS-in-IP tunneling
[MPLS-in-IP], with a MPLS shim header used as PW demultiplexer,
will be referred to as MPLS-IP PSN. A PSN, which makes use of
L2TPv3 [L2TPv3] as the tunneling technology, will be referred to
as L2TP-IP PSN.
A PE interworks or adapts an AC onto a PW, depending on whether it
terminates the attachment circuit or the AC corresponds to the NS
for the PW. The other PE that terminates the PW is the "peer" PE
and the attachment circuit associated with the far end PW
termination is the "remote AC".
Defects are discussed in the context of defect states, and the
criteria to enter and exit the defect state.
The direction of defects is discussed from the perspective of the
observing PE and what the PE may explicitly know about information
transfer capabilities of the VPWS service.
A forward defect is one that impacts information transfer to the
observing PE. It impacts the observing PE's ability to receive
information. A forward defect MAY also imply impact on information
sent or relayed by the observer (and as it cannot receive is
therefore unknowable) and so the forward defect state is
considered to be a superset of the two defect states.
A reverse defect is one that uniquely impacts information sent or
relayed by observer.
At the present time code points for forward defect and reverse
defect notifications have not been specified for BFD and LDP PW
Status signaling. These are referred to as "forward defect" and
"reverse defect" indications as placeholders for code point
assignment. A crude mapping may be performed between current code
points in [PWE3-IANA]:
Forward defect - corresponds to the logical OR of
Local Attachment Circuit (ingress) Receive Fault
and
Local PSN-facing PW (egress) Transmit Fault
Reverse defect - corresponds to the logical OR of
Aissaoui, et al. Expires April 2006 [Page 4]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
Local Attachment Circuit (egress) Transmit Fault
and
Local PSN-facing PW (egress) Transmit Fault
3 Introduction
This draft augments OAM message mapping [OAM-MSG] with OAM
procedures for scenarios when the attachment circuit does not
correspond to the pseudo wire. When combined with procedures
defined in [OAM-MSG], comprehensive OAM interworking can be
defined for VPWS services. VPWS services are defined in the L2 VPN
framework [L2VPN-FRMK].
The following VPWS types are covered in this document:
1. VPWS with heterogeneous ACs of ATM and FR types, and in which
the PW type is ATM or FR. In this case, FR-ATM service
interworking [FRF8.2] is performed in PE1 (or PE2) and a FR (or
ATM) PW is extended to the remote PE. This VPWS type will be
referred to as "FR-ATM Interworking VPWS".
2. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and
in which the PW type is Ethernet. This VPWS type will be
referred to as "Ethernet Interworking VPWS".
3. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and
in which the PW type is IP [ARP-Mediation]. This VPWS type will
be referred to as "IP Interworking VPWS".
OAM procedures for homogeneous VPWS circuits of ATM, FR, or
Ethernet types are described in [OAM-MSG].
4 General OAM Procedures
4.1 Defect Locations
Figure 1 illustrates a VPWS network model with an indication of
the possible defect locations. This model will be referenced in
the remainder of this document for describing the OAM procedures.
ACs PSN tunnel ACs
+----+ +----+
+----+ | PE1|==================| PE2| +----+
| |---(a)---(b) (c)......PW1...(d).(c)..(f)--(e)----| |
| CE1| (N1) | | | | (N2) |CE2 |
| |----------|............PW2.............|----------| |
+----+ | |==================| | +----+
^ +----+ +----+ ^
| Provider Edge 1 Provider Edge 2 |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Aissaoui, et al. Expires April 2006 [Page 5]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
Edge 1 Edge 2
Figure 1: VPWS Defect Locations
In all interworking scenarios described in this document, it is
assumed that at PE1 the AC does not correspond to the PW. The
procedures described in this document exclusively apply to PE1.
PE2 either implements the procedures described in this document or
those in [OAM-MSG]. The notifications received from PE2 and
consequent actions taken at PE1 will be common to both scenarios.
The following is a brief description of the defect locations:
(a) Defect in the first L2 network (N1). This covers any defect
in the N1 which impacts all or a subset of ACs terminating in
PE1. The defect is conveyed to PE1 and to the remote L2
network (N2) using a L2 specific OAM defect indication.
(b) Defect on a PE1 AC interface.
(c) Defect on a PE PSN interface.
(d) Defect in the PSN network. This covers any defect in the PSN
which impacts all or a subset of the PSN tunnels and PWs
terminating in a PE. The defect is conveyed to the PE using a
PSN and/or a PW specific OAM defect indication.
(e) Defect in the second L2 network (N2). This covers any defect
in N2 which impacts all or a subset of ACs terminating in PE2
(which is considered a "remote AC defect" in the context of
procedures outlined in this draft). The defect is conveyed to
PE2 and to the remote L2 network (N1) using a L2 specific OAM
defect indication.
(f) Defect on a PE2 AC interface (which is also considered a
"remote AC defect" in the context of this draft).
4.2 Abstract Defect States
PE1 is obliged to track four abstract defect states that reflect
the observed state of both directions of the VPWS service on both
the AC and the PW sides. Faults may impact only one or both
directions of the PW.
The observed state is a combination of faults directly detected by
PE1, or faults it has been made aware of via notifications.
+-----+
----AC forward---->| |-----PW reverse---->
defect state | | defect state
CE1 | PE1 | PE2/CE2
<---AC reverse-----| |<----PW forward-----
defect state | | defect state
+-----+
(arrows indicate direction of user traffic impacted by a defect)
Aissaoui, et al. Expires April 2006 [Page 6]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
Figure 2: Forward and Reverse Defect States
PE1 will directly detect or be notified of AC forward and PW
forward defects as they occur upstream of PE1 and impact traffic
being sent to PE1.
In Figure 2, PE1 may be notified of a forward defect in the AC by
receiving a Forward Defect indication, e.g., ATM AIS, from CE1.
This defect impacts the ability of PE1 to receive user traffic
from CE1 on the AC. PE1 can also directly detect this defect if it
resulted from a failure of the receive side in the local port or
link over which the AC is configured.
Similarly, PE1 may detect or be notified of a forward defect in
the PW by receiving a Forward Defect indication from PE2. This
notification can either be a "Local PSN-facing PW (egress)
Transmit Fault" or a "Local Attachment Circuit (ingress) Receive
Fault". This defect impacts the ability of PE1 to receive user
traffic from CE2.
Note that the AC or PW Forward Defect notification is sent in the
same direction as the user traffic impacted by the defect.
PE1 will only be notified of AC reverse and PW reverse defects as
they universally will be detected by other devices and only impact
traffic that has already been relayed by PE1. In Figure 2, PE1 may
be notified of a reverse defect in the AC by receiving a Reverse
Defect indication, e.g., ATM RDI, from CE1. This defect impacts
the ability of PE1 to send user traffic to CE1 on the AC.
Similarly, PE1 may be notified of a reverse defect in the PW by
receiving a Reverse Defect indication from PE2. This notification
can either be a "Local PSN-facing PW (ingress) Receive Fault" or a
"Local Attachment Circuit (egress) Transmit Fault". This defect
impacts the ability of PE1 to send user traffic to CE2.
Note that the AC or PW Reverse Defect notification is sent in the
reverse direction to the user traffic impacted by the defect.
The procedures outlined in this document define the entry and exit
criteria for each of the four states with respect to the set of
potential ACs and PWs within the document scope and the consequent
actions that PE1 must perform to properly interwork those
notifications. The abstract defect states used by PE1 are common
to all potential interworking combinations of PWs and ACs.
4.3 VPWS OAM Interworking Models
There are two different OAM interworking models which are dictated
by the type of VPWS.
In a homogeneous VPWS circuit, the AC link layer is emulated by
the PW by extending it across the PSN. This has the implication
that the native service OAM has to operate transparently across
the PSN. In this case, the default OAM procedures are to use the
native service OAM for both the AC and PW defect indications. This
model is referred to as the homogeneous VPWS circuit OAM model. An
Aissaoui, et al. Expires April 2006 [Page 7]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
example of this is ATM VPWS OAM procedures. Some homogenous
scenarios use PW OAM mechanisms to synchronize VPWS state between
PEs due to discontinuities in native service OAM between the AC
and the PW (e.g. FR LMI), or lack of native service OAM (e.g.
Ethernet). Detailed OAM procedures for the homogeneous VPWS
circuit types are described in [OAM-MSG].
In a heterogeneous VPWS circuit, the AC link layer is terminated
at a PE. Therefore, the native service OAM always terminates at
the AC endpoint in the PE. In this case, the default OAM
procedures are to terminate the native service OAM and to convey
the corresponding defect state using a PW specific defect
mechanism. This model is referred to as the heterogeneous VPWS
circuit OAM model and is the model suitable for the VPWS types
covered in this document.
For a MPLS PSN and a IP PSN using MPLS-in-IP (MPLS-IP PSN), PW
status signaling messages are used as the default mechanism for AC
and PW status and defect notification [PWE3-CONTROL]. If the PEs
have negotiated the use of VCCV-BFD for PW fault detection and
AC/PW fault notifications as explained in [VCCV] then BFD is the
preferred mechanism. The interaction of BFD and PW status is
explained in more details in Section 4.5.
For a IP PSN using L2TPv3, i.e., a L2TP-IP PSN, StopCCN and CDN
messages are used for conveying defects in the PSN and PW
respectively, while the Set-Link-Info (SLI) messages are used to
convey status and defects in the AC and local L2 network as
detailed in [OAM-MSG].
Finally, it may be desirable to operate ATM OAM inband in the case
of the FR-ATM interworking VPWS. This document proposes to use the
homogeneous OAM circuit model together with an ATM cell mode PW to
achieve this.
Table 1 summarizes the OAM model used with each type of VPWS
covered in this document.
------------------------------------------------------------------
|VPWS Type | Homogeneous Circuit | Heterogeneous |
| | OAM Model | Circuit OAM Model|
------------------------------------------------------------------
|FR-ATM Interworking | | |
|- ATM cell mode PW | X | |
------------------------------------------------------------------
|FR-ATM Interworking | | |
|- FR or AAL5 PDU/SDU PW| | X |
------------------------------------------------------------------
|Ethernet Interworking | | X |
------------------------------------------------------------------
|IP Interworking | | X |
------------------------------------------------------------------
Table 1: Summary of VPWS OAM Interworking
Aissaoui, et al. Expires April 2006 [Page 8]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
4.4 PW Status Notifications
PW status signaling is the default mechanism for conveying the
status of a PW and ACs between PEs in a MPLS PSN and a IP PSN
using MPLS-in-IP (MPLS-IP PSN).
[PWE3-IANA] defines the following valid PW status codepoints:
0x00000000 - Pseudo Wire forwarding (clear all failures)
0x00000001 - Pseudo Wire Not Forwarding
0x00000002 - Local Attachment Circuit (ingress) Receive Fault
0x00000004 - Local Attachment Circuit (egress) Transmit Fault
0x00000008 - Local PSN-facing PW (ingress) Receive Fault
0x00000010 - Local PSN-facing PW (egress) Transmit Fault
[PWE3-CONTROL] specifies that "Pseudo Wire forwarding" is used to
clear all faults and that "Pseudo Wire Not Forwarding" is used to
convey any other defects that cannot be represented by the other
codepoints. The remaining codepoints map to the "forward defect"
and "reverse defect" defined in this document as follows:
Forward defect - corresponds to the logical OR of
Local Attachment Circuit (ingress) Receive Fault
AND
Local PSN-facing PW (egress) Transmit Fault
Reverse defect - corresponds to the logical OR of
Local Attachment Circuit (egress) Transmit Fault
AND
Local PSN-facing PW (ingress) Receive Fault
Note that there are a couple of situations which require PW label
withdrawal as opposed to a PW status notification by the PE. The
first one is when the PW is taken administratively down in
accordance to [PWE3-CONTROL]. The second one is when the Target
LDP session established between the two PE's is lost. In the
latter case, the PW labels will need to be re-signaled when the
Targeted LDP session is re-established.
4.5 L2TPv3 Control Connection Messages
For a L2TP-IP PSN, StopCCN and CDN messages are used for conveying
defects which impact one or many PWs controlled by a given control
connection.
A StopCCN message indicates that the control connection has been
shut down by the remote PE [L2TPv3]. This is typically used for
defects in the PSN which impact both the control connection and
the individual data plane sessions. On reception of this message,
a PE closes the control connection and will clear all the sessions
managed by this control connection. Since each session carries a
single PW, the state of the corresponding PWs is changed to DOWN.
A CDN message indicates that the remote peer requests the
Aissaoui, et al. Expires April 2006 [Page 9]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
disconnection of a specific session [L2TPv3]. In this case only
the state of the corresponding PW is changed to DOWN. This is
typically used for local defects in a PE which impact only a
specific session and the corresponding PW.
Finally, the Set-Link-Info (SLI) messages are used to convey
status and defects in the AC and local L2 network
4.6 BFD Fault Detection and Notification
BFD is a mechanism which can be used to detect defects in the PW
data path. This document specifies two uses of BFD. When used for
PW fault detection only, a PE will continue to use PW status to
report defects other than those detected by BFD. When used for
both PW fault detection and all PW/AC fault notifications, PW
status should not be used. This section describes the behavior of
the PE nodes in both use cases.
For a MPLS-PSN, the PE's negotiate the use of the VCCV
capabilities when the label mapping messages are exchanged to
establish the two directions of the PW. A new OAM capability TLV
is signaled as part of the PW FEC interface parameters TLV.
The CV Type Indicators field in this TLV defines a bitmask used to
indicate the specific OAM capabilities that the PE can make use of
over the PW being established. The defined values are:
0x01 ICMP Ping
0x02 LSP Ping (VCCV-Ping over a MPLS PSN and MPLS-IP PSN)
0x04 BFD for PW Fault Detection only
0x08 BFD for PW Fault Detection and AC/PW Fault Notification
A CV type of 0x04 is part of the VCCV-BFD capability. It indicates
that BFD is used for PW fault detection only. A BFD message will
notify the remote PE of the fault and the latter enters into the
proper PW defect state and triggers the appropriate actions as
explained in the subsequent sections. All other PW and AC defects
are indicated using PW status signaling.
A CV type of 0x08 is also part of the VCCV-BFD capability. It
indicates that BFD is used for both PW fault detection and AC/PW
Fault Notification, even if the fault was not detected via BFD. In
this case, PW status signaling messages should not be used.
Similarly, [VCCV] describes a L2TPv3 VCCV Capability AVP which
provides the equivalent means to signal OAM capabilities between
PE's for PW's over a L2TP-IP PSN.
[BFD] defined the following diagnostic codes:
Code Message
---- ------------------------------
0 No Diagnostic
Aissaoui, et al. Expires April 2006 [Page 10]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
1 Control Detection Time Expired
2 Echo Function Failed
3 Neighbor Signaled Session Down
4 Forwarding Plane Reset
5 Path Down (Alarm Suppression)
6 Concatenated Path Down
7 Administratively Down
8 Reverse Concatenated Path Down
9-31 Reserved for future use
[VCCV] states that, when used over PWs, the asynchronous mode of
BFD should be used. Of these, 0 is used when the PW is up and 2 is
not applicable to asynchronous mode. 3 is used as explained below.
6 and 8 are used to signal AC forward and reverse defect states
respectively when the PE's negotiated the use of BFD as the
mechanism for AC and PW fault detection and notification.
The following are the BFD procedures for PW fault detection (valid
for both CV types 0x04 and 0x08):
When the downstream PE (PE1) does not receive control messages
from the upstream PE (PE2) during a certain number of transmission
intervals (a number provisioned by the operator), it declares that
the PW in its receive direction is down. In other word, PE1 enters
the "forward defect" state for this PW. PE1 sends a message to PE2
with H=0 (i.e. "I do not hear you") and with diagnostic code 1. In
turn, PE2 declares the PW is down in its transmit direction and it
uses diagnostic code 3 in its control messages to PE1. PE2 enters
the "reverse defect" state for this PW.
When a PW is taken administratively down, the PEs will withdraw
the PW labels or will send L2TP CDN messages with code "Session
disconnected for administrative reasons". In addition, exchange of
BFD control messages MUST be suspended. To that end, the PEs MUST
send control messages with H=0 and diagnostic code 7
5 PW Entry/Exit Criteria
5.1.1 PW Forward Defect Entry
PE1 enters the forward defect state if any of the following
conditions are met:
(i) It detects or is notified of a defect upstream of PE1 in
the PSN tunnel over which the PW is riding.
Defects detected explicitly include the loss of
connectivity, label swapping errors and label merging
errors. In the case of a MPLS PSN and a MPLS-IP PSN, these
defects can be detected by running a MPLS specific
connectivity verification mechanism such as LSP-Ping [LSP-
Ping], BFD on a LSP [LSP-BFD] or Y.1711 CV [Y.1711]. The
Aissaoui, et al. Expires April 2006 [Page 11]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
assumption is that deployed PSN resiliency mechanisms have
not been sufficient to recover from the defect and restore
connectivity to the peer PE.
Notifications of defects remote from the PE include Y.1711
FDI/BDI, BFD and RSVP-TE PathErr message.
(ii) It receives a message from the remote PE indicating a
forward defect. In the case of a MPLS PSN and a MPLS-IP
PSN, this is a PW status message [PWE3-CONTROL] or BFD
diagnostic code indicating a "Forward defect", or "PW not
forwarding".
(iii) It detects a loss of PW connectivity, including label
errors, via an inband PW OAM connectivity verification,
such as VCCV.
Note that if the PW control session between the PEs fails, the PW
is torn down and needs to be re-established. However, the
consequent actions towards the ACs are the same as if the PW state
were DOWN.
5.1.2 PW Reverse Defect Entry
For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 enters the PW
reverse defect state when the following conditions are true:
(i) The status communicated by PE2 via BFD or LDP status TLV
indicates a reverse defect. This indicates PE2 detected or
was notified of a PW/PSN fault upstream of it or that
there was a remote AC fault and it is not already in the
PW forward defect state.
For a PWE3 over a L2TP-IP PSN, the PW reverse defect state is not
valid and a PE can only enter the PW forward defect state.
5.1.3 PW reverse defects that require PE state synchronization
Some PW mechanisms will result in PW defects being detected by or
notified to PE1 when PE1 is upstream of the fault but the
notification did not originate with PE2. The resultant actions are
identical to that of entering the PW reverse defect state with the
addition that PE1 needs to synchronize state with PE2 and the PW
state communicated from PE1 to PE2 needs to indicate state
accordingly.
When the PSN uses RSVP-TE or proactively uses LSP-PING as a PW
fault detection mechanism, PE1 must enter the AC forward defect.
The exit criteria being when, the RSVP fault state or the LSP-PING
fault state exit criteria has been met, indicating no PW reverse
defects.
Aissaoui, et al. Expires April 2006 [Page 12]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
5.1.4 PW Forward Defect Exit
For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 exits the PW
Forward state when the following conditions are true:
(ii) The status communicated by PE2 via BFD or LDP status TLV
no longer indicates a forward defect AND
Local indications (BFD processing etc.) indicate that PW and PSN
connectivity is working in the forward direction. Note that this
may result in a transition to the PW working or PW reverse defect
states.
For a PWE3 over a L2TP-IP, a PE exits the PW DOWN state when the
following conditions are true:
(i) All defects it had previously detected have disappeared,
and
(ii) A L2TPv3 session is successfully established to carry the
PW packets.
5.1.5 PW Reverse Defect Exit
For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 exits the PW
Reverse defect state when the following conditions are true:
(i) The status communicated by PE2 via BFD or LDP status TLV
no longer indicates a reverse defect or,
(ii) PE1 has entered the PW forward defect state.
6 AC Defect Entry/Exit Criteria
6.1 ATM AC Defect Entry/Exit Criteria
6.1.1 Forward Defect Entry
PE1 enters the AC forward defect state if any of the following
conditions are met:
(i) It detects a physical layer alarm on the ATM interface.
(ii) It receives an F5 AIS OAM cell indicating that the ATM
VP/VC is down in the adjacent L2 ATM network (e.g., N1 for
PE1).
(iii) It detects loss of connectivity on the ATM VPC/VCC while
running ATM continuity checking (ATM CC) with the local
ATM network and CE.
Note that all interworking VPWS referred to in this document make
use of ATM VCCs as the AC. ATM VPC cannot be terminated directly
on an interworking VPWS. Therefore only F5 OAM messages are
relevant.
Aissaoui, et al. Expires April 2006 [Page 13]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
6.1.2 Forward Defect Exit
PE1 exits the AC forward defect state when all defects it had
previously detected have disappeared. The exact conditions under
which a PE exits AIS or declares that connectivity is restored via
ATM CC are explained in I.610 [I.610]. Note that it is possible to
transition directly from the forward to the reverse defect states.
6.1.3 Reverse Defect Entry
PE1 enters the AC reverse defect state if:
(i) It terminates the ATM layer and it receives an F5 RDI OAM
cell indicating that the ATM VP/VC is down in the adjacent
L2 ATM network (e.g., N1 for PE1).
6.1.4 Reverse Defect Exit
PE1 exits the AC reverse defect state if:
(i) It enters the forward defect state OR
(ii) All defects it had previously detected have
disappeared. The exact conditions under which a PE
exits the RDI state are explained in I.610 [I.610].
6.2 FR AC Defect Entry/Exit
Note that the FR AC "inactive" state, as communicated by the FR
LMI, does not indicate direction but is assumed to be the
equivalent of a forward defect and is translated to same. The
reverse defect state is not valid for an FR AC.
6.2.1 Forward Defect Entry Criteria
PE1 enters the AC forward defect state if any of the following
conditions are met:
(i) A PVC is not 'deleted' from the Frame Relay network and
the Frame Relay network explicitly indicates in a full
status report (and optionally by the asynchronous status
message) that this Frame Relay PVC is 'inactive'. In this
case, this status maps across the PE to the corresponding
PW only.
(ii) The LIV indicates that the link from the PE to the Frame
Relay network is down. In this case, the link down
indication maps across the PE to all corresponding PWs.
(iii) A physical layer alarm is detected on the FR interface. In
this case, this status maps across the PE to all
corresponding PWs.
6.2.2 Forward Defect Exit Criteria
A PE exits the FR AC Down state when all defects it had previously
detected have disappeared.
Aissaoui, et al. Expires April 2006 [Page 14]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
6.3 Ethernet AC Defect Entry/Exit Criteria
Ethernet AC failures are translated directly into AC forward
defects. The reverse defect state is not valid for Ethernet ACs.
6.3.1 Forward Defect State Entry
PE1 enters the AC forward defect state if any of the following
conditions are met:
(i) A physical layer alarm is detected on the Ethernet
interface.
6.3.2 Forward Defect State Exit
A PE exits the Ethernet AC Down state when all defects it had
previously detected have disappeared.
7 AC Defect Entry/Exit Procedures
7.1 AC Forward defect entry:
On entry to the forward defect state, PE1 may need to perform
procedures on both the PW and the AC.
7.1.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs
On entry to the AC forward defect state, PE1 notifies PE2 of a
forward defect:
For PW over MPLS PSN or MPLS-IP PSN
(i) A PW Status message indicating "forward defect", or
(ii) A VCCV-BFD diagnostic code of "forward defect" if the
optional use of VCCV-BFD notification has been negotiated.
For PW over L2TP-IP PSN
(i) An L2TP Set-Link Info (LSI) message with a Circuit Status
AVP indicating "inactive", or
(ii) A VCCV-BFD diagnostic code of "forward defect" if the
optional use of VCCV-BFD notification has been negotiated.
7.1.2 Procedures for ATM cell PWs
On entry to the AC forward defect state, PE1 MUST:
a. Commence insertion of ATM AIS cells into the corresponding
PW.
b. If PE1 is originating F5 I.610 CC cells, PE1 will suspend
CC generation for the duration of the defect state.
7.1.3 Additional procedures for ATM ACs
On entry to the AC forward defect state PE1 will commence RDI
insertion into the AC as per I.610.
Aissaoui, et al. Expires April 2006 [Page 15]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
7.2 AC Reverse defect entry
7.2.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs
On entry to the AC reverse defect state, PE1 notifies PE2 of a
reverse defect:
For PW over MPLS PSN or MPLS-IP PSN
(iii) A PW Status message indicating "reverse defect", or
(iv) A VCCV-BFD diagnostic code of "reverse defect" if the
optional use of VCCV-BFD notification has been
negotiated..
For PW over L2TP-IP PSN
(iii) An L2TP Set-Link Info (LSI) message with a Circuit Status
AVP indicating "inactive", or
(iv) A VCCV-BFD diagnostic code of "reverse defect" if the
optional use of VCCV-BFD notification has been negotiated.
7.2.2 Procedures for ATM cell PWs
ATM AC would be the only potential source of AC reverse defect
state within the scope of this document. However, There are no
procedures in this case as the AC reverse defect state is not
valid for PE1 with a ATM AC and a ATM cell mode PW.
7.3 AC Forward Defect Exit
7.3.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs
On exit from the AC forward defect state PE1 notifies PE2 that the
forward defect state has cleared (note that this may be a direct
state transition to either the working state or the reverse defect
state):
For PW over MPLS PSN or MPLS-IP PSN
(i) A PW Status message with forward defect clear and the
remaining indicators showing either working or reverse
defect state, or
(ii) A VCCV-BFD diagnostic code with the same attributes as (i)
if the optional use of VCCV-BFD notification has been
negotiated.
For PW over L2TP-IP PSN
(i) An L2TP Set-Link Info (LSI) message with a Circuit Status
AVP indicating "active", or
(ii) A VCCV-BFD diagnostic code with the same attributes as (i)
if the optional use of VCCV-BFD notification has been
negotiated.
7.3.2 Procedures for ATM cell PWs
On exit from the AC forward defect state, PE1 MUST:
Aissaoui, et al. Expires April 2006 [Page 16]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
(i) Cease insertion of ATM AIS cells into the corresponding
PW.
(ii) If PE1 is originating F5 I.610 CC cells, PE1 will resume
CC generation.
If the transition is to the AC reverse defect state, the
corresponding procedures apply.
7.3.3 Additional procedures for ATM ACs
On exit from the AC forward defect state PE1 will cease RDI
insertion into the AC as per I.610.
7.4 AC Reverse Defect Exit
7.4.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs
On exit from the AC reverse defect state, PE1 notifies PE2 that
the reverse defect state has cleared (note that this may be a
direct state transition to either the working state or the forward
defect state). Depending on the negotiated notification mechanism
this will be one of:
For PW over MPLS PSN or MPLS-IP PSN
(i) A PW Status message with the "reverse defect" indicator
cleared and the remaining indicators showing either
working or a transition to the "forward defect" state, or
(ii) A VCCV-BFD diagnostic code with the same information as
(i) if the optional use of VCCV-BFD notification has been
negotiated.
For PW over L2TP-IP PSN
(i) An L2TP Set-Link Info (LSI) message with a Circuit Status
AVP indicating "active", or
(ii) A VCCV-BFD diagnostic code with the same information as
(i) if the optional use of VCCV-BFD notification has been
negotiated.
7.4.2 Procedures for ATM cell PWs
ATM AC would be the only potential source of AC reverse defect
state within the scope of this document. However, there are no
procedures in this case as the AC reverse defect state is not
valid for PE1 with a ATM AC and a ATM cell mode PW.
8 PW Forward Defect Entry/Exit procedures
8.1 PW Forward Defect Entry Procedures
8.1.1 FR AC procedures
These procedures are applicable only if the transition from the
working state to the PW Forward defect state. A transition from PW
reverse defect state to the forward defect state does not require
Aissaoui, et al. Expires April 2006 [Page 17]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
any additional notification procedures to the FR AC as it has
already been told the peer is down.
(i) PE1 MUST generate a full status report with the Active bit
= 0 (and optionally in the asynchronous status message),
as per Q.933 annex A, into N1 for the corresponding FR
ACs.
8.1.2 Ethernet AC Procedures
No procedures are currently defined.
8.1.3 ATM AC procedures
On entry to the PW Forward Defect State
(i) PE1 MUST commence F5 AIS insertion into the corresponding
AC.
(ii) PE1 MUST terminate any F5 CC generation on the
corresponding AC.
8.1.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs
If the PW failure was explicitly detected by PE1, it MUST assume
PE2 has no knowledge of the defect and MUST notify PE2 in the form
of a reverse defect notification:
For PW over MPLS PSN or MPLS-IP PSN
(i) A PW Status message indicating a "reverse defect", or
(ii) A VCCV-BFD diagnostic code indicating a "reverse defect"
if the optional use of VCCV-BFD notification has been
negotiated.
For PW over L2TP-IP PSN
(i) An L2TP Set-Link Info (LSI) message with a Circuit Status
AVP indicating "active", or
(ii) A VCCV-BFD diagnostic code with the same attribute as (i)
if the optional use of VCCV-BFD notification has been
negotiated.
Otherwise the entry to the defect state was the result of a
notification from PE2 (indicating that PE2 already had knowledge
of the fault) or loss of the control adjacency (similarly visible
to PE2).
8.1.5 Additional procedures for ATM Cell PWs
If the PW failure was explicitly detected, by PE1 by entering to
the ATM AIS state or loss of CC, PE1 MUST also commence RDI
insertion into the reverse direction of the PW.
Aissaoui, et al. Expires April 2006 [Page 18]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
8.2 PW Forward Defect Exit Procedures
8.2.1 FR AC procedures
On transition from the PW forward defect state to the reverse
defect state PE1 takes no action with respect to the AC.
On exit from the PW Forward defect state
(i) PE1 MUST generate a full status report with the Active bit
= 1 (and optionally in the asynchronous status message),
as per Q.933 annex A, into N1 for the corresponding FR
ACs.
8.2.2 Ethernet AC Procedures
No procedures are currently defined
8.2.3 ATM AC procedures
On exit from the PW Forward Defect State
(i) PE1 MUST cease F5 AIS insertion into the corresponding AC.
(ii) PE1 MUST resume any F5 CC generation on the corresponding
AC.
8.2.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs
If the PW failure was explicitly detected by PE1, it MUST notify
PE2 in the form of clearing the reverse defect notification:
For PW over MPLS PSN or MPLS-IP PSN
(i) A PW Status message with the "reverse defect" indication
clear, and the remaining indicators showing either working
or a transition to the "forward defect" state, or
(ii) A VCCV-BFD diagnostic code with the same attribute as in
(i) if the optional use of VCCV-BFD notification has been
negotiated.
For PW over L2TP-IP PSN
(i) An L2TP Set-Link Info (LSI) message with a Circuit Status
AVP indicating "active", or
(ii) A VCCV-BFD diagnostic code with the same attributes as (i)
if the optional use of VCCV-BFD notification has been
negotiated.
8.2.5 Additional procedures for ATM Cell PWs
On exit from the PW forward defect state, PE1 will cease F5 RDI
generation into the corresponding PW.
8.3 PW Reverse Defect Entry Procedures
8.3.1 FR AC procedures
On transition from the PW forward defect state to the reverse
defect state PE1 takes no action with respect to the AC.
Aissaoui, et al. Expires April 2006 [Page 19]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
On entry to the PW Forward defect state
(i) PE1 MUST generate a full status report with the Active bit
= 0 (and optionally in the asynchronous status message),
as per Q.933 annex A, into N1 for the corresponding FR
ACs.
8.3.2 Ethernet AC Procedures
No procedures are currently defined
8.3.3 ATM AC procedures
On entry to the PW Reverse Defect State
(i) PE1 MUST commence F5 RDI insertion into the corresponding
AC.
8.4 PW Reverse Defect Exit Procedures
8.4.1 FR AC procedures
On transition from the PW reverse defect state to the PW forward
defect state PE1 takes no action with respect to the AC.
On exit from the PW Reverse defect state
(i) PE1 MUST generate a full status report with the Active bit
= 1 (and optionally in the asynchronous status message),
as per Q.933 annex A, into N1 for the corresponding FR
ACs.
8.4.2 Ethernet AC Procedures
No procedures are currently defined
8.4.3 ATM AC procedures
On exit from the PW Reverse Defect State
(i) PE1 MUST cease F5 RDI insertion into the corresponding AC.
9 Security Considerations
This draft does not introduce any new security considerations to
VPWS. Though, it is worth mentioning that in the heterogeneous
VPWS OAM model, a flooding of alarms on the ACs may result in a
large number of PW status signaling messages generated. This may
have an impact on the performance of the MPLS control plane. This
issue should be investigated and solutions should be provided if
required. A method for aggregating PW status messages is one
possible solution.
10 References
[ARP-MEDIATION] Shah, H., et al., "ARP Mediation for IP
interworking of Layer 2 VPN", draft-ietf-l2vpn-arp-mediation-
05.txt, June 2006.
Aissaoui, et al. Expires April 2006 [Page 20]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
[BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection",
Internet Draft <draft-ietf-bfd-base-05.txt>, June 2006
[FRF8.2] Frame Relay Forum, "FRF 8.2 - Frame Relay / ATM PVC
Service Interworking Implementation Agreement", February
2004.
[FRF.19] Frame Relay Forum, "Frame Relay Operations,
Administration, and Maintenance Implementation Agreement",
March 2001.
[I.610] "B-ISDN operation and maintenance principles and
functions", ITU-T Recommendation I.610, February 1999.
[L2TPv3] Lau, J., et.al. " Layer Two Tunneling Protocol (Version
3", RFC 3931, March 2005.
[L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf-
l2vpn-l2-framework-05.txt, June 2004.
[LSP-BFD] Aggarwal, R., et al., " BFD For MPLS LSPs", draft-ietf-
bfd-mpls-02.txt, July 2005.
[LSP-Ping] Kompella, K., et al., "Detecting MPLS Data Plane
Liveness", RFC 4379, February 2006.
[MPLS-in-IP] Worster. T., et al., "Encapsulating MPLS in IP or
Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[OAM-MSG] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message
Mapping", draft-ietf-pwe3-oam-msg-map-04.txt, March 2006.
[PWE3-ATM] Martini, L., et al., "Encapsulation Methods for
Transport of ATM Over IP and MPLS Networks", draft-ietf-pwe3-
atm-encap-11.txt, May 2006.
[PWE3-CONTROL] Martini, L., et al., "Pseudowire Setup and
Maintenance using LDP", RFC 4447, April 2006.
[PWE3-ETH] Martini, L., et al., "Encapsulation Methods for
Transport of Ethernet Frames Over IP/MPLS Networks", RFC
4448, April 2006.
[PWE3-FR] Kawa, C., et al., "Frame Relay over Pseudo-Wires",
draft-ietf-pwe3-frame-relay-07.txt, February 2006.
[PWE3-IANA] Martini, L. et.al., "IANA Allocations for pseudo Wire
Edge to Edge Emulation (PWE3)", RFC 4446, April 2006
[Q933AnnexA] ITU-T, "Additional procedures for Permanent Virtual
Connection (PVC) status management", ITU-T Q.933 Annex A,
February 2003.
Aissaoui, et al. Expires April 2006 [Page 21]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
[VCCV] Nadeau, T., et al., "Pseudo Wire (PW) Virtual Circuit
Connection Verification (VCCV)", draft-ietf-pwe3-vccv-09.txt,
June 2006.
[Y.1711] "OAM Mechanisms for MPLS Networks", ITU-T Recommendation
Y.1711, November 2002.
11 Authors' Addresses
Mustapha Aissaoui
Alcatel
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: mustapha.aissaoui@alcatel.com
Matthew Bocci
Alcatel
Voyager Place, Shoppenhangers Rd
Maidenhead, Berks, UK SL6 2PJ
Email: matthew.bocci@alcatel.co.uk
David Watkinson
Alcatel
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: david.watkinson@alcatel.com
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortelnetworks.com
Mike Loomis
Nortel Networks
600 Technology Park Dr.
Billerica, MA 01821
Phone: +1-978-288-6322
Email: mloomis@nortelnetworks.com
David Allan
Nortel Networks
3500 Carling Ave.,
Ottawa, Ontario, CANADA
Email: dallan@nortelnetworks.com
Thomas D. Nadeau
Cisco Systems, Inc.
300 Beaverbrook Drive
Boxborough, MA
Phone: +1-978-936-1470
Aissaoui, et al. Expires April 2006 [Page 22]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
Email: tnadeau@cisco.com
Monique Morrow
Cisco Systems, Inc.
Glatt-com
CH-8301 Glattzentrum
Switzerland
Email: mmorrow@cisco.com
John Yu
Hammerhead Systems, Inc.
640 Clyde Court
Mountain View, CA 94043 USA
Phone: +1 650 210 3312
Email: john@hammerheadsystems.com
Himanshu Shah
Ciena Networks
35 Nagog Park,
Acton, MA 01720
Email: hshah@ciena.com
Paul Doolan
Mangrove Systems
10 Fairfield Blvd.,
Wallingford, CT 06492
Email: pdoolan@mangrovesystems.com
Peter B. Busschbach
Lucent Technologies
67 Whippany Road
Whippany, NJ, 07981
Email: busschbach@lucent.com
Simon Delord
France Telecom
2 av, Pierre Marzin
22300 LANNION, France
E-mail: simon.delord@francetelecom.com
Vasile Radoaca
West Ridge Networks
Littleton, MA 01460
Email: vradoaca@westridgenetworks.com
Intellectual Property Statement
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
Aissaoui, et al. Expires April 2006 [Page 23]
Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Aissaoui, et al. Expires April 2006 [Page 24]
