PIM-Bidir RPL Resiliency
draft-zzhang-pim-bidir-rpl-resiliency-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Zhaohui (Jeffrey) Zhang , Kurt Windisch , Jaroslaw Adam Gralak | ||
| Last updated | 2014-04-19 (Latest revision 2013-10-16) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
With PIM-Bidir, the RPA does not have to be associated with a router. Rather, it only needs to be a routable address on a RPL (typically a multi-access network). Such a scenario is commonly referred as Phantom RPA. This achieves RP resiliency to some extent, because the "RP" will not fail. However, if the RPL itself partitions, traffic converged to one partition will not be able to reach other parts of the network where joins converge to the other partitions of the RPL. This document proposes simple procedures, which does not require signaling extensions, to achieve RPL resiliency.
Authors
Zhaohui (Jeffrey) Zhang
Kurt Windisch
Jaroslaw Adam Gralak
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)