One document matched: draft-zhang-mpls-tp-pw-oam-config-01.txt
Differences from draft-zhang-mpls-tp-pw-oam-config-00.txt
MPLS Working Group F. Zhang
Internet-Draft B. Wu
Intended status: Standards Track X. Dai
Expires: September 9, 2010 ZTE Corporation
March 08, 2010
LDP Extensions for MPLS-TP PW OAM configuration
draft-zhang-mpls-tp-pw-oam-config-01
Abstract
This document describes a procedure for the configuration of the
pseudowire (PW) virtual circuit connectivity verification (VCCV)
Bidirectional Forwarding Detection (BFD) OAM mechanism through LDP
extensions. As the other MPLS-TP PW OAM functionalities develop, the
procedure may be changed to cover them.
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.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice
Copyright (c) 2010 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
Zhang, et al. Expires September 9, 2010 [Page 1]
Internet-Draft LDP extensions for TP PW OAM March 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Operation overviews . . . . . . . . . . . . . . . . . . . . . 3
3.1. Establishment of OAM Entities and Functions . . . . . . . 4
3.2. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 5
4. LDP extensions . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. PW OAM configuration TLV . . . . . . . . . . . . . . . . . 6
4.2. Local Discriminator sub-TLV . . . . . . . . . . . . . . . 7
4.3. MEP_IDs . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. ME_IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4.1. IP Compatible ME-IDs . . . . . . . . . . . . . . . . . 8
4.4.2. ICC-based ME_IDs . . . . . . . . . . . . . . . . . . . 8
4.5. PW status TLV . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative references . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Zhang, et al. Expires September 9, 2010 [Page 2]
Internet-Draft LDP extensions for TP PW OAM March 2010
1. Introduction
This document describes a procedure for the configuration of the PW
VCCV BFD OAM mechanism through LDP extensions. As the other MPLS-TP
PW OAM functionalities develop, the procedure may be changed to cover
them.
PW VCCV provides end-to-end fault detection and diagnostics for PWs,
and currently supports the following OAM mechanisms: ICMP Ping, LSP
Ping, and BFD, as described in [RFC5085]. BFD has been chosen to
cover MPLS-TP CC functionality [base-BFD], and an extended version of
BFD, as described in [BFD-CV], can accomplish both MPLS-TP CC and CV,
even signal the AC status. BFD for VCCV supports two modes of
encapsulation - either IP/UDP encapsulated (with IP/UDP header) or
PW-ACH encapsulated (with no IP/UDP header).
The use of the VCCV control channel provides the context, based on
the MPLS-PW label, required to bind and bootstrap the BFD session to
a particular PW (FEC), see the analysis in [tp-oam-analysis]. But in
order to identify certain extreme cases of misconnectivity and fill
the requirements that the BFD mechanism MUST be the same for LSP,
(MS-)PW and Section as well as for LSP Tandem Connection and PW
Tandem Connection [BFD-CV], BFD still needs to use Discriminator
values to identify the connection being verified at both ends of the
PW.
The discriminator values can be statically configured, or signaled
via LSP-Ping [[tp-ping-bfd-procedure]. According to the requirements
in [RFC5654], "The MPLS-TP control plane MUST support the
configuration and modification of OAM maintenance points as well as
the activation/deactivation of OAM when the transport path or
transport service is established or modified", it is naturally to
extend LDP for setting up BFD or BFD extended version in order to
configure MPLS-TP CC and CV OAM functionalities during the PW setup.
2. 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 RFC2119.
3. Operation overviews
Below, extension to LDP for setting up BFD or BFD extended version
are defined in order to configure MPLS-TP CC and CV OAM
functionalities during the PW setup. PW signaling [RFC4447] defines
Zhang, et al. Expires September 9, 2010 [Page 3]
Internet-Draft LDP extensions for TP PW OAM March 2010
two FECs used to signal PWs. Of these, FEC Type 129 along with AII
Type 2 as defined in [RFC5003] fits the identification requirements
of MPLS-TP, so the current version of this draft just focus on the
P2P PW (FEC 129) along with AII type 2, P2MP PW will be studied in
the future.
The terms "ingress LER" and "egress LER" will not refer in this
document to any direction in the forwarding plane, but only to the
LER triggering the PW setup (ingress LER) and the one receiving the
mapping message (egress LER).
During the PW signaling, the Control Plane instance in the ingress
and the egress LER announces the BFD OAM Configuration TLV (inside
the interface parameters TLV carried by the mapping message,
following the VCCV parameter field), which includes the "Local
Discriminator" sub-TLV.
During the BFD session the ingress LER will use as "MyDiscriminator"
the value announced in the "Local Discriminator" (Mapping message
sent) and as YourDiscriminator" the value received in the "Local
Discriminator" (Mapping message received).
The interval value of BFD control packets both in transmission and
reception can be negotiated through BFD session itself, so the
mapping message does not need to carry these time values. In the
case BFD extended version should be configured, the ME ID and MEP ID
do not need to be carried also, for they can be deduced from the
advertised FEC(129) TLV, as described in the following sections.
3.1. Establishment of OAM Entities and Functions
Assuming there is one PW needs to be setup between LSR1 and LSR2.
(1) LSR1 MUST setup the OAM sink function to be prepared to receive
OAM messages but MUST suppress any OAM alarms (e.g., due to missing
or unidentified OAM messages). The Mapping message MUST be sent with
the "OAM Alarms Enabled" cleared, "OAM MEP Entities desired" set,
"OAM MIP Entities desired" set in the PW status code.
(2) When the Mapping message arrives at the receiver LSR2, it MUST
establish and configure OAM entities according to the OAM information
provided in mapping message. If this is not possible, a Label
Release message SHOULD be sent and neither the OAM entities nor the
PW SHOULD be established. If OAM entities are established
successfully, the OAM Source function MUST be prepared to Send OAM
messages. At the same time, LSR2 needs to setup the OAM sink
function to be prepared to receive OAM messages but MUST suppress any
OAM alarms (e.g., due to missing or unidentified OAM messages). The
Zhang, et al. Expires September 9, 2010 [Page 4]
Internet-Draft LDP extensions for TP PW OAM March 2010
Mapping message MUST be sent with the "OAM Alarms Enabled" cleared,
"OAM MEP Entities desired" set, "OAM MIP Entities desired" set in the
PW status code.
(3) When LSR1 receives the Mapping message, it completes any pending
OAM configuration and enables the OAM source function to send OAM
messages.
After this round, OAM entities are established and configured for the
PW and OAM messages MAY already be exchanged. OAM alarms can now be
enabled. The LSR1, while still keeping OAM alarms disabled sends a
LDP Notification message with "OAM Alarms Enabled" PW status flag
set. LSR2 enables the OAM alarms after processing the LDP
Notification message. LSR1 enables OAM alarms after it receives the
LDP Notification message from LSR2. Data plane OAM is now fully
functional.
3.2. Deleting OAM Entities
In some cases it may be useful to remove some or all OAM entities and
functions from one PW without actually tearing down the connection.
To avoid any spurious alarm, the following procedure should be
followed:
(1) LSR1/LSR2 SHOULD send Notification message with "OAM Alarms"
cleared but unchanged OAM configuration.
After that,
(2) LSR1 SHOULD delete OAM source functions, then send Notification
message with "OAM MEP Entities desired" and "OAM MIP Entities
desired" cleared.
(3) LSR2 SHOULD delete OAM source and sink functions, and then send
Notification message with "OAM MEP Entities desired" and "OAM MIP
Entities desired" cleared.
Then, LSR1 SHOULD delete OAM sink functions.
4. LDP extensions
Zhang, et al. Expires September 9, 2010 [Page 5]
Internet-Draft LDP extensions for TP PW OAM March 2010
4.1. PW OAM configuration 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| PHB | |V|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PW OAM configuration TLV
Type: indicates a new type, the "PW OAM Configuration TLV" (IANA to
define).
Length: indicates the total length including sub-TLVs.
Version: identifies the BFD protocol version.
PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic
continuity monitoring messages.
C: BFD CC OAM functon should be configured
V: BFD CV OAM function should be configured (C MUST be set at the
same time).
The BFD CC OAM Configuration MUST include the following sub-TLVs in
the Mapping message:
Local Discriminator" sub-TLV (described in paragraph 4.2)
The BFD CV OAM Configuration May include the following sub-TLVs
except the "Local Discriminator" sub-TLV during the Mapping message:
"ICC based ME-IDs" sub-TLV (described in paragraph 4.4.2)
If the receiving LER does not support this PW OAM configuration TLV,
it must be ignored and return a Notification message.
Zhang, et al. Expires September 9, 2010 [Page 6]
Internet-Draft LDP extensions for TP PW OAM March 2010
4.2. Local Discriminator sub-TLV
The Local Discriminator sub-TLV is depicted 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| Type (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Local Discriminator sub-TLV
Type: indicates a new type, the Local Discriminator sub TLV (1) (IANA
to define)
Length: indicates the total length of the TLV including padding.
Local Discriminator: A unique, nonzero discriminator value generated
by the transmitting system and referring to itself, used to
demultiplex multiple BFD sessions between the same pair of systems.
This Discriminator will be signaled both by the ingress LSR and the
egress LSR in the Mapping message respectively.
If the receiving LER does not support this Local Discriminator
format, it must be ignored and return a Notification message.
4.3. MEP_IDs
In order to automatically generate MEP_IDs for MPLS-TP PWs, this
draft is apt to use the AII associated with that end of the PW. The
AII is composed of three fields. These are the Global_ID, the
Prefix, and the AC_ID. The Global_ID used in this document is
identical to the Global_ID defined in [RFC5003]. The Node_ID is used
as the Prefix. The AC_ID is as defined in [RFC5003]. In this way,
the definition is in accordance with the suggestion in the draft
[tp-identifier], and there is no need to carry MEP_ID in the mapping
message.
4.4. ME_IDs
Zhang, et al. Expires September 9, 2010 [Page 7]
Internet-Draft LDP extensions for TP PW OAM March 2010
4.4.1. IP Compatible ME-IDs
In order to automatically generate ME_IDs for MPLS-TP PWs, it is
convenient to use the corresponding PW identifier. In an MPLS-TP
environment, a PW is identified by a set of identifiers which can be
mapped directly to the elements required by FEC 129 and AII Type 2,
so there is no need to carry ME_IDs in the mapping messages also.
4.4.2. ICC-based ME_IDs
ME ID for PWs MAY use the globally unique ICC-based format. This ME
ID format MAY be used to identify SME, LME, LTCME, PME and PTCME
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| ME ID Type | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ICC-based ME_ID TLV
ME ID Type: it identifies the specific format, value = TBD.
Length: indicates the total length and it is set to 20.
ME ID value: the ME ID is a string of up to thirteen characters, each
character being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9)
characters. It consists of two subfields: the ICC (as defined in
section 3) followed by a unique ME ID code (UMC). The UMC MUST be
unique within the organization identified by the ICC.
If the receiving LER does not support this ME ID format, it must be
ignored and return a Notification message.
Zhang, et al. Expires September 9, 2010 [Page 8]
Internet-Draft LDP extensions for TP PW OAM March 2010
4.5. PW status TLV
In this document, three new PW status flags are defined: "OAM Alarms
Enabled", "OAM MEP Entities desired", "OAM MIP Entities desired".
5. IANA Considerations
TBD.
6. Security Considerations
TBD.
7. Acknowledgement
The author would like to thank Hongbo Wei for his useful discussion.
8. References
8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, September 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
8.2. Informative References
[BFD-CV] Fulignoli, A., Boutros, S., and M. Vigoureux, "MPLS-TP BFD
for Proactive CC-CV and RDI", July 2009.
Zhang, et al. Expires September 9, 2010 [Page 9]
Internet-Draft LDP extensions for TP PW OAM March 2010
[base-BFD]
Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", January 2010.
[tp-identifier]
Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
July 2009.
[tp-oam-analysis]
Sprecher, N., Van Helvoort, H., Bellagamba, E., and Y.
Weingarten, "MPLS-TP OAM Analysis", March 2010.
[tp-ping-bfd-procedure]
Bahadur, N., Aggarwal, R., Nadeau, T., Sprecher, N., and
Y. Weingarten, "LSP-Ping and BFD for MPLS-TP", July 2009.
Authors' Addresses
Fei Zhang
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: zhang.fei3@zte.com.cn
Bo Wu
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877276
Email: wu.bo@zte.com.cn
Xuehui Dai
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: dai.xuehui@zte.com.cn
Zhang, et al. Expires September 9, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 04:34:38 |