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/ |