One document matched: draft-zhou-pim-vrrp-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc category="info" ipr="trust200902"
     docName="draft-zhou-pim-vrrp-00.txt">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<front>
  <title>VRRP PIM Interoperability</title>
  <author initials='W.' surname='Zhou' fullname='Wei Zhou'>
    <organization>cisco Systems</organization>
    <address><postal>
        <street>Tasman Drive</street>
	<city>San Jose</city> <region>CA</region>
	<code>95134</code>
	<country>USA</country>
      </postal>
      <email>weizho2@cisco.com</email></address>
  </author>
  <date/>
  <abstract>
    <t>This document introduces VRRP Aware PIM, a redundancy mechanism
    for the Protocol Independent Multicast (PIM) to interoperate with 
	Virtual Router Redundancy Protocol (VRRP). It allows PIM to track VRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled.</t>
  </abstract>
</front>

<middle>
  <section title="Introduction">
    <t>Virtual Router Redundancy Protocol (VRRP) <xref target="RFC5798"/> is a redundancy protocol for
    establishing a fault-tolerant default gateway. The protocol 
	establishes a framework between network devices in order to achieve 
	default gateway failover if the primary gateway becomes inaccessible .
    
    </t>
	<t>
    PIM has no inherent redundancy capabilities and its operation is completely independent of VRRP group states. As a result, IP multicast traffic is forwarded not necessarily by the same device as is elected by VRRP. The VRRP Aware PIM feature provides consistent IP multicast forwarding in a redundant network with virtual routing groups enabled.
    </t>
    <t>
    In a multi-access segment (such as LAN), PIM designated router (DR) election is unaware of the redundancy configuration, and the elected DR and VRRP master router (MR) may not be the same router. In order to ensure that the PIM DR is always able to forward PIM Join/Prune message towards RP or FHR, the VRRP MR becomes the PIM DR (if there is only one VRRP group). PIM is responsible for adjusting DR priority based on the group state. When a failover occurs, multicast states are created on the new MR elected by the VRRP group and the MR assumes responsibility for the routing and forwarding of all the traffic addressed to the VRRP virtual IP address. This ensures the PIM DR runs on the same gateway as the VRRP MR and maintains mroute states. It enables multicast traffic to be forwarded through the VRRP MR, allowing PIM to leverage VRRP redundancy, avoid potential duplicate traffic, and enable failover, depending on the VRRP states in the device.
</t>
  </section>
  <section title="Tracking and Failover">
    <t>
    With VRRP Aware PIM enabled, PIM listens to the state change notifications from VRRP and automatically adjusts the priority of the PIM DR based on the VRRP state, and ensures VRRP MR (if there is only one VRRP group) becomes the DR of the LAN. If there are multiple VRRP groups, the DR is determined by user-configured priority.
	    </t>
    <t>
	PIM triggers communication between upstream and downstream devices upon failover in order to create mroute states on the new MR. PIM sends additional PIM Hello message using the VRRP virtual IP addresses as the source address for each active VRRP group when a device becomes VRRP Active. The PIM Hello will carry a new GenID in order to trigger other routers to respond to the failover. When a downstream device receives this PIM Hello, it will add the virtual address to its PIM neighbor list. The new GenID carried in the PIM Hello will trigger downstream routers to resend PIM Join messages towards the virtual address. Upstream routers will process PIM Join/Prunes (J/P) based on VRRP group state.
    </t>
    <t>
	If the J/P destination matches the VRRP group virtual address and if the destination device is in VRRP active state, the new MR processes the PIM Join because it is now the acting PIM DR. This allows all PIM Join/Prunes to reach the VRRP group virtual address and minimizes changes and configurations at the downstream routers side.
    </t>

  </section>
	 <section title="PIM Assert Metric Auto-Adjustment">
   
	<t>It is possible that, after VRRP active switched from A to B; A is still forwarding multicast traffic which will result in duplicate traffic and PIM Assert mechanism will kick in. PIM Assert with redundancy is enabled.</t>
	<t><list style="symbols">      
	<t>If only one VRRP group, passive routers will send a large penalty metric preference (PIM_ASSERT_INFINITY - 1) and make MR the Assert winner.</t>
	<t>If there are multiples VRRP groups configured on an interface, Assert metric preference will be (PIM_ASSERT_INFINITY - 1) if and only if all VRRP groups are in passive.</t>
	<t>If there is at least one VRRP group is in Active, then original Assert metric preference will be used. That is, winner will be selected between routers using their real Assert metric preference with at least one active VRRP Group, just like no VRRP is involved.</t>
	    </list></t>
	  </section>

    <section title="DF Election for BiDir Group">

	<t>Change to DF offer/winner metric is handled similarly to PIM Assert handling with VRRP.</t>
		<t><list style="symbols"> 
<t>If only one VRRP group, passive routers will send a large penalty metric preference in Offer (PIM_BIDIR_INFINITY_PREF- 1) and make MR the DF winner.</t>
<t>If there are multiples VRRP groups configured on an interface, Offer metric preference will be (PIM_BIDIR_INFINITY_PREF- 1) if and only if all VRRP groups are in passive.</t> 
<t>If there is at least one VRRP group is in Active, then original Offer metric preference to RP will be used. That is, winner will be selected between routers using their real Offer metric with at least one active VRRP Group, just like no VRRP is involved.</t>
  </list></t>
    </section>
	
    <section title="Tracking Multiple VRRP Groups on an Interface">
      <t>User can configure PIM to track more than one VRRP groups on an interface. This allows other applications to exploit the PIM/VRRP interoperability to achieve various goals (e.g., load balancing). Since each VRRP groups configured on an interface could be in different states at any moment, the DR priority is adjusted. PIM Assert metric and PIM Bidir DF metric if and only if all VRRP groups configured on an interface are in passive (non-Active) states to ensure that interfaces with all-passive VRRP groups will not win in DR, Assert and DF election. In other words, DR, Assert, DF winner will be elected among the interfaces with at least one Active VRRP group.</t>
    </section>

	<section title="Support of HSRP">
      <t>Although there are differences between VRRP and Hot Standby Router Protocol (HSRP) <xref target="RFC2281"/> including number of backup (standby) routers, virtual IP address and timer intervals, the proposed scheme can also enable HSRP aware PIM with similar switchover and tracking mechanism described in this draft.</t>
    </section>

  <section title="Security Considerations">
    <t>
The proposed tracking mechanism has no negative impact on security.
</t>
  </section>
  <section title="Acknowledgments">
	    <t>I would like to give a special thank you and appreciation
   to Stig Venaas for his ideas and comments in this draft.</t>
  </section>
</middle>
<back>
  <references title='Informative References'>
    <?rfc include='reference.RFC.5798' ?>
	<?rfc include='reference.RFC.2281' ?>
  </references>
</back>
</rfc>