Internet-Draft T. Theimer
Expires April 2000 J. Klink
Siemens
October 1999
Requirements for OAM Functionality in MPLS
<draft-theimer-mpls-oam-requ-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
This draft discusses the motivation for MPLS OAM functionality and
possible requirements for OAM in MPLS networks. Examples of OAM
functions include support for fault management, continuity checks,
loopbacks, performance monitoring and protection switching. Such
capabilities may be useful in many applications of MPLS networks, but
a detailed set of requirements is currently not available. Further
discussion and input is solicited, in particular from network
operators and service providers.
1. Introduction
OAM (Operation, Administration and Maintenance) functionality is
important in public networks for ease of network operation, for
verifying network performance and to reduce network operating costs.
OAM functionality is especially relevant for networks in which
Quality of Service is an important issue. OAM functions have
therefore been defined e.g. for SONET/SDH and also for ATM networks.
MPLS, as one of the key technologies for scalable next-generation
networks providing QoS and supporting a diverse range of network
services, will most likely require some basic OAM functionality as
well.
[Page 1]
Internet-Draft OAM Requirements for MPLS October 1999
MPLS OAM functionality is not seen as a substitute for physical layer
(e.g. SONET/SDH) OAM functionality. However, MPLS layer OAM functions
may nevertheless be desirable in addition to physical layer OAM: They
will be required whenever OAM functionality is needed that permits
differentiation per individual LSP. For example:
- monitoring of connectivity, availability or performance of an
individual LSP
- MPLS protection switching for an individual LSP
This draft intends to initiate a discussion on requirements for OAM
functionality in MPLS, with the ultimate goal to identify a set of
basic OAM functions and the protocol extensions needed for an
interoperable implementation of these functions. Note that we do not
intend to simply adopt the OAM functions and procedures previously
defined for other technologies (in particular ATM), as this would
probably lead to very complex and expensive implementations. It is
therefore very important to carefully define the OAM requirements for
MPLS, focusing primarily on those issues where market demand is
already beginning to appear.
2. Motivation and Requirements for OAM Functionality in MPLS
OAM functionality may be useful in MPLS for the following reasons
(this list is clearly not exhaustive, and requires further work to
describe each requirement in more detail):
2.1. It allows the Operator to verify whether Quality of Service
guarantees committed in SLAs (Service Level Agreements) are in fact
being met by the label switched path (LSP).
Associated requirements:
- in-service verification of LSP availability (whether an LSP is _up_
or _down_) and error performance (counting of lost frames)
- in-service verification of delay and delay variation
- in-service verification of connection throughput guarantees.
2.2. It allows the Operator to improve network reliability.
Associated requirements:
- LSP failure detection and automatic rerouting
- MPLS protection switching
2.3. It allows the Operator to reduce network operating costs. Long term
statistics show that the costs of operating a public network are higher
than the initial installation costs.
Theimer & Klink Expires April 2000 [Page 2]
Internet-Draft OAM Requirements for MPLS October 1999
Associated requirements:
- tools for fast and efficient fault detection and fault localization
(related to individual LSPs)
- tools for efficient network setup and configuration.
2.5. It allows the Operator to improve traffic flow/distribution through
the network.
Traffic engineering requirements have already been addressed in [3],
and work is currently in progress in the IETF.
2.6. It gives support for improved accounting/billing procedures.
Associated requirements:
- measurement of throughput per connection for throughput based
billing
- detection of violations to an SLA traffic contract that can be
given consideration for billing.
3. Examples of MPLS OAM Functionality
Some examples of MPLS OAM functionality that may be used to address
the above requirements are listed below:
3.1. Fault Management/Continuity Check
OAM functionality could be defined to provide alarm information in
cases where an MPLS path is _down_ or interrupted. This information
could be propagated downstream along the MPLS path. Such
functionality is particularly important when LSPs are manually
configured in each node rather than established through a signalling
protocol. Protocols such as LDP already provide similar functionality
for the control plane path, covering severe errors such as total node
or link failures. However, some error scenarios cannot be detected
through these control plane mechanisms, and would also require inband
monitoring capabilities within an LSP.
One key application for such a function would be the in-service
verification of MPLS path availability (continual monitoring whether
the path is _up_ or _down_), enabling an Operator to verify whether
Service Level Agreements with high availability guarantees are being
met. Another possible application is as a trigger for MPLS protection
switching.
3.2. Loopbacks
OAM loopback packets could be defined, that would be looped back to
the source of the loopback request at different nodes within an LSP
Theimer & Klink Expires April 2000 [Page 3]
Internet-Draft OAM Requirements for MPLS October 1999
(similar to a _ping_ function). This could be used to enable
verification of correct connectivity/configuration of the LSP prior
to its being taken into service. It could also be used to localise
faults along an LSP.
3.3. Performance Monitoring
OAM functionality could be defined to continually monitor the
performance of an MPLS path, e.g. with respect to lost packets.
Possible applications for this function include:
- triggering of an alarm if a performance threshold is exceeded
- performance statistics per individual LSP
- triggering of MPLS protection switching if a _signal degrade_
situation is detected.
3.4. MPLS Protection Switching
Work on MPLS protection switching has already been started, e.g. [1]
and [2]. MPLS OAM functionality may be defined to support MPLS
protection switching. Basic functionality that will probably need to
be supported for this is:
- Detection of failure situations (_hard_ or _soft_ failures) and
propagation of this information to the MPLS protection domain
source/sink. OAM functions for Fault Management/Continuity Check
and Performance Monitoring (see above) could be used to achieve
this.
- Communication between protection domain source and sink in order to
coordinate protection switching operations.
4. Areas for Standardisation
Depending on the detailed list of OAM requirements and their
relevance, extensions to existing protocols and/or some new protocols
may have to be defined to support OAM functions in MPLS. Examples
include extensions to TE-RSVP [4] and CR-LDP [5] to enable and
control OAM capabilities for selected LSPs, and to forward error
notification messages.
In some cases it may also be required to introduce an OAM indicator
in the MPLS header. This OAM indicator would enable a simple
differentiation between user packets and OAM packets in equipment
supporting MPLS. Further discussion is required to clarify the need
for such an OAM indicator and to identify a suitable encoding.
Theimer & Klink Expires April 2000 [Page 4]
Internet-Draft OAM Requirements for MPLS October 1999
5. References
[1] K. Owens, C. Huang: Protection/Restoration of MPLS Networks.
Work in progress <draft-makam-mpls-protection-00.txt>, June
1999.
[2] D. Haskin, R. Krishnan: A Method for Setting an Alternative
Label Switched Paths to Handle Fast Reroute. Work in Progress
<draft-haskin-mpls-fast-reroute-01.txt>, June 1999.
[3] D. Awduche, et al: _Requirements for Traffic Engineering Over
MPLS. RFC 2702, September 1999.
[4] D.O. Awduche, et al: Extensions to RSVP for LSP Tunnels. Work in
progress <draft-ietf-mpls-rsvp-lsp-tunnel-04.txt>, September
1999.
[5] B. Jamoussi, et al: Constraint-Based LSP Setup using LDP. Work
in progress <draft-ietf-mpls-cr-ldp-03.txt>, October 1999.
6. Authors' Addresses
Thomas Theimer
Siemens AG
Hofmannstr. 51
81359 Munich, Germany
Email: Thomas.Theimer@icn.siemens.de
Joachim Klink
Siemens AG
Hofmannstr. 51
81359 Munich, Germany
Email: Joachim.Klink@icn.siemens.de
Theimer & Klink Expires April 2000 [Page 5]