INTERNET DRAFT Expires: December 2003 Satoru Matsushima Japan Telecom Ken-ichi Nagami Intec Netcore June 2003 Traffic Accounting Requirements for MPLS Networks draft-satoru-mpls-lsp-accounting-req-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 document describes that requirements of traffic accounting in per LSP basis. That is important as providing SLA and the evidence of bandwidth guarantee so that these service are on their LSP. 1. Requirements Overview In MPLS network, LSR measuring packets which labeled correspond to target LSP is measuring LSP traffic so that label is identifier of LSP. The [LSR-MIB], [FTN-MIB] and [TE-MIB] can use to measure labeled packets. However, these can not match to accounting purpose in per LSP basis. This document describes the per LSP accounting and its requirements. Matsushima, Nagami [Page 1] Internet Draft draft-satoru-mpls-lsp-accounting-req-00.txt June 2003 2. Definition In this document, per LSP traffic accounting means as following: - At ingress LSR, it means that accounting traffic through LSP for each egress. - At intermediate LSR, it means that accounting traffic through LSP for each pair of ingress to egress. - At egress LSR, it means that accounting traffic through LSP for each ingress. - In case of there is a number of LSP among a pair of ingress and egress, it means that accounting traffic for each LSP. 3. Issues There are following issues in intermediate and egress LSR. 3.1. Distinguishing the target LSP This problem is classified by the mechanism of MPLS which consist of the difference from merged, non-merged LSP and PHP. 3.1.1. Merged LSP The example of merged-LSP is shown as following. o o o o <--------- Ingress LSRs \ / \ / \ / \ / o o <------------ 1st Intermediate LSRs \ / \ / o o <--------------- 2nd Intermediate LSRs \/ o <----------------- Egress LSR In the case of merged LSP, accounting in which distinguish each ingress can not achieve on the intermediate LSR. In the above example, it is possible on 1st intermediate LSRs that ingress LSR is distinguished. However, as for the 2nd intermediate LSRs and egress LSR, merge has already been done to LSP by the 1st intermediateLSRs. Therefore, ingress can't be distinguished, and then accounting with per LSP basis can't be done. 3.1.2. Non-merged LSP Matsushima, Nagami [Page 2] Internet Draft draft-satoru-mpls-lsp-accounting-req-00.txt June 2003 In the case of non-merged LSP such as, [RSVP-TE], fundamentally the pair of LSP source and destination address become the key to distinguish a target LSP in intermediate LSR. However, more than one LSP between the same ingress/egress LSRs can't be distinguished. Therefore, it can think that it is based on Tunnel-ID and LSP-ID but these don't become keys for intermediate LSR because ingress LSR is decided at random. 3.1.3. PHP (Penultimate Hop Popping) This is the problem which is common for the merge and non-merge LSPs. PHP is used with many MPLS implements. As a result, label to distinguish LSP doesn't exist when it reaches egress. 3.2. Acquisition of accounting-data According to the LSR-MIB, label value is the key of LSP accounting. But in almost case, LSR decide the label value dynamically. Therefore, the binding information of the LSP and its label value becomes indispensable for LSP accounting. However, the means to examine such information is never provided with scheme which is the same as account. For example, it is provided with CLI of every LSR, but it has problem that it depend on other function and/or environment. In the case of RSVP-TE, TE-MIB could provide other key except for the label value though there is a problem like mentioning above. 4. Requirements 1. As for the purpose of distinguishing each LSP, non-merged LSP must have the key which stand for LSP and never change regardless of the situation when LSP is rerouted and/or re-established. 2. Furthermore, per LSP accounting must be able to do intermediate and egress LSR by the key regardless of merged, non-merged LSP. Note that if intermediate LSR was operated as INTER-AS LSR, per LSP accounting is needed even if it operate merged LSP. 3. No PHP in principle. In the case of when PHP is done and accounting of every LSP is done, ingress LSR must include identifier which stand for ingress. As for this purpose, it is stacked label for instance. This is effective in merged LSP by [LDP] as well. 5. Security Considerations Matsushima, Nagami [Page 3] Internet Draft draft-satoru-mpls-lsp-accounting-req-00.txt June 2003 Security issue expansion is not expected with the requirements of this document. However, when a new mechanism and a protocol are designed, consideration about security is necessary. 6. Ackowledgments We would like to thank Yuichi Ikejiri and Miya Kohno for their suggestions and helpful comments. 7. Authors' Address: Satoru Matsushima Japan Telecom 4-7-1, Hatchobori, Chuo-ku Tokyo, 104-8508 Japan Phone: +81-3-5540-8214 Email: satoru@ft.solteria.net Ken-ichi Nagami Intec NetCore, Inc. Email: nagami@wide.ad.jp 8. References [LSR-MIB], Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switch Router Management Information Base ", Internet Draft , November 2002. (work in progress) [FTN-MIB], Nadeau, T., Srinivasan, C., Viswanathan, A., "MPLS Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base", Internet Draft , April 2003. (work in progress) [TE-MIB], Srinivasan, C., Viswanathan, A. and Nadeau, T., "MPLS Traffic Engineering Management Information Base ", Internet Draft , November 2002. (work in progress) [RSVP-TE], Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 [LDP], Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001. Matsushima, Nagami [Page 4]