draft-ietf-mpls-tp-cc-cv-rdi-06.txt   rfc6428.txt 
MPLS Working Group Dave Allan, Ed.
Internet Draft Ericsson
Intended status: Standards Track
Expires: February 2012 George Swallow Ed.
Cisco Systems, Inc
John Drake Ed. Internet Engineering Task Force (IETF) D. Allan, Ed.
Request for Comments: 6428 Ericsson
Category: Standards Track G. Swallow, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
J. Drake, Ed.
Juniper Juniper
November 2011
August 2011 Proactive Connectivity Verification, Continuity Check, and
Remote Defect Indication for the MPLS Transport Profile
Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile
draft-ietf-mpls-tp-cc-cv-rdi-06
Abstract Abstract
Continuity Check, Proactive Connectivity Verification and Remote Continuity Check, Proactive Connectivity Verification, and Remote
Defect Indication functionalities are required for MPLS-TP OAM. Defect Indication functionalities are required for MPLS Transport
Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM).
Continuity Check monitors a label switched path for any loss-of- Continuity Check monitors a Label Switched Path for any loss of
continuity defect. Connectivity Verification augments Continuity continuity defect. Connectivity Verification augments Continuity
Check in order to provide confirmation that the desired source is Check in order to provide confirmation that the desired source is
connected to the desired sink. Remote defect indication enables an connected to the desired sink. Remote Defect Indication enables an
End Point to report, to its associated End Point, a fault or defect end point to report, to its associated end point, a fault or defect
condition that it detects on a pseudo wire, label switched path or condition that it detects on a pseudowire, Label Switched Path, or
Section. Section.
This document specifies specific extensions to BFD and methods for This document specifies specific extensions to Bidirectional
proactive Continuity Check, Continuity Verification, and Remote Forwarding Detection (BFD) and methods for proactive Continuity
Defect Indication for MPLS-TP label switched paths, pseudo wires and Check, Continuity Verification, and Remote Defect Indication for
Sections using Bidirectional Forwarding Detection as extended by MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as
this memo. extended by this memo.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1].
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 Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 9th, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6428.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described include Simplified BSD License text as described in Section 4.e of
in Section 4.e of the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided without warranty as
without warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................3
2. Conventions used in this document..............................4 2. Conventions Used in This Document ...............................3
2.1. Terminology..................................................4 2.1. Terminology ................................................3
3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD...........5 2.2. Requirements Language ......................................5
3.1. Existing Capabilities........................................5 3. MPLS-TP CC, Proactive CV, and RDI Mechanism Using BFD ...........5
3.2. CC, CV, and RDI Overview.....................................6 3.1. Existing Capabilities ......................................5
3.3. ACH code points for CC and proactive CV......................7 3.2. CC, CV, and RDI Overview ...................................5
3.4. MPLS-TP BFD CC Message format................................7 3.3. ACH Code Points for CC and Proactive CV ....................6
3.5. MPLS-TP BFD proactive CV Message format......................8 3.4. MPLS-TP BFD CC Message Format ..............................7
3.5.1. Section MEP-ID.............................................9 3.5. MPLS-TP BFD Proactive CV Message Format ....................8
3.5.2. LSP MEP-ID................................................10 3.5.1. Section MEP-ID ......................................9
3.5.3. PW Endpoint MEP-ID........................................10 3.5.2. LSP MEP-ID ..........................................9
3.6. BFD Session in MPLS-TP terminology..........................11 3.5.3. PW End Point MEP-ID ................................10
3.7. BFD Profile for MPLS-TP.....................................12 3.6. BFD Session in MPLS-TP Terminology ........................10
3.7.1. Session initiation and Modification.......................13 3.7. BFD Profile for MPLS-TP ...................................11
3.7.2. Defect entry criteria.....................................13 3.7.1. Session Initiation and Modification ................12
3.7.3. Defect entry consequent action............................15 3.7.2. Defect Entry Criteria ..............................13
3.7.4. Defect exit criteria......................................15 3.7.3. Defect Entry Consequent Action .....................14
3.7.5. State machines............................................15 3.7.4. Defect Exit Criteria ...............................14
3.7.6. Configuration of MPLS-TP BFD sessions.....................18 3.7.5. State Machines .....................................15
3.7.7. Discriminator values......................................18 3.7.6. Configuration of MPLS-TP BFD Sessions ..............17
4. Configuration Considerations..................................18 3.7.7. Discriminator Values ...............................17
5. Acknowledgments...............................................19 4. Configuration Considerations ...................................18
6. IANA Considerations...........................................19 5. IANA Considerations ............................................18
7. Security Considerations.......................................20 6. Security Considerations ........................................19
8. References....................................................20 7. References .....................................................19
8.1. Normative References........................................20 7.1. Normative References ......................................19
8.2. Informative References......................................21 7.2. Informative References ....................................20
8. Acknowledgments ................................................20
9. Contributing Authors ...........................................21
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 Operations, Administration more switches. Service providers need Operations, Administration,
and Maintenance (OAM) tools to detect mis-connectivity and loss-of- and Maintenance (OAM) tools to detect mis-connectivity and loss of
continuity of transport circuits. Both pseudo wires (PWs) and MPLS-TP continuity of transport circuits. Both pseudowires (PWs) and MPLS-TP
label switched paths (LSPs) [12] emulating traditional transport Label Switched Paths (LSPs) [12] emulating traditional transport
circuits need to provide the same Continuity Check (CC), proactive circuits need to provide the same Continuity Check (CC), proactive
Continuity Verification (CV), and Remote Defect Indication (RDI) Continuity Verification (CV), and Remote Defect Indication (RDI)
capabilities as required in RFC 5860[3]. This document describes the capabilities as required in RFC 5860 [3]. This document describes
use of Bidirectional Forwarding Detection (BFD)[4] for CC, proactive the use of Bidirectional Forwarding Detection (BFD) [4] for CC,
CV, and RDI of a PW, LSP or sub-path maintenance entity (SPME) proactive CV, and RDI of a PW, LSP, or Sub-Path Maintenance Entity
between two Maintenance Entity Group End Points (MEPs). (SPME) between two Maintenance Entity Group End Points (MEPs).
As described in [13], CC and CV functions are used to detect loss-of- As described in RFC 6371 [13], CC and CV functions are used to detect
continuity (LOC), and unintended connectivity between two MEPs (e.g. loss of continuity (LOC) and unintended connectivity between two MEPs
mis-merging or mis-connectivity or unexpected MEP). (e.g., mis-merging or mis-connectivity or unexpected MEP).
RDI is an indicator that is transmitted by a MEP to communicate to RDI is an indicator that is transmitted by a MEP to communicate to
its peer MEP that a signal fail condition exists. RDI is only used its peer MEP that a signal fail condition exists. RDI is only used
for bidirectional LSPs and is associated with proactive CC & CV BFD for bidirectional LSPs and is associated with proactive CC and CV BFD
control 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 bidirectional LSPs. Supported
encapsulations include generic alert label (GAL)/generic associated encapsulations include Generic Associated Channel Label (GAL) /
channel (G-ACh), virtual circuit connectivity verification (VCCV) and Generic Associated Channel (G-ACh), Virtual Circuit Connectivity
UDP/IP. Procedures for uni-directional point-to-point (p2p) and Verification (VCCV), and UDP/IP. Procedures for unidirectional
point-to-multipoint (p2mp) LSPs are for further study. point-to-point (P2P) and point-to-multipoint (P2MP) LSPs are for
further study.
This document utilizes identifiers for MPLS-TP systems as defined in This document utilizes identifiers for MPLS-TP systems as defined in
[9]. Work is on-going in the ITU-T to define a globally-unique RFC 6370 [9]. Work is ongoing in the ITU-T to define a globally-
semantic for ITU Carrier Codes (ICCs), and future work may extend unique semantic for ITU Carrier Codes (ICCs), and future work may
this document to utilize ICCs as identifiers for MPLS-TP systems. extend this document to utilize ICCs as identifiers for MPLS-TP
systems.
The mechanisms specified in this document are restricted to BFD The mechanisms specified in this document are restricted to BFD
asynchronous mode. asynchronous mode.
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
CC: Continuity Check
CC: Continuity Check CV: Connectivity Verification
CV: Connectivity Verification GAL: Generic Associated Channel Label
GAL: G-ACh Label G-ACh: Generic Associated Channel
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 LSP: Label Switched Path
LSP: Label Switched Path LSR: Label Switching Router
LSR: Label Switching Router ME: Maintenance Entity
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: Multiprotocol Label Switching
MPLS: Multi-Protocol Label Switching
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 Switched Path MPLS-TP LSP: Unidirectional or bidirectional Label Switched 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
OAM: Operations, Administration, and Maintenance [14] OAM: Operations, Administration, and Maintenance [14]
PW: Pseudo Wire PW: Pseudowire
PDU: Protocol Data Unit PDU: Protocol Data Unit
P/F: Poll-Final P/F: Poll/Final
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 2.2. Requirements Language
3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD 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].
This document describes procedures for achieve combined CC, CV and 3. MPLS-TP CC, Proactive CV, and RDI Mechanism Using BFD
RDI functionality within a single MPLS-TP MEG using BFD. This
This document describes procedures for achieve combined CC, CV, and
RDI functionality within a single MPLS-TP MEG using BFD. This
augments the capabilities that can be provided for MPLS-TP LSPs using augments the capabilities that can be provided for MPLS-TP LSPs using
existing specified tools and procedures. existing specified tools and procedures.
3.1. Existing Capabilities 3.1. Existing Capabilities
A CC-only mode may be provided via protocols and procedures described A CC-only mode may be provided via protocols and procedures described
in RFC 5885[7] with ACH channel 7. These procedures may be applied to in RFC 5885 [7] with ACH channel 7. These procedures may be applied
bi-directional LSPs (via the use of the GAL), as well as PWs. to bidirectional LSPs (via the use of the GAL) as well as PWs.
Implementations may also interoperate with legacy equipment by Implementations may also interoperate with legacy equipment by
implementing RFC 5884[8] for LSPs and RFC 5085[10] for PWs, in implementing RFC 5884 [8] for LSPs and RFC 5085 [10] for PWs, in
addition to the procedures documented in this memo. In accordance addition to the procedures documented in this memo. In accordance
with RFC 5586[2], when BFD control packets are encapsulated in an IP with RFC 5586 [2], when BFD control packets are encapsulated in an IP
header, the fields in the IP header are set as defined in RFC header, the fields in the IP header are set as defined in RFC 5884
5884[8]. When IP encapsulation is used CV mis-connectivity defect [8]. When IP encapsulation is used, CV mis-connectivity defect
detection can be performed by inferring a globally unique source on detection can be performed by inferring a globally unique source on
the basis of the combination of the source IP address and My the basis of the combination of the source IP address and My
Discriminator" fields. Discriminator fields.
3.2. CC, CV, and RDI Overview 3.2. CC, CV, and RDI Overview
The combined CC, CV, and RDI functionality for MPLS-TP is achieved by The combined CC, CV, and RDI functionality for MPLS-TP is achieved by
multiplexing CC and CV PDUs within a single BFD session. The CV PDUs multiplexing CC and CV PDUs within a single BFD session. The CV PDUs
are augmented with a source MEP ID TLV to permit mis-connectivity are augmented with a Source MEP-ID TLV to permit mis-connectivity
detection to be performed by sink MEPs. detection to be performed by sink MEPs.
The interleaving of PDUs is achieved via the use of distinct The interleaving of PDUs is achieved via the use of distinct
encapsulations and code points for generic associated channel (G-ACh) encapsulations and code points for generic associated channel (G-ACh)
encapsulated BFD depending on whether the PDU format is CC or CV: encapsulated BFD depending on whether the PDU format is CC or CV:
o CC format: defines a new code point in the Associated Channel o CC format: defines a new code point in the Associated Channel
Header (ACH) described in RFC 5586[2].This format supports Header (ACH) described in RFC 5586 [2]. This format supports
Continuity Check and RDI functionalities. Continuity Check and RDI functionalities.
o CV format: defines a new code point in the Associated Channel o CV format: defines a new code point in the Associated Channel
Header (ACH) described in RFC 5586[2]. The ACH with "MPLS-TP Header (ACH) described in RFC 5586 [2]. The ACH with "MPLS-TP
Proactive CV" code point indicates that the message is an MPLS-TP Proactive CV" code point indicates that the message is an MPLS-TP
BFD proactive CV message, and information for CV processing is BFD proactive CV message, and information for CV processing is
appended in the form of the source MEP ID TLV. appended in the form of the Source MEP-ID TLV.
RDI is communicated via the BFD diagnostic field in BFD CC messages, RDI is communicated via the BFD diagnostic field in BFD CC messages,
and the diagnostic code field in CV messages MUST be ignored. It is and the diagnostic code field in CV messages MUST be ignored. It is
not a distinct PDU. As per [4], a sink MEP SHOULD encode a diagnostic not a distinct PDU. As per [4], a sink MEP SHOULD encode a
code of "1 - Control detection time expired" when the interval times diagnostic code of "1 - Control Detection Time Expired" when the time
detect multiplier have been exceeded. A sink MEP SHOULD encode a since the last received BFD control packet exceeds the detection
diagnostic code of "5 - Path Down" as a consequence of the sink MEP time, which is equal to the remote system's Transmit Interval
receiving LDI. A sink MEP MUST encode a diagnostic code of "XX - - multiplied by the remote system's Detect Multiplier (which is set to
Misconnectivity defect" (to be assigned by IANA) when CV PDU 3 in this document). A sink MEP SHOULD encode a diagnostic code of
processing indicates a misconnectivity defect. A sink MEP that has "5 - Path Down" as a consequence of the sink MEP receiving LDI. A
started sending diagnostic code 5 SHOULD NOT change it to 1 when the sink MEP MUST encode a diagnostic code of "9 - mis-connectivity
detection timer expires. defect" when CV PDU processing indicates a mis-connectivity defect.
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 3.3. ACH Code Points for CC and Proactive CV
Figure 1 illustrates the G-ACh encoding for BFD CC-CV-RDI Figure 1 illustrates the G-ACh encoding for BFD CC-CV-RDI
functionality. functionality.
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 | BFD CC/CV Code Point | |0 0 0 1|Version| Flags | BFD CC/CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP CC/CV/RDI Figure 1: ACH Indication of MPLS-TP CC/CV/RDI
The first nibble (0001b) indicates the G-ACh as per RFC 5586[2]. The first nibble (0001b) indicates the G-ACh as per RFC 5586 [2].
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 = XX1. [XX1 to be assigned by IANA from the PW - BFD CC code point = 0x0022, or
Associated Channel Type registry.] or,
- BFD proactive CV code point = XX2. [XX2 to be assigned by IANA from - BFD proactive CV code point = 0x0023.
the PW Associated Channel Type registry.]
CC and CV PDUs apply to all pertinent MPLS-TP structures, including CC and CV PDUs apply to all pertinent MPLS-TP structures, including
PWs, MPLS LSPs (including SPMEs), and Sections. PWs, MPLS LSPs (including SPMEs), and Sections.
CC and CV operation is simultaneously employed on a maintenance CC and CV operations are simultaneously employed on a maintenance
entity (ME) within a single BFD session. The expected usage is that entity (ME) within a single BFD session. The expected usage is that
normal operation is to send CC BFD protocol data units (PDUs) normal operation is to send CC BFD protocol data units (PDUs)
interleaved with a CV BFD PDU (augmented with a source MEP-ID and interleaved with a CV BFD PDU (augmented with a Source MEP-ID and
identified as requiring additional processing by the different ACh identified as requiring additional processing by the different ACh
channel type). The insertion interval for CV PDUs is one per second. channel types). The insertion interval for CV PDUs is one per
Detection of a loss-of-continuity defect is the detect multiplier second. Detection of a loss of continuity defect occurs when the
(fixed at 3 for the CC code point) times the session periodicity. time since the last received BFD control packet exceeds the detection
time, which is equal to the session periodicity times the remote
system's Detect Multiplier (which is set to 3 for the CC code point).
Mis-connectivity defects are detected in a maximum of one second. Mis-connectivity defects are detected in a maximum of one second.
3.4. MPLS-TP BFD CC Message format
The format of an MPLS-TP CC Message is shown below. 3.4. MPLS-TP BFD CC Message Format
The format of an MPLS-TP 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 0 1|Version| Flags | BFD CC Code point | 0 0 1|Version| Flags | BFD CC Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | ~ BFD Control Packet ~ |
~ BFD Control Packet ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP CC Message Figure 2: MPLS-TP CC Message
As shown in figure 2, the MPLS-TP CC message consists of the BFD As shown in Figure 2, the MPLS-TP CC message consists of the BFD
control packet as defined in [4] pre-pended by the G-ACh. control packet as defined in [4] pre-pended by the G-ACh.
3.5. MPLS-TP BFD proactive CV Message format 3.5. MPLS-TP BFD Proactive CV Message Format
The format of an MPLS-TP CV Message is shown below. The format of an MPLS-TP 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 | BFD CV Code Point | |0 0 0 1|Version| Flags | BFD CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ MEP Source ID TLV ~ ~ Source MEP-ID TLV ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS-TP CV Message Figure 3: MPLS-TP CV Message
As shown in figure 3, the MPLS-TP CV message consists of the BFD As shown in Figure 3, the MPLS-TP CV message consists of the BFD
control packet as defined in [4] pre-pended by the ACH, and appended control packet as defined in [4], pre-pended by the ACH and appended
by a MEP source ID TLV. by a Source MEP-ID TLV.
A MEP Source ID TLV is encoded as a 2 octet field that specifies a A Source MEP-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. A BFD session will only use one encoding of the length Value field. A BFD session will only use one encoding of the
Source ID TLV. Source ID TLV.
The length in the BFD control packet is as per [4]; the length of the The length in the BFD control packet is as per [4]; the length of the
MEP Source ID TLV is not included. There are 3 possible Source MEP Source MEP-ID TLV is not included. There are three possible Source
TLVs (corresponding to the MEP-IDs defined in [9]) [type fields to be MEP TLVs (corresponding to the MEP-IDs defined in [9]). The type
assigned by IANA]. The type fields are: fields are:
X1 - Section MEP-ID 0 - Section MEP-ID
X2 - LSP MEP-ID 1 - LSP MEP-ID
X3 - PW MEP-ID 2 - PW MEP-ID
When GAL label is used, the time to live (TTL) field of the GAL MUST When the GAL is used, the TTL field of the GAL MUST be set to at
be set to at least 1, and the GAL MUST be the end of stack label least 1, and the GAL MUST be the end of stack label (S=1) as per [2].
(S=1) as per [2].
A node MUST NOT change the value in the MEP Source ID TLV. A node MUST NOT change the value in the Source MEP-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.5.1. Section MEP-ID 3.5.1. Section MEP-ID
The IP compatible MEP-IDs for MPLS-TP sections is the interface ID. The IP-compatible MEP-ID for MPLS-TP Sections is the interface ID.
The format of the Section MEP-ID TLV is: The format of the Section MEP-ID TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID | | MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier | | MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number | | MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Section MEP-ID TLV format Figure 4: Section MEP-ID TLV Format
Where the type is of value 'X1' (to be assigned by IANA). The length Where the Type is of value '0'. The Length is the length of the
is the length of the value fields. The MPLS-TP Global ID, Node value fields. The MPLS-TP Global_ID, Node Identifier, and Interface
Identifier and Interface Numbers are as per [9]. Numbers are as per [9].
3.5.2. LSP MEP-ID 3.5.2. LSP MEP-ID
The fields for the LSP MEP-ID is as defined in [9]. This is The fields for the LSP MEP-ID are as defined in [9]. This is
applicable to both LSPs and SPMEs. This consists of 32-bit MPLS-TP applicable to both LSPs and SPMEs. This consists of the 32-bit MPLS-
Global ID, the 32-bit Node Identifier, followed by the 16-bit 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 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 Identifier), and the 16-bit LSP_NUM (that MUST be unique within the
context of the Tunnel Num). The format of the TLV is: context of the Tunnel_Num). The format of the TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID | | MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier | | MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel_Num | LSP_Num | | Tunnel_Num | LSP_Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: LSP MEP-ID TLV format Figure 5: LSP MEP-ID TLV Format
Where the type is of value 'X2' (to be assigned by IANA). The length Where the type is of value '1'. The length is the length of the
is the length of the value fields. The MPLS-TP Global ID, Node value fields. The MPLS-TP Global_ID, Node Identifier, Tunnel_Num,
Identifier, Tunnel Num and LSP_Num are as per [9]. and LSP_Num are as per [9].
3.5.3. PW Endpoint MEP-ID 3.5.3. PW End Point MEP-ID
The fields for the MPLS-TP PW Endpoint MEP-ID is as defined in [9]. The fields for the MPLS-TP PW End Point MEP-ID are as defined in [9].
The format of the TLV is: The format of the TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID | | MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier | | MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC_ID | | AC_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | AGI Length | AGI Value | | AGI Type | AGI Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~ ~ AGI Value (contd.) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: PW Endpoint MEP-ID TLV format Figure 6: PW End Point MEP-ID TLV Format
Where the type is value 'X3' (to be assigned by IANA). The length is Where the type is value '2'. The length is the length of the
the length of the following data. The Global ID, Node Identifier and following data: the Global_ID, Node Identifier, and Attachment
Attachment Circuit (AC)_ID are as per [9]. The Attachment Group Circuit ID (AC_ID) are as per [9]. The Attachment Group Identifier
Identifier (AGI) Type is as per [6], and the AGI length is the length (AGI) Type is as per [6], and the AGI Length is the length of the AGI
of the AGI value field. value field.
3.6. BFD Session in MPLS-TP terminology 3.6. BFD Session in MPLS-TP Terminology
A BFD session corresponds to a CC and proactive CV OAM instance in 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 MPLS-TP terminology. A BFD session is enabled when the CC and
proactive CV functionality is enabled on a configured Maintenance proactive CV functionality are enabled on a configured Maintenance
Entity (ME). Entity (ME).
When the CC and proactive CV functionality is disabled on an ME, the When the CC and proactive CV functionality are 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
enables the CC and CV functionality. re-enables the CC and CV functionality.
All BFD state changes and P/F exchanges MUST be done using CC 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 packets. P/F and session state information in CV packets MUST be
ignored. ignored.
3.7. BFD Profile for MPLS-TP 3.7. BFD Profile for MPLS-TP
BFD operates in asynchronous mode utilizing the encapsulation defined BFD operates in asynchronous mode utilizing the encapsulation defined
in section 3 for all sessions in a given MEG. For LSPs, SPMEs and 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 Sections, this is GAL/G-ACh-encapsulated BFD using the code points
specified in section 3.3. For PWs, this is G-ACh or GAL/G-ACh specified in Section 3.3. For PWs, this is G-ACh or GAL/G-ACh-
encapsulated BFD using the code points specified in section 3.3. In encapsulated BFD using the code points specified in Section 3.3. In
this mode, the BFD Control packets are periodically sent at this mode, the BFD control packets are periodically sent at a
configurable time rate. This rate is a fixed value common for both configurable time rate. This rate is a fixed value common for both
directions of MEG for the lifetime of the MEG. directions of MEG for the lifetime of the MEG.
This document specifies bi-directional BFD for p2p transport LSPs; This document specifies bidirectional BFD for P2P transport LSPs;
hence all BFD packets MUST be sent with the M bit clear. 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 bidirectional LSPs: one in which
which the session state of both directions of the LSP is coordinated the session state of both directions of the LSP is coordinated, and
and one constructed from BFD sessions in such a way that the two one constructed from BFD sessions in such a way that the two
directions operate independently but are still part of the same MEG. directions operate independently but are still part of the same MEG.
A single bi-directional BFD session is used for coordinated A single bidirectional BFD session is used for coordinated operation.
operation. Two independent BFD sessions are used for independent Two independent BFD sessions are used for independent operation. It
operation. It should be noted that independent operation treats should be noted that independent operation treats session state and
session state and defect state as independent entities. For example defect state as independent entities. For example, an independent
an independent session can be in the UP state while receiving RDI session can be in the UP state while receiving RDI. For a
indication. For a coordinated session, the session state will track coordinated session, the session state will track the defect state.
the defect state.
In coordinated mode, an implementation SHOULD NOT reset In coordinated mode, an implementation SHOULD NOT reset
bfd.RemoteDiscr until it is exiting the DOWN state. bfd.RemoteDiscr until it is exiting the DOWN state.
In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr
upon transitioning to the DOWN state. upon transitioning to the DOWN state.
Overall operation is as specified in [4] and augmented for MPLS in Overall operation is as specified in RFC 5880 [4] and augmented for
[8]. Coordinated operation is as described in [4]. Independent MPLS in RFC 5884 [8]. Coordinated operation is as described in [4].
operation requires clarification of two aspects of [4]. Independent Independent operation requires clarification of two aspects of [4].
operation is characterized by the setting of bfd.MinRxInterval to Independent operation is characterized by the setting of
zero by the MEP that is typically the session originator (referred to bfd.MinRxInterval to zero by the MEP that is typically the session
as the source MEP), and there will be a session originator at either originator (referred to as the source MEP), and there will be a
end of the bi-directional LSP. Each source MEP will have a session originator at either end of the bidirectional LSP. Each
corresponding sink MEP that has been configured to a Tx interval of source MEP will have a corresponding sink MEP that has been
zero. configured to a transmission interval of zero.
This memo specifies a preferred interpretation of the base spec on This memo specifies a preferred interpretation of the base
how a MEP with a BFD transmit rate set to zero behaves. One specification on how a MEP behaves with a BFD transmit rate set to
interpretation is that no periodic messages on the reverse component zero. One interpretation is that no periodic messages on the reverse
of the bi-directional LSP originate with that MEP, it will only component of the bidirectional LSP originate with that MEP; it will
originate messages on a state change. 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
to a transmit rate of zero sends BFD control messages with a one set 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
a transmit rate of zero can resume quiescent behavior. This adds to 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 clarification is that the originating MEP (the one with a
bfd.TxInterval) will ignore a DOWN state received from a zero non-zero bfd.TxInterval) will ignore a DOWN state received from a
interval peer. This means that the zero interval peer will continue zero-interval peer. This means that the zero-interval peer will
to send DOWN state messages that include the RDI diagnostic code as continue to send DOWN state messages that include the RDI diagnostic
the state change is never confirmed. This adds robustness to the code as the state change is never confirmed. This adds robustness to
exchange of RDI indication on a uni-directional failure (for both the exchange of RDI on a unidirectional failure (for both session
session types DOWN with a diagnostic of either control detection types DOWN with a diagnostic of either control detection period
period expired or neighbor signaled session down offering RDI expired or neighbor signaled session down offering RDI
functionality). 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, the Lock Report interaction being
optional. optional.
3.7.1. Session initiation and Modification 3.7.1. Session Initiation and Modification
Session initiation occurs starting from MinRx = 1 second, MinTx >= 1 Session initiation occurs starting from MinRx = 1 second, MinTx >= 1
second and the detect multiplier = 3. second, and the detect multiplier = 3.
Once in the UP state, poll/final discipline is used to modify the
Once in the UP state, Poll/Final discipline is used to modify the
periodicity of control message exchange from their default rates to periodicity of control message exchange from their default rates to
the desired rates and set the detect multiplier to 3. the desired rates and to set the detect multiplier to 3.
Once the desired rate has been reached using the poll/final
Note that in the Poll/Final process a receiver of a new timer value
with a poll flag can reject the timer value by tearing the session,
or it can return its preferred timer value with the final flag. Note
also that the receiver of a new timer value with a final flag can
reject the timer value by tearing the session, or it can return its
preferred timer value with the poll flag.
Once the desired rate has been reached using the Poll/Final
mechanism, implementations SHOULD NOT attempt further rate mechanism, implementations SHOULD NOT attempt further rate
modification. modification.
In the rare circumstance where an operator has a reason to further In the rare circumstance where an operator has a reason to further
change session parameters, beyond the initial migration from default change session parameters, beyond the initial migration from default
values; poll/final discipline can be used with the caveat that a peer values, Poll/Final discipline can be used with the caveat that a peer
implementation may consider a session change unacceptable and/or implementation may consider a session change unacceptable and/or
bring the BFD session down via the use of the ADMIN DOWN state. bring the BFD session down via the use of the ADMIN DOWN state.
3.7.2. Defect entry criteria 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 defects. [4] to consider given the possibility of mis-connectivity defects.
The result is the criteria for a LSP direction to transition from the The result is the criteria for an LSP direction to transition from
defect free state to a defect state is a superset of that in the BFD the defect-free state to a defect state is a superset of that in the
base specification [4]. BFD 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
PDUs (in no particular order): PDUs (in no particular order):
1. BFD session times out (loss-of-continuity defect).
2. Receipt of a link down indication or lock report.
And the following will cause the MEP to enter the mis-connectivity 1. BFD session times out (loss of continuity defect).
defect state for CV operation (again not in any particular order):
1. BFD control packets are received with an unexpected
encapsulation (mis-connectivity defect), these include:
- receiving an IP encoded CC or CV BFD control packet on a
LSP configured to use GAL/G-ACh, or vice versa
(note there are other possibilities that can also alias as an
OAM packet)
2. Receipt of an unexpected globally unique Source MEP identifier
(Mis-connectivity defect). Note that as each encoding of the
Source MEP ID TLV contains unique information (there is no
mechanical translation possible between MEP ID formats), receipt
of an unexpected source MEP ID type is the same as receiving an
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
incorrect authentication information (password, MD5 digest, or
SHA1 hash).
The effective defect hierarchy (order of checking) is 2. Receipt of a Link Down Indication or Lock Report.
1. Receiving nothing. The following will cause the MEP to enter the mis-connectivity defect
state for CV operation (again, not in any particular order):
2. Receiving link down indication. E.g. a local link failure, an 1. BFD control packets are received with an unexpected
MPLS-TP LDI indication, or Lock Report. encapsulation (mis-connectivity defect), these include:
3. Receiving from an incorrect source (determined by whatever - receiving an IP encoded CC or CV BFD control packet on an
means). LSP configured to use GAL/G-ACh, or
- vice versa
(Note there are other possibilities that can also alias as an
OAM packet.)
4. Receiving from a correct source (as near as can be determined), 2. Receipt of an unexpected globally unique Source MEP identifier
but with incorrect session information). (mis-connectivity defect). Note that as each encoding of the
Source MEP-ID TLV contains unique information (there is no
mechanical translation possible between MEP-ID formats),
receipt of an unexpected Source MEP-ID type is the same as
receiving an unexpected value.
5. Receiving BFD control packets in all discernable ways correct. 3. Receipt of a session discriminator that is not in the local BFD
database in the Your Discriminator field (mis-connectivity
defect).
3.7.3. Defect entry consequent action 4. Receipt of a session discriminator that is in the local
database but does not have the expected label (mis-connectivity
defect).
Upon defect entry a sink MEP will assert signal fail into any client 5. If BFD authentication is used, receipt of a message with
(sub-)layers. It will also communicate session DOWN to its session incorrect authentication information (password, MD5 digest, or
SHA1 hash).
The effective defect hierarchy (order of checking) is:
1. Receiving nothing.
2. Receiving Link Down Indication, e.g., a local link failure, an
MPLS-TP LDI, or Lock Report.
3. Receiving from an incorrect source (determined by whatever
means).
4. Receiving from a correct source (as near as can be determined),
but with incorrect session information.
5. Receiving BFD control packets in all discernable ways correct.
3.7.3. Defect Entry Consequent Action
Upon defect entry, a sink MEP will assert signal fail into any client
(sub-)layers. It will also communicate session DOWN to its session
peer using CC messages. peer using CC messages.
The blocking of traffic as a consequent action MUST be driven only by The blocking of traffic as a consequent action MUST be driven only by
a defect's consequent action as specified in [13] section 5.1.1.2. a defect's consequent action as specified in Section 5.1.1.2 of RFC
6371 [13].
When the defect is mis-connectivity, the section, LSP or PW When the defect is mis-connectivity, the Section, LSP, or PW
termination will silently discard all non-OAM traffic received. The termination will silently discard all non-OAM traffic received. The
sink MEP will also send a defect indication back to the source MEP sink MEP will also send a defect indication back to the source MEP
via the use of a diagnostic code of mis-connectivity defect to be via the use of a diagnostic code of mis-connectivity defect (9).
assigned by IANA.
3.7.4. Defect exit criteria 3.7.4. Defect Exit Criteria
3.7.4.1. Exit from a loss-of-continuity defect 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 7 which updates [4]. as described in Figure 7, which updates RFC 5880 [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 BFD control packet from the peer occurs upon receipt of a well-formed BFD control packet from the peer
MEP as described in figures 8 and 9. MEP as described in Figures 8 and 9.
3.7.4.2. 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
with mis-connectivity defects have been received for a period of 3.5 with mis-connectivity defects have been received for a period of 3.5
seconds. seconds.
3.7.5. State machines 3.7.5. State Machines
The following state machines update [4]. They have been modified to The following state machines update RFC 5880 [4]. They have been
include LDI and LKR as specified in [5] as inputs to the state modified to include LDI and LKR as specified in [5] as inputs to the
machine and to clarify the behavior for independent mode. LKR is an state machine and to clarify the behavior for independent mode. LKR
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
LDI and optionally LKR as inputs to the state machine. For a session LDI and optionally LKR as inputs to the state machine. For a session
that is in the UP state, receipt of LDI or optionally LKR will that is in the UP state, receipt of LDI or optionally LKR will
transition the session into the DOWN state. transition the session into the DOWN state.
+--+ +--+
| | UP, ADMIN DOWN, TIMER, LDI, LKR | | UP, ADMIN DOWN, TIMER, LDI, LKR
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | MISCONNECTIVITY,| | | | MIS-CONNECTIVITY,| |
| | ADMIN DOWN,| | | | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| | | |ADMIN DOWN, DOWN,| |
| |TIMER TIMER,| | | |TIMER TIMER,| |
V |LDI,LKR LDI,LKR | V V |LDI,LKR LDI,LKR | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
Figure 7: MPLS CC state machine for coordinated session operation Figure 7: 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 (which requested bfd.MinRxInterval=0) and the sink MEP source MEP (which requested bfd.MinRxInterval=0) and one for the sink
(which agreed to bfd.MinRxInterval=0). MEP (which 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 LDI and initialized except in the case of a forced ADMIN DOWN. Hence, LDI
optionally LKR do not enter into the state machine transition from and optionally LKR do not enter into the state machine transition
the UP state, but do enter into the INIT and DOWN states. from the UP state, but do enter into the INIT and DOWN states.
+--+ +--+
| | UP, ADMIN DOWN, TIMER, LDI, LKR | | UP, ADMIN DOWN, TIMER, LDI, LKR
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| |ADMIN DOWN ADMIN DOWN | | | |ADMIN DOWN ADMIN DOWN | |
| |TIMER, | | | |TIMER, | |
| |LDI, | | | |LDI, | |
V |LKR | V V |LKR | V
+------+ +------+ +------+ +------+
skipping to change at page 17, line 20 skipping to change at page 16, line 24
| |ADMIN DOWN ADMIN DOWN | | | |ADMIN DOWN ADMIN DOWN | |
| |TIMER, | | | |TIMER, | |
| |LDI, | | | |LDI, | |
V |LKR | V V |LKR | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN, DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,
+--->| | INIT, UP | |<---+ LDI, LKR +--->| | INIT, UP | |<---+ LDI, LKR
+------+ +------+ +------+ +------+
Figure 8: MPLS CC State machine for source MEP for independent Figure 8: MPLS CC State Machine for Source MEP for
session operation Independent 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
unidirectional fault scenarios will never transition to the INIT normal unidirectional fault scenarios, it will never transition to
state. the INIT state.
+--+ +--+
| | ADMIN DOWN, TIMER, LDI, LKR | | ADMIN DOWN, TIMER, LDI, LKR
| V | V
DOWN +------+ INIT, UP DOWN +------+ INIT, UP
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | MISCONNECTIVITY,| | | | MIS-CONNECTIVITY,| |
| | ADMIN DOWN,| | | | ADMIN DOWN,| |
| |ADMIN DOWN, TIMER, | | | |ADMIN DOWN, TIMER, | |
| |TIMER, DOWN, | | | |TIMER, DOWN, | |
| |LDI, LDI, | V | |LDI, LDI, | V
V |LKR LKR | | V |LKR LKR | |
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
Figure 9: MPLS CC State machine for the sink MEP for independent Figure 9: MPLS CC State Machine for the Sink MEP
session operation for Independent Session Operation
3.7.6. Configuration of MPLS-TP BFD sessions 3.7.6. Configuration of MPLS-TP BFD Sessions
Configuration of MPLS-TP BFD session parameters and coordination of The configuration of MPLS-TP BFD session parameters and the
same between the source and sink MEPs is out of scope of this memo. coordination of the same between the source and sink MEPs are out of
scope of this memo.
3.7.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 either are local
to the sink MEP or no significance (when not known). to the sink MEP or have no significance (when not known).
My Discriminator field MUST be set to a nonzero value (it can be a The My Discriminator field MUST be set to a non-zero value (which can
fixed value), the transmitted Your Discriminator value MUST reflect be a fixed value). The transmitted Your Discriminator value MUST
back the received value of My Discriminator field or be set to 0 if reflect back the received value of the My Discriminator field or be
that value is not known. set to zero if that value is not known.
Per RFC5884 Section 7 [8], a node MUST NOT change the value of the My Per Section 7 of RFC 5884 [8], a node MUST NOT change the value of
Discriminator" field for an established BFD session. the My Discriminator field for an established BFD session.
4. Configuration Considerations 4. Configuration Considerations
The following is an example set of configuration parameters for a BFD The following is an example set of configuration parameters for a BFD
session: session:
Mode and Encapsulation Mode and Encapsulation
----------------------
RFC 5884 - BFD CC in UDP/IP/LSP RFC 5884 - BFD CC in UDP/IP/LSP
RFC 5885 - BFD CC in G-ACh RFC 5885 - BFD CC in G-ACh
RFC 5085 - UDP/IP in G-ACh RFC 5085 - UDP/IP in G-ACh
MPLS-TP - CC/CV in GAL/G-ACh or G-ACh MPLS-TP - CC/CV in GAL/G-ACh or G-ACh
For MPLS-TP, the following additional parameters need to be For MPLS-TP, the following additional parameters need to be
configured: configured:
1) Session mode, coordinated or independent 1) Session mode, coordinated or independent
2) CC periodicity 2) CC periodicity
3) The MEP ID for the MEPs at either end of the LSP 3) The MEP-ID for the MEPs at either end of the LSP
4) Whether authentication is enabled (and if so, the associated 4) Whether authentication is enabled (and if so, the associated
parameters) parameters)
And the the discriminators used by each MEP, both bfd.LocalDiscr and The discriminators used by each MEP, both bfd.LocalDiscr and
bfd.RemoteDiscr can optionally be configured or locally assigned. bfd.RemoteDiscr, can optionally be configured or locally assigned.
Finally a detect multiplier of 3 is directly inferred from the code Finally, a detect multiplier of 3 is directly inferred from the code
points. points.
5. Acknowledgments 5. IANA Considerations
Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher and Yaacov IANA has allocated two channel types from the "Pseudowire Associated
Weingarten also contributed to this document. Channel Types" registry in RFC 4385 [15].
6. IANA Considerations 0x0022 MPLS-TP CC message
0x0023 MPLS-TP CV message
This draft requires the allocation of two channel types from the IANA IANA has created a "CC/CV MEP-ID TLV" registry. The parent registry
"PW Associated Channel Type" registry in RFC4446 [6]. is the "Pseudowire Associated Channel Types" registry of RFC 4385
XX1 MPLS-TP CC message [15]. All code points within this registry shall be allocated
XX2 MPLS-TP CV message according to the "Standards Action" procedures as specified in [11].
This draft requires the creations of a source MEP-ID TLV The items tracked in the registry will be the type, associated name,
registry. The parent registry will be the "PW Associated Channel and reference.
Type" registry of RFC4446 [6]. All code points within this
registry shall be allocated according to the "Standards Action"
procedures as specified in [11].
The initial values are: The initial values are:
X1 - Section MEP-ID 0 - Section MEP-ID
1 - LSP MEP-ID
X2 - LSP MEP-ID 2 - PW MEP-ID
X3 - PW MEP-ID
The items tracked in the registry will be the type, and the
associated name and reference. The source MEP-ID TLV will require
standards action registration procedures for additional values.
This memo requests a code point from the registry for BFD IANA has assigned the following code point from the "Bidirectional
diagnostic codes [4]: Forwarding Detection (BFD) Parameters" registry, "BFD Diagnostic
Codes" subregistry [4]:
XX - - mis-connectivity defect 9 - mis-connectivity defect
7. Security Considerations 6. Security Considerations
The use of CV improves network integrity by ensuring traffic is The use of CV improves network integrity by ensuring traffic is not
not "leaking" between LSPs. "leaking" between LSPs.
Base BFD foresees an optional authentication section (see [4] Base BFD foresees an optional authentication section (see Section 6.7
section 6.7); that can be applied to this application. Although of [4]) that can be applied to this application. Although the Source
the source MEP-ID TLV is not included in the BFD authentication MEP-ID TLV is not included in the BFD authentication digest, there is
digest, there is a chain of trust such that the discriminator a chain of trust such that the discriminator associated with the
associated with the digest is also associated with the expected digest is also associated with the expected MEP-ID; this will prevent
MEP-ID which will prevent impersonation of CV messages in this impersonation of CV messages in this application.
application.
This memo specifies the use of globally unique identifiers for This memo specifies the use of globally unique identifiers for MEP-
MEP IDs. This provides absolutely authoritative detection of IDs. This provides absolutely authoritative detection of persistent
persistent leaking of traffic between LSPs. Non-uniqueness can leaking of traffic between LSPs. Non-uniqueness can result in
result in undetected leaking in the scenario where two LSPs with undetected leaking in the scenario where two LSPs with common MEP-IDs
common MEP IDs are misconnected. This would be considered to be are misconnected. This would be considered undesirable but rare; it
undesirable but rare, it would also be difficult to exploit for would also be difficult to exploit for malicious purposes as, at a
malicious purposes as at a minimum, both a network end point, minimum, both a network end point and a node that was a transit point
and a node that was a transit point for the target MEG would for the target MEG would need to be compromised.
need to be compromised.
8. References 7. References
8.1. Normative References 7.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
Requirement Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Bocci, M. et al., "MPLS Generic Associated Channel ", RFC [2] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS
5586 , June 2009 Generic Associated Channel", RFC 5586, June 2009.
[3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for [3] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
Operations Administration and Maintenance in MPLS "Requirements for Operations, Administration, and Maintenance
Transport Networks", RFC5860, May 2010 (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[4] Katz, D. and D. Ward, "Bidirectional Forwarding [4] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
Detection", RFC 5880, June 2010 (BFD)", RFC 5880, June 2010.
[5] Swallow, G. et al., "MPLS Fault Management OAM", draft- [5] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
ietf-mpls-tp-fault-04 (work in progress), April 2011 Boutros, S., and D. Ward, "MPLS Fault Management Operations,
Administration, and Maintenance (OAM)", RFC 6427, November
2011.
[6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge [6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", RFC 4446, April 2006 Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[7] Nadeau, T. et al. "Bidirectional Forwarding Detection [7] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
(BFD) for the Pseudowire Virtual Circuit Connectivity Forwarding Detection (BFD) for the Pseudowire Virtual Circuit
Verification (VCCV) ", IETF RFC 5885, June 2010 Connectivity Verification (VCCV)", RFC 5885, June 2010.
[8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection [8] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
(BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, "Bidirectional Forwarding Detection (BFD) for MPLS Label
June 2010 Switched Paths (LSPs)", RFC 5884, June 2010.
[9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- [9] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile
ietf-mpls-tp-identifiers-06 (work in progress), June 2011 (MPLS-TP) Identifiers", RFC 6370, September 2011.
[10] Nadeau, T, et al., "Pseudowire Virtual Circuit [10] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
Connectivity Verification (VCCV): A Control Channel for Circuit Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007 Pseudowires", RFC 5085, December 2007.
[11] Narten, T., Alvestrand, H., "Guidelines for Writing an [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
IANA Considerations Section in RFCs", IETF RFC 5226, May Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
2008
8.2. Informative References 7.2. Informative References
[12] Bocci, M., et al., "A Framework for MPLS in Transport [12] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L.,
Networks", RFC5921, July 2010 and L. Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[13] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- [13] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration,
ietf-mpls-tp-oam-framework-11 (work in progress), February and Maintenance Framework for MPLS-Based Transport Networks",
2011 RFC 6371, September 2011.
[14] Andersson et. al., "OAM Terminology", IETF RFC 6291, June [14] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and
2011 S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in
the IETF", BCP 161, RFC 6291, June 2011.
Authors' Addresses [15] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
over an MPLS PSN", RFC 4385, February 2006.
Dave Allan 8. Acknowledgments
Ericsson
Email: david.i.allan@ericsson.com
John Drake Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher, and Yaacov
Juniper Weingarten also contributed to this document.
Email: jdrake@juniper.net
George Swallow 9. Contributing Authors
Cisco Systems, Inc.
Email: swallow@cisco.com
Annamaria Fulignoli Annamaria Fulignoli
Ericsson Ericsson
Email: annamaria.fulignoli@ericsson.com EMail: annamaria.fulignoli@ericsson.com
Sami Boutros Sami Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
Email: sboutros@cisco.com EMail: sboutros@cisco.com
Martin Vigoureux Martin Vigoureux
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 Robert Rennison
ECI Telecom ECI Telecom
Email: robert.rennison@ecitele.com EMail: robert.rennison@ecitele.com
Editors' Addresses
Dave Allan
Ericsson
EMail: david.i.allan@ericsson.com
George Swallow
Cisco Systems, Inc.
EMail: swallow@cisco.com
John Drake
Juniper
EMail: jdrake@juniper.net
 End of changes. 202 change blocks. 
509 lines changed or deleted 514 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/