One document matched: draft-fhbs-mpls-tp-cv-proactive-00.txt
MPLS Working Group A. Fulignoli (Ed)
Internet Draft Ericsson
Intended status: Informational H. van Helvoort (Ed)
Huawei
I. Busi (Ed)
Alcatel-Lucent
N.Sprecher (Ed)
Nokia Siemens Networks
Expires: August 2009 February 9, 2009
MPLS-TP Proactive Continuity and Connectivity Verification
draft-fhbs-mpls-tp-cv-proactive-00.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 Notice
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Fulignoli and al. Expires August 9, 2009 [Page 1]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
The aim of this draft is to define an MPLS-TP OAM mechanism to meet
the requirements for proactive Continuity Check and Connectivity
Verification functionality as defined in [3].
Note: this version of the draft is focused on analyzing possible
solutions and evaluating their pros&cons as well as issues. In the
next version of the draft the solution to be standardized will be
proposed using the analysis done in this version to motivate the
selection.
Table of Contents
1. Introduction.................................................3
1.1. Terminology.............................................3
2. Unique ME Identifier.........................................4
2.1. LSP ME ID IPv4 Source/Destination Address Format........5
2.2. LSP ME ID IPv6 Source/Destination Address Format........6
2.3. Type FEC128PWv4 Format..................................7
2.4. Type FEC128PWv6 Format..................................7
2.5. ICC-based Format........................................7
3. Possible Solution............................................8
3.1. Backward compatibility..................................9
4. Definition of BFDv2.........................................10
4.1. New semantic for Discriminator fields..................10
4.2. New ME ID field........................................12
5. Two different ACH encapsulation of OAM tool.................13
5.1. Current BFD with only CC functionality.................13
5.2. ACH encapsulation of the new tool......................13
5.2.1. New tool based on current BFD.....................14
5.2.2. New tool based on the extended BFD................15
5.2.3. New tool like Y.1731 CCM..........................15
6. Remote Defect Indication....................................18
7. Point to Multipoint transport paths.........................18
8. Conclusion..................................................18
9. Security Considerations.....................................19
10. IANA Considerations........................................19
11. Acknowledgments............................................19
12. References.................................................19
12.1. Normative References..................................19
12.2. Informative References................................20
Fulignoli and al. Expires August 9, 2009 [Page 2]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
1. Introduction
The aim of this draft is to define an MPLS-TP OAM mechanism to meet
the requirements for proactive Continuity Check and Connectivity
Verification functionality required in [3].
Note: this version of the draft is focused on analyzing possible
solutions and evaluating their pros&cons as well as issues. In the
next version of the draft the solution to be standardized will be
proposed using the analysis done in this version to motivate the
selection.
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. This document further expands the analysis of
possible solutions.
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 p2p and in unidirectional p2mp connection.
The mechanism MUST foresee the configuration of the transmit
frequency.
The mechanism MUST be the same for LSP, (MS-)PW and Section.
1.1. Terminology
LME LSP Maintenance Entity
ME Maintenance Entity
MEP Maintenance End Point
MIP Maintenance Intermediate Point
PME PW Maintenance Entity
SME Section Maintenance Entity
Fulignoli and al. Expires August 9, 2009 [Page 3]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
TCME Tandem Connection Maintenance Entity
TPME Tandem PW 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. Unique ME Identifier
The globally unique ME Identifier can use some of the ACH TLV objects
defined in Section 3 of [10]:
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.
Fulignoli and al. Expires August 9, 2009 [Page 4]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
[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
CV TLV.
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.
2.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ME ID Type
2 octet field; it identifies the specific format, value = TBD;
Length
Fulignoli and al. Expires August 9, 2009 [Page 5]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
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;
LSP ID
4 octets field; set to the LSP identifier.
2.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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ME ID Type
2 octet field; it identifies the specific format, value = TBD;
Length
Fulignoli and al. Expires August 9, 2009 [Page 6]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
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
4 octets field; set to the IPv6 address of the LSP destination
port/node;
LSP ID
4 octets field; set to the LSP identifier.
2.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.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).
Fulignoli and al. Expires August 9, 2009 [Page 7]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
2.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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP ID value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MEG ID |
+ (13 bytes) +
| |
+ +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ME ID Type
2 octet field; it identifies the specific format, value = TBD;
Length
2 octets field; set to 15;
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.
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.
Fulignoli and al. Expires August 9, 2009 [Page 8]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
3. Possible Solution
Several solutions have been analyzed:
1. Define a new BFD version (BFDv2) that extends the current BFD
(BFDv1) to support also CV functionality. The new BFD version can
be obtained by:
1. changing the semantic of MY discriminator and Your discriminator
fields ([8]);
2. adding a new ME ID field in the BFD packet for the CV
functionality to the existing session identifier;
2. 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 that meet all the OAM MPLS-TP requirement.
The new tool can be:
1. based on current BFD;
2. an extension of the ACH encapsulation for the current BFD;
3. a new tool like Y.1731 CCM;
All analyzed solutions imply extension of CV types, foreseen by [6]
and yet extended by[7], in order to include the MPLS-TP OAM mechanism
too. 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.
3.1. 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
Fulignoli and al. Expires August 9, 2009 [Page 9]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
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.
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 desires to interoperate with a current BFD can
apply the same discriminator field semantic as described in [8] or:
o It MUST set the My discriminator field to a nonzero value (it can
be a fixed value);
o 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.
4. Definition of BFDv2
Common to both solutions detailed in this section are the following
considerations:
o The Channel Type field of the G-ACH is the one proposed by [7]
i.e. 0x0007 indicating the raw BFD control packet;
o The version number of the protocol needs to be updated to protocol
version 2 respect to protocol version 1 defined in [8]
4.1. New semantic for Discriminator fields
As defined in [8], the mandatory Section of a BFD Control packet has
the following format:
Fulignoli and al. Expires August 9, 2009 [Page 10]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A possible BFD extension can be obtained changing the semantic of the
two 32 bit fields, My Discriminator and Your Discriminator, to form a
one 64 bit field carrying the globally unique ME Identifier as shown
in figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ME ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One of the disadvantages of this solution is on the too limited
number of octets available for the globally unique ME ID field: that
Fulignoli and al. Expires August 9, 2009 [Page 11]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
doesn't allow the possibility to have different format of ME
identifier.
4.2. New ME ID field
This solution adds the new field required for the CV functionality,
i.e. a globally unique ME Identifier section, after the mandatory
section of a BFD control packet and before the optional
Authentication section as the figure below shows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ME ID Section +
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Optional Authentication Section +
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The advantages of this solution are that the behavior of the current
BFD protocol as defined in [8] is unchanged and on the variable
length of the ME ID Section.
Fulignoli and al. Expires August 9, 2009 [Page 12]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
5. Two different ACH encapsulation of OAM tool
5.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 Section OAM and LSP
OAM.
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 |
+ +
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. ACH encapsulation of the new tool
In order to meet the MPLS-TP OAM requirement, a new tool has to be
introduced, encapsulated into the G-ACH with a new channel type code
point. Common to all solutions detailed below are the following G-ACH
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- 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];
Fulignoli and al. Expires August 9, 2009 [Page 13]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
- 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 sections below describe the format of the different possible new
tool.
5.2.1. New tool based on current BFD
A new tool can be obtained introducing a globally unique ME
Identifier TLV 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ME ID TLV
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 4 bytes represent the G-ACH as described in section 5.2.
The G-ACH is followed by the ACH TLV Header as defined in Section 2.1
of [10] and by one ACH TLV object carrying the Unique ME Identifier
Section as described in section 2.
The BFD control packet is the base BFD as described [8].
Fulignoli and al. Expires August 9, 2009 [Page 14]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
The benefit of this solution is to maintain the behavior and protocol
version of BFD as defined in[8]; however it needs some considerations
on the optional Authentication Section how described in section 9.
5.2.2. New tool based on the extended BFD
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ME ID Section +
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Optional Authentication Section +
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The solutions and considerations are the same of what described in
section 4.2. except the G-ACH Channel type code, rather than the
Version field, distinguishes between existing BFD (supporting CC) and
the new tools (supporting both CC&CV).
The Version field in this case is set to 0 (this is the first version
for this tool).
Fulignoli and al. Expires August 9, 2009 [Page 15]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
5.2.3. New tool like Y.1731 CCM
The Mandatory Section of the CC/CV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Res1 | Res2 |A|R| Res3 | Per | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ME ID Section +
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional Authentication Section may be present:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is inherited and described in [8].
Version (Vers)
4 bit field, version number of the protocol; this document defines
protocol version 0;
Reserved (Res1)
4 bit field, reserved for future use; set to all ZEROes;
Reserved (Res2)
Fulignoli and al. Expires August 9, 2009 [Page 16]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
7 bit field; reserved for future use; set to all ZEROes;
Authentication Present (A)
1 bit field; if set, the Authentication Section is present and the
session is to be authenticated;
RDI (R)
1 bit field; it is set to 1 to indicate Remote Defect Indication
otherwise it is set to 0.
Reserved (Res3)
4 bit field reserved for future use; set to all ZEROes;
Period (Per)
3 bit field; it indicates the transmission period with the encoding
shown in the following table:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| Invalid value | Invalid value for CCM PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1| 3.33 ms | 300 frames per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0| 10 ms | 100 frames per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1| 100 ms | 10 frames per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 1 s | 1 frame per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 1| 10 s | 6 frames per minute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0| 1 min | 1 frame per minute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1| 10 min | 6 frame per hour |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
1 octet field; it is the total CC/CV packet length in octet,
excluded the G-ACH header;
ME ID Section
Fulignoli and al. Expires August 9, 2009 [Page 17]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
Variable length field containing the Unique Path Identifier as
detailed in section 2.
This solution has the advantage of an easier peer interworking with
the ETH OAM.
6. Remote Defect Indication
Remote Defect Indication (RDI) is used by a MEP to notify its peer
MEP that a defect is detected on a bi-directional connection between
them([4]). RDI is only used for bidirectional connections and is
associated with proactive CC & CV packet generation.[5]
The Diagnostic (Diag) field of the Current 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 section will be completed in the next version of the draft.
For the solution in section 5.2.3. , RDI is foreseen in the packet
format with a single bit.
7. Point to Multipoint transport paths
Solution described in section 5.2.3. is valid for both bidirectional
and unidirectional connection: in unidirectional connection only
source MEP is enabled only to generate CC/CV OAM packets and sink MEP
is enabled only to receive CC/CV OAM packets.
The BFD tool has a straightforward state machine for bidirectional
path. Anyway the behavior and state machine need to be modified for
the unidirectional connection; this is described in [9].
This section will be completed in the next version of the draft.
Fulignoli and al. Expires August 9, 2009 [Page 18]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
8. Conclusion
CC and CV functionality are required to be used always together for
MPLS-TP OAM (see [3] and [5]).
For interoperability issue, a MPLS-TP node MAY support even the
current BFD tool; anyway only one tool, configurable by operator, for
OAM instance MUST run at time.
This section will be completed in the next version of the draft.
9. 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 section 5.2.1. in this case 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.
10. IANA Considerations
<Add any IANA considerations>
11. Acknowledgments
<Add any acknowledgements>
This document was prepared using 2-Word-v2.0.template.dot.
Fulignoli and al. Expires August 9, 2009 [Page 19]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
" MPLS Generic Associated Channel ", draft-ietf-mpls-tp-gach-
gal-01 (work in progress), January 2009
[3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
00 (work in progress), November 2008
[4] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., "
MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-02
(work in progress), September 2008
[5] Busi,I., Niven-Jenkins, B. "MPLS-TP OAM Framework and
Overview", draft-busi-mpls-tp-oam-framework-00(work in
progress), October 2008
[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-
02.txt, February 2008.
[8] Katz, D. and D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-08 (work in progress), March 2008.
[9] Katz, D. and D. Ward, "BFD for Multipoint Networks",
ID draft-katz-ward-bfd-multipoint-01.txt, December 2007
[10] S. Boutros, et. al., "Definition of ACH TLV Structure", draft-
bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009.
Fulignoli and al. Expires August 9, 2009 [Page 20]
Internet-Draft MPLS-TP Proactive CC&CV February 2009
12.2. Informative References
Authors' Addresses
Italo Busi (Editor)
Alcatel-Lucent
Email: italo.busi@alcatel-lucent.it
Annamaria Fulignoli (Editor)
Ericsson
Email: annamaria.fulignoli@ericsson.com
Huub van Helvoort (Editor)
Huawei Technologies
Email: hhelvoort@huawei.com
Nurit Sprecher
Nokia Siemens Networks
Email: nurit.sprecher@nsn.com
Fulignoli and al. Expires August 9, 2009 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 01:57:36 |