draft-ietf-mpls-oam-requirements-01.txt   draft-ietf-mpls-oam-requirements-02.txt 
Network Working Group Thomas D. Nadeau Network Working Group Thomas D. Nadeau
Internet Draft Monique Morrow Internet Draft Monique Morrow
Expires: November 2003 George Swallow Expires: November 2003 George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
David Allan David Allan
Nortel Networks Nortel Networks
Satoru Matsushima
Japan Telecom
June 2003 June 2003
OAM Requirements for MPLS Networks OAM Requirements for MPLS Networks
draft-ietf-mpls-oam-requirements-01.txt draft-ietf-mpls-oam-requirements-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC 2026 conformance with all provisions of Section 10 of RFC 2026
[RFC2026]. [RFC2026].
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
skipping to change at page 8, line 33 skipping to change at page 8, line 36
modeling of management and control of OAM functionality. This modeling of management and control of OAM functionality. This
will be reflected in the the integration of standard MPLS-related will be reflected in the the integration of standard MPLS-related
MIBs (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) for fault, statistics MIBs (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) for fault, statistics
and configuration management. These standard interfaces and configuration management. These standard interfaces
provide operators with common programmatic interface access to provide operators with common programmatic interface access to
operations and management functions and their status. operations and management functions and their status.
3.9 Detection of Denial of Service attacks as part of security 3.9 Detection of Denial of Service attacks as part of security
management. management.
3.10 Per-LSP Accounting Requirements
In an MPLS network, SPs can measure traffic from an LSR to the
egress
of the MPLS network using some MPLS related MIBs, for example.
This means that it is reasonable wish to know how much traffic is
traveling from where to where (i.e.: a traffic matrix) by analyzing
the flow of traffic.
Therefore, traffic accounting in an MPLS network can be summarized
as
the following three items.
(1) Collecting information to design network
For the purpose of optimized network design, SP offers that the
traffic information regarding among POP and/or router.
Optimizing network design needs this information.
(2) Providing high-level SLA
Due to the progress of the recent [MPLS-TE] technology,
SPs and their customers may need to verify high-level SLAs. The
resource optimization and high-speed restoration by [FRR] is
being offered; therefore, continuous improvement of the service
is expected. Moreover, bandwidth guaranteed service can be
achieved by resource management based on [DS-TE].
To provide services based on these applications, the SP
needs to perform traffic accounting to monitor their
services.
(3) Inter-AS environment
SPs which offer inter-as services [Inter-AS TE][Inter-AS VPN]
require accounting of the service.
These three motivations need to satisfy the following.
- In (1) and (2), collection of information on a per-LSP basis
is a minimum level of granularity of collecting accounting
information at both of ingress and egress of an LSP.
- In (3), SP's ASBR carry out interconnection functions as an
intermediate LSR. Therefore, identifying a pair of ingress
and egress LSRs using each LSP is needed to determine the
cost of the service that a customer is using.
3.10.1 Requirements
Accounting on a per-LSP basis encompasses the following set of
functions:
(1) At an ingress LSR accounting of traffic through LSPs
beginning at each egress in question.
(2) At an intermediate LSR, accounting of traffic through
LSPs for each pair of ingress to egress.
(3) At egress LSR, accounting of traffic through LSPs
for each ingress.
(4) All LSRs that contain LSPs that are being measuremented
need to have a common key to distinguish each LSP.
The key must be unique to each LSP, and its mapping to
LSP should be provided from whether manual or automatic
configuration.
3.10.2 Scalability
It is not realistic to perform the just described operations by
LSRs in a network and on all LSPs which exist in a network.
At a minimum, per-LSP based accounting should be performed on the
edges of the network -- at the edges of both LSPs and the MPLS
domain.
4. Security Considerations 4. Security Considerations
LSP mis-merging has security implications beyond that of simply LSP mis-merging has security implications beyond that of simply
being a network defect. LSP mis-merging can happen due to a number being a network defect. LSP mis-merging can happen due to a number
of potential sources of failure, some of which (due to MPLS label of potential sources of failure, some of which (due to MPLS label
stacking) are new to MPLS. stacking) are new to MPLS.
The performance of diagnostic functions and path characterization The performance of diagnostic functions and path characterization
involve extracting a significant amount of information about involve extracting a significant amount of information about
network construction which the network operator may consider network construction which the network operator may consider
private. private.
Mechanisms are required to prevent unauthorized use of either those Mechanisms are required to prevent unauthorized use of either those
tools or protocol features. tools or protocol features.
5. Acknowledgments 5. Acknowledgments
The authors wish to acknowledge and thank the following The authors wish to acknowledge and thank the following
individuals for their valuable comments to this document: individuals for their valuable comments to this document:
Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr.
Ikejiri, NTT Communications and Mr.Kumaki of KDDI. Ikejiri, NTT Communications and Mr.Kumaki of KDDI.
Hari Rakotoranto, Miya Khono, Cisco Systems; Luyuan Fang, AT&T;
Hari Rakotoranto, Cisco Systems; Luyuan Fang, AT&T; Danny McPherson, TCB; Dr.Ken Nagami, Ikuo Nakagawa, Intec Netcore.
Danny McPherson, TCB.
6. References 6. References
[TUNTRACE] Bonica, R., Kompella, K., Meyer, D., [TUNTRACE] Bonica, R., Kompella, K., Meyer, D.,
"Tracing Requirements for Generic Tunnels", "Tracing Requirements for Generic Tunnels",
Internet Draft <draft-bonica-tunneltrace- Internet Draft <draft-bonica-tunneltrace-
02.txt>, November 2001. 02.txt>, November 2001.
[LSRMIB] Srinivasan, C., Viswanathan, A. and T. [LSRMIB] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "MPLS Label Switch Router Management Nadeau, "MPLS Label Switch Router Management
skipping to change at page 9, line 39 skipping to change at page 11, line 14
(MPLS) FEC-To-NHLFE (FTN) Management (MPLS) FEC-To-NHLFE (FTN) Management
Information Base", Internet Draft <draft- Information Base", Internet Draft <draft-
ietf-mpls-ftn-mib-03.txt>, August 2001. ietf-mpls-ftn-mib-03.txt>, August 2001.
[LBMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. [LBMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J.
Lang, "Link Bundling Management Information Lang, "Link Bundling Management Information
Base Using SMIv2", Internet Draft <draft- Base Using SMIv2", Internet Draft <draft-
ietf-mpls-bundle-mib-00.txt>, September ietf-mpls-bundle-mib-00.txt>, September
2001. 2001.
[MPLS-TE] Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001
[FRR] Pan et.al., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", Internet draft,
<draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt>, December 2003
[DS-TE] Le Faucheur & Lai., "Requirements for Diff-Serv-aware TE",
RFC3564, July 2003
[Inter-AS TE] Zhang, Vasseur, et. al., "MPLS Inter-AS Traffic
Engineering requirements", Internet draft
<draft-ietf-tewg-interas-mpls-te-req-00.txt>, May 2003
[Inter-AS VPN] Rosen, et al., "BGP/MPLS IP VPNs", Internet draft,
<draft-ietf-l3vpn-rfc2547bis-01.txt>, September 2003
[PWE3FRAME] Pate, P., Xiao, X., White., C., Kompella., [PWE3FRAME] Pate, P., Xiao, X., White., C., Kompella.,
K., Malis, A., Johnson, T., and T. Nadeau, K., Malis, A., Johnson, T., and T. Nadeau,
"Framework for Pseudo Wire Emulation Edge-to- "Framework for Pseudo Wire Emulation Edge-to-
Edge (PWE3)", Internet Draft <draft-ietf- Edge (PWE3)", Internet Draft <draft-ietf-
pwe3-framework-00.txt>, September, 2001. pwe3-framework-00.txt>, September, 2001.
[RFC2026] S. Bradner, "The Internet Standards Process [RFC2026] S. Bradner, "The Internet Standards Process
-- Revision 3", RFC 2026, October 1996. -- Revision 3", RFC 2026, October 1996.
[Y1710] ITU-T Recommendation Y.1710, "Requirements for [Y1710] ITU-T Recommendation Y.1710, "Requirements for
skipping to change at page 10, line 43 skipping to change at page 12, line 35
Boxboro, MA 01719 Boxboro, MA 01719
Voice: +1-978-936-1398 Voice: +1-978-936-1398
Email: swallow@cisco.com Email: swallow@cisco.com
David Allan David Allan
Nortel Networks Nortel Networks
3500 Carling Ave. 3500 Carling Ave.
Ottawa, Ontario, CANADA Ottawa, Ontario, CANADA
Voice: 1-613-763-6362 Voice: 1-613-763-6362
Email: dallan@nortelnetworks.com Email: dallan@nortelnetworks.com
Satoru Matsushima
Japan Telecom
4-7-1, Hatchobori, Chuo-ku
Tokyo, 104-8508 Japan
Phone: +81-3-5540-8214
Email: satoru@ft.solteria.net
8. Full Copyright Statement 8. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Copyright (C) The Internet Society (2001). All Rights
Reserved. Reserved.
This document and translations of it may be copied and This document and translations of it may be copied and
furnished to others, and derivative works that comment on furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or be prepared, copied, published and distributed, in whole or
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/