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 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
    1.1.  Contributing Authors
    1.2.  Requirements Language
    1.3.  Overview of BFD OAM operation
2.  Overview of MPLS OAM for Transport Applications
3.  Theory of Operations
    3.1.  MPLS OAM Configuration Operation Overview
    3.2.  TLVs structure
    3.3.  MPLS OAM SOURCE MEP-ID TLV for LSP Ping
4.  BFD OAM configuration errors
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
Appendix A.  Additional Stuff
§  Authors' Addresses

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 document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 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 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".

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

6.2. Informative References

Appendix A.  Additional Stuff

This becomes an Appendix.

Authors' Addresses