Neil Harrison
Internet Draft Peter Willis
Document: draft-harrison-mpls-oam-req-01.txt British Telecom
Expires: May 2002
Shahram Davari
PMC-Sierra
Enrique G. Cuevas Ben Mack-Crane
AT&T Tellabs
Elke Franze Hiroshi Ohta
Deutsche Telekom NTT
Tricci So Sanford Goldfless
Caspian Network Feihong Chen
Lucent
Mina Azad (this version's editor)
David Allan Eric Davalo
Nortel Networks Maple Optical Systems
Wesam Alanqar Marcus Brunner
Sprint NEC Europe Ltd.
Chou Lan Pok Arun Punj
SBC Technology Resources, Inc. Marconi Communications
December 2001
Requirements for OAM in MPLS Networks
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.
MPLS OAM Requirements Expires May 2002 [Page 1]
Copyright Notice
Copyright(C) The Internet Society (2001). All Rights Reserved.
Abstract
This draft provides requirements for maintenance procedures and
Protocols (a.k.a. OAM) to determine the health and performance of MPLS
user-plane.
Motivation for MPLS user-plane maintenance tools rose from Network
operators need to determine availability and performance of MPLS LSPs
(Label Switched Paths). User-plane OAM tools are required to verify
that LSPs have been setup and are available to deliver customer data to
target destinations according to QoS (Quality of Service) guarantees
given in SLAs (Service Level Agreements).
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].
Table of Contents
-----------------
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation for MPLS user-plane maintenance functionality . . . . 3
3. Network Provider's Requirements . . . . . . . . . . . . . . . . . 3
4. Requirements extracted from IETF RFCs and Internet Drafts . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
MPLS OAM Requirements Expires May 2002 [Page 2]
1. Introduction
This draft provides requirements for maintenance procedures and
protocols (a.k.a. OAM) to determine the health and performance of MPLS
user-plane. It is recognized that OAM functionality is important in
public networks to facilitate and reduce cost of network operation,
determine LSP availability, and measure quality of service. Standardized
definition of availability performance and performance monitoring tools
allow network users to verify whether network operators are providing
contracted Service Layer Agreements.
2. Motivation for MPLS user-plane maintenance functionality
Operators need MPLS user-plane OAM in order to:
- Ensure that MPLS becomes a reliable network platform that can be
operable, administered, and maintained through appropriate user-plane
mechanisms
- Allow development of simple, consistent and measurable availability
and QoS SLAs for services such as MPLS-based VPNs
- Drive down operational costs (which are the largest cost-line over
the life of a network)
- Protect the security/integrity of the network
- Reduce defect detection time and, thus, increase reliability.
3. Network Provider's Requirements
This section describes the high level requirements that have been
identified and requested by a number of service providers.
User-plane maintenance functionality must:
1) be made available at any level in the MPLS stack;
MPLS nesting/tunneling capability (realized through label stack
encoding [5]) allows LSPs to create layer networks in their own right.
Therefore, It should be made possible to insert OAM packets at each
nesting level. At this point, there are no requirements for maintenance
functionality across nesting levels.
Note: Similar requirement has been stated in
draft-team-tewg-restore-hierarchy-00.txt
"However, a capability should be provided for a network operator to
control the operation of survivability mechanisms among different
layers".
MPLS OAM Requirements Expires May 2002 [Page 3]
2) automatically detect most types of user-plane defects;
All the major defect conditions must be identified with in-service
Measurable entry and exit criteria, and all consequent actions must be
specified. At least the following MPLS user-plane defects need to be
detected:
a. Loss of LSP connectivity (due to a server layer failure or a
failure within the MPLS layer)
b. Swapped LSP trails
c. LSP mismerging (of 2 or more LSP trails; including loops)
d. Unintended replication (e.g. unintended multicasting).
It is also important to specify how unavailable/available state
Transition relate to the stopping/starting of the aggregation of
available state QoS metrics.
Note: similar requirement is also stated in
draft-ietf-ppvpn-requirements-02.txt
"6.1 Fault management
Support for fault management includes:
- indication of customers impacted by failure,
- fault detection (incidents reports, alarms, failure
visualization),
- fault localization (analysis of alarms reports, diagnostics),
- incident recording or logs, creation and follow through of
trouble tickets),
- corrective actions (traffic, routing, resource allocation)".
3) facilitate automated and timely network response to user-plane
defects; If a defect occurs, it is necessary to detect, notify and
localize it immediately and to take necessary actions. This is to
minimize service interruption by providing the network with sufficient
information to take corrective action to bypass the defect (protection
switching, re-routing etc.), and to minimize the time to correct the
defect and return the failed resource to the available state. It is
necessary that defects be detected and notified automatically without
operator intervention for this purpose.
4) provide automatic and on-demand maintenance and diagnostic functions.
5) be independent of any control-plane maintenance functionality;
The control-plane must also have its own maintenance capability.
This version of the requirements draft does not address control-plane
OAM.
Note: Similar requirement is stated in
draft-ietf-ipo-carrier-requirements-00.txt
"Requirement 60. The signaling network shall have its own OAM
mechanisms."
6) be independent of user-plane maintenance functionality used in other
client or server layer network technologies; This is critical to ensure
that layer networks can evolve (or new/old layer networks be
added/removed) without impacting other layer networks.
MPLS OAM Requirements Expires May 2002 [Page 4]
Note: Client and server layer independency is also required for MPLS
based recovery. As indicated draft-ietf-mpls-recovery-frmwrk-03.txt,
client layer (i.e. layer 3 and IP) functionality might not be fast
enough and server layer functionality might not be sufficiently
accessible to address MPLS based recovery.
7) be scalable to at least the order that LSPs are scalable;
Specifically, operator actions for set up and activation of
Maintenance functions should be kept to minimum in large-scale networks.
8) be backward compatible;
LSRs that do not support such function must silently discard or pass
Through the OAM packets without disturbing the traffic or causing
Unnecessary actions.
9) be an extensible framework that will support important MPLS
applications (e.g., TE, VPN, Frame Relay, ATM, Ethernet, Layer-2
Encapsulations).
Note: Similar requirement is stated in
draft-ietf-pwe3-requirements-01.txt
"5.2. Status Monitoring
Some native services have mechanisms for status monitoring.
For example, ATM supports OAM for this purpose. For such
services, the corresponding emulated services MUST specify how
to perform status monitoring. The mechanisms NEED NOT be
defined in this WG. Some status monitoring mechanisms defined
in other WGs, e.g., [LSPPING] or [MPLSOAM], may be leveraged".
Note: [LSPPING] is the same as [7] and [MPLSOAM] is the same as [8].
4. Requirements extracted from IETF RFCs and Internet Drafts
Numerous OAM requirements have been stated in existing IETF RFCs and
Working group Internet drafts. This section provides a summary of such
requirements to highlight the significance of dependency on MPLS
user-plane OAM.
draft-heron-ppvpn-vpsn-reqmts-00.txt
"While further OAM functionality, such as the ability to trigger
remote network loopbacks or to verify that frames are successfully
delivered to the intended remote VPSN instance, is desirable it is
to be considered out of scope for this effort. Other groups are
defining such functionality, for example the LSP-ping effort [7]
and the MPLS OAM effort [8], and it may be possible to leverage
this work in VPSN implementations."
MPLS OAM Requirements Expires May 2002 [Page 5]
RFC 2702
"when a fault occurs along the path through which the traffic trunk
traverses. The following basic problems need to be addressed under
such circumstances: (1) fault detection, (2) failure notification,
(3) recovery and service restoration. Obviously, an MPLS
implementation will have to incorporate mechanisms to address these
issues".
draft-owens-te-network-survivability-01.txt
"7.3.1 Considerations for the ATM and/or MPLS Layer
As discussed, fault detection at the MPLS layer could be by
Detecting TTL errors or by counting unlabeled packets or packets
with unrecognized labels. An issue with TTL errors is that they
could be the result of either an MPLS layer or an IP layer problem,
since the MPLS header carries the IP TTL. For instance, TTL mis-
matches could be due to a genuine problem with an upstream LSR or
due to a router upstream of the LSR detecting the mismatches,
probably the edge router that converted the IP packet into a
labeled MPLS packet. Likewise, the persistent receipt of unlabeled
packets or packets with unknown labels might indicate protocol
problems, and necessitate a protection switch.
Thus, detection of some types of errors at the MPLS layer may
require a protection switch at the same layer, which is independent
of lower layers."
5. Security Considerations
The OAM function described in this document enhances the security of
MPLS networks, by detecting mis-connections, and therefore
preventing customers traffic to be exposed to other customers.
The MPLS OAM functions as defined in this document do not raise any
new security issue, to MPLS networks.
6. References
[1] IETF, RFC-2119, "Key words for use in RFCs to Indicate
Requirement Levels", Category: Best Current Practice, March 1997
[2] IETF, RFC-2026, "The Internet Standards Process -- Revision 3",
Best Current Practice, October 1996
[3] IETF, RFC-2702, "Requirements for Traffic Engineering Over MPLS"
, Informational, September 1999
[4] IETF, RFC3031, "Multiprotocol Label Switching Architecture",
Category: Standards Track, January 2001.
[5] IETF, RFC 3032, "MPLS label stack encoding",
Category: Standards Track, January 2001.
MPLS OAM Requirements Expires May 2002 [Page 6]
[6] Marco Carugi et. al., "Service requirements for Provider
Provisioned Virtual Private Networks",
draft-ietf-ppvpn-requirements-02.txt, August 2001
[7] Ping Pan et. al., "Detecting Data Plane Liveliness in
RSVP-TE", draft-pan-lsp-ping-01.txt, July 2001
[8] Neil Harrison et. al. "Requirements for OAM in MPLS
Networks", draft-harrison-mpls-oam-req-01.txt, May 2001
[9] Wai Sum Lai st. al., "Network Hierarchy and Multilayer
Survivability",
draft-team-tewg-restore-hierarchy-00.txt, July 2001
[10] Yong Xue et. al., "Carrier Optical Services Requirements",
draft-ietf-ipo-carrier-requirements-00.txt., expiry: January 2002
[11] XiPeng Xiao et. al., "Requirements for Pseudo-Wire Emulation
Edge-to-Edge(PWE3)", draft-ietf-pwe3-requirements-01.txt, July 2001
[12] Giles Heron et. Al., "Requirements for Virtual Private Switched
Networks", draft-heron-ppvpn-vpsn-reqmts-00.txt, July 2001
[13] Ken Owens et. al., "Network Survivability Considerations for
Traffic Engineered IP Networks",
draft-owens-te-network-survivability-01.txt, July 2001
[14] Vishal Sharma et. al., "Framework for MPLS-based Recovery",
draft-ietf-mpls-recovery-frmwrk-03.txt, July 2001
7. Author's Addresses
Neil Harrison
British Telecom Phone: 44-1604-845933
Heath Bank Email: neil.2.Harrison@bt.com
Iugby Road, Harleston
South Hampton, UK
Peter Willis
British Telecom Phone: 44-1473-645178
BT, PP RSB10/PP3 B81 Email: peter.j.willis@bt.com
Adastrial Park
Martlesham, Ipswich, UK
Shahram Davari
PMC-Sierra
411 Legget Drive Phone: 1-613-271-4018
Kanata, ON, Canada Email: Shahram_Davari@pmc-sierra.com
Ben Mack-Crane
Tellabs
4951 Indiana Ave Phone: 1-630-512-7255
Lisle, IL, USA Email: ben.mack-crane@tellabs.com
MPLS OAM Requirements Expires May 2002 [Page 7]
Hiroshi Ohta
NTT
3-9-11 Midori-cho phone: +81-422-59-3617
Musashino-Shi, Email: ohta.hiroshi@lab.ntt.co.jp
Tokyo 180-8585 Japan
Sanford Goldfless
Lucent Technologies
200 Nickerson Road Phone: 508-786-3655
Marlborough, MA 01752 Email: sgoldfless@lucent.com
Feihong Chen
Lucent Technologies
200 Nickerson Road Phone: 508-786-3675
Marlborough, MA 01752 Email: fchen6@lucent.com
Tricci So
Caspian Network
170 Baytech Drive Phone: 408-382-5217
San Jose, CA Email: tso@caspiannetworks.com
U.S.A. 94070
Elke Franze
Deutsche Telekom
T-Systems
T-Nova, Technologiezentrum Phone: +49 6151 83 5459
D-64307 Darmstadt Email: elke.franze@t-systems.de
Darmstadt, Germany
Enrique G. Cuevas
AT&T
Room D3-2B25 Phone: +1 732 420 3252
200 S. Laurel Avenue E-mail: ecuevas@att.com
Middletown, NJ 07748 USA
Mina Azad
Nortel Networks
3500 Carling Ave. phone: 1-613-763-2044
Ottawa, Ontario, CANADA Email: mazad@nortelnetworks.com
David Allan
Nortel Networks Phone: (613) 763-6362
3500 Carling Ave. Email: dallan@nortelnetworks.com
Ottawa, Ontario, CANADA
Eric Davalo
Maple Optical Systems
3200 North First Street Phone: 408 545 3110
San Jose, CA 95134 Email: edavalo@mapleoptical.com
Wesam Alanqar
Sprint
9300, Metcalf Ave, Phone: +1-913-534-5623
Overland Park, KS 66212 E-mail: wesam.alanqar@mail.sprint.com
MPLS OAM Requirements Expires May 2002 [Page 8]
Marcus Brunner
NEC Europe Ltd.
Adenauerplatz 6 Phone: +49 (0)6221/ 9051129
D-69115 Heidelberg, Germany Email: brunner@ccrle.nec.de
Chou Lan Pok
SBC Technology Resources, Inc.
4698 Willow Road, Phone: 925-598-1229
Pleasanton, CA 94583 Email: pok@tri.sbc.com
Arun Punj
Marconi Communications
1000 Marconi Drive, warrandale - PA - 15086
MPLS OAM Requirements Expires May 2002 [Page 9]