Internet DRAFT - draft-mjsraman-panet-ecmp-redirect-power-repl-cap

draft-mjsraman-panet-ecmp-redirect-power-repl-cap



 



PANET Working Group                                        Shankar Raman
Internet-draft                                Balaji Venkat Venkataswami
Intended Status: Standards Track                            Gaurav Raina
Expires: May 9, 2013                                       I.I.T Madras.
                                                        November 5, 2012


  PIM ECMP Redirect based on Linecard Replication Capacity and Power 
          draft-mjsraman-panet-ecmp-redirect-power-repl-cap-00


Abstract

   This work derives itself from [1] which proposes a ECMP redirect from
   a PIM upstream neighbor that instructs or advices the PIM downstream
   neighbor to choose another of its own ECMP links between the former
   and the latter. What we propose in this document is a criterion based
   on power consumed in the linecards that comprise the ECMP links
   between the former and the latter. Also the multicast replication
   capacity available within the said linecards which form the ECMP
   links between the two is taken into consideration while making a ECMP
   redirect.

   A PIM router uses RPF procedure to select an upstream interface and
   router to build forwarding state.  When there are equal cost multiple
   paths (ECMP), existing implementations often use hash algorithms to
   select a path.  Such algorithms do not allow the spread of traffic
   among the ECMPs according to administrative metrics.  This usually
   leads to inefficient or ineffective use of network resources.  This
   document introduces the ECMP Redirect, a mechanism to improve the RPF
   procedure over ECMPs.  It allows ECMP path selection to be based on
   administratively selected metrics, such as data transmission delays,
   path preferences and routing metrics.





Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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.

 


Shankar Raman et.al         Expires May 2013                    [Page 1]

INTERNET DRAFT Replication capability based PIM redirect   November 2012


   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   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
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conditions where this mechanism applies. . . . . . . . . . . .  3
   3  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   5  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1  Normative References  . . . . . . . . . . . . . . . . . . .  6
     5.2  Informative References  . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  6








 


Shankar Raman et.al         Expires May 2013                    [Page 2]

INTERNET DRAFT Replication capability based PIM redirect   November 2012


1  Introduction

   This work derives itself from [1] which proposes a ECMP redirect from
   a PIM upstream neighbor that instructs or advices the PIM downstream
   neighbor to choose another of its own ECMP links between the former
   and the latter. What we propose in this document is a criterion based
   on power consumed in the linecards that comprise the ECMP links
   between the former and the latter. Also the multicast replication
   capacity available within the said linecards which form the ECMP
   links between the two is taken into consideration while making a ECMP
   redirect.

   A PIM router uses RPF procedure to select an upstream interface and
   router to build forwarding state.  When there are equal cost multiple
   paths (ECMP), existing implementations often use hash algorithms to
   select a path.  Such algorithms do not allow the spread of traffic
   among the ECMPs according to administrative metrics.  This usually
   leads to inefficient or ineffective use of network resources.  This
   document introduces the ECMP Redirect, a mechanism to improve the RPF
   procedure over ECMPs.  It allows ECMP path selection to be based on
   administratively selected metrics, such as data transmission delays,
   path preferences and routing metrics.

   As mentioned earlier this document also proposes the use of the power
   being consumed by the linecards (if the ECMP links fall on multiple
   linecards with respect to their ECMP link ports) and the available
   replication capacity of the linecard within its ASICs as a measure of
   which ECMP link to which the PIM-Join is to be redirected to. If for
   example there exist multiple replication engines within different
   linecards then the lightly loaded replication engine and its
   corresponding ECMP link on that linecard can be recommended to the
   PIM downstream neighbor which sends the upstream neighbor a PIM join
   for a specific (S,G) or (*,G) group.




1.1  Terminology

   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].


2.  Conditions where this mechanism applies. 


   Assume there are multiple ECMP links between a PIM upstream and
 


Shankar Raman et.al         Expires May 2013                    [Page 3]

INTERNET DRAFT Replication capability based PIM redirect   November 2012


   downstream router. Lets assume they fall on different linecards on
   the upstream neighbor with respect to the port placement of these
   ECMP links. Assume one linecard A, which is already carrying multiple
   data streams in either the incoming direction on its ports and
   replicating it to multiple other outgoing linecards through the
   switch fabric. Assume another linecard B that is lightly loaded with
   respect to multicast traffic and heavily loaded with respect to the
   unicast traffic. Assume another linecard C which is lightly loaded
   with respect to both. Now also assume that these linecards A,B and C
   are all members of the group of linecards whose ports place
   themselves within the ECMP links between the upstream and downstream
   neighbor.

   It is possible to decipher from this is that linecard C would be a
   better point of placement of the replication for the group for which
   the PIM-Join comes from the downstream neighbor. Assume now that the
   downstream neighbor selects the linecard A. It is now possible as a
   result of using the mechanism dictated to in [1], to send a redirect
   to the downstream neighbor that it would be a better choice to choose
   linecard C. This it does by recommending the neighbor address field
   as the port IP address which falls on linecard C. The PDU format for
   the ECMP redirect specified in [1] and the procedures that go along
   with it follow.

   It is also possible to make this decision in combination with the
   above or solely on a metric which we will call PWR-REPLIC-CAP. This
   metric is derived as follows...

   PWR-REPLIC-CAP = Power Consumed on that linecard
                    -------------------------------
                    Available replication capacity on the linecard.

   In the metric case the lowest PWR-REPLIC-CAP metric is chosen. This
   optimizes on the power being spent on replication to the extent
   possible.

   It is important to note that a linecard may have multiple replication
   engines and ports assigned to each replication engine or to all of
   them. It is possible that the ECMP links and their ports fall on the
   same linecard and in that case it would be possible to choose a
   specific replication engine from among the multiple replication
   engines available. that has better available replication capacity by
   choosing a neighbor address belonging to the port that falls in a set
   that belongs to the superior replication engine (with respect to the
   available replication capacity at that point in time). If there is no
   distinction amongst ports with respect to the multiple replication
   then it actually makes no difference since it would be an internal
   decision as to where the replication for that port actually happens.
 


Shankar Raman et.al         Expires May 2013                    [Page 4]

INTERNET DRAFT Replication capability based PIM redirect   November 2012


   It is also important to note here that the linecards that are
   multicast capable have well advertised replication capacities which
   the vendors advice in the linecard data sheets. This could be placed
   in a variable that can be monitored for shifts within intervals of
   threshold values. The same goes for the power consumed by the
   linecards as well.

   Pseudo code for the steps to be followed to implement this scheme is
   as follows...

   if (multiple ECMP links exist to the PIM neighbor 
       from which PIM-Join was received) then

       Get the list of ECMP ports which are members of the ECMP links;

       Get the list of linecards on which these ECMP ports are placed;

       LCA = Consider the least used linecard with respect 
       to the replication capacity;

       if (port on LCA is the same on which PIM-Join was received)

           do nothing; return;

       else if (choice is to be made on replication capacity)

           LCA = Consider the least used linecard with respect 
                 to replication capacity;

       else if (choice is to be made on PWR-REPLIC-CAP)

           LCA = Consider the linecard with the best 
                 PWR-REPLIC-CAP metric;

       end if

       Send PIM redirect to PIM downstream neighbor 
       recommending LCA ECMP link;

   end if








 


Shankar Raman et.al         Expires May 2013                    [Page 5]

INTERNET DRAFT Replication capability based PIM redirect   November 2012


3  Security Considerations

   <Security considerations text>


4  IANA Considerations

   <IANA considerations text>


5  References

5.1  Normative References


5.2  Informative References

              [1] Yiqun, Cai et.al, Protocol Independent Multicast ECMP
              Redirect, "draft-ietf-pim-ecmp-02.txt", Work in Progress,
              October 2011.

              [2] Shankar Raman, et.al, Building power optimal Multicast
              Trees, "draft-mjsraman-rtgwg-pim-power-01.txt", Work in
              Progress, February 2011.




Authors' Addresses


   Shankar Raman
   Department of Computer Science and Engineering
   I.I.T Madras,
   Chennai - 600036
   TamilNadu,
   India.

   EMail: mjsraman@cse.iitm.ac.in



   Balaji Venkat Venkataswami
   Department of Electrical Engineering,
   I.I.T Madras,
   Chennai - 600036,
   TamilNadu,
   India.
 


Shankar Raman et.al         Expires May 2013                    [Page 6]

INTERNET DRAFT Replication capability based PIM redirect   November 2012


   EMail: balajivenkat299@gmail.com



   Prof.Gaurav Raina
   Department of Electrical Engineering,
   I.I.T Madras,
   Chennai - 600036,
   TamilNadu,
   India.

   EMail: gaurav@ee.iitm.ac.in







































Shankar Raman et.al         Expires May 2013                    [Page 7]