Network Working Group Shuying Liu Internet Draft Huawei Technologies Expires: December 2006 June 16, 2006 Load-Balancing among a set of candidate upstream LSRs on a LAN draft-liu-mpls-upstream-load-balance-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on December 16, 2006. Abstract This document describes a mechanism for Load-Balancing among a set of candidate upstream LSRs on a LAN interface. When there are several candidates to be selected as an upstream LSR, according the current upstream label allocation methods, the load on the candidate upstream LSR which is selected by the routing protocol may be very heavy, while the load on other candidate upstream LSRs is little. The Load- Balancing also provides some procedures to minimize the packet loss in following cases: 1) adding/removing a candidate upstream LSR; 2) a better path emerging. Liu Expires December 16, 2006 [Page 1] Internet-Draft draft-liu-mpls-upstream-load-balance-00.txt June 2006 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. Terminology..................................................2 2. Introduction.................................................3 3. The Load-Balancing mechanism.................................3 3.1. The procedure of Load-Balancing.........................3 3.2. In case of adding a candidate upstream LSR..............4 3.3. In case of removing a candidate upstream LSR............4 3.4. In case of a better path emerging.......................5 4. Security Considerations......................................5 5. Acknowledgments..............................................5 6. References...................................................6 6.1. Normative References....................................6 6.2. Informative References..................................6 Author's Addresses..............................................6 Intellectual Property Statement.................................7 Disclaimer of Validity..........................................7 Copyright Statement.............................................7 Acknowledgment..................................................7 1. Terminology LSR: Label Switching Router LSP: Label Switched Path Ingress LSR: Router acting as a sender of an LSP Egress LSR: Router acting as a receiver of an LSP P2MP LSP: A LSP that has one unique Ingress LSR and one or more Egress LSRs Root LSR: Ingress LSR of a P2MP LSP Leaf LSR: Egress LSR of a P2MP LSP Transit LSR: A LSR of a P2MP LSP that has one or more downstream LSRs Branch LSR: A LSR of a P2MP LSP that has more than one downstream LSR Liu Expires December 16, 2006 [Page 2] Internet-Draft draft-liu-mpls-upstream-load-balance-00.txt June 2006 ILM: Incoming Label Map ECMP: Equal-cost multipath Candidate upstream LSR: a next-hop among several equal-cost next-hops to the root LSR of a P2MP LSP. 2. Introduction There are some requirements to support for the LAN interfaces in the document [5]. When there are some candidate upstream LSRs on a LAN interface, the mechanism for P2MP must provide a method for all downstream LSRs of a given P2MP LSP to select the same upstream LSR, so as to avoid traffic replication. The P2MP mechanism should also allow for an efficient balancing of a set of P2MP LSPs among a set of candidate upstream LSRs on a LAN interface. This document describes a mechanism for Load-Balancing among a set of candidate upstream LSRs on a LAN interface. When there are several candidate upstream LSRs on a LAN interface, the Load-Balancing mechanism can distribute the multicast traffic of a set of P2MP LSPs onto those candidate upstream LSRs rightly. The Load-Balancing also provides some procedures to minimize the packet loss in following cases: 1) adding/removing a candidate upstream LSR; 2) a better path emerging. 3. The Load-Balancing mechanism Suppose there are many P2MP LSPs that traverse a LAN in MPLS networks, some of the P2MP LSPs have a set of candidate upstream LSRs on the LAN in common. This document provides an efficient mechanism to balance the multicast traffic of those P2MP LSPs among the set of candidate upstream LSRs on the LAN. 3.1. The procedure of Load-Balancing The Load-Balancing mechanism only supports Per-Flow balance. This part only introduces the process for one P2MP LSP to balance its multicast traffic among the set of candidate upstream LSRs. If a downstream LSR is about to join a P2MP LSP and finds there is a set of candidate upstream LSRs which have equal cost to the root LSR, the downstream LSR should select a candidate upstream LSR as its upstream LSR according to ECMP algorithm which takes the Root Node Address and the Opaque Value in the P2MP FEC element as input parameters. Liu Expires December 16, 2006 [Page 3] Internet-Draft draft-liu-mpls-upstream-load-balance-00.txt June 2006 After selecting its upstream LSR, the downstream LSR sends an upstream label request to its upstream LSR. On receiving the upstream label request, the upstream LSR will check whether it already has forwarding state for the P2MP LSP, if the upstream LSR has forwarding state for the P2MP LSP, it will take the outgoing label of the forwarding state as the upstream label and send the upstream label to the downstream LSR. If not, the upstream LSR will create a forwarding state for the P2MP LSP and allocate an upstream label as the outgoing label of the forwarding state. After assigning the upstream label, the upstream LSR will send the upstream label to the downstream LSR. Then the upstream LSR will take the same actions as in [6]. The Load-Balancing mechanism provides an efficient balancing of a set of P2MP LSPs among a set of candidate upstream LSRs on a LAN interface. 3.2. In case of adding a candidate upstream LSR According to ECMP algorithm, the upstream LSR in some P2MP LSPs will change from a candidate upstream LSR to another candidate upstream LSR in case of adding a candidate upstream LSR. For each of these P2MP LSPs, the downstream LSR do not send a label withdraw message to the current upstream LSR when a candidate upstream is added. Firstly the downstream LSR sends an upstream label request to the new upstream LSR. The upstream LSR will take the same process as in [6] and [7]. After receiving the upstream label mapping message from the new upstream LSR, the downstream LSR does not install the new incoming label into LFIB until it receives an unknown multicast packet from the new upstream LSR. When the downstream LSR receives the unknown multicast packet, it will send a label withdraw message to the current upstream LSR to withdraw the unwanted LSP. Using the procedure above, the multicast traffic does not be disrupted during upstream LSR changing from a candidate upstream LSR to another candidate upstream LSR. 3.3. In case of removing a candidate upstream LSR There are mainly two aspects to bring on removing a candidate upstream LSR. One aspect is the cost of a path changing, and another is network failures. When the cost of a path which traverses a candidate upstream LSR is increased, the LSR is not a candidate upstream LSR any longer. According to ECMP algorithm, some P2MP LSPs on these candidate upstream LSRs must be moved from one candidate upstream LSR to another candidate upstream LSR. For each of the P2MP LSPs, the Liu Expires December 16, 2006 [Page 4] Internet-Draft draft-liu-mpls-upstream-load-balance-00.txt June 2006 downstream LSR takes the same operations as in 3.2 to guarantee the multicast traffic continuity. When network failure happens, the multicast traffic on a candidate upstream LSR may be disrupted, and the LSR is not a candidate upstream LSR any longer. How to minimize the time of traffic disruption is for further study. 3.4. In case of a better path emerging When a better path emerges, all of the P2MP LSPs on those candidate upstream LSRs must be moved to the new upstream LSR. For each of these P2MP LSPs, the downstream LSR also takes the same operations as in 3.2 to guarantee the multicast traffic continuity. 4. Security Considerations The security considerations for the base LDP specification described in [2] is applied here as well. 5. Acknowledgments The authors would like to thank Guoyi CHEN and Zengjie KOU for their review and contribution. Liu Expires December 16, 2006 [Page 5] Internet-Draft draft-liu-mpls-upstream-load-balance-00.txt June 2006 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] C Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.Thomas, "LDP Specification", RFC 3036, January 2001. [3] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast", RFC 2991, November 2000. [4] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000. [5] Roux, J., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", draft-ietf-mpls-mp-ldp-reqs- 00, May 2006. [6] Minei, I., et al., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-00, February 26, 2006. [7] Aggarwal, R., et al., "MPLS Upstream Label Assignment and Context Specific Label Space", draft-ietf-mpls-upstream-label- 00, February 2006. 6.2. Informative References [8] Liu, S., et al., "Reroute Extensions to LDP for P2MP LSP", draft-liu-mpls-ldp-p2mp-reroute-00(work in progress), June 16, 2006. Author's Addresses Shuying Liu Huawei Technologies Huawei Bld.,No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing P.R. China Email: lshuying@huawei.com Liu Expires December 16, 2006 [Page 6] Internet-Draft draft-liu-mpls-upstream-load-balance-00.txt June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Liu Expires December 16, 2006 [Page 7]