Internet DRAFT - draft-joshi-pim-ecmp-neighbor-select
draft-joshi-pim-ecmp-neighbor-select
PIM B. Joshi
Internet-Draft J. Kaveetil
Intended status: Experimental Infosys Ltd.
Expires: January 10, 2014 July 9, 2013
PIM neighbor selection with ECMP routes
draft-joshi-pim-ecmp-neighbor-select-00
Abstract
A Protocol Independent Multicast (PIM) router uses local forwarding
table to select the upstream PIM neighbor towards the source or
Rendezvous Point (RP). A router need to choose one upstream PIM
neighbor from the list of PIM neighbors if the route for a source or
RP is an Equal Cost Multipath (ECMP) route. Currently PIM routers
use vendor specific algorithm to choose one neighbor. This may lead
to unnecessary wastage of network resources. This draft first
explains the need for a standard algorithm to select a PIM neighbor
with ECMP route and then suggest such an algorithm.
Requirements Language
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 10, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Joshi & Kaveetil Expires January 10, 2014 [Page 1]
Internet-Draft PIM neighbor selection with ECMP routes July 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Need for a standard algorithm . . . . . . . . . . . . . . . . . 3
3. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Joshi & Kaveetil Expires January 10, 2014 [Page 2]
Internet-Draft PIM neighbor selection with ECMP routes July 2013
1. Introduction
A PIM router uses local forwarding table to select the upstream PIM
neighbor towards the source or RP. A router need to choose one
upstream PIM neighbor from a list of PIM neighbors if the route for a
source or RP is an ECMP route. Currently PIM routers use some vendor
specific algorithm to choose one PIM neighbor from the list of PIM
neighbors. This may lead to wastage of network resources if two
downstream routers on a LAN chooses two different upstream routers to
reach a source or RP.
There is a need for routers to use a standard algorithm to choose the
same PIM neighbor when an ECMP routes provide a list of PIM
neighbors. This draft first explains the usefulness of such a
standard algorithm and then suggest the same.
2. Need for a standard algorithm
Let us look at the network configuration of figure 1. Let us assume
that R4 and R5 received a PIM join for a source 'S'. Let us also
assume that both R4 and R5 has an ECMP route to reach source 'S'.
Let us assume that this ECMP route has two gateways R1 and R3.
+----+ +----+ +----+
| R1 | | R2 | | R3 |
+----+ +----+ +----+
| | |
| | |
| | |
---+------+---------+------+--------+---------
| |
| |
+----+ +----+
| R4 | | R5 |
+----+ +----+
Figure 1
There is no guarantee that R4 and R5 will selects the same upstream
router i.e R1 or R3 for the PIM join. This may be because R4 and R5
are from two different vendors or they use two different mechanism to
select a PIM neighbor. Let us assume R4 select R1 while R5 select R3
as the upstream PIM neighbor and send the PIM join to them. R1 and
R3 will forward these joins towards the source and somewhere these
joins may or may not converge in the network. When both R1 and R3
forwards the multicast traffic, PIM assert techniques will elect one
Joshi & Kaveetil Expires January 10, 2014 [Page 3]
Internet-Draft PIM neighbor selection with ECMP routes July 2013
of them as forwarder.
So selecting two different PIM neighbors lead to following:
o A complete leg of multicast tree will be unnecessarily created.
o Multicast data will be unnecessarily forwarded along this leg.
o An unnecessary assert mechanism will trigger in the LAN.
3. Proposed algorithm
These wastages can be avoided, if router R4 and R5 uses some standard
algorithm to determine the upstream PIM neighbor. Any algorithm will
work only if the routing protocols have converged and all routers on
a LAN have the same forwarding table. One simple mechanism could be
to choose the highest IP address PIM neighbor from the list of PIM
neighbors. However, with such a mechanism, all multicast channels
using a specific ECMP route, would end up using the same PIM
neighbor. This means that there is no load balancing among the PIM
neighbors in the list. So this draft proposes to use a hash
algorithm which uses PIM neighbor's address, multicast group address
and multicast source address or RP address. The hash function should
implicitly provide the load balancing among the PIM neighbors that
can be used.
The hash function explained in PIM-SM [RFC4601] is extended. The
hash function proposed here will be used to calculate hash value for
each combination of source/RP, group and PIM neighbor's primary
address. The PIM neighbor with the highest value will be chosen as
the upstream PIM neighbor for the corresponding multicast group and
source.
HashValue_for_ASM(Group-address,RP-address,Neighbor-address) =
( 1103515245 *
( ( 1103515245 *
( ( ( 1103515245 * Group-address ) + 12345 )
XOR ( RP-address ) ) + 12345 )
XOR ( Neighbor-address ) ) + 12345 ) mod 2^31
HashValue_for_SSM(Group-address,Source-address,Neighbor-address) =
( 1103515245 *
( ( 1103515245 *
( ( ( 1103515245 * Group-address ) + 12345 )
XOR ( Source-address ) ) + 12345 )
XOR ( Neighbor-address ) ) + 12345 ) mod 2^31
Joshi & Kaveetil Expires January 10, 2014 [Page 4]
Internet-Draft PIM neighbor selection with ECMP routes July 2013
4. Security Considerations
This draft does not suggest any change in protocol messages. If all
routers in a LAN support this document but one rough router choose
different upstream router than others, the situation will be similar
to what exists today.
5. Acknowledgements
The idea to use a hash function to identify the PIM neighbor in the
list of PIM neighbors was discussed during an informal discussion
with Saravana Prasad.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
6.2. Informative References
Authors' Addresses
Bharat Joshi
Infosys Ltd.
Email: bharat_joshi@infosys.com
Jithesh Kaveetil
Infosys Ltd.
Email: jithesh_k@infosys.com
Joshi & Kaveetil Expires January 10, 2014 [Page 5]
