One document matched: draft-asm-mpls-tp-bfd-cc-cv-01.txt
Differences from draft-asm-mpls-tp-bfd-cc-cv-00.txt
MPLS Working Group A. Fulignoli, Ed.
Internet Draft Ericsson
Intended status: Standards Track
Expires: April 2010 S. Boutros, Ed.
Cisco Systems, Inc
M. Vigoureux, Ed.
Alcatel-Lucent
October 26, 2009
Proactive Connection Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile
draft-asm-mpls-tp-bfd-cc-cv-01
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.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2010.
Copyright Statement
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.
Fulignoli et al., Expires April 26, 2010 [Page 1]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
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).
Table of Contents
1. Introduction...................................................3
1.1. Contributing Authors.........................................3
2. Conventions used in this document..............................3
2.1. Terminology..................................................3
3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD...........4
3.1. MPLS-TP BFD CC Message format................................5
3.2. MPLS-TP BFD proactive CV/CC Message format...................6
3.3. BFD Session in MPLS-TP terminology...........................6
3.4. BFD Profile for MPLS-TP......................................7
3.4.1. Timer negotiation.........................................10
3.4.2. Discriminator values......................................10
3.5. Remote Detection Indication (RDI)...........................10
4. Operation.....................................................11
4.1. Unidirectional p2p or p2mp transport path...................12
5. Acknowledgments...............................................13
6. IANA Considerations...........................................13
7. Security Considerations.......................................13
8. References....................................................13
8.1. Normative References........................................13
8.2. Informative References......................................14
Fulignoli et al., Expires April 26, 2010 [Page 2]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
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 [7] for CC, proactive CV, and RDI
of an MPLS-TP LSP between two Maintenance End Points (MEPs).
The mechanism specified in this document is restricted only to BFD
asynchronous mode.
The proposed method uses BFD state machine defined in Section 6.2 of
[7] for bidirectional p2p connections and uses the p2mp BFD state
machine defined in [8] for p2p unidirectional and p2mp unidirectional
transport path.
As described in [4], 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 behaviour to
satisfy the CC, proactive CV monitoring and the RDI functionality.
1.1. Contributing Authors
Siva Sivabalan, George Swallow, David Ward.
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
Fulignoli et al., Expires April 26, 2010 [Page 3]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
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
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.
Fulignoli et al., Expires April 26, 2010 [Page 4]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
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 [5] and yet
extended by [6], 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
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.
3.1. MPLS-TP BFD CC Message format
The format of an MPLS-TP CC Message format is shown below.
Fulignoli et al., Expires April 26, 2010 [Page 5]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 2: MPLS-TP CV/CC Message
As shown in Figure 2, BFD Control packet as defined in [7] 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.
Fulignoli et al., Expires April 26, 2010 [Page 6]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
A BFD session is enabled when the CC or proactive CV/CC functionality
is enabled on a configured Maintenance Entity (ME).
An enabled BFD session can be in DOWN, INIT or UP state as detailed
in [7] for p2p bidirectional connections and in [8] for
unidirectional p2p and p2mp connections.
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.
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 as described in [7]. In this mode,
the BFD Control packets are periodically sent at configurable time
rate
BFD state machine is defined in [7] for p2p bidirectional transport
path and in [8] for unidirectional p2p and p2mp transport path.
BFD session is declared Down:
If an unexpected MEP identifier is received (mis-connectivity
defect)
If timer and detect multiplier re-negotiation is disabled and an
unexpected desired min Tx interval field value or unexpected
detect multiplier field are received (Unexpected period defect).
If BFD session times out (Loss of Connectivity)
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 as per [4].
The diagram in Figure 1 provides an overview of the state machine for
MEP configured on p2p bidirectional transport path, as defined in
[7].
Fulignoli et al., Expires April 26, 2010 [Page 7]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
+--+
| | 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 1: State Machine for p2p bidirectional connection
The diagram in Figure 2 provides an overview of the state machine for
MEP Sink of unidirectional p2p transport as well as for MEP Sink
configured on each tail of a p2mp path as defined in [8].
(DOWN), ADMIN DOWN,
+------+ Defects +------+
+----| |<---------------------| |----+
(DOWN)| | DOWN | | UP | |UP
ADMIN DOWN,+--->| |--------------------->| |<---+
Defects +------+ UP +------+
Figure 2: State Machine for p2p and p2mp unidirectional
connection
State transitions on MEP Source on unidirectional p2p and p2mp path
are administratively driven.
Fulignoli et al., Expires April 26, 2010 [Page 8]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
Editor's Note
In unidirectional p2p o p2mp the DOWN State in the received BFD could
be removed as State transitions on MEP Source on unidirectional p2p
and p2mp path are administratively driven. Action should be taken in
[8].
EndofEditor'Note
In both diagram, each arc represents the state of the remote
system (as received in the State field in the BFD Control
packet) or indicates the expiration of the Detection Timer, here
extended to the occurrence of one or more of the following
defect: mis-connectivity, Unexpected period, Loss of
Connectivity
The raising and clearing conditions of defects identified by the
proactive Continuity Check and Connectivity Verification
functionality are as per [4]
As reported in [7], 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.
The AdminDown state semantic is equivalent to disabling on a MEP
the CC-CV proactive monitoring; in this case the source MEP
SHOULD send BFD Control packets 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.
Editor's Note:
The behaviour of the sink MEP, i.e the MEP receiving a BFD packet
with AdminDown State, will be detailed in a next revision of the
draft.
EndofEditor's Note:
Fulignoli et al., Expires April 26, 2010 [Page 9]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
3.4.1. Timer negotiation
BFD timer values negotiation is optional and disabled by default on
the MPLS-TP transport paths.
The configured BFD packet transmission is carried in the "Desired Min
TX Interval field". For a bidirectional p2p transport path the
"Required Min RX Interval field" MUST be the same as "Desired Min TX
Interval field". The source MEP of an unidirectional p2p and p2mp
session MUST set the "Required Min RX Interval field " to 0.
The default timer values to be used based on what's recommended in
[4].
3.4.2. Discriminator values
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 yet.
3.5. Remote Detection Indication (RDI)
The BFD Diagnostic (Diag) field defined in [8] can be used for this
functionality.
On MEP mismatch, loss of connectivity or unexpected timer and
unexpected detect multiplier a MEP sends to its peer MEP a BFD packet
with the Diagnostic (Diag) field value set to 1 (corresponding to the
"Control Detection Time Expired").
In order to help debugging, it is also possible to use one of the
following diagnostic code that indicate RDI condition:
- TBD: Unexpected MEP
- TBD: Unexpected timer and unexpected detect multiplier
The value 0 indicates RDI condition has been cleared.
Fulignoli et al., Expires April 26, 2010 [Page 10]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
4. Operation
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 [4].
MPLS labels at both MEPs are used to provide context for the received
BFD packets.
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.
When timer negotiation is disabled, 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.
Open issue:
- shall a source MEP send the BFD Control Packets at the
configured transmission rate in any BFD session State
or
- shall a source MEP send one BFD Control Packet per second
starting xx seconds after entering the Down state and prior to
entering the Init state ?
The details of the BFD state machine are as per Section 6.2 of [7]
for bidirectional p2p transport path; the following scenario
exemplifies the operation and is aligned with [6] section 3.1.
Fulignoli et al., Expires April 26, 2010 [Page 11]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
+-----+ +-----+
| | ------- X -------->| |
| A | <----------------- | B |
+-----+ +-----+
Figure 3
o If a MEP-B in Figure 3 detects one of the following faults (miss-
connectivity, Unexpected Period or loss of continuity) from its
peer MEP, it declares that the transport path in its receive
direction is down (in other words, MEP-B enters the "receive
defect" state for this transport path) and signals it to its peer
MEP (MEP-A) sending the BFD packets with State (Sta) field set to
"Down" and Diagnostic code 1 (RDI)
o In turn, the peer MEP (MEP-A) declares the transport path is down
in its transmit direction, (in other words, MEP-A enters the
"transmit defect" state for this transport path) setting the State
(Sta field ) to Down with Diagnostic code 3 (Neighbor signaled
session down) in its BFD packets towards MEP-B. Please note that
if the failure is unidirectional, i.e. only from A to B direction
as in Figure 1. MEP-A, transits first to Down State but then to
Init state as it still receives BFD packets from its peer MEP B.
4.1. Unidirectional p2p or p2mp transport path.
o In a unidirectional (point-to-point or point-to-multipoint)
transport path, where the proactive CV/CC or CC monitoring is
enabled, only the Source MEP is enabled to generate BFD control
packets with rate of the operator configured transmission period,
with the State field always set to "UP" and with "Your
discriminator" field always set to zero.
Editor's note : This last setting requires modification on [8]
section 4.16.2.
EndofEditorNote
The multipoint BFD control packets are explicitly marked as such,
via the setting of the M bit (see [8]).
The Source MEP does not expect to receive any BFD packets from its
peer MEP(s), as such all state transitions are administratively
driven.
Fulignoli et al., Expires April 26, 2010 [Page 12]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
o A MEP Sink, configured on a unidirectional transport path where
the proactive CV and CC monitoring is enabled, expects to receive
the BFD packets from its peer MEP at the operator configured
period; the defects detection procedure is the same as the
bidirectional MEP.
5. Acknowledgments
To be added in a later version of this document
6. IANA Considerations
To be added in a later version of this document
7. Security Considerations
The security considerations for the authentication TLV need further
study.
Base BFD foresees an optional authentication section (see [7]
section 6.7); that can be extended also to the tool proposed in
this document.
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.
8. References
8.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-03 (work in progress), August 2009
[4] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and
Overview", draft-ietf-mpls-tp-oam-framework-01 (work in
progress), July 2009
Fulignoli et al., Expires April 26, 2010 [Page 13]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009
[5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007
[6] 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
[7] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-09 (work in progress),
February 2009
[8] Katz, D. and D. Ward, "BFD for Multipoint Networks",
draft-katz-ward-bfd-multipoint-02 (work in progress),
February 2009
[9] Boutros, S. et al., "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-00 (work in progress), June
2009
[10] Aggarwal, R., Kompella, K., Nadeau, T. and G. Swallow,
"BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in
progress), June 2008
[11] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", draft-ietf-mpls-tp-framework-05, (work in
progress), September 2009
[12] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-
swallow-mpls-tp-identifiers-01 (work in progress), July
2009
8.2. Informative References
To be added in a later version of this document
Fulignoli et al., Expires April 26, 2010 [Page 14]
Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 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 April 26, 2010 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 05:36:36 |