--- 1/draft-ietf-mpls-oam-requirements-01.txt 2006-02-05 00:42:07.000000000 +0100 +++ 2/draft-ietf-mpls-oam-requirements-02.txt 2006-02-05 00:42:07.000000000 +0100 @@ -1,23 +1,26 @@ Network Working Group Thomas D. Nadeau Internet Draft Monique Morrow Expires: November 2003 George Swallow Cisco Systems, Inc. David Allan Nortel Networks + Satoru Matsushima + Japan Telecom + June 2003 OAM Requirements for MPLS Networks - draft-ietf-mpls-oam-requirements-01.txt + draft-ietf-mpls-oam-requirements-02.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 @@ -365,43 +368,116 @@ modeling of management and control of OAM functionality. This will be reflected in the the integration of standard MPLS-related MIBs (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) for fault, statistics and configuration management. These standard interfaces provide operators with common programmatic interface access to operations and management functions and their status. 3.9 Detection of Denial of Service attacks as part of security 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 LSP mis-merging has security implications beyond that of simply 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 stacking) are new to MPLS. The performance of diagnostic functions and path characterization involve extracting a significant amount of information about network construction which the network operator may consider private. Mechanisms are required to prevent unauthorized use of either those tools or protocol features. 5. Acknowledgments 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. - - Hari Rakotoranto, Cisco Systems; Luyuan Fang, AT&T; - Danny McPherson, TCB. + Hari Rakotoranto, Miya Khono, Cisco Systems; Luyuan Fang, AT&T; + Danny McPherson, TCB; Dr.Ken Nagami, Ikuo Nakagawa, Intec Netcore. 6. References [TUNTRACE] Bonica, R., Kompella, K., Meyer, D., "Tracing Requirements for Generic Tunnels", Internet Draft , November 2001. [LSRMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switch Router Management @@ -420,20 +496,37 @@ (MPLS) FEC-To-NHLFE (FTN) Management Information Base", Internet Draft , August 2001. [LBMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. Lang, "Link Bundling Management Information Base Using SMIv2", Internet Draft , September 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, + , 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 + , May 2003 + + [Inter-AS VPN] Rosen, et al., "BGP/MPLS IP VPNs", Internet draft, + , September 2003 + [PWE3FRAME] Pate, P., Xiao, X., White., C., Kompella., K., Malis, A., Johnson, T., and T. Nadeau, "Framework for Pseudo Wire Emulation Edge-to- Edge (PWE3)", Internet Draft , September, 2001. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [Y1710] ITU-T Recommendation Y.1710, "Requirements for @@ -474,20 +567,27 @@ Voice: +1-978-936-1398 Email: swallow@cisco.com David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA Voice: 1-613-763-6362 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 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