MPLS Working Group A. Fulignoli, Ed.
Internet Draft Ericsson
Intended status: Standards Track
Expires: September 2010 S. Boutros, Ed.
Cisco Systems, Inc
M. Vigoureux, Ed.
Alcatel-Lucent
March 3, 2010
Proactive Connection Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile
draft-asm-mpls-tp-bfd-cc-cv-02
Abstract
Continuity Check (CC), Proactive Connectivity Verification (CV) and
Remote Defect Indication (RDI) functionalities are MPLS-TP OAM
requirements listed in [3].
Continuity Check monitors the integrity of the continuity of the path
for any loss of continuity defect. Connectivity verification monitors
the integrity of the routing of the path between sink and source for
any connectivity issues. RDI enables an End Point to report, to its
associated End Point, a fault or defect condition that it detects on
a PW, LSP or Section.
It is RECOMMENDED that a protocol solution, meeting one or more
functional requirement(s), be the same for PWs, LSPs and Sections as
per [3].
This document specifies methods for proactive CV, CC, and RDI for
MPLS-TP Label Switched Path (LSP), PWs and Sections using
Bidirectional Forwarding Detection (BFD).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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.
Fulignoli et al., Expires September 3, 2010 [Page 1]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
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
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
Table of Contents
1. Introduction.................................................3
1.1. Contributing Authors.......................................3
2. Conventions used in this document............................4
2.1. Terminology................................................4
3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD.........4
3.1. MPLS-TP BFD CC Message format..............................6
3.2. MPLS-TP BFD proactive CV/CC Message format.................6
3.3. BFD Session in MPLS-TP terminology.........................7
3.4. BFD Profile for MPLS-TP....................................8
3.4.1. Administrative Down State...............................10
3.4.2. Timer negotiation.......................................11
3.4.3. Discriminator values....................................11
3.5. Remote Detection Indication (RDI).........................12
Fulignoli et al., Expires September 4, 2010 [Page 2]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
4. Operation on bidirectional p2p connection...................12
4.1. Bidirectional BFD.........................................12
4.2. Unidirectional BFD........................................13
5. Unidirectional p2p or p2mp transport path...................15
6. Acknowledgments.............................................15
7. IANA Considerations.........................................15
8. Security Considerations.....................................15
9. References..................................................16
9.1. Normative References......................................16
9.2. Informative References....................................16
1. Introduction
In traditional transport networks, circuits are provisioned on
multiple switches. Service Providers (SP) need OAM tools to detect
mis-connectivity and loss of continuity of transport circuits. MPLS-
TP LSPs [11]emulating traditional transport circuits need to provide
the same CC and proactive CV capabilities as mentioned in [3]. This
document describes the use of BFD for CC, proactive CV, and RDI of an
MPLS-TP LSP between two Maintenance End Points (MEPs).
As described in [9], Continuity Check (CC) and Proactive Connectivity
Verification (CV) functions are used to detect loss of continuity
(LOC), unintended connectivity between two MEPs (e.g. mismerging or
misconnection or unexpected MEP).
The Remote Defect Indication (RDI) is an indicator that is
transmitted by a MEP to communicate to its peer MEPs that a signal
fail condition exists. RDI is only used for bidirectional connections
and is associated with proactive CC & CV packet generation.
The main goal here is to specify the BFD extension and behavior to
satisfy the CC, proactive CV monitoring and the RDI functionality.
The mechanism specified in this document is restricted only to BFD
asynchronous mode.
1.1. Contributing Authors
Siva Sivabalan, George Swallow, David Ward.
Fulignoli et al., Expires September 4, 2010 [Page 3]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
2. 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 [1].
2.1. Terminology
ACH: Associated Channel Header
BFD: Bidirectional Forwarding Detection
CV: Connection Verification
EOS: End of Stack
GAL: Generalized Alert Label
LSR: Label Switching Router
MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
MPLS-OAM: MPLS Operations, Administration and Maintenance
MPLS-TP: MPLS Transport Profile
MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit
MS-PW: Mult-Segment PseudoWire
NMS: Network Management System
PW: PseudoWire
RDI: Remote defect indication.
TTL: Time To Live
TLV: Type Length Value
3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD
This document proposes two modes of BFD operation
Fulignoli et al., Expires September 4, 2010 [Page 4]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
o CC mode: uses the existing ACH code point (0x0007) and BFD ACH
packet encapsulation (BFD without IP/UDP headers ) as defined in
[6]. In this mode Continuity Check and RDI functionalities are
supported.
o CV/CC mode: defines a new code point in the Associated Channel
Header (ACH) described in [2]. Under MPLS label stack of the MPLS-
TP LSP, the ACH with "MPLS-TP Proactive CV/CC" code point
indicates that the message is an MPLS-TP BFD proactive CV and CC
message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags |0xHH MPLS-TP CV/CC Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Connection Verification
The first nibble (0001b) indicates the ACH.
The version and the reserved values are both set to 0 as specified in
[2].
MPLS-TP proactive CV/CC code point = 0xHH. [HH to be assigned by IANA
from the PW Associated Channel Type registry.]
In this mode Continuity Check, Connectivity Verifications and RDI
functionalities are supported.
Editor's Note:
1) CV/CC mode require extension of CV types, foreseen by [4] and yet
extended by [5], in order to include the MPLS-TP OAM mechanism
too for PW Fault Detection only. This is due to the fact that
VCCV also includes mechanisms for negotiating the control channel
and connectivity verification (i.e. OAM functions) between PEs.
2) Does also the CC mode for MPLS-TP require such extension ?
3) Shall we trace that in this document ?
EndofEditorNote
Both CC and CV/CC modes apply to PWs, MPLS LSPs (including tandem
connection monitoring), and Sections.
Fulignoli et al., Expires September 4, 2010 [Page 5]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
It's possible to run the BFD in CC mode on some transport paths and
the BFD in CV/CC mode on other transport paths. In any case, only one
tool for OAM instance at time, configurable by operator, can run. A
MEP that is configured to support CC mode and receives CV/CC BFD
packets, or vice versa, MUST consider them as an unexpected packet,
i.e. detect a mis-connectivity defect.
3.1. MPLS-TP BFD CC Message format
The format of an MPLS-TP CC Message format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP CC Message
3.2. MPLS-TP BFD proactive CV/CC Message format
The format of an MPLS-TP CV/CC Message format is shown below, ACH
TLVs MUST precede the BFD control packet.
Fulignoli et al., Expires September 4, 2010 [Page 6]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags |0xHH MPLS-TP CV/CC Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unique MEP-ID of source of the BFD packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS-TP CV/CC Message
As shown in Figure 3, BFD Control packet as defined in [6] is
transmitted as MPLS labeled packets along with ACH, ACH TLV Header
defined in Section 3 of RFC 5586 and one ACH TLV object carrying the
unique MEP Identifier of the source of the BFD packet defined in [12]
When GAL label is used, the TTL field of the GAL MUST be set to at
least 1, and the GAL will be the end of stack label.
3.3. BFD Session in MPLS-TP terminology
A BFD session corresponds to a CC or a proactive CV/CC OAM instance
in MPLS-TP terminology.
A BFD session is enabled when the CC or proactive CV/CC functionality
is enabled on a configured Maintenance Entity (ME).
On a Sink MEP, an enabled bidirectional BFD session can be in DOWN,
INIT or UP state as detailed in [6].
On a Sink MEP, a unidirectional BFD session can be in UP or DOWN
state as reported in [10].
When on a ME the CC or proactive CV/CC functionality is disabled, the
BFD session transits in the ADMIN DOWN State and the BFD session
ends.
Fulignoli et al., Expires September 4, 2010 [Page 7]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
A new BFD session is initiated when the operator enables or re-
enables the CC or CV/CC functionality on the same ME.
3.4. BFD Profile for MPLS-TP
BFD MUST run in asynchronous mode. In this mode, the BFD Control
packets are periodically sent at configurable time rate.
When on bidirectional path, associated or co-routed, it is required
the BFD state be independent from the peer MEP BFD state, two
unidirectional BFD sessions MUST be configured, one for each
direction of the bidirectional path to be monitored; each MEP is
aware of the relationship among the MEP source function and MEP sink
function of the two unidirectional BFD sessions.
This applies, for instance, when it is required to transmit the BFD
control packet at a regular, operator configured rate and to maintain
this rate at any BFD state in order to manage the 1+1 unidirectional
protection.
When it is required that both sessions on peer MEPs go in DOWN state
if one goes in DOWN state, the bidirectional BFD session MUST be
configured on the bidirectional using the three state machine and
following the behavior detailed in [6].
The unidirectional BFD on the sink MEP uses the two state machine
defined in [10]. When running the unidirectional state machine the M
bit MUST be always set to 1.
On a Sink MEP, a BFD session is declared Down if one of the following
defects identified by the proactive CC-CV functions occurs:
- an unexpected globally unique Source MEP identifier is received
(Mis-connectivity defect),
- timer negotiation is disabled and the value of the received
"Desired min TX Interval field" is different from the locally
configured reception period, or the received value of the
"DetectMult field" is different from the locally configured one
(Period Mis-configuration defect);
- BFD session times out (Loss of Continuity defect).
- a Mis-connectivity defect SHOULD be also detected if an
unexpected M bit value is received.
Fulignoli et al., Expires September 4, 2010 [Page 8]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
The raising and clearing conditions of defects identified by the
Continuity Check, proactive Connectivity Verification
functionality and RDI MUST be as per [9] where a protocol
constant set to 3,5 is used. This protocol constant corresponds
to the BFD Detection Time multiplier that is RECOMMENDED to be
set to value 3.
Traffic MUST NOT be affected when proactive CV/CC or CC
monitoring is enabled/disabled by an operator on a configured
MEP or when a BFD session transits from one state to another;
the blocking of traffic as consequent action MUST be driven only
by a defect's consequent action as specified in [9] section
5.1.2
The diagram in Figure 4 provides an overview of the three state
machine as defined in [6].
+--+
| | UP, ADMIN DOWN, Defects,
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |Defects Defects | |
V | | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Figure 4: State Machine for bidirectional BFD
Fulignoli et al., Expires September 4, 2010 [Page 9]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
The diagram in Figure 5 provides an overview of the two state machine
of unidirectional BFD on Sink MEP
ADMIN DOWN,
+------+ Defects +------+
+----| |<---------------------| |----+
Defects,| | DOWN | | UP | |UP
ADMIN DOWN,+--->| |--------------------->| |<---+
+------+ No defects +------+
&& UP
Figure 5: MEP Sink State Machine for unidirectional BFD
State transitions on MEP Source of unidirectional BFD are
administratively driven. On a Source MEP, when the CC, CV/CC
functionality is enabled, the state machine transits from the ADMIN-
DOWN State to UP State; vice-versa when the functionality is
disabled.
In both diagram, each arc represents the state of the remote
system (as received in the State field in the BFD Control
packet) or the occurrence of one or more of the following
defect: Mis-connectivity, Period Misconfiguration, Loss of
Continuity as previously detailed.
As reported in [6], another state (AdminDown) exists so that the
BFD session can be administratively put down indefinitely. In
the above diagram transitions involving AdminDown state are
deleted for clarity; further considerations are reported in
section 3.4.1.
3.4.1. Administrative Down State
The AdminDown state semantic is equivalent to disabling on a MEP
the CC-CV proactive function.
When the MEP source function is disabled, BFD Control packets
SHOULD be sent in AdminDown state for a period equal
to(bfd.DesiredMinTxInterval * bfd.DetectMult) in order to ensure
that the remote system is aware of the state change.
Fulignoli et al., Expires September 4, 2010 [Page 10]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
A MEP Sink receiving a BFD packet with AdminDown State MUST
transit to the DOWN State and report the event to the operator.
The MEP Sink receiving the BFD packet with AdminDown State
SHOULD continue to monitor the path until the operator disables
the CC or proactive CV monitoring on it.
On bidirectional path, the MEP source function of the MEP
receiving BFD packets in AdminDown state SHOULD continue to
transmit BFD control packet until the operator disables the CC
or proactive CV monitoring on it.
Editor's Note: The behavior of the sink MEP needs further review and
will be updated in the next version of this document.
3.4.2. Timer negotiation
When running unidirectional BFD, on unidirectional or bidirectional
connection path, the timer negotiation does not apply.
The configured BFD packet transmission period is carried into the
''Desired Min TX Interval field''. In a typical transport application
today the period is the same in both directions; in this case, for
Bidirectional BFD on p2p transport path the "Required Min RX Interval
field" value is the same as "Desired Min TX Interval field" value.
The source MEP of unidirectional BFD MUST set the "Required Min RX
Interval field " to 0.
The default timer values to be used based on what's recommended in
[9].
3.4.3. Discriminator values
MPLS labels at peer MEPs are used to provide context for the received
BFD packets.
In the BFD control packet the discriminator values have either local
or no significance.
My Discriminator field MUST be set to a nonzero value (it can be a
fixed value), the transmitted your discriminator value MUST reflect
back the received value of My discriminator field or be set to 0 if
that value is not known.
Your discriminator field is always set to 0 on Unidirectional BFD
control packets.
Fulignoli et al., Expires September 4, 2010 [Page 11]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
3.5. Remote Detection Indication (RDI)
Remote Defect Indication (RDI) is an indicator that is transmitted by
a MEP to communicate to its peer MEP that a signal fail condition
exists.
The BFD Diagnostic (Diag) field defined in [6] is used for this
functionality.
When a MEP detects mis-connectivity, or loss of continuity, or period
misconfiguration defect, sends to its peer MEP the proactive CC,
CV/CC BFD packet with the Diagnostic (Diag) field value set to 1.
When a MEP receives the proactive CC, CV/CC BFD packet with the
Diagnostic (Diag) field value set to 1, enters in the RDI defect
conditions.
A MEP exits from the RDI defect condition when it receives a
proactive CC, CV/CC BFD packet with the RDI field clear,
corresponding to receive Diagnostic(Diag) field with values different
from 1.
4. Operation on bidirectional p2p connection
For p2p bidirectional LSPs, both endpoints of the bidirectional MPLS-
TP LSP MUST send BFD messages in-band in the MPLS-TP LSP using the
defined code point.
When on a configured bidirectional transport path the proactive CV/CC
or CC monitoring is enabled, each MEP sends the BFD Control Packets
at the rate of the configured transmission period and each MEP
expects to receive the BFD packets from its peer MEP at the same rate
as per [9].
4.1. Bidirectional BFD
When on bidirectional path the bidirectional BFD is enabled, the
behaviour SHOULD be as detailed in [6] for asynchronous BFD.
Active role is the default behavior, passive role is optional.
In Active role both MEPs start sending initial BFD Control Packets
with the State field set to "Down" value and with "Your
discriminator" field set to zero.
Fulignoli et al., Expires September 4, 2010 [Page 12]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
4.2. Unidirectional BFD
When on bidirectional path it is required the BFD state be
independent from the peer MEP BFD state, two unidirectional BFD
sessions MUST be configured. Considering figure 6 below, an
unidirectional BFD session is configured to monitor the direction
from A to B and an unidirectional BFD session is configured to
monitor the direction from B to A.
+-----+ +-----+
| |------------------->| |
| A | | B |
| |< ------------------| |
+-----+ +-----+
Figure 6
On the unidirectional BFD session monitoring the A to B direction,
the MEP source function is located on node A while the MEP sink
function is located on node B.
On the unidirectional BFD session monitoring the B to A direction,
the MEP source function is located on node B while the MEP sink
function is located on node A.
o When the source function of an unidirectional BFD is enabled, the
source MEP state machine transits from AdminDown State to UP state
and starts sending BFD unidirectional control packets at the
configured transmission rate with the M bit always set to 1, the
State field set to "UP" and Diagnostic code set to zero (0).
Fulignoli et al., Expires September 4, 2010 [Page 13]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
+--------+ M =1;Tx=10ms;Rx=0;MyDis=10;YourDis=0; +--------+
| | St=UP;Diag=0 | |
| |-------------------------------------->| |
| A | | B |
| |<--------------------------------------| |
| | M =1;Tx=10ms;Rx=0;MyDis=20;YourDis=0; | |
| | St=UP;Diag=0 | |
+--------+ +--------+
Figure 7
Editor's note: The slow rate startup requires further analysis and is
under study.
o When enabled, the MEP Sink is allowed to detect continuity and
connectivity defects.
+-----+ +-----+
| | ------- X -------->| |
| A | <----------------- | B |
+-----+ +-----+
Figure 8
o If the MEP sink monitoring function, as the one on MEP-B in Figure
8, detects one of the following faults: mis-connectivity, period
misconfiguration, or loss of continuity defect it declares that
the transport path in its receive direction is down and signals it
to its peer MEP (MEP-A) sending the BFD control packet running on
the unidirectional BFD from B to A with Diagnostic code set to 1
(RDI); see figure 9 below. Besides, the MEP Sink SHOULD notify the
equipment fault management process of the detected defect.
Fulignoli et al., Expires September 4, 2010 [Page 14]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
+--------+ M =1;Tx=10ms;Rx=0;MyDis=10;YourDis=0; +--------+
| | St=UP;Diag=0 | |
| |-----------------X-------------------> | |
| A | | B |
| | <-------------------------------------| |
| | M =1;Tx=10ms;Rx=0;MyDis=20;YourDis=0;| |
| | St=UP;Diag=1 | |
+--------+ +--------+
Figure 9
Timer parameters are configured by the operator and statically
provisioned or signaled by the control plane; the timer configured
value are carried inside the BFD packets and this value never change
unless modified by operator; the new timer configuration must be
statically provisioned or signaled by the control plane.
5. Unidirectional p2p or p2mp transport path.
Unidirectional (point-to-point or point-to-multipoint) transport path
are monitored through one unidirectional BFD session. The behavior
and MPLS-TP profile is the same as described in previous section for
unidirectional BFD except for RDI generation that is not required to
be sent on unidirectional transport path.
6. Acknowledgments
To be added in a later version of this document
7. IANA Considerations
To be added in a later version of this document
8. Security Considerations
The security considerations for the authentication TLV need further
study.
Base BFD foresees an optional authentication section (see [6]
section 6.7); that can be extended also to the tool proposed in
this document.
Fulignoli et al., Expires September 4, 2010 [Page 15]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
Authentication methods that require checksum calculation on the
outgoing packet must extend the checksum also on the ME
Identifier Section. This is possible but seems uncorrelated with
the solution proposed in this document: it could be better to
use the simple password authentication method.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC
5586 , June 2009
[3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for OAM
in MPLS Transport Networks", draft-ietf-mpls-tp-oam-
requirements-05 (work in progress), February 2010
[4] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007
[5] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-
bfd-07 (work in progress), July 2009
[6] Katz, D. and D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-11 (work in progress), January 2010
[7] Boutros, S. et al., "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-01 (work in progress), June
2009
[8] Aggarwal, R., Kompella, K., Nadeau, T. and G. Swallow, "BFD
For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
June 2008
9.2. Informative References
[9] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and
Overview", draft-ietf-mpls-tp-oam-framework-04 (work in
progress), July 2009
Fulignoli et al., Expires September 4, 2010 [Page 16]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-02 March 2010
[10] Katz, D. and D. Ward, "BFD for Multipoint Networks", draft-
katz-ward-bfd-multipoint-02 (work in progress), December
2009
[11] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", draft-ietf-mpls-tp-framework-10, (work in
progress), February 2010
[12] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-ietf-
mpls-tp-identifiers-00 (work in progress), July 2009
Authors' Addresses
Annamaria Fulignoli (Editor)
Ericsson
Email: annamaria.fulignoli@ericsson.com
Sami Boutros (Editor)
Cisco Systems, Inc.
Email: sboutros@cisco.com
Martin Vigoureux (Editor)
Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.com
Contributing Authors' Addresses
Siva Sivabalan
Cisco Systems, Inc.
Email: msiva@cisco.com
George Swallow
Cisco Systems, Inc.
Email: swallow@cisco.com
David Ward
Cisco Systems, Inc.
Email: wardd@cisco.com
Fulignoli et al., Expires September 4, 2010 [Page 17]