[resending due to excess size ]
Dear Routing area; About http://www.ietf.org/id/draft-thubert-rtgwg-arc-00.txt The ARC technology derives from some internal research at cisco, and following that line of thought, we found a number of interesting properties that we want to share with you. Some of you already know about ARCs. This is not yet another FRR solution, but rather another way of looking at a routing topology and forwarding. Instead of following the arrows along a path, a packet will cascade from arc to arc, each arc providing at least 2 edges that the packet can use to progress. Certainly, ARCs can be used for fast reroute, but there are tons of other applications. This particular draft mainly presents the concepts, and will defrer to more drafts to specify actual solutions for the specific problems that we want to address with ARCs. We have begun recently to open the technology for particular applications, in particular at ISA100 and IEC SC65C in the context of industrial wireless networking. Those networks require multiple forwarding solutions for each node and a packet may hit multiple transient failures along its way over a multihop wireless mesh. Industrial WSN is thus a practical use case for which simple DAGS cannot apply and where even the MRT approach is not sufficient. As you go through the draft, you'll find that an ARC topology is made of multiple ARCs and that each ARC allows at least one breakage with the FRR low packet loss. You’ll find that an ARC topology can be made to follow the SPF path in normal operation and yet provide an alternate for all nodes in a biconnected graph. You’ll find that monoconnected zones are easily isolated and that the proposed computation can recurse there to obtain a maximal redundancy. [cid:[email protected]] An ARC topology can be exploited in classical routing or in MPLS. The recovery can be data plane or control plane which provides additional capabilities. Because ARCs are (at least) dual ended, an ARC topology also enables load balancing and a recursive overflow management to take the traffic away from the pain points. There's probably a lot more, but we'll have to discover that together. About IPR: Stewart recommended that I talk to Alia (and effectively Joel) in Taipei to make sure that the IPR cisco has on ARC is not on the way of MRT, and we concluded that these were effectively 2 different technologies. So cisco did not claim IPR regarding MRT but we certainly have IPR on ARCs. We'll post ASAP on that. Please let us know if this approach triggers interest. We wish to discuss ARCs during the RTGWG meeting in Atlanta and will be asking for a slot from the chairs. Cheers, Pascal
<<inline: image003.png>>
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
