draft-ietf-mpls-tp-cc-cv-rdi-02.txt | draft-ietf-mpls-tp-cc-cv-rdi-03.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: April 2011 George Swallow Ed. | Expires: August 2011 George Swallow Ed. | |||
Cisco Systems, Inc | Cisco Systems, Inc | |||
John Drake Ed. | John Drake Ed. | |||
Juniper | Juniper | |||
October 22, 2010 | February 2, 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-02 | draft-ietf-mpls-tp-cc-cv-rdi-03 | |||
Abstract | Abstract | |||
Continuity Check (CC), Proactive Connectivity Verification (CV) and | Continuity Check (CC), Proactive Connectivity Verification (CV) and | |||
Remote Defect Indication (RDI) functionalities are required for MPLS- | Remote Defect Indication (RDI) functionalities are required for MPLS- | |||
TP OAM. | TP OAM. | |||
Continuity Check monitors the integrity of the continuity of the LSP | Continuity Check monitors the integrity of the continuity of the LSP | |||
for any loss of continuity defect. Connectivity verification monitors | for any loss of continuity defect. Connectivity verification monitors | |||
the integrity of the routing of the LSP between sink and source for | the integrity of the routing of the LSP between sink and source for | |||
skipping to change at page 2, line 19 | skipping to change at page 2, line 19 | |||
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 November 28, 2010. | This Internet-Draft will expire on August 2nd 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 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 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 | |||
1.1. Authors......................................................4 | 1.1. Authors......................................................4 | |||
2. Conventions used in this document..............................4 | 2. Conventions used in this document..............................4 | |||
2.1. Terminology..................................................4 | 2.1. Terminology..................................................4 | |||
2.2. Issues for discussion........................................5 | ||||
3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 | 3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 | |||
3.1. ACH code points for CC and proactive CV......................6 | 3.1. ACH code points for CC and proactive CV......................6 | |||
3.2. MPLS BFD CC Message format...................................6 | 3.2. MPLS BFD CC Message format...................................6 | |||
3.3. MPLS BFD proactive CV Message format.........................7 | 3.3. MPLS BFD proactive CV Message format.........................7 | |||
3.4. BFD Session in MPLS-TP terminology...........................7 | 3.3.1. ICC-based MEP-ID...........................................8 | |||
3.5. BFD Profile for MPLS-TP......................................8 | 3.3.2. LSP MEP-ID.................................................8 | |||
3.5.1. Session initiation.........................................9 | 3.3.3. PW Endpoint MEP-ID.........................................8 | |||
3.5.2. Defect entry criteria......................................9 | 3.4. BFD Session in MPLS-TP terminology...........................8 | |||
3.5.3. Defect entry consequent action............................10 | 3.5. BFD Profile for MPLS-TP......................................9 | |||
3.5.4. Defect exit criteria......................................11 | 3.5.1. Session initiation........................................10 | |||
3.5.5. State machines............................................11 | 3.5.2. Defect entry criteria.....................................10 | |||
3.5.6. Configuration of MPLS-TP BFD sessions.....................14 | 3.5.3. Defect entry consequent action............................11 | |||
3.5.7. Discriminator values......................................14 | 3.5.4. Defect exit criteria......................................12 | |||
4. Acknowledgments...............................................15 | 3.5.5. State machines............................................12 | |||
5. IANA Considerations...........................................15 | 3.5.6. Configuration of MPLS-TP BFD sessions.....................15 | |||
6. Security Considerations.......................................15 | 3.5.7. Discriminator values......................................15 | |||
7. References....................................................15 | 4. Acknowledgments...............................................16 | |||
7.1. Normative References........................................15 | 5. IANA Considerations...........................................16 | |||
7.2. Informative References......................................16 | 6. Security Considerations.......................................16 | |||
7. References....................................................16 | ||||
7.1. Normative References........................................16 | ||||
7.2. Informative References......................................17 | ||||
1. Introduction | 1. Introduction | |||
In traditional transport networks, circuits are provisioned on two or | In traditional transport networks, circuits are provisioned on two or | |||
more switches. Service Providers (SP) need OAM tools to detect mis- | more switches. Service Providers (SP) need OAM tools to detect mis- | |||
connectivity and loss of continuity of transport circuits. Both PWs | connectivity and loss of continuity of transport circuits. Both PWs | |||
and MPLS-TP LSPs [7] emulating traditional transport circuits need to | and MPLS-TP LSPs [10] emulating traditional transport circuits need | |||
provide the same CC and proactive CV capabilities as required in | to provide the same CC and proactive CV capabilities as required in | |||
draft-ietf-mpls-tp-oam-requirements[3]. This document describes the | RFC 5860[3]. This document describes the use of BFD for CC, proactive | |||
use of BFD for CC, proactive CV, and RDI of a PW, LSP or SPME between | CV, and RDI of a PW, LSP or SPME between two Maintenance Entity Group | |||
two Maintenance Entity Group End Points (MEPs). | End Points (MEPs). | |||
As described in [9], Continuity Check (CC) and Proactive Connectivity | As described in [11], Continuity Check (CC) and Proactive | |||
Verification (CV) functions are used to detect loss of continuity | Connectivity Verification (CV) functions are used to detect loss of | |||
(LOC), and unintended connectivity between two MEPs (e.g. mismerging | continuity (LOC), and unintended connectivity between two MEPs (e.g. | |||
or misconnectivity or unexpected MEP). | mismerging or misconnectivity or unexpected MEP). | |||
The Remote Defect Indication (RDI) is an indicator that is | The Remote Defect Indication (RDI) is an indicator that is | |||
transmitted by a MEP to communicate to its peer MEP that a signal | transmitted by a MEP to communicate to its peer MEP that a signal | |||
fail condition exists. RDI is only used for bidirectional LSPs and is | fail condition exists. RDI is only used for bidirectional LSPs and is | |||
associated with proactive CC & CV packet generation. | associated with proactive CC & CV packet generation. | |||
This document specifies the BFD extension and behavior to satisfy the | This document specifies the BFD extension and behavior to satisfy the | |||
CC, proactive CV monitoring and the RDI functional requirements for | CC, proactive CV monitoring and the RDI functional requirements for | |||
both co-routed and associated bi-directional LSPs. Supported | both co-routed and associated bi-directional LSPs. Supported | |||
encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for | encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for | |||
skipping to change at page 5, line 10 | skipping to change at page 5, line 10 | |||
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. Issues for discussion | ||||
1) Requirement for additional BFD diagnostic codes? | ||||
1. When periodicity of CV cannot be supported | ||||
3. MPLS CC, proactive CV and RDI Mechanism using BFD | 3. MPLS CC, proactive CV and RDI Mechanism using BFD | |||
This document proposes distinct encapsulations and code points for | This document proposes distinct encapsulations and code points for | |||
ACh encapsulated BFD depending on whether the mode of operation is CC | ACh encapsulated BFD depending on whether the mode of operation is CC | |||
or CV: | or CV: | |||
o CC mode: defines a new code point in the Associated Channel Header | o CC mode: defines a new code point in the Associated Channel Header | |||
(ACH) described in [2].In this mode Continuity Check and RDI | (ACH) described in RFC 5586[2].In this mode Continuity Check and | |||
functionalities are supported. | RDI functionalities are supported. | |||
o CV mode: defines a new code point in the Associated Channel Header | o CV mode: defines a new code point in the Associated Channel Header | |||
(ACH) described in [2]. The ACH with "MPLS Proactive CV" code | (ACH) described in RFC 5586[2]. The ACH with "MPLS Proactive CV" | |||
point indicates that the message is an MPLS BFD proactive CV and | code point indicates that the message is an MPLS BFD proactive CV | |||
CC message and CC, CV and RDI functionalities are supported. | and CC message and CC, CV and RDI functionalities are supported. | |||
RDI: is communicated via the BFD diagnostic field in BFD CC and CV | RDI: is communicated via the BFD diagnostic field in BFD CC and CV | |||
messages. It is not a distinct PDU. A sink MEP will encode a | messages. It is not a distinct PDU. A sink MEP will encode a | |||
diagnostic code of "1- Control detection time expired" when the | diagnostic code of "1- Control detection time expired" when the | |||
interval times detect multipler have been exceeded, and with "3 - | interval times detect multipler have been exceeded, and with "3 - | |||
neighbor signaled session down" as a consequence of the sink MEP | neighbor signaled session down" as a consequence of the sink MEP | |||
receiving AIS with LDI set. A sink MEP that has started sending diag | receiving AIS with LDI set. A sink MEP that has started sending diag | |||
code 3 will NOT change it to 1 when the detection timer expires. | code 3 will NOT change it to 1 when the detection timer expires. | |||
In accordance with RFC 5586, when these packets are encapsulated in | In accordance with RFC 5586[2], when these packets are encapsulated | |||
an IP header the fields in the IP header are set as defined in RFC | in an IP header, the fields in the IP header are set as defined in | |||
5884. It should also be noted that existing ACh code points and | RFC 5884[8]. Further existing ACh code points and mechanisms for BFD | |||
mechanisms for negotiating the control channel and connectivity | VCCV are specified in RFC5885[7]. These MAY be applied to | |||
verification (i.e. OAM functions) between PEs are specified for | Pseudowires by configuration. Also by configuration, the BFD PW-ACH- | |||
VCCV[6]. | encapsulated for PW fault detection only encapsulation can be applied | |||
to bi-directional LSPs by employing the GAL to indicate the presence | ||||
of the ACh. | ||||
A further artifact of IP encapsulation is that CV mis-connectivity | ||||
defect detection can be performed by inferring MEP_ID on the basis of | ||||
the combination of the source IP address and "my discriminator" | ||||
fields. | ||||
3.1. ACH code points for CC and proactive CV | 3.1. ACH code points for CC and proactive CV | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0 0 0 1|Version| Flags |0xHH BFD CC/CV Code Point | | |0 0 0 1|Version| Flags |0xHH BFD CC/CV Code Point | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: ACH Indication of MPLS-TP Connectivity Verification | Figure 1: ACH Indication of MPLS-TP Connectivity Verification | |||
skipping to change at page 6, line 27 | skipping to change at page 6, line 27 | |||
The version and the flags are set to 0 as specified in [2]. | The version and the flags are set to 0 as specified in [2]. | |||
The code point is either | The code point is either | |||
- BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW | - BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW | |||
Associated Channel Type registry.] or, | Associated Channel Type registry.] or, | |||
- BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from | - BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from | |||
the PW Associated Channel Type registry.] | the PW Associated Channel Type registry.] | |||
Both CC and CV modes apply to PWs, MPLS LSPs (including tandem | Both CC and CV modes apply to PWs, MPLS LSPs (including SPMEs), and | |||
connection monitoring), and Sections. | Sections. | |||
CC and CV operation can be simultaneously employed on an ME within a | CC and CV operation can be simultaneously employed on an ME within a | |||
single BFD session. The expected usage is that normal operation is to | single BFD session. The expected usage is that normal operation is to | |||
send CC BFD PDUs with every nth BFD PDU augmented with a source MEP | send CC BFD PDUs with every nth BFD PDU augmented with a source MEP- | |||
ID and identified as requiring additional processing by the different | ID and identified as requiring additional processing by the different | |||
ACh channel type. | ACh channel type. When CC and CV are interleaved, the minimum | |||
insertion interval for CV PDUs is one per second. | ||||
3.2. MPLS BFD CC Message format | 3.2. MPLS BFD CC Message format | |||
The format of an MPLS CC Message is shown below. | The format of an MPLS CC Message is shown below. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0 0 0 1|Version| Flags | 0xHH BFD CC Code point | | |0 0 0 1|Version| Flags | 0xHH BFD CC Code point | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 7, line 27 | skipping to change at page 7, line 27 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
~ Unique MEP-ID of source of the BFD packet ~ | ~ Unique MEP-ID of source of the BFD packet ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 3: MPLS CV Message | Figure 3: MPLS CV Message | |||
As shown in Figure 3, BFD Control packet as defined in [4] is | As shown in Figure 3, BFD Control packet as defined in [4] is | |||
transmitted as MPLS labeled packets along with the ACH. Appended to | transmitted as MPLS labeled packets along with the ACH. Appended to | |||
the BFD control packet is a MEP Source ID TLV. The length in the BFD | the BFD control packet is a MEP Source ID TLV. | |||
control packet is as per [4]. There are 4 possible Source MEP TLVs | ||||
(corresponding to the MEP IDs defined in [8] [type fields to be | ||||
assigned by IANA]. The type fields are: | ||||
X1 - ICC encoded MEP ID | 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 | ||||
length Value field. | ||||
X2 - LSP-MEP_ID | The length in the BFD control packet is as per [4]. There are 3 | |||
Source MEP TLVs (corresponding to the MEP-IDs defined in Error! | ||||
Reference source not found. [type fields to be assigned by IANA]. The | ||||
type fields are: | ||||
X3 - PW MEP ID | X1 - ICC encoded MEP-ID | |||
X4 - PW Segment endpoint ID | X2 - LSP MEP-ID | |||
X3 - PW MEP-ID | ||||
When GAL label is used, the TTL field of the GAL MUST be set to at | When GAL label is used, the TTL field of the GAL MUST be set to at | |||
least 1, and the GAL will be the end of stack label (S=1). | least 1, and the GAL will be the end of stack label (S=1). | |||
A node MUST NOT change the value in the MEP Source ID TLV. | ||||
When digest based authentication is used, the Source ID TLV MUST NOT | ||||
be included in the digest | ||||
3.3.1. ICC-based MEP-ID | ||||
As defined in [9], the ICC-based MEP_ID consists of the MEG_ID, a | ||||
string of up to 13 characters (A-Z and 0-9), followed by the MEP | ||||
Index, an unsigned 16 bit integer that MUST be unique within the | ||||
context of the MEG_ID. | ||||
3.3.2. LSP MEP-ID | ||||
As defined in [9], the MPLS_TP LSP MEP-ID consists of the Node | ||||
Identifier, a thirty two bit identifier that MUST be unique within | ||||
the context of an operator's network, followed by the Tunnel_Num, an | ||||
unsigned sixteen bit integer that MUST be unique within the context | ||||
of the Node Identifier, and the LSP_NUM, an unsigned sixteen bit | ||||
integer that MUST be unique with the context of the Tunnel Num. | ||||
3.3.3. PW Endpoint MEP-ID | ||||
As defined in [9], the PW Endpoint MEP-ID consists of the Node | ||||
Identifier, a thirty two bit identifier that MUST be unique within | ||||
the context of an operator's network, followed by the AC_ID, a thirty | ||||
two bit identifier that MUST be unique within the context of the Node | ||||
Identifier. | ||||
In situations where global uniqueness is required, the Node | ||||
Identifier is preceded by the Global ID, a thirty two bit identifier | ||||
that contains the two-octet (right hand justified and preceded by | ||||
sixteen bits of zero) or four-octet value of the operator's | ||||
Autonomous System Number (ASN). | ||||
3.4. BFD Session in MPLS-TP terminology | 3.4. BFD Session in MPLS-TP terminology | |||
A BFD session corresponds to a CC or a proactive CV OAM instance in | A BFD session corresponds to a CC or a proactive CV OAM instance in | |||
MPLS-TP terminology. | MPLS-TP terminology. | |||
A BFD session is enabled when the CC or proactive CV functionality is | A BFD session is enabled when the CC or proactive CV functionality is | |||
enabled on a configured Maintenance Entity (ME).. | enabled on a configured Maintenance Entity (ME).. | |||
On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as | On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as | |||
detailed in [4]. | detailed in [4]. | |||
skipping to change at page 8, line 21 | skipping to change at page 9, line 11 | |||
A new BFD session is initiated when the operator enables or re- | A new BFD session is initiated when the operator enables or re- | |||
enables the CC or CV functionality on the same ME. | enables the CC or CV functionality on the same ME. | |||
3.5. BFD Profile for MPLS-TP | 3.5. BFD Profile for MPLS-TP | |||
BFD MUST operate in asynchronous mode. In this mode, the BFD Control | BFD MUST operate in asynchronous mode. In this mode, the BFD Control | |||
packets are periodically sent at configurable time rate. This rate is | packets are periodically sent at configurable time rate. This rate is | |||
typically a fixed value for the lifetime of the session. In the rare | typically a fixed value for the lifetime of the session. In the rare | |||
circumstance where an operator has a reason to change session | circumstance where an operator has a reason to change session | |||
parameters, the session must be moved to the ADMIN DOWN state. | parameters, the session MUST be moved to the ADMIN DOWN state. | |||
Poll/final discipline can only used for VCCV and UDP/IP encapsulated | Poll/final discipline can only used for VCCV and UDP/IP encapsulated | |||
BFD. | BFD. | |||
The transport profile is designed to operate independent of the | ||||
control plane; hence the C bit SHOULD be set. | ||||
This document specifies bi-directional BFD for p2p transport LSPs, | This document specifies bi-directional BFD for p2p transport LSPs, | |||
hence the M bit MUST be clear. | hence the M bit MUST be clear. | |||
There are two modes of operation for bi-directional LSPs. One in | There are two modes of operation for bi-directional LSPs. One in | |||
which the session state of both directions of the LSP is coordinated | which the session state of both directions of the LSP is coordinated | |||
and one constructed from BFD sessions in such a way that the two | and one constructed from BFD sessions in such a way that the two | |||
directions operate independently. A single bi-directional BFD session | directions operate independently. A single bi-directional BFD session | |||
is used for coordinated operation. Two independent BFD sessions are | is used for coordinated operation. Two independent BFD sessions are | |||
used for independent operation. | used for independent operation. | |||
skipping to change at page 9, line 30 | skipping to change at page 10, line 17 | |||
machine; these are the Link Down Indication [5] and the Lock | machine; these are the Link Down Indication [5] and the Lock | |||
Instruct/Lock Report transactions; Lock Report interaction being | Instruct/Lock Report transactions; Lock Report interaction being | |||
optional. | optional. | |||
3.5.1. Session initiation | 3.5.1. Session initiation | |||
In all scenarios a BFD session starts with both ends in the DOWN | In all scenarios a BFD session starts with both ends in the DOWN | |||
state. DOWN state messages exchanged include the desired Tx and Rx | state. DOWN state messages exchanged include the desired Tx and Rx | |||
rates for the session. If a node cannot support the Min Tx rate | rates for the session. If a node cannot support the Min Tx rate | |||
desired by a peer MEP it does not transition from down to the INIT | desired by a peer MEP it does not transition from down to the INIT | |||
state and sends a diagnostic code (TBD) indicating that the requested | state and sends a diagnostic code of configuration error (to be | |||
Tx rate cannot be supported. | assigned by IANA) indicating that the requested Tx rate cannot be | |||
supported. | ||||
Otherwise once a transition from DOWN to INIT has occurred, the | Otherwise once a transition from DOWN to INIT has occurred, the | |||
session progresses as per [4]. In both the DOWN and INIT states | session progresses as per [4]. In both the DOWN and INIT states | |||
messages are transmitted at a rate of one per second and the defect | messages are transmitted at a rate of one per second and the defect | |||
detection interval is fixed at 3.5 seconds. On transition to the UP | detection interval is fixed at 3.5 seconds. On transition to the UP | |||
state message periodicity changes to the negotiated rate and the | state, message periodicity changes to the negotiated and/or | |||
detect interval switches to detect multiplier times the session | configured rate and the detect interval switches to detect multiplier | |||
peer's Tx Rate. | times the session peer's Tx Rate. | |||
3.5.2. Defect entry criteria | 3.5.2. Defect entry criteria | |||
There are further defect criteria beyond those that are defined in | There are further defect criteria beyond those that are defined in | |||
[4] to consider given the possibility of mis-connectivity and mis- | [4] to consider given the possibility of mis-connectivity and mis- | |||
configuration defects. The result is the criteria for a LSP direction | configuration defects. The result is the criteria for a LSP direction | |||
to transition from the defect free state to a defect state is a | to transition from the defect free state to a defect state is a | |||
superset of that in the BFD base specification [4]. | superset of that in the 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 | |||
or CV: | or CV: | |||
skipping to change at page 10, line 4 | skipping to change at page 10, line 39 | |||
3.5.2. Defect entry criteria | 3.5.2. Defect entry criteria | |||
There are further defect criteria beyond those that are defined in | There are further defect criteria beyond those that are defined in | |||
[4] to consider given the possibility of mis-connectivity and mis- | [4] to consider given the possibility of mis-connectivity and mis- | |||
configuration defects. The result is the criteria for a LSP direction | configuration defects. The result is the criteria for a LSP direction | |||
to transition from the defect free state to a defect state is a | to transition from the defect free state to a defect state is a | |||
superset of that in the BFD base specification [4]. | superset of that in the 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 | |||
or CV: | or CV: | |||
1. BFD session times out (Loss of Continuity defect). | 1. BFD session times out (Loss of Continuity defect). | |||
2. Receipt of a link down indication. | 2. Receipt of a link down indication. | |||
3. Receipt of an unexpected M bit (Session Mis-configuration | 3. Receipt of an unexpected M bit (Session Mis-configuration | |||
defect). | defect). | |||
And the following will cause the MEP to enter the defect state for CV | And the following will cause the MEP to enter the defect state for CV | |||
operation | operation | |||
1. BFD control packets are received with an unexpected | 1. BFD control packets are received with an unexpected | |||
encapsulation (mis-connectivity defect), these include: | encapsulation (mis-connectivity defect), these include: | |||
- a PW receiving a packet with a GAL | - a PW receiving a packet with a GAL | |||
- an LSP receiving an IP header instead of a GAL | - receiving an IP encoded CC or CV packet on a LSP configured | |||
to use GAL/GaCH, or vice versa | ||||
(note there are other possibilities that can also alias as an | (note there are other possibilities that can also alias as an | |||
OAM packet) | OAM packet) | |||
2. Receipt of an unexpected globally unique Source MEP identifier | 2. Receipt of an unexpected globally unique Source MEP identifier | |||
(Mis-connectivity defect). | (Mis-connectivity defect). | |||
3. Receipt of an unexpected session discriminator in the your | 3. Receipt of an unexpected session discriminator in the your | |||
discriminator field (mis-connectivity defect). | discriminator field (mis-connectivity defect). | |||
4. Receipt of an expected session discriminator with an unexpected | 4. Receipt of an expected session discriminator with an unexpected | |||
label (mis-connectivity defect). | 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 | The effective defect hierarchy (order of checking) is | |||
1. Receiving nothing. | 1. Receiving nothing. | |||
2. Receiving link down indication. | 2. Receiving link down indication. | |||
3. Receiving from an incorrect source (determined by whatever | 3. Receiving from an incorrect source (determined by whatever | |||
means). | means). | |||
skipping to change at page 10, line 46 | skipping to change at page 11, line 40 | |||
5. Receiving control packets in all discernable ways correct. | 5. Receiving control packets in all discernable ways correct. | |||
3.5.3. Defect entry consequent action | 3.5.3. Defect entry consequent action | |||
Upon defect entry a sink MEP will assert signal fail into any client | Upon defect entry a sink MEP will assert signal fail into any client | |||
(sub-)layers. It will also communicate session DOWN to its session | (sub-)layers. It will also communicate session DOWN to its session | |||
peer. | peer. | |||
The blocking of traffic as consequent action MUST be driven only by a | The blocking of traffic as consequent action MUST be driven only by a | |||
defect's consequent action as specified in draft-ietf-mpls-tp-oam- | defect's consequent action as specified in draft-ietf-mpls-tp-oam- | |||
framework [9] section 5.1.1.2. | framework [11] section 5.1.1.2. | |||
When the defect is mis-branching, the LSP termination will silently | When the defect is mis-branching, the LSP termination will silently | |||
discard all non-oam traffic received. | discard all non-oam traffic received. | |||
3.5.4. Defect exit criteria | 3.5.4. Defect exit criteria | |||
3.5.4.1. Exit from a Loss of continuity defect | 3.5.4.1. Exit from a Loss of continuity defect | |||
For a coordinated session, exit from a loss of connectivity defect is | For a coordinated session, exit from a loss of connectivity defect is | |||
as described in figure 4 which updates [4]. | as described in figure 4 which updates [4]. | |||
For an independent session, exit from a loss of connectivity defect | For an independent session, exit from a loss of connectivity defect | |||
occurs upon receipt of a well formed control packet from the peer MEP | occurs upon receipt of a well formed control packet from the peer MEP | |||
as described in figures 5 and 6. | as described in figures 5 and 6. | |||
3.5.4.2. Exit from a session mis-configuration defect | 3.5.4.2. Exit from a session mis-configuration defect | |||
[editors: for a future version of the document] | Exit from a misconfiguration defect occurs when two consecutive CC or | |||
CV frames have been received with the expected M bit setting. | ||||
3.5.4.3. Exit from a mis-connectivity defect | 3.5.4.3. Exit from a mis-connectivity defect | |||
[Editors node: The shift to CC with interleaved CV suggests the CV | Exit from a mis-connectivity defect state occurs when no CV messages | |||
periodicity may not be known by a sink MEP, hence exit criteria from | have been received with an incorrect source MEP-ID for a period of | |||
a mis-connectivity defect may not be able to be established. We | 3.5 seconds. | |||
suggest two possible resolutions for this: | ||||
1. Exit criteria is manual intervention. | ||||
2. A minimum CV insertion rate (say 1/sec) be specified such that | ||||
the exit criteria be specified as no mis-connected CV PDUs be | ||||
received for a minimum of 3 times the minimum insertion rate] | ||||
3.5.5. State machines | 3.5.5. State machines | |||
The following state machines update [4]. They have been modified to | The following state machines update [4]. They have been modified to | |||
include AIS with LDI set and LKI as inputs to the state machine and | include AIS with LDI set and LKI as specified in [5] as inputs to the | |||
to clarify the behavior for independent mode. LKR is an optional | state machine and to clarify the behavior for independent mode. LKR | |||
input. | is an optional input. | |||
The coordinated session state machine has been augmented to indicate | The coordinated session state machine has been augmented to indicate | |||
AIS with LDI set and optionally LKR as inputs to the state machine. | AIS with LDI set and optionally LKR as inputs to the state machine. | |||
For a session that is in the UP state, receipt of AIS with LDI set or | For a session that is in the UP state, receipt of AIS with LDI set or | |||
optionally LKR will transition the session into the DOWN state. | optionally LKR will transition the session into the DOWN state. | |||
+--+ | +--+ | |||
| | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR | | | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR | |||
| V | | V | |||
DOWN +------+ INIT | DOWN +------+ INIT | |||
skipping to change at page 14, line 30 | skipping to change at page 15, line 30 | |||
+----| | | |----+ | +----| | | |----+ | |||
DOWN| | INIT |--------------------->| UP | |INIT, UP | DOWN| | INIT |--------------------->| UP | |INIT, UP | |||
+--->| | INIT, UP | |<---+ | +--->| | INIT, UP | |<---+ | |||
+------+ +------+ | +------+ +------+ | |||
Figure 6: State machine for the sink MEP for independent session | Figure 6: State machine for the sink MEP for independent session | |||
operation | operation | |||
3.5.6. Configuration of MPLS-TP BFD sessions | 3.5.6. Configuration of MPLS-TP BFD sessions | |||
[Editors note, for a future revision of the document] | Configuration of MPLS-TP BFD session paramters and coordination of | |||
same between the source and sink MEPs is out of scope of this memo. | ||||
3.5.7. Discriminator values | 3.5.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. | |||
Although the BFD base specification permits an implementation to | Per RFC5884 Section 7 [8], a node MUST NOT change the value of the | |||
change the my discriminator field at arbitrary times, this is not | "my discriminator" field for an established BFD session. | |||
permitted for CV mode in order to avoid race conditions in mis- | ||||
connectivity defects. | ||||
4. Acknowledgments | 4. Acknowledgments | |||
To be added in a later version of this document | Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit | |||
Sprecher and Yaacov Weingarten also contributed to this | ||||
document. | ||||
5. IANA Considerations | 5. IANA Considerations | |||
To be added in a later version of this document | This draft requires the allocation of two channel types from the | |||
the IANA "PW Associated Channel Type" registry in RFC4446 [6]. | ||||
6. Security Considerations | Xx MPLS-TP CC message | |||
The security considerations for the authentication TLV need further | Xx+1 MPLS-TP CV message | |||
study. | ||||
Base BFD foresees an optional authentication section (see [4] | This draft requires the creations of a source MEP-ID TLV | |||
section 6.7); that can be extended also to the tool proposed in | registry with initial values of: | |||
this document. | ||||
Authentication methods that require checksum calculation on the | Xx - ICC encoded MEP-ID | |||
outgoing packet must extend the checksum also on the ME | ||||
Identifier Section. This is possible but seems uncorrelated with | Xx+1 - LSP MEP-ID | |||
the solution proposed in this document: it could be better to | ||||
use the simple password authentication method. | Xx+2 - PW MEP-ID | |||
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 | ||||
diagnostic codes [4]: | ||||
Xx - configuration error | ||||
6. Security Considerations | ||||
Base BFD foresees an optional authentication section (see [4] | ||||
section 6.7); that can be applied to this application. | ||||
7. References | 7. References | |||
7.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 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-02 (work in progress), July 2010 | ietf-mpls-tp-fault-03 (work in progress), October 2010 | |||
[6] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit | [6] Martini, L., " IANA Allocations for Pseudowire Edge to | |||
Connectivity Verification (VCCV): A Control Channel for | Edge Emulation (PWE3)", RFC 4446, April 2006 | |||
Pseudowires", RFC 5085, December 2007 | ||||
7.2. Informative References | [7] Nadeau, T. et al. "Bidirectional Forwarding Detection | |||
(BFD) for the Pseudowire Virtual Circuit Connectivity | ||||
Verification (VCCV) ", IETF RFC 5885, June 2010 | ||||
[7] Bocci, M., et al., "A Framework for MPLS in Transport | [8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection | |||
Networks", RFC5921, July 2010 | (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, | |||
June 2010 | ||||
[8] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- | [9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- | |||
swallow-mpls-tp-identifiers-02 (work in progress), July | ietf-mpls-tp-identifiers-03 (work in progress), October | |||
2010 | 2010 | |||
[9] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- | 7.2. Informative References | |||
ietf-mpls-tp-oam-framework-09 (work in progress), October | ||||
[10] Bocci, M., et al., "A Framework for MPLS in Transport | ||||
Networks", RFC5921, July 2010 | ||||
[11] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- | ||||
ietf-mpls-tp-oam-framework-10 (work in progress), December | ||||
2010 | 2010 | |||
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 | |||
End of changes. 47 change blocks. | ||||
115 lines changed or deleted | 172 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |