Internet DRAFT - draft-nadeau-ip-basedtool-requirements
draft-nadeau-ip-basedtool-requirements
Network Working Group Thomas D. Nadeau
Internet Draft Monique Morrow
Expires: April 2003 George Swallow
Cisco Systems, Inc.
October 2002
IP-based Tool Requirements for MPLS Networks
draft-nadeau-ip-basedtool-requirements-00.txt
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC 2026
[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 memo describes requirements for operations and
management (OAM) based on IP-based tools for Multi-Protocol
Label Switching (MPLS) [RFC3031] networks. As customers
gain deployment experience with MPLS, managing these networks
and services becomes pivotal to the service provider business.
Minimal requirements include the ability to detect a break in
the LSP data path and trace the source of the failure.
Therefore, maintaining core integrity is key in identifying
requirements for MPLS OAM. The document scope is IP-based
tool requirement capture for fault detection, diagnostics,
and statistic reporting and security management.
1. Introduction
Nadeau et al. Expires April 2003 [Page 1]
Internet Draft IP-based Tools Requirements October 28, 2002
This document identifies a set of OAM requirements
gathered from network operators in various workshops by the
authors of this document. No specific mechanisms are
proposed to address these requirements at this time.
Comments should be made directly to the MPLS mailing list
at mpls@uu.net.
This memo does not, in its draft form, specify a standard
for the Internet community.
2. Terminology
This document uses terminology from the MPLS architecture
document [MPLSArch], CCAMP Architecture [CCAMPArch] and
various MPLS-related MIBs such as the MPLS-TC-MIB [TCMIB],
MPLS-LSR-MIB [LSRMIB], MPLS-TE-MIB [TEMIB], MPLS-LDP-MIB
[LDPMIB], MPLS-FTN-MIB [FTNMIB], and the MPLS-LINK-BUNDLING-
MIB [LBMIB].
Defect: Any error condition that prevents an LSR from
functioning correctly. For example, loss of an
IGP path will most likely also result in an LSP
not being able to deliver traffic to its
destination. Another example is the breakage of
a TE tunnel. These may be due to physical
circuit failures or failure of switching nodes
to operate as expected.
3. Requirements
We have compiled requirements from a diverse group of
network operators that have much experience running MPLS
networks.
The following are requirements for MPLS Label Switching
Router OAM functions that have been identified directly
from operators deploying MPLS.
a) Detection and diagnosis of broken Label Switch Path (LSP)
that does not require manual hop-by-hop troubleshooting
across the data path, specifically an LSP path-tracing
tool.
b) LSP tunnel trace capability [TUNTRACE] from both head-end
Label Switch Router (LSR) and mid-point LSR.
c) Automation of LSP path tracing for LSPs originating on a
Provider Edge (PE) and ability to raise alarms when
failures are detected.
Nadeau et al. Expires April 2003 [Page 2]
Internet Draft IP-based Tools Requirements October 28, 2002
d) Lightweight IP-layer ping function to validate customer
edge (CE) to CE connectivity in order to demonstrate true
end-to-end connectivity for the customer [LSPPING]. This
mechanism should allow for configuration of automatic path
tracing as described in b upon discovery of a ping failure.
Other automatic actions may be necessary as well.
e) VPN integrity by providing a mechanism to detect LSP mis-
merging.
f) Service Level Agreement (SLA) support by providing a
mechanism to measure LSP latency.
g) Error Detection and Recovery. A mechanism needed to detect
an error, recover from it and alert the network operator prior
to the customer informing the network operator of the error
condition. It is however, sometimes a requirement that the
customer be notified of the defect condition at the same time
that the network operator is made aware of the defect.
Depending on the device's capabilities, the device may be
programmed to take automatic corrective actions as a result of
detection of defect conditions. These actions may be user or
operator-specified, or may simply be inherent to the
underlying transport technology (i.e.: MPLS Fast-Reroute).
h) Ability to detect failures on any parallel paths of LSPs
which loadshare traffic across parallel paths. (LSRs may
split traffic using, for example, hashing of fields within the
packet header. It is important that to detect failures on all
operational paths as failure of any branch may lead to loss of
traffic.)
i) Ability to perform OAM functions both point-to-point LSPs
(such as those created by RSVP-TE) and multipoint to point
LSPs (such as those created by LDP DU).
j) Operator configurable OAM and frequency of OAM execution.
k) Data plane OAM packets must follow the same path as for
customer, however under certain conditions, for example, when
there is load-balancing in the LSP, the OAM ping and customer
data packets may take different paths.
l) The OAM function can be extended for Service Level
Agreement (SLA) measurement and limited to latency.
m) OAM packet statistics that measure quantity (i.e.: number
of packets) and quality (i.e.: latency measure) of OAM packets
generated and received at each end of the tested LSP.
n) Ability to suppress unnecessary alarms. For example, if an
Nadeau et al. Expires April 2003 [Page 3]
Internet Draft IP-based Tools Requirements October 28, 2002
underlying LSP that carries many VCs is not operational, it
is unnecessary for the LSR to generate one alarm for every
VC within the affected LSP. The operator Elemental
Management System (EMS) can instead determine the affected
VCs and VPNs by correlating the single LSP alarm with the
LSRĘs configuration. Another example is the failure of
an LSP at the bottom of the label stack may result in the
failure of many other LSPs. OAM functions should suppress
alarms on nested LSPs in this case.
o) Allow for the integration of standard MPLS-related MIBs
[LSRMIB][TEMIB][LBMIB][FTNMIB] for fault and statistics
management.
p) Allow for detection of Denial of Service attacks via an
OAM filtering mechanism as part of security management.
q) An LSR supporting OAM functions for pseudo-wire functions
that join one or more networking technologies over MPLS must
be able to translate an MPLS defect into the native
technology's error condition. For example, errors occurring
over the MPLS LSP must translate into native ATM OAM cells at
the edges of the pseudo-wire.
r) Separation of Data and Control Plane OAM. The inherent
separation of control and data planes in MPLS lends itself to
being sometimes implemented independently within an MPLS LSR.
For example, in a multi-slot LSR, one slot may run a control
process responsible for running MPLS control protocols such as
LDP and RSVP, and then programming line cards residing in
other slots to forward traffic accordingly. In doing so, the
switch separates out the data plane from the control plane in
such as way that it is possible for the line card to be mis-
programmed whilst the control card is unaware. This leads to a
potential for the line card to black hole data plane traffic.
This is one example of why it is important for LSRs to possess
functions that allow an operator to detect data plane
liveliness. Data Plane liveliness MUST use the exact same path
as data.
4. Security Considerations
Detection and recovery from LSP mis-merging is a clear
security consideration and is identified as a requirement
for MPLS OAM.
5. Acknowledgments
Nadeau et al. Expires April 2003 [Page 4]
Internet Draft IP-based Tools Requirements October 28, 2002
The authors wish to acknowledge and thank the following
individuals for their valuable comments to this document:
Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr.
Ikejiri, NTT Communications and Mr.Kumaki of KDDI.
6. References
[LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper,
D., Swallow, G., Wadhwa, S., Bonica, R., "
Detecting Data Plane Liveliness in MPLS",
Internet Draft <draft-ietf-mpls-lsp-ping-
00.txt>, March 2002.
[TUNTRACE] Bonica, R., Kompella, K., Meyer, D.,
"Tracing Requirements for Generic Tunnels",
Internet Draft <draft-bonica-tunneltrace-
02.txt>, November 2001.
[GTTP] Bonica, R., Kompella, K., Meyer, D.,
"Generic Tunnel Tracing Protocol (GTTP)
Specification", Internet Draft <draft-bonica-
tunproto-01.txt>, July 2001.
[LSRMIB] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "MPLS Label Switch Router Management
Information Base Using SMIv2", Internet
Draft <draft-ietf-mpls-lsr-mib-07.txt>,
January 2001.
[TEMIB] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "MPLS Traffic Engineering Management
Information Base Using SMIv2", Internet
Draft <draft-ietf-mpls-te-mib-07.txt>,
August 2001.
[FTNMIB] Nadeau, T., Srinivasan, C., and A.
Viswanathan, "Multiprotocol Label Switching
(MPLS) FEC-To-NHLFE (FTN) Management
Information Base", Internet Draft <draft-
ietf-mpls-ftn-mib-03.txt>, August 2001.
[LBMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J.
Lang, "Link Bundling Management Information
Base Using SMIv2", Internet Draft <draft-
ietf-mpls-bundle-mib-00.txt>, September
2001.
[PWE3FRAME] Pate, P., Xiao, X., White., C., Kompella.,
K., Malis, A., Johnson, T., and T. Nadeau,
Nadeau et al. Expires April 2003 [Page 5]
Internet Draft IP-based Tools Requirements October 28, 2002
"Framework for Pseudo Wire Emulation Edge-to-
Edge (PWE3)", Internet Draft <draft-ietf-
pwe3-framework-00.txt>, September, 2001.
[PPVPNFW] Callon, R., Suzuki, M., Gleeson, B., Malis,
A., Muthukrishnan, K., Rosen, E., Sargor,
C., and J. Yu, "A Framework for Provider
Provisioned Virtual Private Networks",
Internet Draft <draft-ietf-ppvpn-framework-
01.txt>, July 2001.
[RFC1155] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for
TCP/IP-based Internets", RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J.
Davin, "Simple Network Management Protocol",
RFC 1157, May 1990.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB
Definitions", RFC 1212, March 1991.
[RFC1215] M. Rose, "A Convention for Defining Traps
for use with the SNMP", RFC 1215, March
1991.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based
SNMPv2", RFC 1901, January 1996.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version
2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version
2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[RFC2026] S. Bradner, "The Internet Standards Process
-- Revision 3", RFC 2026, October 1996.
[RFC2233] McCloghrie, K. and F. Kastenholtz, "The
Interface Group MIB Using SMIv2", RFC 2233,
November 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching
Architecture", RFC 3031, January 2001.
Nadeau et al. Expires April 2003 [Page 6]
Internet Draft IP-based Tools Requirements October 28, 2002
[ITU-T] Draft Recommendation Y.17fw (MPLS
Management Framework)
7. Authors' Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-244-3051
Email: tnadeau@cisco.com
Monique Jeanne Morrow
Cisco Systems, Inc.
Glatt-Com, 2nd Floor
CH-8301
Switzerland
Voice: +41 (0)1 878-9412
EMail: mmorrow@cisco.com
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Voice: +1 978 244 8143
Email: swallow@cisco.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
Nadeau et al. Expires April 2003 [Page 7]
Internet Draft IP-based Tools Requirements October 28, 2002
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Nadeau et al. Expires April 2003 [Page 8]
