MPLS Working Group E. Bellagamba, Ed.
Internet-Draft L. Andersson, Ed.
Intended status: Standards Track Ericsson
Expires: June 13, 2011 P. Skoldstrom, Ed.
Acreo AB
D. Ward
Juniper
December 10, 2010
Configuration of pro-active MPLS-TP Operations, Administration, and
Maintenance (OAM) Functions Using LSP Ping
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-00
Abstract
This specification describes the configuration of pro-active MPLS-TP
Operations, Administration, and Maintenance (OAM) Functions for a
given LSP using a common set of TLVs that is carried on LSP Ping.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 13, 2011.
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
(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
Bellagamba, et al. Expires June 13, 2011 [Page 1]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 3
1.3. Overview of BFD OAM operation . . . . . . . . . . . . . . . 4
2. Overview of MPLS OAM for Transport Applications . . . . . . . . 4
3. Theory of Operations . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS OAM Configuration Operation Overview . . . . . . . . . 5
3.2. TLVs structure . . . . . . . . . . . . . . . . . . . . . . 5
3.3. MPLS OAM SOURCE MEP-ID TLV for LSP Ping . . . . . . . . . . 6
4. BFD OAM configuration errors . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Bellagamba, et al. Expires June 13, 2011 [Page 2]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
1. Introduction
This document describes the configuration of pro-active MPLS-TP
Operations, Administration, and Maintenance (OAM) Functions for a
given LSP using a common set of TLVs that can be carried on either
RSVP-TE [RFC3209] or LSP Ping [BFD-Ping]. In particular it specifies
the mechanisms necessary to establish MPLS-TP OAM entities monitoring
an LSP and defines information elements and procedures to configure
pro-active MPLS OAM functions. Initialization and control of on-
demand MPLS OAM functions are expected to be carried out by directly
accessing network nodes via a management interface; hence
configuration and control of on-demand OAM functions are out-of-scope
for this document.
Because the Transport Profile of MPLS, by definition [RFC5654], must
be capable of operating without a control plane, there are two
options for in-band OAM: by using an NMS or by using LSP-Ping if a
control plane is not instantiated.
Pro-active MPLS OAM is based on the Bidirectional Forwarding
Detection (BFD) protocol [BFD]. Bidirectional Forwarding Detection
(BFD), as described in [BFD], defines a protocol that provides low-
overhead, short-duration detection of failures in the path between
two forwarding engines, including the interfaces, data link(s), and
to the extent possible the forwarding engines themselves. BFD can be
used to track the liveliness and detect data plane failures of
MPLS-TP point-to-point and might also be extended to p2mp
connections.
MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that
enables operational models typical in transport networks, while
providing additional OAM, survivability and other maintenance
functions not currently supported by MPLS. [MPLS-TP-OAM-REQ] defines
the requirements for the OAM functionality of MPLS-TP.
BFD has been chosen to be the basis of pro-active MPLS-TP OAM
functions. MPLS-TP OAM extensions for transport applications, for
which this document specifies the configuration, are specified in
[BFD-CCCV], [MPLS-PM], and [MPLS-FMS].
1.1. Contributing Authors
The editors gratefully acknowledge the contribution of John Drake.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Bellagamba, et al. Expires June 13, 2011 [Page 3]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Overview of BFD OAM operation
BFD is a simple hello protocol that in many respects is similar to
the detection components of well-known routing protocols. A pair of
systems transmits BFD packets periodically over each path between the
two systems, and if a system stops receiving BFD packets for long
enough, some component in that particular bidirectional path to the
neighboring system is assumed to have failed. Systems may also
negotiate to not send periodic BFD packets in order to reduce
overhead.
A path is only declared to be operational when two-way communication
has been established between systems, though this does not preclude
the use of unidirectional links to support bidirectional paths (co-
routed or bidirectional or associated bidirectional).
Each system estimates how quickly it can send and receive BFD packets
in order to come to an agreement with its neighbor about how rapidly
detection of failure will take place. These estimates can be
modified in real time in order to adapt to unusual situations. This
design also allows for fast systems on a shared medium with a slow
system to be able to more rapidly detect failures between the fast
systems while allowing the slow system to participate to the best of
its ability.
The ability of each system to control the BFD packet transmission
rate in both directions provides a mechanism for congestion control,
particularly when BFD is used across multiple network hops.
As recommended in [BFD-CCCV], the BFD tool needs to be extended for
the proactive CV functionality by the addition of an unique
identifier in order to meet the requirements. The document in [BFD-
CCCV] specifies the BFD extension and behavior to meet the
requirements for MPLS-TP proactive Continuity Check and Connectivity
Verification functionality and the RDI functionality as defined in
[MPLS-TP-OAM-REQ].
2. Overview of MPLS OAM for Transport Applications
[MPLS-TP-OAM-FWK] describes how MPLS OAM mechanisms are operated to
meet transport requirements outlined in [MPLS-TP-OAM-REQ].
[BFD-CCCV] specifies two BFD operation modes: 1) "CC mode", which
uses periodic BFD message exchanges with symmetric timer settings,
supporting Continuity Check, 2) "CV/CC mode" which sends unique
Bellagamba, et al. Expires June 13, 2011 [Page 4]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
maintenance entity identifiers in the periodic BFD messages
supporting Connectivity Verification as well as Continuity Check.
[MPLS-PM] specifies mechanisms for performance monitoring of LSPs, in
particular it specifies loss and delay measurement OAM functions.
[MPLS-FMS] specifies fault management signals with which a server LSP
can notify client LSPs about various fault conditions to suppress
alarms or to be used as triggers for actions in the client LSPs. The
following signals are defined: Alarm Indication Signal (AIS), Link
Down Indication (LDI) and Locked Report (LKR). To indicate client
faults associated with the attachment circuits Client Signal Failure
Indication (CSF) can be used. CSF is described in [MPLS-TP-OAM-FWK]
and in the context of this document is for further study.
[MPLS-TP-OAM-FWK] describes the mapping of fault conditions to
consequent actions. Some of these mappings may be configured by the
operator, depending on the application of the LSP. The following
defects are identified: Loss Of Continuity (LOC), Misconnectivity,
MEP Misconfiguration and Period Misconfiguration. Out of these
defect conditions, the following consequent actions may be
configurable: 1) whether or not the LOC defect should result in
blocking the outgoing data traffic; 2) whether or not the "Period
Misconfiguration defect" should result a signal fail condition.
3. Theory of Operations
3.1. MPLS OAM Configuration Operation Overview
Refer to section 3.1 of [RSVP-TE CONF] for the applicability
scenarios description and their related configurations and
mechanisms. In fact, each of them can be completely reused in case
of LSP Ping configuration as well as already done for RSVP-TE.
The only exception is that LSP Ping needs an extra TLV to carry the
information required for the "CV/CC mode" OAM [BFD-CCCV] and defined
in [MPLS-TP-IDENTIF]. Such information is supplied by an additional
sub-TLV as defined in section 3.3.
3.2. TLVs structure
LSP Ping follows the same TLV structure defined for RSVP-TE in
[RSVP-TE CONF] from section 3.2 to section 3.6.
In addition, an extra TLV is defined "MPLS OAM SOURCE MEP-ID TLV" in
order to supply the information needed for the Connectivity
Verification functionality. In fact, RSVP-TE does not need such TLV
Bellagamba, et al. Expires June 13, 2011 [Page 5]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
because it already encodes this information in other mandatory
objects already included in its messages.
The MPLS OAM SOURCE MEP-ID TLV is intended to be inserted in the
scope of the "OAM configuration TLV" together with the othe sub-TLV
as defined in [RSVP-TE CONF] section 3.2.
3.3. MPLS OAM SOURCE MEP-ID TLV for LSP Ping
The "MPLS OAM SOURCE MEP-ID TLV for LSP Ping" depicted below is
carried as a sub-TLV of the "OAM Configuration TLV" in case LSP Ping
is used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (6) (IANA) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRC NODE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TUNNEL ID | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type, the "MPLS OAM SOURCE MEP-ID" (IANA to
define).
Length: indicates the TLV total length in octets.
SRC NODE ID: 32-bit node identifier as defined in [MPLS-TP-IDENTIF].
TUNNEL ID: a 16-bit unsigned integer unique to the node as defined in
[MPLS-TP-IDENTIF].
LSP ID: a 16-bit unsigned integer unique within the Tunnel_ID as
defined in [MPLS-TP-IDENTIF].
4. BFD OAM configuration errors
In addition to error values specified in [OAM-CONF-FWK] and [ETH-OAM]
this document defines the following values for the "OAM Problem"
Error Code:
- "MPLS OAM Unsupported Functionality";
- "OAM Problem/Unsupported TX rate interval".
Bellagamba, et al. Expires June 13, 2011 [Page 6]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
5. Security Considerations
The signaling of OAM related parameters and the automatic
establishment of OAM entities introduces additional security
considerations to those discussed in [RFC3473]. In particular, a
network element could be overloaded, if an attacker would request
liveliness monitoring, with frequent periodic messages, for a high
number of LSPs, targeting a single network element.
Security aspects will be covered in more detailed in subsequent
versions of this document.
6. References
6.1. Normative References
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", 2009, <draft-ietf-bfd-base>.
[MPLS-CSF]
He, J. and H. Li, "Indication of Client Failure in
MPLS-TP", 2009, <draft-he-mpls-tp-csf>.
[MPLS-FMS]
Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault
Management OAM", 2009, <draft-sfv-mpls-tp-fault>.
[MPLS-PM] Bryant, S. and D. Frost, "Packet Loss and Delay
Measurement for the MPLS Transport Profile", 2009,
<draft-frost-mpls-tp-loss-delay>.
[MPLS-TP-IDENTIF]
Bocci, M. and G. Swallow, "MPLS-TP Identifiers", 2009,
<draft-swallow-mpls-tp-identifiers>.
[MPLS-TP-OAM-REQ]
Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks", 2009,
<draft-ietf-mpls-tp-oam-requirements>.
[OAM-CONF-FWK]
Takacs, A., Fedyk, D., and J. van He, "OAM Configuration
Framework for GMPLS RSVP-TE", 2009,
<draft-ietf-ccamp-oam-configuration-fwk>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Bellagamba, et al. Expires June 13, 2011 [Page 7]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RSVP-TE CONF]
Bellagamba, E., Ward, D., Andersson, L., and P.
Skoeldstroem, "Configuration of pro-active MPLS-TP
Operations, Administration, and Maintenance (OAM)
Functions Using RSVP-TE", 2010,
<draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext>.
6.2. Informative References
[BFD-CCCV]
Fulignoli, A., Boutros, S., and M. Vigoreux, "MPLS-TP BFD
for Proactive CC-CV and RDI", 2009,
<draft-asm-mpls-tp-bfd-cc-cv>.
[BFD-Ping]
Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher,
N., and Y. Weingarten, "LSP-Ping and BFD encapsulation
over ACH", 2009,
<draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02>.
[ETH-OAM] Takacs, A., Gero, B., Fedyk, D., Mohan, D., and D. Long,
"GMPLS RSVP-TE Extensions for Ethernet OAM", 2009,
<draft-ietf-ccamp-rsvp-te-eth-oam-ext>.
[LSP Ping]
Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", 2006, <RFC
3479>.
[MPLS-TP OAM Analysis]
Sprecher, N., Nadeau, T., van Helvoort, H., and
Weingarten, "MPLS-TP OAM Analysis", 2006,
<draft-sprecher-mpls-tp-oam-analysis>.
[MPLS-TP-FWK]
Bocci, M., Bryant, S., Frost, D., and L. Levrau, "OAM
Configuration Framework for GMPLS RSVP-TE", 2009,
Bellagamba, et al. Expires June 13, 2011 [Page 8]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
<draft-ietf-mpls-tp-framework>.
[MPLS-TP-OAM-FWK]
Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and
Overview", 2009, <draft-ietf-mpls-tp-oam-framework>.
[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.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Elisa Bellagamba (editor)
Ericsson
Farogatan 6
Kista, 164 40
Sweden
Phone: +46 761440785
Email: elisa.bellagamba@ericsson.com
Loa Andersson (editor)
Ericsson
Farogatan 6
Kista, 164 40
Sweden
Phone:
Email: loa.andersson@ericsson.com
Pontus Skoldstrom (editor)
Acreo AB
Electrum 236
Kista, 164 40
Sweden
Phone: +46 8 6327731
Email: pontus.skoldstrom@acreo.se
Bellagamba, et al. Expires June 13, 2011 [Page 9]
Internet-Draft Extensions for MPLS-TP OAM Conf December 2010
Dave Ward
Juniper
Phone:
Email: dward@juniper.net
Bellagamba, et al. Expires June 13, 2011 [Page 10]
