draft-ietf-mpls-tp-cc-cv-rdi-01.txt   draft-ietf-mpls-tp-cc-cv-rdi-02.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: January 2011 George Swallow Ed. Expires: April 2011 George Swallow Ed.
Cisco Systems, Inc Cisco Systems, Inc
John Drake Ed. John Drake Ed.
Juniper Juniper
July 12, 2010 October 22, 2010
Proactive Connection 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-01 draft-ietf-mpls-tp-cc-cv-rdi-02
Abstract Abstract
Continuity Check (CC), Proactive Connectivity Verification (CV) and Continuity Check (CC), Proactive Connectivity Verification (CV) and
Remote Defect Indication (RDI) functionalities required for are MPLS- Remote Defect Indication (RDI) functionalities are required for MPLS-
TP OAM. TP OAM.
Continuity Check monitors the integrity of the continuity of the path 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 path between sink and source for the integrity of the routing of the LSP between sink and source for
any connectivity issues. RDI enables an End Point to report, to its any connectivity issues. RDI enables an End Point to report, to its
associated End Point, a fault or defect condition that it detects on associated End Point, a fault or defect condition that it detects on
a PW, LSP or Section. a PW, LSP or Section.
This document specifies methods for proactive CV, CC, and RDI for This document specifies methods for proactive CV, CC, and RDI for
MPLS-TP Label Switched Path (LSP), PWs and Sections using MPLS-TP Label Switched Path (LSP), PWs and Sections using
Bidirectional Forwarding Detection (BFD). Bidirectional Forwarding Detection (BFD).
Requirements Language Requirements Language
skipping to change at page 2, line 42 skipping to change at page 2, line 42
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........................................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......................5 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.........................6 3.3. MPLS BFD proactive CV Message format.........................7
3.4. BFD Session in MPLS-TP terminology...........................7 3.4. BFD Session in MPLS-TP terminology...........................7
3.5. BFD Profile for MPLS-TP......................................7 3.5. BFD Profile for MPLS-TP......................................8
3.5.1. Session initiation.........................................8 3.5.1. Session initiation.........................................9
3.5.2. Defect entry criteria......................................8 3.5.2. Defect entry criteria......................................9
3.5.3. Defect entry consequent action............................10 3.5.3. Defect entry consequent action............................10
3.5.4. Defect exit criteria......................................10 3.5.4. Defect exit criteria......................................11
3.5.5. State machines............................................10 3.5.5. State machines............................................11
3.5.6. Configuration of MPLS-TP BFD sessions.....................13 3.5.6. Configuration of MPLS-TP BFD sessions.....................14
3.5.7. Discriminator values......................................13 3.5.7. Discriminator values......................................14
4. Acknowledgments...............................................13 4. Acknowledgments...............................................15
5. IANA Considerations...........................................14 5. IANA Considerations...........................................15
6. Security Considerations.......................................14 6. Security Considerations.......................................15
7. References....................................................14 7. References....................................................15
7.1. Normative References........................................14 7.1. Normative References........................................15
7.2. Informative References......................................15 7.2. Informative References......................................16
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 [7] emulating traditional transport circuits need to
provide the same CC and proactive CV capabilities as required in provide the same CC and proactive CV capabilities as required in
draft-ietf-mpls-tp-oam-requirements[3]. This document describes the draft-ietf-mpls-tp-oam-requirements[3]. This document describes the
use of BFD for CC, proactive CV, and RDI of a PW, LSP or PST between use of BFD for CC, proactive CV, and RDI of a PW, LSP or SPME between
two Maintenance Entity Group End Points (MEPs). two Maintenance Entity Group End Points (MEPs).
As described in [9], Continuity Check (CC) and Proactive Connectivity As described in [9], Continuity Check (CC) and Proactive Connectivity
Verification (CV) functions are used to detect loss of continuity Verification (CV) functions are used to detect loss of continuity
(LOC), and unintended connectivity between two MEPs (e.g. mismerging (LOC), and unintended connectivity between two MEPs (e.g. mismerging
or misconnection or unexpected MEP). 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 connections fail condition exists. RDI is only used for bidirectional LSPs and is
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
bi-directional paths. Procedures for uni-directional paths are for both co-routed and associated bi-directional LSPs. Supported
further study. encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for
uni-directional LSPs are for further study.
The mechanisms specified in this document are restricted to BFD The mechanisms specified in this document are restricted to BFD
asynchronous mode. asynchronous mode.
1.1. Authors 1.1. Authors
David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami
Boutros, Siva Sivabalan, David Ward, Martin Vigoureux. Boutros, Siva Sivabalan, David Ward, Martin Vigoureux.
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
ACH: Associated Channel Header ACH: Associated Channel Header
BFD: Bidirectional Forwarding Detection BFD: Bidirectional Forwarding Detection
CV: Connection Verification CV: Connectivity Verification
GAL: Generalized Alert Label GAL: Generalized Alert Label
LDI: Link Down Indication
LKI: Lock Instruct
LKR: Lock Report
LSR: Label Switching Router LSR: Label Switching Router
MEG: Maintenance Entity Group MEG: Maintenance Entity Group
MEP: Maintenance Entity Group End Point MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point MIP: Maintenance Entity Group Intermediate Point
MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-OAM: MPLS Operations, Administration and Maintenance
skipping to change at page 4, line 45 skipping to change at page 4, line 51
representing a circuit representing a circuit
MS-PW: Multi-Segment PseudoWire MS-PW: Multi-Segment PseudoWire
NMS: Network Management System NMS: Network Management System
PW: Pseudo Wire PW: Pseudo Wire
RDI: Remote Defect Indication. RDI: Remote Defect Indication.
SPME: Sub-Path Maintenance Entity
TTL: Time To Live TTL: Time To Live
TLV: Type Length Value TLV: Type Length Value
VCCV: Virtual Circuit Connectivity Verification
2.2. Issues for discussion 2.2. Issues for discussion
1) Requirement for additional BFD diagnostic codes? 1) Requirement for additional BFD diagnostic codes?
1. When periodicity of CV cannot be supported 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
BFD depending on whether the mode of operation is CC or CV: ACh encapsulated BFD depending on whether the mode of operation is CC
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 [2].In this mode Continuity Check and RDI
functionalities are supported. 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]. Under MPLS label stack, the ACH with "MPLS (ACH) described in [2]. The ACH with "MPLS Proactive CV" code
Proactive CV" code point indicates that the message is an MPLS BFD point indicates that the message is an MPLS BFD proactive CV and
proactive CV and CC message. CC message and CC, CV and RDI functionalities are supported.
o RDI: is communicated via the BFD state 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. messages. It is not a distinct PDU. A sink MEP will encode a
diagnostic code of "1- Control detection time expired" when the
interval times detect multipler have been exceeded, and with "3 -
neighbor signaled session down" as a consequence of the sink MEP
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.
In accordance with RFC 5586, when these packets are encapsulated in
an IP header the fields in the IP header are set as defined in RFC
5884. It should also be noted that existing ACh code points and
mechanisms for negotiating the control channel and connectivity
verification (i.e. OAM functions) between PEs are specified for
VCCV[6].
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 Connection Verification Figure 1: ACH Indication of MPLS-TP Connectivity Verification
The first nibble (0001b) indicates the ACH. The first nibble (0001b) indicates the ACH.
The version and the flags are set to 0 as specified in [2]. The version and the flags are set to 0 as specified in [2].
The code point is either The code point is either
- BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW - BFD CC code point = 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 tandem
connection monitoring), and Sections. connection monitoring), and Sections.
It's possible to run BFD in CC mode on some transport paths and BFD CC and CV operation can be simultaneously employed on an ME within a
in CV mode on other transport paths. For a given Maintenance Entity single BFD session. The expected usage is that normal operation is to
Group (MEG) only one mode can be used. A MEP that is configured to send CC BFD PDUs with every nth BFD PDU augmented with a source MEP
support CC mode and receives CV BFD packets, or vice versa, MUST ID and identified as requiring additional processing by the different
consider them as an unexpected packet, i.e. detect a mis-connectivity ACh channel type.
defect.
3.2. MPLS BFD CC Message format 3.2. MPLS BFD CC Message format
The format of an MPLS CC Message format 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS CC Message Figure 2: MPLS CC Message
3.3. MPLS BFD proactive CV Message format 3.3. MPLS BFD proactive CV Message format
The format of an MPLS CV Message format is shown below, ACH TLVs [5] The format of an MPLS CV Message is shown below.
MUST precede the BFD control packet.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags | 0xHH BFD CV Code Point | |0 0 0 1|Version| Flags | 0xHH BFD CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Unique MEP-ID of source of the BFD packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control 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 ACH, ACH TLV Header transmitted as MPLS labeled packets along with the ACH. Appended to
defined in Section 3 of RFC 5586 and one ACH TLV object carrying the the BFD control packet is a MEP Source ID TLV. The length in the BFD
unique MEP Identifier of the source of the BFD packet defined in [8]. 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
X2 - LSP-MEP_ID
X3 - PW MEP ID
X4 - PW Segment endpoint 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).
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) or in the case of an enabled on a configured Maintenance Entity (ME)..
associated bi-directional path, pair of Maintenance Entities.
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].
When on a ME the CC or proactive CV functionality is disabled, the When on a ME the CC or proactive CV functionality is disabled, the
BFD session transitions to the ADMIN DOWN State and the BFD session BFD session transitions to the ADMIN DOWN State and the BFD session
ends. ends.
A new BFD session is initiated when the operator enables or re- A new BFD session is initiated when the operator enables or re-
enables the CC or CV functionality on the same ME. enables the CC 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, poll/final discipline is used. parameters, the session must be moved to the ADMIN DOWN state.
Poll/final discipline can only used for VCCV and UDP/IP encapsulated
BFD.
The transport profile is designed to operate independent of the The transport profile is designed to operate independent of the
control plane; hence the C bit SHOULD be set. control plane; hence the C bit SHOULD be set.
This document specifies bi-directional BFD for p2p transport paths, 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 paths. One in There are two modes of operation for bi-directional LSPs. One in
which the session state of both directions of the path 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.
Coordinated operation is as described in [4]. Independent operation Coordinated operation is as described in [4]. Independent operation
requires clarification of two aspects of [4]. Independent operation requires clarification of two aspects of [4]. Independent operation
is characterized by the setting of MinRxInterval to zero by the MEP is characterized by the setting of MinRxInterval to zero by the MEP
that is typically the session originator (referred to as the source that is typically the session originator (referred to as the source
MEP), and there will be a session originator at either end of the bi- MEP), and there will be a session originator at either end of the bi-
directional path. Each source MEP will have a corresponding sink MEP directional LSP. Each source MEP will have a corresponding sink MEP
that has been configured to a Tx interval of zero. that has been configured to a Tx interval of zero.
The base spec is unclear on aspects of how a MEP with a BFD transmit The base spec is unclear on aspects of how a MEP with a BFD transmit
rate set to zero behaves. One interpretation is that no periodic rate set to zero behaves. One interpretation is that no periodic
messages originate with that MEP, it will only originate messages on messages on the reverse component of the bi-directional LSP originate
a state change. with that MEP, it will only originate messages on a state change.
The first clarification is that when a state change occurs a MEP set The first clarification is that when a state change occurs a MEP set
to a transmit rate of zero sends BFD control messages with a one to a transmit rate of zero sends BFD control messages with a one
second period until such time that the state change is confirmed by second period on the reverse component until such time that the state
the session peer. At this point the MEP set to a transmit rate of change is confirmed by the session peer. At this point the MEP set to
zero can resume quiescent behavior. This adds robustness to all state a transmit rate of zero can resume quiescent behavior. This adds
transitions in the RxInterval=0 case. robustness to all state transitions in the RxInterval=0 case.
The second is that the originating MEP (the one with a non-zero The second is that the originating MEP (the one with a non-zero
TxInterval) will ignore a DOWN state received from a zero interval TxInterval) will ignore a DOWN state received from a zero interval
peer. This means that the zero interval peer will continue to send peer. This means that the zero interval peer will continue to send
DOWN state messages as the state change is never confirmed. This adds DOWN state messages that include the RDI diagnostic code as the state
robustness to the exchange of RDI indication on a uni-directional change is never confirmed. This adds robustness to the exchange of
failure (for both session types DOWN with a diagnostic of control RDI indication on a uni-directional failure (for both session types
detection period expired offering RDI functionality). DOWN with a diagnostic of either control detection period expired or
neighbor signaled session down offering RDI functionality).
A further extension to the base specification is that there are A further extension to the base specification is that there are
additional OAM protocol exchanges that act as inputs to the BFD state additional OAM protocol exchanges that act as inputs to the BFD state
machine; these are the Link Down Indication [6] and the Lock machine; these are the Link Down Indication [5] and the Lock
Instruct/Lock Report transactions. Instruct/Lock Report transactions; Lock Report interaction being
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 (TBD) indicating that the requested
Tx rate cannot be supported. 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]. 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
detection interval is fixed at 3.5 seconds. On transition to the UP
state message periodicity changes to the negotiated rate and the
detect interval switches to detect multiplier 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 that defined in [4] to There are further defect criteria beyond those that are defined in
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 path configuration defects. The result is the criteria for a LSP direction
direction to transition from the defect free state to a defect state to transition from the defect free state to a defect state is a
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
of 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 - an LSP receiving an IP header instead of a GAL
(note there are other possibilities but these can also alias (note there are other possibilities that can also alias as an
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).
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).
4. Receiving from a correct source (as near as can be determined), 4. Receiving from a correct source (as near as can be determined),
but with incorrect session information) but with incorrect session information).
5. Receiving control packets in all discernable ways correct. 5. Receiving 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 [9] section 5.1.1.2.
When the defect is mis-branching, the transport path termination will
silently discard all non-oam traffic received. When the defect is mis-branching, the LSP termination will silently
discard all non-oam traffic received.
3.5.4. Defect exit criteria 3.5.4. Defect exit criteria
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.
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] [editors: for a future version of the document]
Exit from a mis-connectivity defect 3.5.4.3. Exit from a mis-connectivity defect
The exit criteria for a mis-connectivity defect is determined by the [Editors node: The shift to CC with interleaved CV suggests the CV
maximum of the set of min Rx session time times the multiplier that periodicity may not be known by a sink MEP, hence exit criteria from
have been received. A session can transition from DOWN to UP a mis-connectivity defect may not be able to be established. We
(independent mode) or DOWN to INIT (coordinated mode) when both suggest two possible resolutions for this:
correctly formed control packets are being exchanged, and no mis-
connected control packets have been received in the specified 1. Exit criteria is manual intervention.
interval.
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 LDI and LKI as inputs to the state machine and to clarify the include AIS with LDI set and LKI as inputs to the state machine and
behavior for independent mode. to clarify the behavior for independent mode. LKR 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 LKR as inputs to the state machine. For a session that is in AIS with LDI set and optionally LKR as inputs to the state machine.
the UP state, receipt of LDI or LKR will transition the session into For a session that is in the UP state, receipt of AIS with LDI set or
the DOWN state. optionally LKR will transition the session into the DOWN state.
[Dave: I have to think that we do not need to consider LDI/LKR for
transition from DOWN to INIT, I have to receive a BFD control packet
to do that which means the condition is cleared, only funky case is
when I'm getting both UP messages and LDI/LKR]
+--+ +--+
| | UP, ADMIN DOWN, TIMER, LDI/LKR | | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| | ADMIN DOWN,| | | | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| | | |ADMIN DOWN, DOWN,| |
| |TIMER TIMER,| | | |TIMER TIMER,| |
V |LDI/LKR LDI/LKR | V V |AIS-LDI,LKR AIS-LDI,LKR | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
Figure 4: State machine for coordinated session operation Figure 4: State machine for coordinated session operation
For independent mode, there are two state machines. One for the For independent mode, there are two state machines. One for the
source MEP (who requested MinRxInterval=0) and the sink MEP (who source MEP (who requested MinRxInterval=0) and the sink MEP (who
agreed to MinRxInterval=0). agreed to 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/LKR initialized except in the case of a forced ADMIN DOWN. Hence AIS-with
do not enter into the state machine transition from the UP state, but LDI set and optionally LKR do not enter into the state machine
do enter into the INIT and DOWN states. transition from the UP state, but do enter into the INIT and DOWN
states.
+--+ +--+
| | UP, ADMIN DOWN, TIMER | | UP, ADMIN DOWN, TIMER
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| | ADMIN DOWN | | | |ADMIN DOWN ADMIN DOWN | |
| |ADMIN DOWN, | |
| |TIMER, | | | |TIMER, | |
V |LDI/LKR | V | |AIS-LDI, | |
V |LKR | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN, DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,
+--->| | INIT, UP | |<---+ LDI/LKR +--->| | INIT, UP | |<---+ AIS-LDI, LKR
+------+ +------+ +------+ +------+
Figure 5: State machine for source MEP for independent session Figure 5: State machine for source MEP for independent session
operation operation
The sink MEP state machine (for which the transmit interval has been The sink MEP state machine (for which the transmit interval has been
set to zero) is modified to: set to zero) is modified to:
1) Permit direct transition from DOWN to UP once the session has been 1) Permit direct transition from DOWN to UP once the session has been
initialized. With the exception of via the ADMIN DOWN state, the initialized. With the exception of via the ADMIN DOWN state, the
source MEP will never transition from the UP state, hence in normal source MEP will never transition from the UP state, hence in normal
unidirectional fault scenarios will never transition to the INIT unidirectional fault scenarios will never transition to the INIT
state. state.
+--+ +--+
| | ADMIN DOWN, TIMER, LDI/LKR | | ADMIN DOWN, TIMER, AIS-LDI, LKR
| V | V
DOWN +------+ INIT, UP DOWN +------+ INIT, UP
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| | ADMIN DOWN,| | | | ADMIN DOWN,| |
| |ADMIN DOWN, TIMER, | | | |ADMIN DOWN, TIMER, | |
| |TIMER, DOWN, | | | |TIMER, DOWN, | |
V |LDI/LKR LDI/LKR | V | |AIS-LDI, AIS-LDI, | V
V |LKR LKR | |
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
Figure 6: State machine for the sink MEP for independent session Figure 6: 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
skipping to change at page 14, line 41 skipping to change at page 15, line 45
[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] Boutros, S. et al., "Definition of ACH TLV Structure", [5] Swallow, G. et al., "MPLS Fault Management OAM", draft-
draft-ietf-mpls-tp-ach-tlv-02 (work in progress), March
2010
[6] Swallow, G. et al., "MPLS Fault Management OAM", draft-
ietf-mpls-tp-fault-02 (work in progress), July 2010 ietf-mpls-tp-fault-02 (work in progress), July 2010
[6] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007
7.2. Informative References 7.2. Informative References
[7] Bocci, M., et al., "A Framework for MPLS in Transport [7] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", RFC5921, July 2010 Networks", RFC5921, July 2010
[8] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- [8] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-
swallow-mpls-tp-identifiers-02 (work in progress), July swallow-mpls-tp-identifiers-02 (work in progress), July
2010 2010
[9] Allan, D., Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM [9] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft-
Framework", draft-ietf-mpls-tp-oam-framework-06 (work in ietf-mpls-tp-oam-framework-09 (work in progress), October
progress), April 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
Email: jdrake@juniper.net Email: jdrake@juniper.net
 End of changes. 72 change blocks. 
131 lines changed or deleted 173 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/