Internet DRAFT - draft-liu-mpls-upstream-load-balance
draft-liu-mpls-upstream-load-balance
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]
