<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
 
<rfc category="std" docName="draft-thubert-rtgwg-arc-bicast-01" ipr="trust200902">
  <front>
    <title abbrev="ARC bicasting">Applying Available Routing Constructs to bicasting</title>


       <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization abbrev="Cisco">Cisco Systems, Inc</organization>
      <address>
         <postal>
            <street>Building D</street>
            <street>45 Allee des Ormes - BP1200 </street>
            <city>MOUGINS - Sophia Antipolis</city>
            <code>06254</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 497 23 26 34</phone>
         <email>pthubert@cisco.com</email>
      </address>
   </author>

	
    <author fullname=" IJsbrand Wijnands" initials="IJ" 
            surname="Wijnands">
      <organization abbrev="Cisco Systems">Cisco Systems</organization>

      <address>
        <postal>
          <street>De kleetlaan 6a</street>

          <city>Diegem</city>

          <code>1831</code>

          <country>Belgium</country>
        </postal>

        <email>ice@cisco.com	</email>
      </address>
    </author>
	
    <date />

    <area>Routing Area</area>

    <workgroup>RTGWG</workgroup>

    <keyword>Draft</keyword>

<abstract>
 <t>	
 <!--
   Existing fast-reroute approaches enable an alternate route for most 
   unique breakages but cannot guarantee loopless traffic continuity
   in case of multiple breakages, nor easily segragate the impacted 
   area. 
   -->
   This draft introduces methods that leverage the concept of ARC to enable 
   bicasting operations.
   <!--
   In particular, a single breakage in an ARC on the way to a preferred end 
   is recovered with no routing recomputation using the other end , so
   an ARC-based routing topology is resilient to multiple breakages,
   one per ARC.--> 
 </t>
</abstract>

    <note title="Requirements Language">
      <t>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in 
   <xref target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
	
    <t>
    Traditional routing and forwarding uses the concept of path as the
    basic routing paradigm to get a packet from a source to a destination
	by following an ordered sequence of arrows between intermediate nodes.
	In this serial design, a path is broken as soon as a single arrow is,
	<!--that is as soon as a node or a link along the path ceases to operate 
	appropriately;--> 
	and getting around a breakage can require path recomputation, 
	network reconvergence, and incur delays to till service is restored. 
	</t>
	<!--t>
	It is also possible to compute an alternate routing topology for fast
	rerouting to a given destination, in which case some signalling, tagging
	or labelling can be put in place to indicate whether a packet follows the
	normal path or was rerouted over an alternate topology. Once a packet 
	is rerouted, it is bound to the alternate topology so only one breakage
	can be handled with looplessness guarantees in most practical situations.
	</t-->
	<t>
	<xref target="I-D.thubert-rtgwg-arc">Available Routing Constructs</xref> (ARC)
	introduces the concept of ARC as a routing construct made of a sequence of nodes
	and links with 2 outgoing edges, that is this resilient to one breakage so that 
	an ARC topology is resilient to one breakage per ARC. 
	</t>
	<t>
	The routing graph to reach a certain destination is expressed as a cascade of ARCs, 
	which terminates in an abstract destination Omega,
	each ARC providing its own independent domain of fault isolation and recovery:
	    <figure anchor="ARCRep" title="ARC Representation">
            <artwork>
            	<![CDATA[ 
          
                          +========I========+
                          |                 |                   
                          |              +====J====+          
                          |              |         |           
                   +====H====+           |     +=====K=====+  
                   |         |           |     |           |  
            +====D====+   +====E====+  +====F====+  +====G====+     
            |         |   |         |  |         |  |         |  
          +=========B=========+     |  |   +==========C==========+
          |                   |     |  |   |                     |   
          |                 +======A=======+                     |
          |                 |              |                     |
 ------------------------------------------------------------------Omega

				]]>
			</artwork>
		</figure> 	
	</t>
	<t>
	This cascade of ARCs appears ideally suited to the operation of bicasting
	(a.k.a. duocasting), which consists in sending two copies of a single packet, 
	if possible over divergent - that is fully or partially non-congruent - paths,
	in order to augment the chances that at least one of the copies 
	reaches the destination timely.
	</t>
	</section>
	
	
	
    <section anchor="Terminology" title="Terminology">

	<t> The draft uses the terminology defined in <xref target="I-D.thubert-rtgwg-arc"/>.</t>
	<t>
	This specificatin also introduces Sided ARCs, that is ARCs with at least an Edge that
	is known as Left and an Edge that is known as Right. 
	The sense of Left and Right adds up to the existing 
	sense of height that is already defined in <xref target="I-D.thubert-rtgwg-arc"/>.
	
	    <figure anchor="ARCSides" title="Orienting ARCs">
            <artwork>
   <![CDATA[ 
                          R========I========L
                          |                 |                   
                          |              L====J====R          
                          |              |         |           
                   L====H====R           |     R=====K=====L 
                   |         |           |     |           |  
            R====D====L   L====E====R  L====F====R  R===G====L    
            |         |   |         |  |         |  |        |  
          R=========B=========L     |  |   R==========C==========L
          |                   |     |  |   |                     |   
          |                 L======A=======R                     |
          |                 |              |                     |
 ------------------------------------------------------------------Omega
  ]]>
			</artwork>
		</figure> 
		One way of doing this is 
		<list style="symbols">
		<t>The basic rule is that an ARC MUST have at least one 
		Left and one Right Edge.
		</t>
		<t>
		The leg of an ARC between the cursor and the Edge inherits
		the side of the Edge. In a Comb, the whole buttressing ARC
		inherits the side of the Edge.
		</t>
		<t>An Edge ending in Omega can arbitrarily become Left or Right
		as long as the basic rule is satisfied. 
		</t>
		<t>An Edge that does not end in Omega inherits
		the side of an ARC it terminates into, again as long as the
		basic rule is satisfied. 
		</t>
		<t>A collision occurs if all the Edges end up on the same side.
		The shortest path is used to resolve the collision and restore
		the basic rule: the Edge closer to Omega and all butressing ARCs
		on the same side of the cursor keep the side, and the other Edges
		are toggled. In case of equal cost, an other tie breaker must be used.  
		</t>
		<t>
		For instance, this situation occurs in the representation above
		for ARC F, which has both ends ending in a Right side of ARCs, 
		and since the Edge closer to Omega is the one that ends in ARC C,
		that Edge becomes Right and the other becomes Left. 
		</t>
		</list>
		</t>
	</section>
	
    <section title="Downward Bicasting Operation">
	<t>	Two copies of a same packet from a given node are forwarded downwards
	along opposite side of the cascading ARCs, each packet bearing an indication
	(such as a tag or a label) of its intended side, Left or Right. 
	</t>
	<t>	The packets exit the ARCs along their paths through an Edge that
	matches the indication in the packet.
	<figure anchor="ARCdown" title="Bicasting Down an ARC ascade">
            <artwork>
 <![CDATA[ 
                                 packet |
                          rrrrrrrrrrrrrrVllll
                          r                 l                   
                          r              llll=J====R          
                          r              l         |           
                   L====H=rrrr           l     R=====K=====L 
                   |         r           l     |           |  
            R====D====L   L==rrrrrrrr  lll==F====R  R===G====L    
            |         |   |         r  l         |  |        |  
          R=========B=========L     r  l   R==========C==========L
          |                   |     r  l   |                     |   
          |                 lllllllllrrlrrrr                     |
          |                 l              r                     |
 ------------------------------------------------------------------Omega
 ]]>
			</artwork>
		</figure> 
	As it goes, the method does not guarantee a full non congruence 
	of the paths, as illustrated above. In case of a breakage, this can be 
	compensated by the capability to return a packet along an ARC upon a 
	failure, that is already used to protect unicast traffic.
	<figure anchor="ARCdnbrek" title="Breakage at a Congruent Link">
            <artwork>
 <![CDATA[ 
                                 packet |
    l Left  packet path   rrrrrrrrrrrrrrVllll
    R Right packet path   r                 l                   
                          r              llll=J====R          
                          r              l         |           
                   L====H=rrrr           l     R=====K=====L 
                   |         r           l     |           |  
            R====D====L   L==rrrrrrrr  lll==F====R  R===G====L    
            |         |   |         r  l         |  |        |  
          R=========B=========L     r  l   R==========C==========L
          |                   |     r  l   |                     |   
          |                 rrrrrrrrr\/lllll                     |
          |                 r        /\    l                     |
 ------------------------------------------------------------------Omega
 ]]>
			</artwork>
		</figure> 	
	</t>
	</section>
    <section title="Upward Bicasting Operations">
	<t>It is also possible with a downward bicasting to place states in the intermediate routers
	in order to provision an upward bicast path from Omega to a source D. In that case, if the graph
	is biconnected, it is possible to resolve the pathological cases so as to ensure a real separation
	of the left and Right paths.
	</t>
	
    <section title="Resolving crossing ARCs">
	
	<t>The first pathological case occurs when both Left and Right packet cross
	over the same ARC, as illustrated below. Say that the Right reservation
	comes first and sets up the right path:
	
	<figure anchor="ARCcross" title="crossing: Right packet">
            <artwork>
 <![CDATA[ 
                             r           |
            R====D====L   L==rrrrrrrr  L====F====R  R===G====L    
            |         |   |         r  |         |  |        |  
          R=========B=========L     r  |   R==========C==========L
          |                   |     r  |   |                     |   
          |                 L======Arrrrrrrr                     |
          |                 |              r                     |
 ------------------------------------------------------------------Omega
 ]]>
			</artwork>
	</figure>
		Then comes the left reservation which collisions:
	<figure anchor="ARCcross1" title="crossing: left packet approaching">
            <artwork>
 <![CDATA[ 
                             r           l
            R====D====L   L==rrrrrrrr  lll==F====R  R===G====L    
            |         |   |         r  l         |  |        |  
          R=========B=========L     r  l   R==========C==========L
          |                   |     r  l   |                     |   
          |                 L======Arrr?rrrr                     |
          |                 |              r                     |
 ------------------------------------------------------------------Omega
 ]]>
			</artwork>
	</figure>
		The segment between the two incoming point of the common ARC
		is common to both path and expose the bicasted traffic.
		The resolution is to leave the second packet through but prune
		the unwanted states along the collision segment of the ARC afterwards.
		
	<figure anchor="ARCcross2" title="crossing: Resolved state">
            <artwork>
 <![CDATA[ 
 
                             r           l
            R====D====L   L==rrrrrrrr  lll==F====R  R===G====L    
            |         |   |         r  l         |  |        |  
          R=========B=========L     r  l   R==========C==========L
          |                   |     r  l   |                     |   
          |                 lllllllll==rrrrr                     |
          |                 l              r                     |
 ------------------------------------------------------------------Omega
 ]]>
			</artwork>
		</figure> 	
		
		States along the ARC between the two incoming points are cleaned,
		up and the paths that were generated by the Left and Right packets
		are now crossed. This results in two non-congruent upward paths. 
	</t>
	</section>
    <section title="Single Point of Failure">
	
	<t>The second pathological case occurs when both Left and Right packet
	reach a same ARC at the same node, which is this a Single Point Of Failure
	(SPoF) for both paths. 
	
	<figure anchor="SPoF" title="SPoF: Right packet">
            <artwork>
 <![CDATA[ 
                             r           |
            R====D====L   L==rrrrrrrr  L====F====R  R===G====L    
            |         |   |         r  |         |  |        |  
          R=========B=========L     r  /   R==========C==========L
          |                   |      r/    |                     |   
          |                 L======A==rrrrrr                     |
          |                 |              r                     |
 ------------------------------------------------------------------Omega
 ]]>
			</artwork>
	</figure>
		The resoution is to reject the second packet and send it back 
		along the incoming ARC to exit on the other side. The rejected
		packet clans up the states that it has created on its way back
		and then creates states on the other side of the ARC.
		
	<figure anchor="SPoF1" title="SPoF: Left Packet">
            <artwork>
 <![CDATA[ 
                             r           l
            R====D====L   L==rrrrrrrr  lllllllllll  R===G====L    
            |         |   |         r  lll       l  |        |  
          R=========B=========L     r  ll  R=====lllllllllllllllll
          |                   |      rll   |                     l   
          |                 L======Arrrrrrrr                     l
          |                 |              r                     l
 ------------------------------------------------------------------Omega
 ]]>
			</artwork>
		</figure> 	
		At this point the downward packet will exit the incoming ARC in
		the wrong side for its own indication.
		<figure anchor="SPoF2" title="SPoF: Resolved state">
            <artwork>
 <![CDATA[ 
                             r           l
            R====D====L   L==rrrrrrrr  L=lllllllll  R===G====L    
            |         |   |         r  |         l  |        |  
          R=========B=========L     r  |   R=====lllllllllllllllll
          |                   |     r  |   |                     l   
          |                 L======Arrrrrrrr                     l
          |                 |              r                     l
 ------------------------------------------------------------------Omega
 ]]>
			</artwork>
		</figure> 	
		This is in fact what happens also in the case of a monoconnected zone,
		or if a breakage cause the downward packet to bounce.
	</t>
 
 
    </section>

	</section>
  
    <section title="Applicability">
    <section title="In conjunction with Protocol Independent Multicast">
	<t>
	Upwards bicasting can be used for Protocol Independent Multicast <xref target="RFC4601">PIM</xref>
    and Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths <xref target="RFC6388">mLDP</xref>.
	A bicasted downards Join message would establish two non congruent return paths, 
	each path joining the receiver and Omega that is the set of existing receivers. 
	</t>
	
    </section>
    </section>
	
    <section title="Manageability">
	<t>This specification describes a generic model. Protocols and management will come later</t>
	
    </section>
    <section anchor="IANA" title="IANA Considerations">
	<t>This specification does not require IANA action.</t>
	
        </section>
		
    <section anchor="Sec" title="Security Considerations">
	<t>This specification is not found to introduce new security threat.</t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
	<t>The authors wishes to thank Dirk Anteunis, Stewart Bryant, Patrice Bellagamba, George Swallow, 
	Eric Osborne, Clarence Filsfils and Eric Levy-Abegnoli for their participation and continuous 
	support to the work	presented here.
	</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
		<?rfc include="reference.RFC.2119"?>
    </references>

    <references title="Informative References">
		<?rfc include="reference.RFC.4601"?>
		<?rfc include="reference.RFC.6388"?>
		<?rfc include='reference.I-D.thubert-rtgwg-arc.xml'?>
    </references>


  </back>
</rfc>
