MPLS Working Group A. Fulignoli (Ed.)
Internet Draft Ericsson
Intended status: Informational
S. Boutros (Ed.)
Cisco Systems, Inc
M.Vigoureux (Ed.)
Alcatel-Lucent
Expires: January 2010 July 7, 2009
MPLS-TP BFD for Proactive CC-CV and RDI
draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi-01.txt
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
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. This document is subject
to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF
Documents in effect on the date of publication of this document
(http://trustee.ietf.org/license-info). Please review these
Fulignoli Expires January 7, 2010 [Page 1]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
documents carefully, as they describe your rights and
restrictions with respect to this document.
Abstract
Several documents on BFD based OAM for MPLS-TP has been put
forward and the dependencies between those drafts are not yet
fully sorted out; this document is one of these drafts. It is
published in now to make ideas, motivations and approaches
available. However we expect the final BFD based solution for
MPLS-TP will be a cooperation of the parties between the
existing drafts and that the BFD based OAM solution for MPLS-TP
will merge into an agreed set of drafts approved by the MEAD
team.
This document specifies the BFD extension and behaviour to meet
the requirements for MPLS-TP proactive Continuity Check and
Connectivity Verification functionality and the RDI
functionality as defined in [3].
Table of Contents
1. Introduction...................................................3
1.1. Terminology..................................................4
2. Trail Termination Source Identifier (TTSI) TLV Object..........4
2.1. Unique ME Identifier.........................................6
2.1.1. LSP ME ID IPv4 Source/Destination Address Format...........7
2.1.2. LSP ME ID IPv6 Source/Destination Address Format...........8
2.1.3. Type FEC128PWv4 Format.....................................9
2.1.4. Type FEC128PWv6 Format.....................................9
2.1.5. ICC-based Format...........................................9
3. Two different ACH encapsulation of BFD tool...................11
3.1. Current BFD with only CC functionality......................11
3.2. New tool based on current BFD...............................12
4. Backward compatibility........................................13
5. BFD behavior specification for MPLS-TP OAM proactive CC&CV....13
5.1. BFD State Machine...........................................14
5.2. Defect conditions...........................................18
5.2.1. Loss of Continuity defect(dLOC)...........................18
5.2.2. Mis-connectivity defect (dUNME)...........................18
5.2.3. Unexpected MEP ID defect (dUNM)...........................18
5.2.4. Unexpected Period Defect (dUNP)...........................18
5.2.5. RDI Defect (dRDI).........................................19
Fulignoli Expires January 7, 2010 [Page 2]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
5.3. Consequent action...........................................20
5.4. Administrative Down State...................................20
5.5. Timer Negotiation...........................................21
5.6. Demultiplexing and the Discriminator Fields.................22
6. Remote Defect Indication......................................22
7. BFD Control Packets field.....................................23
8. Interoperability with current BFD.............................27
9. Point to Multipoint transport paths...........................27
10. Acknowledgments..............................................28
11. Contributors.................................................28
12. IANA Considerations..........................................28
13. Security Considerations......................................28
14. References...................................................28
14.1. Normative References.......................................28
14.2. Informative References.....................................30
1. Introduction
Several documents on BFD based OAM for MPLS-TP has been put
forward and the dependencies between those drafts are not yet
fully sorted out; this document is one of these drafts. It is
published in now to make ideas, motivations and approaches
available.
However we expect the final BFD based solution for MPLS-TP will
be a cooperation of the parties between the existing drafts and
that the BFD based OAM solution for MPLS-TP will merge into an
agreed set of drafts approved by the MEAD team.
This document specifies the BFD extension and behaviour to meet
the requirements for MPLS-TP proactive Continuity Check and
Connectivity Verification functionality and the RDI
functionality as defined in [3].
As recommended in [4], the BFD tool needs to be extended for the
CV functionality by the addition of a unique identifier in order
to meet the requirements.
As described in [5], the Proactive Continuity Check (CC) and
Continuity Verification (CV) function are used together to
detect loss of continuity (LOC), unintended connectivity between
two MEs (e.g. mismerging or misconnection) as well as unintended
connectivity within the ME with an unexpected MEP. It MUST
operate both in bidirectional and unidirectional p2p and
unidirectional p2mp connection.
Fulignoli Expires January 7, 2010 [Page 3]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
The mechanism MUST foresee the configuration of the transmit
frequency.
The mechanism MUST be the same for LSP, (MS-)PW and Section as
well as for LSP Tandem Connection and PW Tandem Connection.
1.1. Terminology
LME LSP Maintenance Entity
LTCME LSP Tandem Connection Maintenance Entity
ME Maintenance Entity
MEP Maintenance End Point
MIP Maintenance Intermediate Point
PME PW Maintenance Entity
PTCME PW Tandem Connection Maintenance Entity
SME Section Maintenance Entity
TLV Type Length Value
Conventions used in this document
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].
2. Trail Termination Source Identifier (TTSI) TLV Object
The MPLS Generic Associated Channel specification (see[2]
section 3) describes the ACH TLV structure that can be used to
provide additional context information to the G-ACh packet.
Fulignoli Expires January 7, 2010 [Page 4]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
In this section the TLV Objects for providing the MEP Identifier
information and the ME Identifier information as required by[5]
are described.
[Editor's note - Some ACH TLV objects defined in this section
can be moved in future versions of [10] and referenced by future
versions of this draft]
Note: in order to simply implementations (e.g. planning
processing resources), especially when BFD implementation is
hardware-assisted, it would be desirable to define the maximum
possible length for the all ACH TLV objects.
The TTSI TLV Object in figure below consists of the MEP-ID
followed by the Unique ME identifier TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTSIAchTlvType = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP ID value |Reserved ( fixed to all ZEROs) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unique ME ID TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
2 octets field; it specifies the number of octets which follows
the Length field.
MEP ID value
13-bit integer value field, identifying the transmitting MEP
within the ME. The three MSBs of the first octet are not used
and set to ZERO.
Unique ME ID
This is the ME Identifier TLV Object as described in section
2.1.
Fulignoli Expires January 7, 2010 [Page 5]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
2.1. Unique ME Identifier
The globally unique ME Identifier ACH TLV objects have the
following structure :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ME ID Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ME ID Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ME ID Type
2 octet field; it identifies the format of the ME Identifier;
Length
2 octets field; it identifies the length in octets of the ME ID
Section that follows the length field.
ME ID payload
value of the ME identifier; its semantic depends on the format.
The ME Identifier Type transmitted and expected MUST be the same
at both MEPs. For statically provisioned connections, the ME
Identifier transmitted and expected is statically configured at
both MEPs. For dynamically established connections, the ME
Identifier transmitted and expected is signaled via the control
plane. The extension of ME identifier signaling is outside the
scope of this document.
Some possible ME Identifier formats are reported in the
following sections.
Fulignoli Expires January 7, 2010 [Page 6]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
2.1.1. LSP ME ID IPv4 Source/Destination Address Format
This ME ID format MAY be used to identify an LME (as defined in
[5]) where IPv4 addresses are used to identify the LERs
terminating the LSP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ME ID Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Index | TunnelInstance Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ME ID Type
2 octet field; it identifies the specific format, value = TBD;
Length
2 octets field; set to 12 (octets);
IPv4 source address
4 octets field; set to the IPv4 address of the LSP source
port/node;
IPv4 destination address
4 octets field; set to the IPv4 address of the LSP destination
port/node;
TunnelIndex
2 octets field as defined in RFC 3812
Fulignoli Expires January 7, 2010 [Page 7]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
TunnelInstance Index
2 octets field as defined in RFC 3812
2.1.2. LSP ME ID IPv6 Source/Destination Address Format
This ME ID format MAY be used to identify an LME (as defined in
[5]) where IPv6 addresses are used to identify the LERs
terminating the LSP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ME ID Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 source address |
~ (16 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 destination address |
~ (16 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Index | TunnelInstance Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ME ID Type
2 octet field; it identifies the specific format, value = TBD;
Length
2 octets field; set to 36 (octets);
IPv6 source address
4 octets field; set to the IPv6 address of the LSP source
port/node;
IPv6 destination address
Fulignoli Expires January 7, 2010 [Page 8]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
4 octets field; set to the IPv6 address of the LSP destination
port/node;
TunnelIndex
2 octets field as defined in RFC 3812
TunnelInstance Index
2 octets field as defined in RFC 3812
2.1.3. Type FEC128PWv4 Format
This TLV is defined in [10]. It contains a PW ID that terminates
on a PE identified by an IPv4 address.
This ME ID format MAY be used to identify a PME (as defined in
[5]) where IPv4 addresses are used to identify the T-PEs
terminating the PW and FEC128 is used to identify the PW.
2.1.4. Type FEC128PWv6 Format
This TLV is defined in [10]. It contains a PW ID that terminates
on a PE identified by an IPv6 address.
This ME ID format MAY be used to identify a PME (as defined in
[5]) where IPv6 addresses are used to identify the T-PEs
terminating the PW and FEC128 is used to identify the PW.
Editor's note: implementation impacts of FEC129PWv4 and
FEC129PWv6 ( as defined in [10])when used as ME Identifier in a
cc-cv proactive tool needs further study (see note in section 2
regarding length of ME ID).
2.1.5. ICC-based Format
This ME ID format MAY be used to identify SME, LME, LTCME, PME
and PTCME(as defined in [5]) independently on LER/T-PE
addressing schemes as well as of the FECs used to identify the
PW.
Fulignoli Expires January 7, 2010 [Page 9]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
Editor's note: for these reasons it is suggested to have this
format as a MUST and the other format as optional in the MPLS-TP
environment.
EndofEditornote
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ME ID Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MEG ID |
+ (13 bytes) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ME ID Type
2 octet field; it identifies the specific format, value = TBD;
Length
2 octets field; set to 16;
MEG ID value
13-octet field. Refer to Annex A of ITU-T Recommendation Y.1731
for the format used for the MEG ID field with ICC-based format.
Editor's note: to decide if insert all ICC-based MEG ID format
(as for Figure A-2 of Y.1731 or only the MEG-ID value as
reported now in above figure EndofEditornote
Fulignoli Expires January 7, 2010 [Page 10]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
3. Two different ACH encapsulation of BFD tool
Among the solutions analyzed in [11], the one based on two
separate tools, running with two different ACH encapsulations
(i.e. two different ACH channel types):
o the current BFD with only CC functionality;
o a new tool based on current BFD that meet all the OAM MPLS-TP
requirement.
is proposed in this document as the solution to be standardized.
As all analyzed solutions reported in [11], even this one
implies extension of CV types, foreseen by [6] and yet extended
by[7], in order to include the MPLS-TP OAM mechanism too for PW
Fault Detection only. This is due to the fact that VCCV also
includes mechanisms for negotiating the control channel and
connectivity verification (i.e. OAM functions) between PEs.
This version of the draft is focused on fault detection on the
transport path.
3.1. Current BFD with only CC functionality
The current BFD, with only CC functionality, is encapsulated in
the G-ACH using as Channel type code point the 0x0007 value as
described in [7]. This mechanism can be even extended to SME,
LME, LTCME and PTCME.
Figure below shows G-ACH encapsulation of current BFD as in [7]
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 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| BFD control packet |
+ +
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fulignoli Expires January 7, 2010 [Page 11]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
3.2. New tool based on current BFD
The new tool is obtained introducing TTSI TLV , described in
section 2. between the ACH and the current BFD (defined in [8])
as detailed below.
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 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TTSI TLV
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first four bytes represent the G-ACH ([2]).
- first nibble: set to 0001b to indicate a channel associated
with a PW, a LSP or a Section;
- Version and Reserved fields are set to 0, as specified in[2]
[2];
- G-ACH Channel Type field with a new TBD code point meaning
"MPLS-TP CC-CV proactive" indicating that the message is an
MPLS-TP OAM CC-CV proactive message. The value MUST be assigned
The G-ACH is followed by the ACH TLV Header as defined in
Section 3 of [2] and by one and only one TTSI ACH TLV object
carrying the MEP Identifier and the Unique ME Identifier
Information. ( see section 2. )
Fulignoli Expires January 7, 2010 [Page 12]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
The IP-based addressing ACH TLV objects ( see [10]) that allow
the usage if this tool also within an IP/MPLS environment can be
even present. In any case the TTSI ACH TLV object MUST be always
carried in the last ACH TLV object ( i.e just before the BFD
packet).
The BFD control packet is the base BFD as described [8].
The benefit of this solution is to maintain the base behavior
and protocol version of BFD as defined in[8] and in [9];
however, it's necessary to define some rules that specify the
BFD profile for MPLS-TP application as detailed in the next
sections.
The proposed solutions needs even some considerations on the
optional Authentication Section how described in section 10.
From now on this solution is referred as extended BFD.
4. Backward compatibility
For backward compatibility, it is still possible to run the
current BFD that supports only CC functionality on some
transport paths and the new tool that supports CC and CV
functionality on other transport paths. In any case, only one
tool for OAM instance at time, configurable by operator, can
run.
A MEP that is configured to support CC and CV functionality, as
required by MPLS-TP, MUST be capable to receive existing BFD
packets (encapsulated with GAL/G-ACH or PW-ACH) that supports
only CC functionality and MUST consider them as an unexpected
packet, i.e. detect a misconnection defect.
5. BFD behavior specification for MPLS-TP OAM proactive CC&CV
In this section some rules that specify the MPLS-TP application
of the extended BFD is detailed. These rules apply even for the
base BFD, limited to the CC functionality only, when an MPLS-TP
node interoperates with MPLS legacy nodes or when only the CC
functionality is required .
Fulignoli Expires January 7, 2010 [Page 13]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
The BFD control packet is the base BFD as described in [8].
The extended BFD MUST operate both in bidirectional and
unidirectional p2p and unidirectional p2mp connection.
This version of the draft is focused on unidirectional and
bidirectional p2p connection of the MPLS-TP CC-CV proactive
tool.
Unidirectional p2mp connections are even reported but it
requires further analysis.
In this document the BFD operating mode is always Asynchronous;
in this mode the systems send CC/CV BFD packets, carrying a
unique ME identifier and sender MEP identifier, at regular
configurable timing rate. If a LOC defect or a mis-connectivity
defect or a period mis-configuration defect occurs, the BFD
session is declared down. For proactive CC-CV functionality
description please refers to [5].
5.1. BFD State Machine
The BFD State Machine is described in [8] for bidirectional p2p
connection and in [9] for p2mp unidirectional connection.
The main goals in defining the state machine for MPLS-TP
extended BFD are:
1. to interoperate with the state machines defined in [8] and in
[9];
2. to satisfy the CC-CV proactive monitoring functionality and even
the RDI functionality as specified in the MPLS-TP OAM framework
[5].
The diagram in Figure 1 provides an overview of the state
machine for MEP configured on p2p bidirectional transport path,
as defined in [8].
Fulignoli Expires January 7, 2010 [Page 14]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
+--+
| | UP, ADMIN DOWN, Defects,
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |Defects Defects | |
V | | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Figure 1: State Machine for p2p bidirectional connection
The diagram in Figure 2 provides an overview of the state
machine for MEP Sink of unidirectional p2p unidirectional
transport path based on the state machine defined in [9];
Fulignoli Expires January 7, 2010 [Page 15]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
(DOWN), ADMIN DOWN,
+------+ Defects +------+
+----| |<---------------------| |----+
(DOWN)| | DOWN | | UP | |UP
ADMIN DOWN,+--->| |--------------------->| |<---+
Defects +------+ UP +------+
Figure 2: State Machine for p2p unidirectional connection
State transitions on MEP Source on unidirectional p2p path are
administratively driven.
In both diagram, each arc represents the state of the remote
system (as received in the State field in the BFD Control
packet) or indicates the expiration of the Detection Timer, here
extended to general defect raising and clearing conditions as
reported in Table 1.
As reported in [8], another state (AdminDown) exists so that a
session can be administratively put down indefinitely. In the
above diagram Transitions involving AdminDown state are deleted
for clarity; further considerations are reported in section 5.4.
Editor's note:
. It is suggested to introduce the following new bfd.SessionType
in [9]:
o MPLS-TP bidirectional p2p: Transport Profile of the
Classic point-to-point BFD .
o MPLS-TP unidirectional Sink
o MPLS-TP unidirectional Source
. In [9] DOWN State in received BFD is even reported. It is
suggested to remove it from [9] as well as from Figure 3 as
State transitions on MEP Source on unidirectional p2p and p2mp
path are administratively driven .
. If in Figure 1 we assume that
o a MPLS-TP node transits from DOWN to UP State even when
receiving UP State and not only INIT State and that
Fulignoli Expires January 7, 2010 [Page 16]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
o a Source MEP of a unidirectional path only transmits BFD
packets in UP state or AdminDown State, the diagram in
Figure 2 becomes a ''sub-branch'' of state machine reported
in Figure 1
EndofEditor's note
. The ''Defects Raise'' and ''Defects Clear'' Event in Figure 1 and
Figure 2 occurs when:
o Defect Raise Event = dLOC or dUNME or dUNM or dUNP;
o Defect Clear Event = (not dLOC)and(not dUNME)and(not
dUNM)and (not dUNP);
o See section 5.2. for defect conditions description.
. When on a configured bidirectional MEP the proactive CC-CV
monitoring is enabled, the MEP sends the CC/CV BFD packet with
frequency of the configured transmission period and it also
expects to receive the CC/CV BFD packets from its peer MEP with
the same transmission period (see [5]).
. In a unidirectional (point-to-point or point-to-multipoint)
transport path , where the proactive CC-CV monitoring is
enabled, only the Source MEP is enabled to generate CC/CV BFD
packets with frequency of the configured transmission period and
always with UP State information . This MEP does not expect to
receive any CC/CV BFD packets from its peer MEP in the ME
. a MEP Sink, configured on a unidirectional transport path where
the proactive CC-CV monitoring is enabled, expects to receive
the CC/CV BFD packets from its peer MEP at the configured
period; the defects detection procedure is the same as the
bidirectional MEP; no CC/CV BFD packets are sent on the ME.
It is worth noticing that CC-CV proactive monitoring can be
enabled/disabled by an operator on a configured ME and this MUST be
not traffic affecting. Please refers to [5] for hitless
enable/disable CC-CV proactive monitoring procedure.
When a BFD session transits from one state to another, the traffic
MUST not be affected. The blocking of traffic as consequent action
MUST be driven only by a defect's consequent action as specified in
the consequent action section 5.3.
Fulignoli Expires January 7, 2010 [Page 17]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
When the CC-CV proactive monitoring is disabled on a ME no CC/CV
BFD packets are sent on the ME neither defects are monitored;
however, the MEP must terminate all OAM packets it receives and in
case of CC-CV proactive packets it must recognize a mis-
connectivity even if the CC-CV proactive monitoring is disabled on
the MEP.
5.2. Defect conditions
Defect triggered at the MPLS-TP layer by the CC-CV proactive
tool are reported in this section.
5.2.1. Loss of Continuity defect(dLOC)
If no CC/CV BFD packets from a peer MEP are received within the
interval equal to K times (see Table 1) the receiving MEP's
configured CC-CV transmission period, loss of continuity with
peer MEP is detected.
5.2.2. Mis-connectivity defect (dUNME)
If an extended BFD with a ME ID different than the configured
expected one is received , mis-connectivity defect is detected.
5.2.3. Unexpected MEP ID defect (dUNM)
If a CC-CV BFD packet with expected ME ID but with an incorrect
MEP ID, including the receiving MEP's own MEP ID, is received,
Unexpected MEP is detected.
5.2.4. Unexpected Period Defect (dUNP)
If a CC-CV BFD packet is received with a correct ME ID, a
correct MEP ID, but with a period field value different than the
receiving MEP's own CC-CV transmission period, Unexpected Period
is detected.
Fulignoli Expires January 7, 2010 [Page 18]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
5.2.5. RDI Defect (dRDI)
The Remote Defect Indicator defect monitors the presence of an
RDI maintenance signal. A MEP detects RDI defect when it
receives a CC/CV BFD packet with the RDI field set.
The following Table summarizes the defect raising and clearing
conditions
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Defect |Raising Condition |Clearing Condition |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dLOC |#Rx BFD==0 (K*CV_Period) |#Rx BFD >= N (K*CV_Period) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dUNME |Unexpected ME Identifier |#UnexpMEId==0 (K*CV_Period) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dUNM |Unexpected MEP Id |#UnexpMEPId==0 (K*CV_Period) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dUNP |Unexpected Period |#UnexpPeriod==0 (K*CV_Period)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dRDI | Rx RDI == 1 | Rx RDI ==0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 1: Table of Raising Clearing Defect Conditions
In Table 1, N and K are protocol constants to be defined; the
CV_Period corresponds to the configured transmission period;
K value is stored in bfd.DetectMult variable while the CV_Period
is stored bfd.DesiredMinTxInterval variable and carried in the
relative BFD packet fields.
Fulignoli Expires January 7, 2010 [Page 19]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
5.3. Consequent action
. If a MEP detects an unexpected ME Identifier, or an unexpected
MEP, it MUST block (BLK) all the traffic (including also the
user data packets) that it receives from the misconnected
transport path.
. If a MEP detects LOC defect and the CC-CV monitoring is enabled
it MUST block (BLK) all the traffic (including also the user
data packets) that it receives from the misconnected transport
path. This consequent action is configurable (see [5])
. If a MEP detects an unexpected ME Identifier, or an unexpected
MEP it MUST declare a Transport Path Fail (TSF).
. If a MEP detects LOC defect and the CC-CV monitoring is enabled
it MUST declare a Transport Path Fail (TSF).
. If a MEP declare a Transport Path Fail it MUST insert an RDI
information towards its peer MEP in a bidirectional connection
Consequent actions are identified by abbreviation prefixed with
an 'a': aXXX, e.g. aTSF. The consequent actions detailed above
can be so summarized :
aBLK <-- (dUNME or dUNM) or (dLOC and CC-
CV_Monitoring_Enabled and LOC_cons_action_Enabled)
aTSF <-- (dLOC and CC-CV_Monitoring_Enabled)or dUNME or dUNM
or Server_SF
aRDI <-- aTSF
5.4. Administrative Down State
As reported in[8]: ''a session MAY be kept administratively down
by entering the AdminDown state and sending an explanatory
diagnostic code in the Diagnostic field. AdminDown state means
that the session is being held administratively down. This
causes the remote system to enter Down state, and remain there
until the local system exits AdminDown state. AdminDown state
has no semantic implications for the availability of the
forwarding path.''
Fulignoli Expires January 7, 2010 [Page 20]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
Please not that the AdminDown state semantic MUST be not
confused with the LOCK functionality as reported in [3]. In this
document the AdminDown state semantic is equivalent to disabling
on a MEP the CC-CV proactive monitoring; in this case the source
MEP SHOULD send BFD Control packets in AdminDown state for a
period equal to(bfd.DesiredMinTxInterval * bfd.DetectMult) in
order to ensure that the remote system is aware of the state
change.
An MPLS-TP MEP receiving a BFD packet with AdminDown State MUST
transit to the DOWN State and report the event to the operator.
Editor's note:
In this case the operator should disable the functionality even
on the other node. Should the node still report the LOC defect ?
If Yes the AdminDown State received can be a simple
report/warning to the operator.
End editor's note
5.5. Timer Negotiation
The negotiation of time value foreseen by the base BFD (see [8])
MUST be disabled on the MPLS-TP extended BFD. The timer
negotiation should be even disabled on an MPLS-TP node that runs
only the CC functionality as well as on a node that
interoperates with current BFD. It's up to the operator
configure the BFD transmission period on the MPLS-TP node in a
way that is suitable for the MPLS legacy node.
The configured BFD packet transmission period MUST be stored
into the bfd.DesiredMinTxInterval variable and carried into the
''Desired Min TX Interval field'' of the transmitted BFD
For a bidirectional point-to-point transport path the same
bfd.DesiredMinTxInterval value MUST be stored even in
bfd.RequiredMinRxInterval; source MEP of unidirectional session
MUST set the bfd.RequiredMinRxInterval to 0.
The bfd.DesiredMinRxInterval value is carried into the ''Required
Min RX Interval field '' of the transmitted BFD.
If BFD packets are received with the ''Desired Min TX Interval
field '' different from than expected and stored in the local
Fulignoli Expires January 7, 2010 [Page 21]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
bfd.DesiredMinTxInterval variable the Unexpected Period defect
is detected.
Please note that this behavior doesn't preclude the base BFD
session running on a MPLS legacy node to adapt to the BFD timers
transmitted by an MPLS-TP node.
The configured transmission period MUST be one of the following
values, both for the extended BFD and current BFD running on a
MPLS-TP node:
. 3.33 ms: Default transmission period for protection switching
application (transmission rate of 300 packets/second);
. 10 ms: (Transmission rate is 100 packets/second);
. 100 ms: Default transmission period for performance monitoring
application (transmission rate of 10 packets/second);
. 1 s: Default transmission period for fault management
application (transmission rate of 1 packets/second).
5.6. Demultiplexing and the Discriminator Fields
The context of MPLS-TP OAM packets is based on MPLS label and G-
ACH, eliminating in the BFD the need to exchange Discriminator
values.
An MPLS-TP node that interoperates with a base BFD can apply the
same discriminator field semantic as described in [8] or:
. It MUST set the My discriminator field to a nonzero value (it
can be a fixed value);
. It MUST reflect back the received value of My discriminator
field into the transmitted Your discriminator field, or set it
to zero if that value is unknown.
6. Remote Defect Indication
The Remote Defect Indication (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 for
bidirectional connections and is associated with proactive CC &
CV packet generation.[5]
Fulignoli Expires January 7, 2010 [Page 22]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
Editor's note: in last version of MPLS-TP OAM requirement
([3])the RDI functionality is now even for unidirectional
connection if a return path exist. However this implies a
further analysis
End of Editor's note
The Diagnostic (Diag) field of base BFD ([8]) can be used for
this functionality. However, there isn't a total correspondence
among the values foreseen by [8] and the defect conditions
detected by the proactive CC-CV tool that require the RDI
function. A solution could be that any defect that requires the
RDI information being sent to the peer MEP is encoded in the
Diagnostic (Diag) field with the value 1 (corresponding to the
''Control Detection Time Expired'' in [8]). The value 0 indicates
RDI condition has been cleared.
This applies for the extended BFD and for the base BFD when a
MPLS-TP node runs only the CC functionality
7. BFD Control Packets field
As defined in [8], the mandatory Section of a BFD Control packet
has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fulignoli Expires January 7, 2010 [Page 23]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
The contents of transmitted and expected BFD Control packets on
a MPLS-TP node for the mechanism proposed in this document are
detailed below both for extended BFD as well as current BFD:
Version
Set to the current version number (1). If version number is not
correct the packet is discarded.
Diagnostic (Diag)
The following value are requested to be supported among the
value reported in [8]:
0 -- No Diagnostic
1 -- Remote Defects Indication
3 -- Neighbor Signaled Session Down
7 -- Administratively Down
Different values are ignored in receipt.
State (Sta)
The current BFD session state as seen by the transmitting
system. Values are:
0 -- AdminDown
1 -- Down
2 -- Init
3 -- Up
Poll (P)
If set, the transmitting system is requesting verification of
connectivity, or of a parameter change, and is expecting a
packet with the Final (F) bit in reply. If clear, the
transmitting system is not requesting verification.
Fulignoli Expires January 7, 2010 [Page 24]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
Final (F)
If set, the transmitting system is responding to a received BFD
Control packet that had the Poll (P) bit set. If clear, the
transmitting system is not responding to a Poll.
Control Plane Independent (C)
Is not required to be supported on a MPLS-TP node. Set to 1 on
transmit and ignored in receipt.
Authentication Present (A)
Set to 1 if authentication is in use on this session
(bfd.AuthType is nonzero), or 0 if not.
Demand (D)
Set to 0 in asynchronous mode.
Multipoint (M)
Set to 1 if bfd.SessionType is MultipointHead (Source MEP of a
point to multipoint connection). Otherwise it is set to 0.
Detect Mult
Detection time multiplier. The configured transmit interval,
multiplied by this value, provides the Detection Time for the
transmitting system in Asynchronous mode. This is the K protocol
constants as defined in Table 1.
Length
Set to the appropriate length, in bytes, of the only BFD Control
packet, based on the fixed header length (24) plus any
Authentication Section.
Fulignoli Expires January 7, 2010 [Page 25]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
My Discriminator
A unique, nonzero discriminator value generated by the
transmitting system. See section 5.6.
Your Discriminator
The discriminator received from the corresponding remote system.
This field reflects back the received value of My Discriminator,
or is zero if that value is unknown. See section 5.6.
Desired Min TX Interval
This is the configured BFD packet transmission period, in
microseconds and stored into the bfd.DesiredMinTxInterval
variable. See section 5.5.
Required Min RX Interval
This is the configured BFD packet period, in microseconds and
stored into the bfd.RequiredMinRxInterval variable. Source MEP
of unidirectional session MUST set it to 0 See section 5.5.
Required Min Echo RX Interval
Is not required to be supported on a MPLS-TP node; set to 0.
An optional Authentication Section MAY be present. For details
see section 10.
Fulignoli Expires January 7, 2010 [Page 26]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
8. Interoperability with current BFD
There's no interoperability issue among a MPLS-TP node running
the current BFD, with the rules defined in previous sections,
and legacy MPLS node at PW layer network level as the use of the
CC Type 1 was previously defined and limited to PWs. (See [7])
Instead, any Network Partitioning scenario with LSP Stitching
present interoperability issues as LSP Ping is designated to
bootstrap the BFD session in an MPLS environment and the session
BFD messages for MPLS are transmitted using a IP/UDP
encapsulation (see [12] and [4]); the IWF requires further
analysis.
This section will be completed in the next version of the draft.
9. Point to Multipoint transport paths
Solution described in section 3.2. is also valid for p2mp
connections. The extended multipoint BFD packets are explicitly
marked as such, via the setting of the M bit (see [9]).
The diagrams reported Figure 2 provides also an overview of the
state machine for MEP Sink configured on each tail of a p2mp
path.
MEP Source, head of unidirectional p2mp, will never receive
packets and have no Detection Timer, and as such all state
transitions are administratively driven.
The MEP Source sends the extended multipoint BFD packet in the
multicast tree at a configured transmission period.
A unidirectional point-to-multipoint connection containing n
end-points contains (n-1) MEs, each one independently monitored
by MEP Sink configured on each tail as described in section 5.
Editor's note:
. It is suggested to introduce the following new bfd.SessionType
in [9]:
oMPLS-TP MultipointHead: Transport Profile of
MultipointHead
Fulignoli Expires January 7, 2010 [Page 27]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
oMPLS-TP MultipointTail: Transport Profile of
MultipointTail
EndofEditor's note
This section requires further analysis.
10. Acknowledgments
<Add any acknowledgements>
This document was prepared using 2-Word-v2.0.template.dot.
11. Contributors
12. IANA Considerations
<Add any IANA considerations>
13. Security Considerations
Base BFD [8] foresees an optional authentication section; that
can be extended even to the tool proposed in this document.
Authentication methods that require checksum calculation on the
outgoing packet must extend the checksum even on the ME
Identifier Section. This is possible but seems uncorrelated with
the solution proposed in this document: it could be better to
use the simple password authentication method.
It is also worth noticing that the interactions between
authentication and connectivity verification need further
analysis.
14. References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bocci, et al., " MPLS Generic Associated Channel ", RFC
5586 , June 2009
Fulignoli Expires January 7, 2010 [Page 28]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
[3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM
in MPLS Transport Networks", draft-ietf-mpls-tp-oam-
requirements-01 (work in progress), March 2009
[4] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten,
Y., " MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-
analysis-04 (work in progress), May 2009
[5] Busi,I., Niven-Jenkins, B. "MPLS-TP OAM Framework and
Overview", draft-ietf-mpls-tp-oam-framework-00(work in
progress), March 2009
[6] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007
[7] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)",ID draft-ietf-pwe3-vccv-
bfd-04.txt, Work in Progress, May 2009
[8] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-09.txt (work in progress),
February 2009.
[9] Katz, D. and D. Ward, "BFD for Multipoint Networks",
ID draft-katz-ward-bfd-multipoint-02.txt, February 2009
[10] S. Boutros, et. al., "Definition of ACH TLV Structure",
draft-bryant-mpls-tp-ach-tlv-00.txt, Work in
Progress, January 2009.
[11] A. Fulignoli, et. al.,''MPLS-TP Proactive Continuity and
Connectivity Verification'', draft-fhbs-mpls-tp-cv-
proactive-00.txt (work in progress), February 2009
[12] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work
in progress), June 2008.
[13] Martini, L.and M.Morrow, ''Pseudo Wire (PW) OAM Message
Mapping'', draft-eitd-pwe3-oam-msg-map-10 (work in
progress), April 2009
Fulignoli Expires January 7, 2010 [Page 29]
Internet-Draft MPLS-TP Proactive CC&CV July 2009
14.2. Informative References
Authors' Addresses
Annamaria Fulignoli (Editor)
Ericsson
Email: annamaria.fulignoli@ericsson.com
Sami Boutros
Cisco Systems, Inc.
Email: sboutros@cisco.com
Martin Vigoureux
Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.com
Fulignoli Expires January 7, 2010 [Page 30]