draft-ietf-mpls-tp-cc-cv-rdi-05.txt   draft-ietf-mpls-tp-cc-cv-rdi-06.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: December 2011 George Swallow Ed. Expires: February 2012 George Swallow Ed.
Cisco Systems, Inc Cisco Systems, Inc
John Drake Ed. John Drake Ed.
Juniper Juniper
June 2011 August 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-05 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-TP OAM.
Continuity Check monitors the integrity of the continuity of the Continuity Check monitors a label switched path for any loss-of-
label switched path for any loss of continuity defect. Connectivity continuity defect. Connectivity Verification augments Continuity
verification monitors the integrity of the routing of the label Check in order to provide confirmation that the desired source is
switched path between sink and source for any connectivity issues. connected to the desired sink. Remote defect indication enables an
Remote defect indication enables an End Point to report, to its End Point to report, to its associated End Point, a fault or defect
associated End Point, a fault or defect condition that it detects on condition that it detects on a pseudo wire, label switched path or
a pseudo wire, label switched path or Section. Section.
This document specifies methods for proactive continuity check, This document specifies specific extensions to BFD and methods for
continuity verification, and remote defect indication for MPLS-TP proactive Continuity Check, Continuity Verification, and Remote
label switched paths, pseudo wires and Sections using Bidirectional Defect Indication for MPLS-TP label switched paths, pseudo wires and
Forwarding Detection. Sections using Bidirectional Forwarding Detection as extended by
this memo.
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 19 skipping to change at page 2, line 22
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress". in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2nd 2011. This Internet-Draft will expire on February 9th, 2012.
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
skipping to change at page 2, line 41 skipping to change at page 2, line 44
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
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
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-TP CC, proactive CV and RDI Mechanism using BFD...........5
3.1. Existing Capabilities........................................5 3.1. Existing Capabilities........................................5
3.2. CC, CV, and RDI Overview.....................................5 3.2. CC, CV, and RDI Overview.....................................6
3.3. ACH code points for CC and proactive CV......................6 3.3. ACH code points for CC and proactive CV......................7
3.4. MPLS BFD CC Message format...................................7 3.4. MPLS-TP BFD CC Message format................................7
3.5. MPLS BFD proactive CV Message format.........................7 3.5. MPLS-TP BFD proactive CV Message format......................8
3.5.1. Section MEP-ID.............................................9 3.5.1. Section MEP-ID.............................................9
3.5.2. LSP MEP-ID.................................................9 3.5.2. LSP MEP-ID................................................10
3.5.3. PW Endpoint MEP-ID........................................10 3.5.3. PW Endpoint MEP-ID........................................10
3.6. BFD Session in MPLS-TP terminology..........................11 3.6. BFD Session in MPLS-TP terminology..........................11
3.7. BFD Profile for MPLS-TP.....................................11 3.7. BFD Profile for MPLS-TP.....................................12
3.7.1. Session initiation and Modification.......................13 3.7.1. Session initiation and Modification.......................13
3.7.2. Defect entry criteria.....................................13 3.7.2. Defect entry criteria.....................................13
3.7.3. Defect entry consequent action............................14 3.7.3. Defect entry consequent action............................15
3.7.4. Defect exit criteria......................................15 3.7.4. Defect exit criteria......................................15
3.7.5. State machines............................................15 3.7.5. State machines............................................15
3.7.6. Configuration of MPLS-TP BFD sessions.....................18 3.7.6. Configuration of MPLS-TP BFD sessions.....................18
3.7.7. Discriminator values......................................18 3.7.7. Discriminator values......................................18
4. Configuration Considerations..................................18 4. Configuration Considerations..................................18
5. Acknowledgments...............................................19 5. Acknowledgments...............................................19
6. IANA Considerations...........................................19 6. IANA Considerations...........................................19
7. Security Considerations.......................................20 7. Security Considerations.......................................20
8. References....................................................20 8. References....................................................20
8.1. Normative References........................................20 8.1. Normative References........................................20
8.2. Informative References......................................21 8.2. Informative References......................................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 OAM tools to detect mis- more switches. Service Providers (SP) need Operations, Administration
connectivity and loss of continuity of transport circuits. Both and Maintenance (OAM) tools to detect mis-connectivity and loss-of-
pseudo wires (PWs) and MPLS-TP label switched paths (LSPs) [12][12] continuity of transport circuits. Both pseudo wires (PWs) and MPLS-TP
emulating traditional transport circuits need to provide the same label switched paths (LSPs) [12] emulating traditional transport
continuity check (CC) proactive continuity verification (CV) and circuits need to provide the same Continuity Check (CC), proactive
remote defect indication (RDI) capabilities as required in RFC Continuity Verification (CV), and Remote Defect Indication (RDI)
5860[3]. This document describes the use of Bidirectional Forwarding capabilities as required in RFC 5860[3]. This document describes the
Detection (BFD)[4] for CC, proactive CV, and RDI of a PW, LSP or sub- use of Bidirectional Forwarding Detection (BFD)[4] for CC, proactive
path maintenance entity (SPME) between two Maintenance Entity Group CV, and RDI of a PW, LSP or sub-path maintenance entity (SPME)
End Points (MEPs). between two Maintenance Entity Group End Points (MEPs).
As described in [13][13], CC and CV functions are used to detect loss As described in [13], CC and CV functions are used to detect loss-of-
of continuity (LOC), and unintended connectivity between two MEPs continuity (LOC), and unintended connectivity between two MEPs (e.g.
(e.g. mis-merging or mis-connectivity or unexpected MEP). 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 & 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 bi-directional LSPs. Supported
encapsulations include generic alert label (GAL)/generic associated encapsulations include generic alert label (GAL)/generic associated
skipping to change at page 4, line 21 skipping to change at page 4, line 24
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
CV: Connectivity Verification CV: Connectivity Verification
GAL: Generalized Alert 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: 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: Uni-directional 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]
PW: Pseudo Wire PW: Pseudo Wire
PDU: Protocol Data Unit
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
3. MPLS CC, proactive CV and RDI Mechanism using BFD 3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD
This document describes procedures for achieve combined CC, CV and This document describes procedures for achieve combined CC, CV and
RDI functionality within a single MPLS-TP MEG using BFD. This 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 to
bi-directional LSPs (via the use of the GAL), as well as PWs. bi-directional 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[8]. When IP encapsulation is used CV mis-connectivity defect 5884[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 Header (ACH) described in RFC 5586[2]. The ACH with "MPLS-TP
Proactive CV" code point indicates that the message is an MPLS BFD Proactive CV" code point indicates that the message is an MPLS-TP
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,
It is not a distinct PDU. As per [4], a sink MEP SHOULD encode a and the diagnostic code field in CV messages MUST be ignored. It is
diagnostic code of "1 - Control detection time expired" when the not a distinct PDU. As per [4], a sink MEP SHOULD encode a diagnostic
interval times detect multiplier have been exceeded. A sink MEP code of "1 - Control detection time expired" when the interval times
SHOULD encode a diagnostic code of "5 - Path Down" as a consequence detect multiplier have been exceeded. A sink MEP SHOULD encode a
of the sink MEP receiving LDI. A sink MEP that has started sending diagnostic code of "5 - Path Down" as a consequence of the sink MEP
diagnostic code 5 SHOULD NOT change it to 1 when the detection timer receiving LDI. A sink MEP MUST encode a diagnostic code of "XX - -
expires. Misconnectivity defect" (to be assigned by IANA) when CV PDU
processing indicates a misconnectivity 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 Connectivity Verification 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 = XX1. [XX1 to be assigned by IANA from the PW
Associated Channel Type registry.] or, Associated Channel Type registry.] or,
- BFD proactive CV code point = XX2. [XX2 to be assigned by IANA from - BFD proactive CV code point = XX2. [XX2 to be assigned by IANA from
the PW Associated Channel Type registry.] 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 operation is simultaneously employed on a maintenance
entity (ME) within a single BFD session. The expected usage is entity (ME) within a single BFD session. The expected usage is that
that normal operation is to send CC BFD protocol data units normal operation is to send CC BFD protocol data units (PDUs)
(PDUs) interleaved with a CV BFD PDU (augmented with a interleaved with a CV BFD PDU (augmented with a source MEP-ID and
source MEP-ID and identified as requiring additional identified as requiring additional processing by the different ACh
processing by the different ACh channel type). The channel type). The insertion interval for CV PDUs is one per second.
insertion interval for CV PDUs is one per second. Detection Detection of a loss-of-continuity defect is the detect multiplier
of a loss of continuity defect is the detect multiplier (fixed at 3 (fixed at 3 for the CC code point) times the session periodicity.
for the CC code point) times the session periodicity. Mis- Mis-connectivity defects are detected in a maximum of one second.
connectivity defects are detected in a maximum of one second. 3.4. MPLS-TP 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-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 1|Version| Flags | BFD CC Code point | |0 0 0 1|Version| Flags | BFD CC Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS CC Message Figure 2: MPLS-TP CC Message
As shown in figure 2, the MPLS CC message consists of the BFD control As shown in figure 2, the MPLS-TP CC message consists of the BFD
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 BFD proactive CV Message format 3.5. MPLS-TP BFD proactive CV Message format
The format of an MPLS 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 ~ ~ MEP Source ID TLV ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS CV Message Figure 3: MPLS-TP CV Message
As shown in figure 3, the MPLS CV message consists of the BFD control As shown in figure 3, the MPLS-TP CV message consists of the BFD
packet as defined in [4] pre-pended by the ACH, and appended by a MEP control packet as defined in [4] pre-pended by the ACH, and appended
source ID TLV. by a MEP 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. 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 MEP Source ID TLV is not included. There are 3 possible Source MEP
TLVs (corresponding to the MEP-IDs defined in [9]) [type fields to be TLVs (corresponding to the MEP-IDs defined in [9]) [type fields to be
assigned by IANA]. The type fields are: assigned by IANA]. The type fields are:
skipping to change at page 9, line 23 skipping to change at page 9, line 40
| 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 'X1' (to be assigned by IANA). The length
is the length of the value fields. The MPLS-TP Global ID, Node is the length of the value fields. The MPLS-TP Global ID, Node
Identifier and Interface Numbers are as per [9]. Identifier and Interface 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 consists of The fields for the LSP MEP-ID is as defined in [9]. This is
32-bit MPLS-TP Global ID, the 32-bit Node Identifier, followed by the applicable to both LSPs and SPMEs. This consists of 32-bit MPLS-TP
16-bit Tunnel_Num (that MUST be unique within the context of the Node 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 Identifier), and the 16-bit LSP_NUM (that MUST be unique with 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 18 skipping to change at page 10, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 'X2' (to be assigned by IANA). The length
is the length of the value fields. The MPLS-TP Global ID, Node is the length of the value fields. The MPLS-TP Global ID, Node
Identifier, Tunnel Num and LSP_Num are as per [9]. Identifier, Tunnel Num and LSP_Num are as per [9].
3.5.3. PW Endpoint MEP-ID 3.5.3. PW Endpoint MEP-ID
The fields for the MPLS_TP PW Endpoint MEP-ID is as defined in [9]. The fields for the MPLS-TP PW Endpoint MEP-ID is 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 |
skipping to change at page 11, line 34 skipping to change at page 12, line 10
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.1. For PWs, this is G-ACh encapsulated BFD specified in section 3.3. For PWs, this is G-ACh or GAL/G-ACh
using the code points specified in section 3.1. In this mode, the BFD encapsulated BFD using the code points specified in section 3.3. In
Control packets are periodically sent at configurable time rate. This this mode, the BFD Control packets are periodically sent at
rate is a fixed value common for both directions of MEG for the configurable time rate. This rate is a fixed value common for both
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 bi-directional 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 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 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 bi-directional BFD session is used for coordinated
operation. Two independent BFD sessions are used for independent operation. Two independent BFD sessions are used for independent
skipping to change at page 12, line 26 skipping to change at page 12, line 47
Overall operation is as specified in [4] and augmented for MPLS in Overall operation is as specified in [4] and augmented for MPLS in
[8]. Coordinated operation is as described in [4]. Independent [8]. Coordinated operation is as described in [4]. Independent
operation requires clarification of two aspects of [4]. Independent operation requires clarification of two aspects of [4]. Independent
operation is characterized by the setting of bfd.MinRxInterval to operation is characterized by the setting of bfd.MinRxInterval to
zero by the MEP that is typically the session originator (referred 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 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 end of the bi-directional LSP. Each source MEP will have a
corresponding sink MEP that has been configured to a Tx interval of corresponding sink MEP that has been configured to a Tx interval of
zero. zero.
The base spec is unclear on aspects of how a MEP with a BFD transmit This memo specifies a preferred interpretation of the base spec on
rate set to zero behaves. One interpretation is that no periodic how a MEP with a BFD transmit rate set to zero behaves. One
messages on the reverse component of the bi-directional LSP originate interpretation is that no periodic messages on the reverse component
with that MEP, it will only originate messages on a state change. of the bi-directional LSP originate 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
bfd.TxInterval) will ignore a DOWN state received from a zero bfd.TxInterval) will ignore a DOWN state received from a zero
skipping to change at page 13, line 14 skipping to change at page 13, line 35
Instruct/Lock Report transactions; Lock Report interaction being Instruct/Lock Report transactions; 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 set the detect multiplier to 3.
Once the desired rate has been reached using the poll/final 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. 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 a LSP direction to transition from the
defect free state to a defect state is a superset of that in the BFD defect free state to a defect state is a 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
PDUs: PDUs (in no particular order):
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 or lock report. 2. Receipt of a link down indication or lock report.
And the following will cause the MEP to enter the defect state for CV And the following will cause the MEP to enter the mis-connectivity
operation defect state for CV operation (again not in any particular order):
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:
- receiving an IP encoded CC or CV BFD control packet on a - receiving an IP encoded CC or CV BFD control packet on a
LSP configured to use GAL/G-ACh, or vice versa LSP configured to use GAL/G-ACh, 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). Note that as each encoding of the (Mis-connectivity defect). Note that as each encoding of the
Source MEP ID TLV contains unique information (there is no Source MEP ID TLV contains unique information (there is no
mechanical translation possible between MEP ID formats), receipt mechanical translation possible between MEP ID formats), receipt
of an unexpected source MEP ID type is the same as receiving an of an unexpected source MEP ID type is the same as receiving an
unexpected value. unexpected value.
3. Receipt of a session discriminator that is not in the local BFD 3. Receipt of a session discriminator that is not in the local BFD
database in the your discriminator field (mis-connectivity database in the Your Discriminator field (mis-connectivity
defect). defect).
4. Receipt of a session discriminator that is in the local database 4. Receipt of a session discriminator that is in the local database
but does not have the expected label (mis-connectivity defect). 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.
skipping to change at page 15, line 5 skipping to change at page 15, line 19
3.7.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 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 [13] section 5.1.1.2.
When the defect is mis-connectivity, the LSP termination will When the defect is mis-connectivity, the section, LSP or PW
silently discard all non-OAM traffic received. The sink MEP will also termination will silently discard all non-OAM traffic received. The
send a defect indication back to the source MEP via the use of a sink MEP will also send a defect indication back to the source MEP
diagnostic code of mis-connectivity defect to be assigned by IANA. via the use of a diagnostic code of mis-connectivity defect to be
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 4 which updates [4]. as described in figure 7 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 BFD control packet from the peer occurs upon receipt of a well formed BFD control packet from the peer
MEP as described in figures 5 and 6. 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 [4]. They have been modified to
include LDI and LKI as specified in [5] as inputs to the state include LDI and LKR as specified in [5] as inputs to the state
machine and to clarify the behavior for independent mode. LKR is an machine and to clarify the behavior for independent mode. LKR is an
optional input. 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,| |
| | 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 | |<---+
+------+ +------+ +------+ +------+
skipping to change at page 17, line 29 skipping to change at page 18, line 4
state. state.
+--+ +--+
| | ADMIN DOWN, TIMER, LDI, LKR | | ADMIN DOWN, TIMER, LDI, LKR
| V | V
DOWN +------+ INIT, UP DOWN +------+ INIT, UP
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | MISCONNECTIVITY,| |
| | 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 | |<---+
+------+ +------+ +------+ +------+
skipping to change at page 18, line 16 skipping to change at page 18, line 30
Configuration of MPLS-TP BFD session parameters 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.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 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
"my discriminator" field for an established BFD session. 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 MEG/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 following parameters can optionally be configured or locally And the the discriminators used by each MEP, both bfd.LocalDiscr and
assigned: bfd.RemoteDiscr can optionally be configured or locally assigned.
1) The discriminators used by each MEP. Both bfd.LocalDiscr and Finally a detect multiplier of 3 is directly inferred from the code
bfd.RemoteDiscr. points.
Finally the following is directly inferred:
1) Detect multiplier of 3
5. Acknowledgments 5. Acknowledgments
Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher and Yaacov Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher and Yaacov
Weingarten also contributed to this document. Weingarten also contributed to this document.
6. IANA Considerations 6. IANA Considerations
This draft requires the allocation of two channel types from the IANA This draft requires the allocation of two channel types from the IANA
"PW Associated Channel Type" registry in RFC4446 [6]. "PW Associated Channel Type" registry in RFC4446 [6].
XX1 MPLS-TP CC message XX1 MPLS-TP CC message
XX2 MPLS-TP CV message XX2 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. The parent registry will be the "PW Associated Channel registry. The parent registry will be the "PW Associated Channel
Type" registry of RFC4446 [6]. All code points within this Type" registry of RFC4446 [6]. All code points within this
registry shall be allocated according to the "Standards Action" registry shall be allocated according to the "Standards Action"
skipping to change at page 20, line 18 skipping to change at page 20, line 28
not "leaking" between LSPs. not "leaking" between LSPs.
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. Although section 6.7); that can be applied to this application. Although
the source MEP-ID TLV is not included in the BFD authentication the source MEP-ID TLV is not included in the BFD authentication
digest, there is a chain of trust such that the discriminator digest, there is a chain of trust such that the discriminator
associated with the digest is also associated with the expected associated with the digest is also associated with the expected
MEP-ID which will prevent impersonation of CV messages in this MEP-ID which will prevent impersonation of CV messages in this
application. application.
This memo specifies the use of globally unique identifiers for
MEP IDs. This provides absolutely authoritative detection of
persistent leaking of traffic between LSPs. Non-uniqueness can
result in undetected leaking in the scenario where two LSPs with
common MEP IDs are misconnected. This would be considered to be
undesirable but rare, it would also be difficult to exploit for
malicious purposes as at a minimum, both a network end point,
and a node that was a transit point for the target MEG would
need to be compromised.
8. References 8. References
8.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-04 (work in progress), April 2011 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
Edge Emulation (PWE3)", RFC 4446, April 2006 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-
skipping to change at page 22, line 5 skipping to change at page 21, line 42
8.2. Informative References 8.2. Informative References
[12] Bocci, M., et al., "A Framework for MPLS in Transport [12] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", RFC5921, July 2010 Networks", RFC5921, July 2010
[13] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- [13] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft-
ietf-mpls-tp-oam-framework-11 (work in progress), February ietf-mpls-tp-oam-framework-11 (work in progress), February
2011 2011
[14] Andersson et. al., "OAM Terminology", IETF RFC 6291, June
2011
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
 End of changes. 61 change blocks. 
121 lines changed or deleted 148 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/