draft-ietf-mpls-tp-cc-cv-rdi-03.txt   draft-ietf-mpls-tp-cc-cv-rdi-04.txt 
MPLS Working Group Dave Allan, Ed. MPLS Working Group Dave Allan, Ed.
Internet Draft Ericsson Internet Draft Ericsson
Intended status: Standards Track Intended status: Standards Track
Expires: August 2011 George Swallow Ed. Expires: December 2011 George Swallow Ed.
Cisco Systems, Inc Cisco Systems, Inc
John Drake Ed. John Drake Ed.
Juniper Juniper
February 2, 2011 June 2011
Proactive Connectivity Verification, Continuity Check and Remote Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile Defect indication for MPLS Transport Profile
draft-ietf-mpls-tp-cc-cv-rdi-03 draft-ietf-mpls-tp-cc-cv-rdi-04
Abstract Abstract
Continuity Check (CC), Proactive Connectivity Verification (CV) and Continuity Check, Proactive Connectivity Verification and Remote
Remote Defect Indication (RDI) functionalities are required for MPLS- Defect Indication functionalities are required for MPLS-TP OAM.
TP OAM.
Continuity Check monitors the integrity of the continuity of the LSP Continuity Check monitors the integrity of the continuity of the
for any loss of continuity defect. Connectivity verification monitors label switched path for any loss of continuity defect. Connectivity
the integrity of the routing of the LSP between sink and source for verification monitors the integrity of the routing of the label
any connectivity issues. RDI enables an End Point to report, to its switched path between sink and source for any connectivity issues.
Remote defect indication enables an End Point to report, to its
associated End Point, a fault or defect condition that it detects on associated End Point, a fault or defect condition that it detects on
a PW, LSP or Section. a pseudo wire, label switched path or Section.
This document specifies methods for proactive CV, CC, and RDI for This document specifies methods for proactive continuity check,
MPLS-TP Label Switched Path (LSP), PWs and Sections using continuity verification, and remote defect indication for MPLS-TP
Bidirectional Forwarding Detection (BFD). label switched paths, pseudo wires and Sections using Bidirectional
Forwarding Detection.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1]. document are to be interpreted as described in RFC2119 [1].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance This Internet-Draft is submitted to IETF in full conformance
skipping to change at page 2, line 43 skipping to change at page 2, line 43
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License. without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Authors......................................................4 1.1. Authors......................................................4
2. Conventions used in this document..............................4 2. Conventions used in this document..............................4
2.1. Terminology..................................................4 2.1. Terminology..................................................4
3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5
3.1. ACH code points for CC and proactive CV......................6 3.1. Existing Capabilities........................................5
3.2. MPLS BFD CC Message format...................................6 3.2. CC, CV, and RDI Overview.....................................5
3.3. MPLS BFD proactive CV Message format.........................7 3.3. ACH code points for CC and proactive CV......................6
3.3.1. ICC-based MEP-ID...........................................8 3.4. MPLS BFD CC Message format...................................7
3.3.2. LSP MEP-ID.................................................8 3.5. MPLS BFD proactive CV Message format.........................7
3.3.3. PW Endpoint MEP-ID.........................................8 3.5.1. ICC-based MEP-ID...........................................9
3.4. BFD Session in MPLS-TP terminology...........................8 3.5.2. Section MEP-ID.............................................9
3.5. BFD Profile for MPLS-TP......................................9 3.5.3. LSP MEP-ID.................................................9
3.5.1. Session initiation........................................10 3.5.4. PW Endpoint MEP-ID........................................10
3.5.2. Defect entry criteria.....................................10 3.6. BFD Session in MPLS-TP terminology..........................11
3.5.3. Defect entry consequent action............................11 3.7. BFD Profile for MPLS-TP.....................................11
3.5.4. Defect exit criteria......................................12 3.7.1. Session initiation and Modification.......................13
3.5.5. State machines............................................12 3.7.2. Defect entry criteria.....................................13
3.5.6. Configuration of MPLS-TP BFD sessions.....................15 3.7.3. Defect entry consequent action............................14
3.5.7. Discriminator values......................................15 3.7.4. Defect exit criteria......................................15
4. Acknowledgments...............................................16 3.7.5. State machines............................................15
5. IANA Considerations...........................................16 3.7.6. Configuration of MPLS-TP BFD sessions.....................18
6. Security Considerations.......................................16 3.7.7. Discriminator values......................................18
7. References....................................................16 4. Configuration Considerations..................................18
7.1. Normative References........................................16 5. Acknowledgments...............................................19
7.2. Informative References......................................17 6. IANA Considerations...........................................19
7. Security Considerations.......................................19
8. References....................................................20
8.1. Normative References........................................20
8.2. Informative References......................................20
1. Introduction 1. Introduction
In traditional transport networks, circuits are provisioned on two or In traditional transport networks, circuits are provisioned on two or
more switches. Service Providers (SP) need OAM tools to detect mis- more switches. Service Providers (SP) need OAM tools to detect mis-
connectivity and loss of continuity of transport circuits. Both PWs connectivity and loss of continuity of transport circuits. Both
and MPLS-TP LSPs [10] emulating traditional transport circuits need pseudo wires (PWs) and MPLS-TP label switched paths (LSPs) [10]
to provide the same CC and proactive CV capabilities as required in emulating traditional transport circuits need to provide the same
RFC 5860[3]. This document describes the use of BFD for CC, proactive continuity check (CC) proactive continuity verification (CV) and
CV, and RDI of a PW, LSP or SPME between two Maintenance Entity Group remote defect indication (RDI) capabilities as required in RFC
End Points (MEPs). 5860[3]. This document describes the use of BFD for CC, proactive CV,
and RDI of a PW, LSP or sub path maintenance entity (SPME) between
two Maintenance Entity Group End Points (MEPs).
As described in [11], Continuity Check (CC) and Proactive As described in [11], CC and CV functions are used to detect loss of
Connectivity Verification (CV) functions are used to detect loss of
continuity (LOC), and unintended connectivity between two MEPs (e.g. continuity (LOC), and unintended connectivity between two MEPs (e.g.
mismerging or misconnectivity or unexpected MEP). mis-merging or mis-connectivity or unexpected MEP).
The Remote Defect Indication (RDI) is an indicator that is RDI is an indicator that is transmitted by a MEP to communicate to
transmitted by a MEP to communicate to its peer MEP that a signal its peer MEP that a signal fail condition exists. RDI is only used
fail condition exists. RDI is only used for bidirectional LSPs and is for bidirectional LSPs and is associated with proactive CC & CV BFD
associated with proactive CC & CV packet generation. control packet generation.
This document specifies the BFD extension and behavior to satisfy the This document specifies the BFD extension and behavior to satisfy the
CC, proactive CV monitoring and the RDI functional requirements for CC, proactive CV monitoring and the RDI functional requirements for
both co-routed and associated bi-directional LSPs. Supported both co-routed and associated bi-directional LSPs. Supported
encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for encapsulations include generic alert label (GAL)/G-ACh, virtual
uni-directional LSPs are for further study. circuit connectivity verification (VCCV) and UDP/IP. Procedures for
uni-directional p2p and p2mp LSPs are for further study.
The mechanisms specified in this document are restricted to BFD The mechanisms specified in this document are restricted to BFD
asynchronous mode. asynchronous mode.
1.1. Authors 1.1. Authors
David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami
Boutros, Siva Sivabalan, David Ward, Martin Vigoureux. Boutros, Siva Sivabalan, David Ward, Martin Vigoureux and Robert
Rennison.
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
ACH: Associated Channel Header ACH: Associated Channel Header
BFD: Bidirectional Forwarding Detection BFD: Bidirectional Forwarding Detection
CV: Connectivity Verification CV: Connectivity Verification
GAL: Generalized Alert Label GAL: Generalized Alert Label
G-ACh: Generic Associated Channel
LDI: Link Down Indication LDI: Link Down Indication
LKI: Lock Instruct LKI: Lock Instruct
LKR: Lock Report LKR: Lock Report
LSR: Label Switching Router LSR: Label Switching Router
ME: Maintenance Entity
MEG: Maintenance Entity Group MEG: Maintenance Entity Group
MEP: Maintenance Entity Group End Point MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point MIP: Maintenance Entity Group Intermediate Point
MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-OAM: MPLS Operations, Administration and Maintenance
MPLS-TP: MPLS Transport Profile MPLS-TP: MPLS Transport Profile
MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path
representing a circuit representing a circuit
MS-PW: Multi-Segment PseudoWire MS-PW: Multi-Segment PseudoWire
NMS: Network Management System NMS: Network Management System
PW: Pseudo Wire PW: Pseudo Wire
RDI: Remote Defect Indication. RDI: Remote Defect Indication
SPME: Sub-Path Maintenance Entity SPME: Sub-Path Maintenance Entity
TTL: Time To Live TTL: Time To Live
TLV: Type Length Value TLV: Type Length Value
VCCV: Virtual Circuit Connectivity Verification VCCV: Virtual Circuit Connectivity Verification
3. MPLS CC, proactive CV and RDI Mechanism using BFD 3. MPLS CC, proactive CV and RDI Mechanism using BFD
This document proposes distinct encapsulations and code points for This document describes procedures for achieve combined CC, CV and
ACh encapsulated BFD depending on whether the mode of operation is CC RDI functionality within a single MPLS-TP MEG using BFD. This
or CV: augments the capabilities that can be provided for MPLS-TP LSPs using
existing specified tools and procedures.
o CC mode: defines a new code point in the Associated Channel Header 3.1. Existing Capabilities
(ACH) described in RFC 5586[2].In this mode Continuity Check and
RDI functionalities are supported.
o CV mode: defines a new code point in the Associated Channel Header A CC-only mode may be provided via protocols and procedures described
(ACH) described in RFC 5586[2]. The ACH with "MPLS Proactive CV" in RFC 5885[7] with ACH channel 7. These procedures may be applied to
code point indicates that the message is an MPLS BFD proactive CV bi-directional LSPs as well as PWs.
and CC message and CC, CV and RDI functionalities are supported.
RDI: is communicated via the BFD diagnostic field in BFD CC and CV Implementations MAY also interoperate with existing equipment by
messages. It is not a distinct PDU. A sink MEP will encode a implementing [2], or [8] in addition to the procedures documented in
diagnostic code of "1- Control detection time expired" when the this memo. In accordance with RFC 5586[2], when BFD control packets
interval times detect multipler have been exceeded, and with "3 - are encapsulated in an IP header, the fields in the IP header are set
neighbor signaled session down" as a consequence of the sink MEP as defined in RFC 5884[8]. When IP encapsulation is used CV mis-
receiving AIS with LDI set. A sink MEP that has started sending diag connectivity defect detection can be performed by inferring a
code 3 will NOT change it to 1 when the detection timer expires. globally unique source on the basis of the combination of the source
IP address and "my discriminator" fields.
In accordance with RFC 5586[2], when these packets are encapsulated 3.2. CC, CV, and RDI Overview
in an IP header, the fields in the IP header are set as defined in
RFC 5884[8]. Further existing ACh code points and mechanisms for BFD
VCCV are specified in RFC5885[7]. These MAY be applied to
Pseudowires by configuration. Also by configuration, the BFD PW-ACH-
encapsulated for PW fault detection only encapsulation can be applied
to bi-directional LSPs by employing the GAL to indicate the presence
of the ACh.
A further artifact of IP encapsulation is that CV mis-connectivity The combined CC, CV, and RDI functionality for MPLS-TP is achieved by
defect detection can be performed by inferring MEP_ID on the basis of multiplexing CC and CV PDUs within a single BFD session. The CV PDUs
the combination of the source IP address and "my discriminator" are augmented with a source MEP ID TLV to permit mis-connectivity
fields. detection to be performed by sink MEPs.
3.1. ACH code points for CC and proactive CV The interleaving of PDUs is achieved via the use of distinct
encapsulations and code points for generic associated channel (G-ACh)
encapsulated BFD depending on whether the PDU format is CC or CV:
o CC format: defines a new code point in the Associated Channel
Header (ACH) described in RFC 5586[2].This format supports
Continuity Check and RDI functionalities.
o CV format: defines a new code point in the Associated Channel
Header (ACH) described in RFC 5586[2]. The ACH with "MPLS
Proactive CV" code point indicates that the message is an MPLS BFD
proactive CV message, and information for CV processing is
appended in the form of the source MEP ID TLV.
RDI is communicated via the BFD diagnostic field in BFD CC messages.
It is not a distinct PDU. A sink MEP will encode a diagnostic code of
"1 - Control detection time expired" when the interval times detect
multiplier have been exceeded, and with "5 - Path Down" as a
consequence of the sink MEP receiving AIS with LDI set. A sink MEP
that has started sending diagnostic code 5 SHOULD NOT change it to 1
when the detection timer expires.
3.3. ACH code points for CC and proactive CV
0 1 2 3 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 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 BFD CC/CV Code Point | |0 0 0 1|Version| Flags | BFD CC/CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Connectivity Verification Figure 1: ACH Indication of MPLS-TP Connectivity Verification
The first nibble (0001b) indicates the ACH. The first nibble (0001b) indicates the ACH.
The version and the flags are set to 0 as specified in [2]. The version and the flags are set to 0 as specified in [2].
The code point is either The code point is either
- BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW - BFD CC code point = 0xXX. [HH to be assigned by IANA from the PW
Associated Channel Type registry.] or, Associated Channel Type registry.] or,
- BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from - BFD proactive CV code point = 0xXX+1. [HH to be assigned by IANA
the PW Associated Channel Type registry.] from the PW Associated Channel Type registry.]
Both CC and CV modes apply to PWs, MPLS LSPs (including SPMEs), and CC and CV PDUs apply to all pertinent MPLS-TP structures, including
Sections. PWs, MPLS LSPs (including SPMEs), and Sections.
CC and CV operation can be simultaneously employed on an ME within a CC and CV operation is simultaneously employed on a maintenance
single BFD session. The expected usage is that normal operation is to entity (ME) within a single BFD session. The expected usage is
send CC BFD PDUs with every nth BFD PDU augmented with a source MEP- that normal operation is to send CC BFD protocol data units
ID and identified as requiring additional processing by the different (PDUs) interleaved with a CV BFD PDU (augmented with a
ACh channel type. When CC and CV are interleaved, the minimum source MEP-ID and identified as requiring additional
insertion interval for CV PDUs is one per second. processing by the different ACh channel type). The
insertion interval for CV PDUs is one per second. Detection
of a loss of continuity defect is the detect multiplier (fixed at 3
for the CC code point) times the session periodicity. Mis-
connectivity defects are detected in a maximum of one second.
3.2. MPLS BFD CC Message format 3.4. MPLS BFD CC Message format
The format of an MPLS CC Message is shown below. The format of an MPLS CC Message is shown below.
0 1 2 3 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 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 BFD CC Code point | |0 0 0 1|Version| Flags | 0xXX BFD CC Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS CC Message Figure 2: MPLS CC Message
3.3. MPLS BFD proactive CV Message format As shown in figure 2, the MPLS CC message consists of the BFD control
packet as defined in [4] pre-pended by the ACh.
3.5. MPLS BFD proactive CV Message format
The format of an MPLS CV Message is shown below. The format of an MPLS CV Message is shown below.
0 1 2 3 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 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 BFD CV Code Point | |0 0 0 1|Version| Flags | 0xXX+1 BFD CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Unique MEP-ID of source of the BFD packet ~ ~ MEP Source ID TLV ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS CV Message Figure 3: MPLS CV Message
As shown in Figure 3, BFD Control packet as defined in [4] is As shown in figure 3, the MPLS CV message consists of the BFD control
transmitted as MPLS labeled packets along with the ACH. Appended to packet as defined in [4] pre-pended by the ACH, and appended by a MEP
the BFD control packet is a MEP Source ID TLV. source ID TLV.
A MEP Source ID TLV is encoded as a 2 octet field that specifies a A MEP Source ID TLV is encoded as a 2 octet field that specifies a
Type, followed by a 2 octet Length Field, followed by a variable Type, followed by a 2 octet Length Field, followed by a variable
length Value field. length Value field. A BFD session will only use one encoding of the
Source ID TLV.
The length in the BFD control packet is as per [4]. There are 3 The length in the BFD control packet is as per [4], the MEP Source ID
Source MEP TLVs (corresponding to the MEP-IDs defined in Error! TLV is not included. There are 3 possible Source MEP TLVs
Reference source not found. [type fields to be assigned by IANA]. The (corresponding to the MEP-IDs defined in [9]) [type fields to be
type fields are: assigned by IANA]. The type fields are:
X1 - ICC encoded MEP-ID X1 - Section MEP-ID
X2 - LSP MEP-ID X2 - LSP MEP-ID
X3 - PW MEP-ID X3 - PW MEP-ID
When GAL label is used, the TTL field of the GAL MUST be set to at When GAL label is used, the time to live (TTL) field of the GAL MUST
least 1, and the GAL will be the end of stack label (S=1). be set to at least 1, and the GAL will be the end of stack label
(S=1).
A node MUST NOT change the value in the MEP Source ID TLV. A node MUST NOT change the value in the MEP Source ID TLV.
When digest based authentication is used, the Source ID TLV MUST NOT When digest based authentication is used, the Source ID TLV MUST NOT
be included in the digest be included in the digest
3.3.1. ICC-based MEP-ID 3.5.1. ICC-based MEP-ID
As defined in [9], the ICC-based MEP_ID consists of the MEG_ID, a ICC based MEP-IDs are for further study.
string of up to 13 characters (A-Z and 0-9), followed by the MEP
Index, an unsigned 16 bit integer that MUST be unique within the
context of the MEG_ID.
3.3.2. LSP MEP-ID 3.5.2. Section MEP-ID
As defined in [9], the MPLS_TP LSP MEP-ID consists of the Node The IP compatible MEP-IDs for MPLS-TP sections is the interface ID.
Identifier, a thirty two bit identifier that MUST be unique within The format of the Section MEP-ID TLV is:
the context of an operator's network, followed by the Tunnel_Num, an
unsigned sixteen bit integer that MUST be unique within the context
of the Node Identifier, and the LSP_NUM, an unsigned sixteen bit
integer that MUST be unique with the context of the Tunnel Num.
3.3.3. PW Endpoint MEP-ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = | Length = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As defined in [9], the PW Endpoint MEP-ID consists of the Node Where the type is of value 'xx' (to be assigned by IANA). The length
Identifier, a thirty two bit identifier that MUST be unique within is the length of the value fields. The MPLS-TP Global ID, Node
the context of an operator's network, followed by the AC_ID, a thirty Identifier and Interface Numbers are as per [9].
two bit identifier that MUST be unique within the context of the Node
Identifier.
In situations where global uniqueness is required, the Node 3.5.3. LSP MEP-ID
Identifier is preceded by the Global ID, a thirty two bit identifier
that contains the two-octet (right hand justified and preceded by
sixteen bits of zero) or four-octet value of the operator's
Autonomous System Number (ASN).
3.4. BFD Session in MPLS-TP terminology The format for the LSP MEP-ID is as defined in [9]. This consists of
32-bit MPLS-TP Global ID, the 32-bit Node Identifier, followed by the
16-bit Tunnel_Num (that MUST be unique within the context of the Node
Identifier), and the 16-bit LSP_NUM (that MUST be unique with the
context of the Tunnel Num). The format of the TLV is:
A BFD session corresponds to a CC or a proactive CV OAM instance in 0 1 2 3
MPLS-TP terminology. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = | Length = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel_Num | LSP_Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A BFD session is enabled when the CC or proactive CV functionality is Where the type is of value 'xx+1' (to be assigned by IANA). The
enabled on a configured Maintenance Entity (ME).. length is the length of the value fields. The MPLS-TP Global ID, Node
Identifier, Tunnel Num and LSP_Num are as per [9].
On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as 3.5.4. PW Endpoint MEP-ID
detailed in [4].
When on a ME the CC or proactive CV functionality is disabled, the The format the MPLS_TP PW Endpoint MEP-ID is as defined in [9]. The
format of the TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = | Length = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | AGI Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the type is value 'xx+2' (to be assigned by IANA). The length
is the length of the following data. The Global ID, Node Identifier
and Attachment Circuit (AC)_ID are as per [9]. The Attachment Group
Identifier (AGI) Type is as per [6], and the AGI length is the length
of the AGI value field.
3.6. BFD Session in MPLS-TP terminology
A BFD session corresponds to a CC and proactive CV OAM instance in
MPLS-TP terminology. A BFD session is enabled when the CC and
proactive CV functionality is enabled on a configured Maintenance
Entity (ME).
When the CC and proactive CV functionality is disabled on an ME, the
BFD session transitions to the ADMIN DOWN State and the BFD session BFD session transitions to the ADMIN DOWN State and the BFD session
ends. ends.
A new BFD session is initiated when the operator enables or re- A new BFD session is initiated when the operator enables or re-
enables the CC or CV functionality on the same ME. enables the CC and CV functionality.
3.5. BFD Profile for MPLS-TP All BFD state changes and P/F exchanges MUST be done using CC
packets. P/F and session state information in CV packets MUST be
ignored.
BFD MUST operate in asynchronous mode. In this mode, the BFD Control 3.7. BFD Profile for MPLS-TP
packets are periodically sent at configurable time rate. This rate is
typically a fixed value for the lifetime of the session. In the rare
circumstance where an operator has a reason to change session
parameters, the session MUST be moved to the ADMIN DOWN state.
Poll/final discipline can only used for VCCV and UDP/IP encapsulated
BFD.
This document specifies bi-directional BFD for p2p transport LSPs, BFD operates in asynchronous mode utilizing the encapsulation defined
hence the M bit MUST be clear. in section 3 for all sessions in a given MEG. For LSPs, SPMEs and
sections this is GAL/G-ACh encapsulated BFD using the code points
specified in section 3.1. For PWs, this is G-ACh encapsulated BFD
using the code points specified in section 3.1. In this mode, the BFD
Control packets are periodically sent at configurable time rate. This
rate is a fixed value common for both directions of MEG for the
lifetime of the MEG.
This document specifies bi-directional BFD for p2p transport LSPs;
hence all BFD packets MUST be sent with the M bit clear.
There are two modes of operation for bi-directional LSPs. One in There are two modes of operation for bi-directional LSPs. One in
which the session state of both directions of the LSP is coordinated which the session state of both directions of the LSP is coordinated
and one constructed from BFD sessions in such a way that the two and one constructed from BFD sessions in such a way that the two
directions operate independently. A single bi-directional BFD session directions operate independently but are still part of the same MEG.
is used for coordinated operation. Two independent BFD sessions are A single bi-directional BFD session is used for coordinated
used for independent operation. operation. Two independent BFD sessions are used for independent
operation. It should be noted that independent operation treats
session state and defect state as independent entities. For example
an independent session can be in the UP state while receiving RDI
indication. For a coordinated session, the session state will track
the defect state.
Coordinated operation is as described in [4]. Independent operation In coordinated mode, an implementation SHOULD NOT reset
requires clarification of two aspects of [4]. Independent operation bfd.RemoteDiscr until it is exiting the DOWN state.
is characterized by the setting of MinRxInterval to zero by the MEP
that is typically the session originator (referred to as the source In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr
MEP), and there will be a session originator at either end of the bi- upon transitioning to the DOWN state.
directional LSP. Each source MEP will have a corresponding sink MEP
that has been configured to a Tx interval of zero. Overall operation is as specified in [4] and augmented for MPLS in
[8]. Coordinated operation is as described in [4]. Independent
operation requires clarification of two aspects of [4]. Independent
operation is characterized by the setting of bfd.MinRxInterval to
zero by the MEP that is typically the session originator (referred to
as the source MEP), and there will be a session originator at either
end of the bi-directional LSP. Each source MEP will have a
corresponding sink MEP that has been configured to a Tx interval of
zero.
The base spec is unclear on aspects of how a MEP with a BFD transmit The base spec is unclear on aspects of how a MEP with a BFD transmit
rate set to zero behaves. One interpretation is that no periodic rate set to zero behaves. One interpretation is that no periodic
messages on the reverse component of the bi-directional LSP originate messages on the reverse component of the bi-directional LSP originate
with that MEP, it will only originate messages on a state change. with that MEP, it will only originate messages on a state change.
The first clarification is that when a state change occurs a MEP set The first clarification is that when a state change occurs a MEP set
to a transmit rate of zero sends BFD control messages with a one to a transmit rate of zero sends BFD control messages with a one
second period on the reverse component until such time that the state second period on the reverse component until such time that the state
change is confirmed by the session peer. At this point the MEP set to change is confirmed by the session peer. At this point the MEP set to
a transmit rate of zero can resume quiescent behavior. This adds a transmit rate of zero can resume quiescent behavior. This adds
robustness to all state transitions in the RxInterval=0 case. robustness to all state transitions in the RxInterval=0 case.
The second is that the originating MEP (the one with a non-zero The second is that the originating MEP (the one with a non-zero
TxInterval) will ignore a DOWN state received from a zero interval bfd.TxInterval) will ignore a DOWN state received from a zero
peer. This means that the zero interval peer will continue to send interval peer. This means that the zero interval peer will continue
DOWN state messages that include the RDI diagnostic code as the state to send DOWN state messages that include the RDI diagnostic code as
change is never confirmed. This adds robustness to the exchange of the state change is never confirmed. This adds robustness to the
RDI indication on a uni-directional failure (for both session types exchange of RDI indication on a uni-directional failure (for both
DOWN with a diagnostic of either control detection period expired or session types DOWN with a diagnostic of either control detection
neighbor signaled session down offering RDI functionality). period expired or neighbor signaled session down offering RDI
functionality).
A further extension to the base specification is that there are A further extension to the base specification is that there are
additional OAM protocol exchanges that act as inputs to the BFD state additional OAM protocol exchanges that act as inputs to the BFD state
machine; these are the Link Down Indication [5] and the Lock machine; these are the Link Down Indication [5] and the Lock
Instruct/Lock Report transactions; Lock Report interaction being Instruct/Lock Report transactions; Lock Report interaction being
optional. optional.
3.5.1. Session initiation 3.7.1. Session initiation and Modification
In all scenarios a BFD session starts with both ends in the DOWN Session initiation occurs starting from MinRx = 1 second, MinTx >= 1
state. DOWN state messages exchanged include the desired Tx and Rx second and the detect multiplier = 3.
rates for the session. If a node cannot support the Min Tx rate Once in the UP state, poll/final discipline is used to modify the
desired by a peer MEP it does not transition from down to the INIT periodicity of control message exchange from their default rates to
state and sends a diagnostic code of configuration error (to be the desired rates and set the detect multiplier to 3.
assigned by IANA) indicating that the requested Tx rate cannot be
supported.
Otherwise once a transition from DOWN to INIT has occurred, the Once the desired rate has been reached using the poll/final
session progresses as per [4]. In both the DOWN and INIT states mechanism, implementations SHOULD NOT attempt further rate
messages are transmitted at a rate of one per second and the defect modification.
detection interval is fixed at 3.5 seconds. On transition to the UP
state, message periodicity changes to the negotiated and/or
configured rate and the detect interval switches to detect multiplier
times the session peer's Tx Rate.
3.5.2. Defect entry criteria In the rare circumstance where an operator has a reason to further
change session parameters, beyond the initial migration from default
values; poll/final discipline can be used with the caveat that a peer
implementation may consider a session change unacceptable and/or
bring the BFD session down.
3.7.2. Defect entry criteria
There are further defect criteria beyond those that are defined in There are further defect criteria beyond those that are defined in
[4] to consider given the possibility of mis-connectivity and mis- [4] to consider given the possibility of mis-connectivity defects.
configuration defects. The result is the criteria for a LSP direction The result is the criteria for a LSP direction to transition from the
to transition from the defect free state to a defect state is a defect free state to a defect state is a superset of that in the BFD
superset of that in the BFD base specification [4]. base specification [4].
The following conditions cause a MEP to enter the defect state for CC The following conditions cause a MEP to enter the defect state for CC
or CV: PDUs:
1. BFD session times out (Loss of Continuity defect). 1. BFD session times out (Loss of Continuity defect).
2. Receipt of a link down indication. 2. Receipt of a link down indication or lock report.
3. Receipt of an unexpected M bit (Session Mis-configuration
defect).
And the following will cause the MEP to enter the defect state for CV And the following will cause the MEP to enter the defect state for CV
operation operation
1. BFD control packets are received with an unexpected 1. BFD control packets are received with an unexpected
encapsulation (mis-connectivity defect), these include: encapsulation (mis-connectivity defect), these include:
- a PW receiving a packet with a GAL - receiving an IP encoded CC or CV BFD control packet on a
- receiving an IP encoded CC or CV packet on a LSP configured LSP configured to use GAL/G-ACh, or vice versa
to use GAL/GaCH, or vice versa
(note there are other possibilities that can also alias as an (note there are other possibilities that can also alias as an
OAM packet) OAM packet)
2. Receipt of an unexpected globally unique Source MEP identifier 2. Receipt of an unexpected globally unique Source MEP identifier
(Mis-connectivity defect). (Mis-connectivity defect). Note that as each encoding of the
3. Receipt of an unexpected session discriminator in the your Source MEP ID TLV contains unique information (there is no
discriminator field (mis-connectivity defect). mechanical translation possible between MEP ID formats), receipt
4. Receipt of an expected session discriminator with an unexpected of an unexpected source MEP ID type is the same as receiving an
label (mis-connectivity defect). unexpected value.
3. Receipt of a session discriminator that is not in the local BFD
database in the your discriminator field (mis-connectivity
defect).
4. Receipt of a session discriminator that is in the local database
but does not have the expected label (mis-connectivity defect).
5. IF BFD authentication is used, receipt of a message with 5. IF BFD authentication is used, receipt of a message with
incorrect authentication information (password, MD5 digest, or incorrect authentication information (password, MD5 digest, or
SHA1 hash). SHA1 hash).
The effective defect hierarchy (order of checking) is The effective defect hierarchy (order of checking) is
1. Receiving nothing. 1. Receiving nothing.
2. Receiving link down indication. 2. Receiving link down indication. E.g. a local link failure, an
MPLS-TP LDI indication, or Lock Report.
3. Receiving from an incorrect source (determined by whatever 3. Receiving from an incorrect source (determined by whatever
means). means).
4. Receiving from a correct source (as near as can be determined), 4. Receiving from a correct source (as near as can be determined),
but with incorrect session information). but with incorrect session information).
5. Receiving control packets in all discernable ways correct. 5. Receiving BFD control packets in all discernable ways correct.
3.5.3. Defect entry consequent action 3.7.3. Defect entry consequent action
Upon defect entry a sink MEP will assert signal fail into any client Upon defect entry a sink MEP will assert signal fail into any client
(sub-)layers. It will also communicate session DOWN to its session (sub-)layers. It will also communicate session DOWN to its session
peer. peer using CC messages.
The blocking of traffic as consequent action MUST be driven only by a The blocking of traffic as a consequent action MUST be driven only by
defect's consequent action as specified in draft-ietf-mpls-tp-oam- a defect's consequent action as specified in draft-ietf-mpls-tp-oam-
framework [11] section 5.1.1.2. framework [11] section 5.1.1.2.
When the defect is mis-branching, the LSP termination will silently
discard all non-oam traffic received.
3.5.4. Defect exit criteria When the defect is mis-connectivity, the LSP termination will
silently discard all non-OAM traffic received. The sink MEP will also
send a defect indication back to the source MEP via the use of a
diagnostic code of mis-connectivity defect.
3.5.4.1. Exit from a Loss of continuity defect 3.7.4. Defect exit criteria
3.7.4.1. Exit from a Loss of continuity defect
For a coordinated session, exit from a loss of connectivity defect is For a coordinated session, exit from a loss of connectivity defect is
as described in figure 4 which updates [4]. as described in figure 4 which updates [4].
For an independent session, exit from a loss of connectivity defect For an independent session, exit from a loss of connectivity defect
occurs upon receipt of a well formed control packet from the peer MEP occurs upon receipt of a well formed BFD control packet from the peer
as described in figures 5 and 6. MEP as described in figures 5 and 6.
3.5.4.2. Exit from a session mis-configuration defect
Exit from a misconfiguration defect occurs when two consecutive CC or
CV frames have been received with the expected M bit setting.
3.5.4.3. Exit from a mis-connectivity defect 3.7.4.2. Exit from a mis-connectivity defect
Exit from a mis-connectivity defect state occurs when no CV messages Exit from a mis-connectivity defect state occurs when no CV messages
have been received with an incorrect source MEP-ID for a period of with mis-connectivity defects have been received for a period of 3.5
3.5 seconds. seconds.
3.5.5. State machines 3.7.5. State machines
The following state machines update [4]. They have been modified to The following state machines update [4]. They have been modified to
include AIS with LDI set and LKI as specified in [5] as inputs to the include AIS with LDI set and LKI as specified in [5] as inputs to the
state machine and to clarify the behavior for independent mode. LKR state machine and to clarify the behavior for independent mode. LKR
is an optional input. is an optional input.
The coordinated session state machine has been augmented to indicate The coordinated session state machine has been augmented to indicate
AIS with LDI set and optionally LKR as inputs to the state machine. AIS with LDI set and optionally LKR as inputs to the state machine.
For a session that is in the UP state, receipt of AIS with LDI set or For a session that is in the UP state, receipt of AIS with LDI set or
optionally LKR will transition the session into the DOWN state. optionally LKR will transition the session into the DOWN state.
skipping to change at page 13, line 24 skipping to change at page 16, line 12
| | ADMIN DOWN,| | | | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| | | |ADMIN DOWN, DOWN,| |
| |TIMER TIMER,| | | |TIMER TIMER,| |
V |AIS-LDI,LKR AIS-LDI,LKR | V V |AIS-LDI,LKR AIS-LDI,LKR | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
Figure 4: State machine for coordinated session operation Figure 4: MPLS CC state machine for coordinated session operation
For independent mode, there are two state machines. One for the For independent mode, there are two state machines. One for the
source MEP (who requested MinRxInterval=0) and the sink MEP (who source MEP (who requested bfd.MinRxInterval=0) and the sink MEP (who
agreed to MinRxInterval=0). agreed to bfd.MinRxInterval=0).
The source MEP will not transition out of the UP state once The source MEP will not transition out of the UP state once
initialized except in the case of a forced ADMIN DOWN. Hence AIS-with initialized except in the case of a forced ADMIN DOWN. Hence AIS-with
LDI set and optionally LKR do not enter into the state machine LDI set and optionally LKR do not enter into the state machine
transition from the UP state, but do enter into the INIT and DOWN transition from the UP state, but do enter into the INIT and DOWN
states. states.
+--+ +--+
| | UP, ADMIN DOWN, TIMER | | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| |ADMIN DOWN ADMIN DOWN | | | |ADMIN DOWN ADMIN DOWN | |
| |TIMER, | | | |TIMER, | |
| |AIS-LDI, | | | |AIS-LDI, | |
skipping to change at page 14, line 20 skipping to change at page 17, line 4
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| |ADMIN DOWN ADMIN DOWN | | | |ADMIN DOWN ADMIN DOWN | |
| |TIMER, | | | |TIMER, | |
| |AIS-LDI, | | | |AIS-LDI, | |
V |LKR | V V |LKR | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN, DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,
+--->| | INIT, UP | |<---+ AIS-LDI, LKR +--->| | INIT, UP | |<---+ AIS-LDI, LKR
+------+ +------+ +------+ +------+
Figure 5: State machine for source MEP for independent session Figure 5: MPLS CC State machine for source MEP for independent
operation session operation
The sink MEP state machine (for which the transmit interval has been The sink MEP state machine (for which the transmit interval has been
set to zero) is modified to: set to zero) is modified to:
1) Permit direct transition from DOWN to UP once the session has been 1) Permit direct transition from DOWN to UP once the session has been
initialized. With the exception of via the ADMIN DOWN state, the initialized. With the exception of via the ADMIN DOWN state, the
source MEP will never transition from the UP state, hence in normal source MEP will never transition from the UP state, hence in normal
unidirectional fault scenarios will never transition to the INIT unidirectional fault scenarios will never transition to the INIT
state. state.
skipping to change at page 15, line 25 skipping to change at page 17, line 41
| |ADMIN DOWN, TIMER, | | | |ADMIN DOWN, TIMER, | |
| |TIMER, DOWN, | | | |TIMER, DOWN, | |
| |AIS-LDI, AIS-LDI, | V | |AIS-LDI, AIS-LDI, | V
V |LKR LKR | | V |LKR LKR | |
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
Figure 6: State machine for the sink MEP for independent session Figure 6: MPLS CC State machine for the sink MEP for independent
operation session operation
3.5.6. Configuration of MPLS-TP BFD sessions 3.7.6. Configuration of MPLS-TP BFD sessions
Configuration of MPLS-TP BFD session paramters and coordination of Configuration of MPLS-TP BFD session parameters and coordination of
same between the source and sink MEPs is out of scope of this memo. same between the source and sink MEPs is out of scope of this memo.
3.5.7. Discriminator values 3.7.7. Discriminator values
In the BFD control packet the discriminator values have either local In the BFD control packet the discriminator values have either local
to the sink MEP or no significance (when not known). to the sink MEP or no significance (when not known).
My Discriminator field MUST be set to a nonzero value (it can be a My Discriminator field MUST be set to a nonzero value (it can be a
fixed value), the transmitted your discriminator value MUST reflect fixed value), the transmitted your discriminator value MUST reflect
back the received value of My discriminator field or be set to 0 if back the received value of My discriminator field or be set to 0 if
that value is not known. that value is not known.
Per RFC5884 Section 7 [8], a node MUST NOT change the value of the Per RFC5884 Section 7 [8], a node MUST NOT change the value of the
"my discriminator" field for an established BFD session. "my discriminator" field for an established BFD session.
4. Configuration Considerations
4. Acknowledgments The following is an exemplary set of configuration parameters for a
BFD session:
Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit Mode and Encapsulation
Sprecher and Yaacov Weingarten also contributed to this RFC 5884 - BFD CC in UDP/IP/LSP
document. RFC 5885 - BFD CC in G-ACh
RFC 5085 - UDP/IP in G-ACh
MPLS-TP - CC/CV in GAL/G-ACh or G-ACh
5. IANA Considerations For MPLS-TP, the following additional parameters need to be
configured:
1) Session mode, coordinated or independent
2) CC periodicity
3) The MEG/MEP ID for the MEPs at either end of the LSP
4) Whether authentication is enabled (and if so, the associated
parameters)
This draft requires the allocation of two channel types from the And the following parameters can optionally be configured or locally
the IANA "PW Associated Channel Type" registry in RFC4446 [6]. assigned:
1) The discriminators used by each MEP. Both bfd.LocalDiscr and
bfd.RemoteDiscr.
Xx MPLS-TP CC message Finally the following is directly inferred:
1) Detect multiplier of 3
Xx+1 MPLS-TP CV message 5. Acknowledgments
Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit Sprecher
and Yaacov Weingarten also contributed to this document.
6. IANA Considerations
This draft requires the allocation of two channel types from the IANA
"PW Associated Channel Type" registry in RFC4446 [6].
XX MPLS-TP CC message
XX+1 MPLS-TP CV message
This draft requires the creations of a source MEP-ID TLV This draft requires the creations of a source MEP-ID TLV
registry with initial values of: registry with initial values of:
Xx - ICC encoded MEP-ID Xx - Section MEP-ID
Xx+1 - LSP MEP-ID Xx+1 - LSP MEP-ID
Xx+2 - PW MEP-ID Xx+2 - PW MEP-ID
The source MEP-ID TLV will require standards action registration The source MEP-ID TLV will require standards action registration
procedures for additional values. procedures for additional values.
This memo requests a code point from the registry for BFD This memo requests a code point from the registry for BFD
diagnostic codes [4]: diagnostic codes [4]:
Xx - configuration error Xx - - misconnectivity defect
6. Security Considerations 7. Security Considerations
Base BFD foresees an optional authentication section (see [4] Base BFD foresees an optional authentication section (see [4]
section 6.7); that can be applied to this application. section 6.7); that can be applied to this application.
7. References 8. References
7.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC [2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC
5586 , June 2009 5586 , June 2009
[3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for [3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for
Operations Administration and Maintenance in MPLS Operations Administration and Maintenance in MPLS
Transport Networks", RFC5860, May 2010 Transport Networks", RFC5860, May 2010
[4] Katz, D. and D. Ward, "Bidirectional Forwarding [4] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", RFC 5880, June 2010 Detection", RFC 5880, June 2010
[5] Swallow, G. et al., "MPLS Fault Management OAM", draft- [5] Swallow, G. et al., "MPLS Fault Management OAM", draft-
ietf-mpls-tp-fault-03 (work in progress), October 2010 ietf-mpls-tp-fault-04 (work in progress), April 2011
[6] Martini, L., " IANA Allocations for Pseudowire Edge to [6] Martini, L., " IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", RFC 4446, April 2006 Edge Emulation (PWE3)", RFC 4446, April 2006
[7] Nadeau, T. et al. "Bidirectional Forwarding Detection [7] Nadeau, T. et al. "Bidirectional Forwarding Detection
(BFD) for the Pseudowire Virtual Circuit Connectivity (BFD) for the Pseudowire Virtual Circuit Connectivity
Verification (VCCV) ", IETF RFC 5885, June 2010 Verification (VCCV) ", IETF RFC 5885, June 2010
[8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection [8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection
(BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884,
June 2010 June 2010
[9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- [9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-
ietf-mpls-tp-identifiers-03 (work in progress), October ietf-mpls-tp-identifiers-06 (work in progress), June 2011
2010
7.2. Informative References 8.2. Informative References
[10] Bocci, M., et al., "A Framework for MPLS in Transport [10] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", RFC5921, July 2010 Networks", RFC5921, July 2010
[11] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- [11] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft-
ietf-mpls-tp-oam-framework-10 (work in progress), December ietf-mpls-tp-oam-framework-11 (work in progress), February
2010 2011
[12] Nadeau, T, et al., "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007
Authors' Addresses Authors' Addresses
Dave Allan Dave Allan
Ericsson Ericsson
Email: david.i.allan@ericsson.com Email: david.i.allan@ericsson.com
John Drake John Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
skipping to change at line 752 skipping to change at page 21, line 38
Alcatel-Lucent Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.com Email: martin.vigoureux@alcatel-lucent.com
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
Email: msiva@cisco.com Email: msiva@cisco.com
David Ward David Ward
Juniper Juniper
Email: dward@juniper.net Email: dward@juniper.net
Robert Rennison
ECI Telecom
Email: robert.rennison@ecitele.com
 End of changes. 108 change blocks. 
255 lines changed or deleted 380 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/