PIM Extensions for Protection Using Maximally Redundant Trees
draft-kebler-pim-mrt-protection-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Robert Kebler , Alia Atlas , Naiming Shen , Yiqun Cai | ||
| Last updated | 2013-02-18 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kebler-pim-mrt-protection-00
Protocol Independent Multicast Working R. Kebler, Ed.
Group A. Atlas
Internet-Draft Juniper Networks
Intended status: Standards Track N. Shen
Expires: August 19, 2013 Cisco Systems, Inc.
Y. Cai
Microsoft
February 15, 2013
PIM Extensions for Protection Using Maximally Redundant Trees
draft-kebler-pim-mrt-protection-00
Abstract
This document specifies Protocol Independent Multicast (PIM)
procedures for Failure Protection, as specified in the MRT Multicast
architecture [I-D.atlas-rtwg-mrt-mc-arch-00]. This can be
accomplished with Global Repair (aka Live-Live) or with Local Repair
(aka Fast Re-route). Maximally Redundant Trees (MRTs) provide the
capability to PIM to provide alternate paths around any given
failure.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 19, 2013.
Copyright Notice
Copyright (c) 2013 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
Kebler, et al. Expires August 19, 2013 [Page 1]
Internet-Draft PIM Protection using MRTs February 2013
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Global Protection (Live-Live) . . . . . . . . . . . . . . . . 4
3.1. Egress Router Behavior . . . . . . . . . . . . . . . . . . 5
3.2. Limitation when a LAN is a cut-link . . . . . . . . . . . 5
3.3. Using Different Groups to identify MRTs . . . . . . . . . 5
4. Local Protection . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. PLR Replication . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Unicast convergence during PLR Replication . . . . . . 7
4.1.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 7
4.1.4. Downstream Routers from the MP . . . . . . . . . . . . 8
4.1.5. Protected Node Behavior . . . . . . . . . . . . . . . 8
4.2. MP-Initiated Alternate Trees . . . . . . . . . . . . . . . 8
4.2.1. Building the Backup Trees . . . . . . . . . . . . . . 9
4.2.2. PLR behavior . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. MP behavior . . . . . . . . . . . . . . . . . . . . . 10
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Hello Options . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. MRT Protection Capabilities . . . . . . . . . . . . . 11
5.1.2. MP ID For PLR Replication . . . . . . . . . . . . . . 12
5.2. Join Attributes . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Merge Point Attribute . . . . . . . . . . . . . . . . 12
5.2.2. MRT Backup Attribute . . . . . . . . . . . . . . . . . 13
5.2.3. Upstream Address Join Attribute . . . . . . . . . . . 15
5.3. Encoded-Source Address Changes . . . . . . . . . . . . . . 16
5.4. New PIM Message Types . . . . . . . . . . . . . . . . . . 17
5.4.1. Join Response . . . . . . . . . . . . . . . . . . . . 17
5.4.2. PIM Backup JoinPrunes . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Kebler, et al. Expires August 19, 2013 [Page 2]
Internet-Draft PIM Protection using MRTs February 2013
1. Introduction
This document specifies how to reduce traffic loss after network
failures by using Maximally Redundant Trees (MRTs). This can be
accomplished with Global Repair (aka Live-Live) or with Local Repair
(aka Fast Re-route). The tradeoffs and applicability for each method
of protection are discussed in the MRT Multicast architecture
[I-D.atlas-rtwg-mrt-mc-arch-00].
With Global Repair, a multicast egress will send PIM Joins for the
same stream on multiple MRT topologies. The Global Repair specified
in this document is similar to [I-D.karan-mofrr]. This document
specifies how this can be accomplished using MRTs, however, providing
100% coverage without requiring any particular network topology.
Local Repair for Link or Node protection can also be used to protect
Multicast traffic. A Point of Local Repair (PLR) can replicate the
traffic to all Merge Points (MPs). In order to accomplish this, the
PLR must know the unicast destination of all MPs. Upon the failure,
the PLR will send the traffic to all MPs.
An alternative to PLR replication is for the MPs to join an alternate
tree to be used upon a network failure. For Node Protection,
additional signaling is required for the MPs to learn of the PLR.
Extensions are also needed to distinguish a backup Join and to signal
the additional information required to specify the particular
alternate tree. Upon a failure to the primary RPF interface, the MP
will forward traffic from the alternate tree.
2. Terminology
2-connected: A graph that has no cut-vertices. This is a graph
that requires two nodes to be removed before the network is
partitioned.
cut-link: A link whose removal partitions the network. A cut-link
by definition must be connected between two cut-vertices. If
there are multiple parallel links, then they are referred to as
cut-links in this document if removing the set of parallel links
would partition the network.
cut-vertex: A vertex whose removal partitions the network.
Maximally Redundant Trees (MRT): A pair of trees where the path
from any node X to the root R along the first tree and the path
from the same node X to the root along the second tree share the
minimum number of nodes and the minimum number of links. Each
Kebler, et al. Expires August 19, 2013 [Page 3]
Internet-Draft PIM Protection using MRTs February 2013
such shared node is a cut-vertex. Any shared links are cut-links.
Any RT is an MRT but many MRTs are not RTs.
Maximally Redundant Multicast Trees (MRMT): A pair of multicast
trees built of the sub-set of MRTs that is needed to reach all
interested receivers.
network graph: A graph that reflects the network topology where all
links connect exactly two nodes and broadcast links have been
transformed into the standard pseudo-node representation.
Redundant Trees (RT): A pair of trees where the path from any node
X to the root R along the first tree is node-disjoint with the
path from the same node X to the root along the second tree.
These can be computed in 2-connected graphs.
Merge Point (MP): For local repair, a router at which the alternate
traffic rejoins the primary multicast tree. For global
protection, a router which receives traffic on multiple trees and
must decide which stream to forward on.
Point of Local Repair (PLR): The router that detects a local
failure and decides whether and when to forward traffic on
appropriate alternates.
MT-ID: Multi-topology identifier
Stream Selection: The process by which a router determines which of
the multiple primary multicast streams to accept and forward. The
router can decide on a packet-by-packet basis or simply per-
stream. This is done for global protection as described in
[I-D.karan-mofrr].
MultiCast Egress (MCE): Multicast Egress, a node where the
multicast stream exists the current PIM domain. This is usually a
receiving router that may forward the multicast traffic towards
receivers based upon IGMP or other technology.
3. Global Protection (Live-Live)
In order to achieve Global Protection, traffic will flow through the
network through disjoint paths. A multicast egress (MCE) router will
trigger this traffic flow by sending PIM joins on two different
interfaces. The MRT algorithm will ensure that these joins travel
through maximally disjoint paths to the source. The egress router
must then forward a single stream along to its downstream members.
Any failure in the network to either stream can be repaired by this
Kebler, et al. Expires August 19, 2013 [Page 4]
Internet-Draft PIM Protection using MRTs February 2013
egress router, since it is receiving the redundant stream.
Any router that is capable of supporting Global Repair with MRTs must
advertise the T bit in the MRT Protection Hello Option.
3.1. Egress Router Behavior
A multicast egress (MCE) router will join a multicast stream on both
the Blue and Red MRT. The MT-ID [RFC6420] of the MRT will be
included in the Join as a Join Attribute [RFC5384]. Traffic will
flow down both MRTs to the egress router to achieve redundancy. The
egress router will forward a single stream along to its downstream
interfaces. The techniques for this stream selection are described
in MoFRR [I-D.karan-mofrr].
3.2. Limitation when a LAN is a cut-link
There is a limitation in end-to-end protection when, for a given S,G,
the MRTs converge on a single LAN with different upstream neighbors.
In this case, both upstream neighbors will be sending on the LAN, and
there is no distinguishing the data traffic for the different MRTs if
it is carried with the same S,G. The PIM Assert procedures will
select a single forwarding router on the LAN and the other router
will stop sending. This could cause the Assert Loser to prune back
the S,G. Therefore, traffic will flow on only one MRT between the
source and the downstream router on the LAN.
3.3. Using Different Groups to identify MRTs
There may be cases when different sources or groups are used to send
the same stream, as decribed in the MRT Multicast architecture
[I-D.atlas-rtwg-mrt-mc-arch-00]. In this case the egress router may
not need to perform the stream selection. However, it would be
desirable for the egress router to join the sources or groups on
different MRTS. The mechanism to perform group to MRT mapping is
outside the scope of this document. Once the egress router knows the
group to MRT mapping, then it will join for the S,G on the particular
tree by including the MT-ID for the MRT in the Join message. In this
case, the streams can travel across the same LAN without the issues
described above.
4. Local Protection
Local Protection can protect either a link or node, and this will be
determined on a per flow basis. Two extra bits will be used from the
Encoded-Source Address in the Join-Prune messages to indicate whether
the source in the Join/Prune should have link or node protection.
Kebler, et al. Expires August 19, 2013 [Page 5]
Internet-Draft PIM Protection using MRTs February 2013
Each router will advertise in its MRT Protection Hello Options
whether it is capable of performing Link or Node protection.
Two methods of Local Protection are discussed in this document. The
first method is when the PLR sends the traffic to be protected to all
Merge Points. Also, there is a second method to reduce the
replication burden on the PLR. With this method, alternate multicast
trees are built from the MPs to the PLR. These methods are described
in subsequent sections.
4.1. PLR Replication
At a PLR, each S,G flow will have a set of downstream interfaces and
a set of MPs for each downstream interface. There will be MPLS label
information learned for each MP. Upon a failure to the protected
link, the PLR will encapsulate and send the protected multicast
traffic to all MPs for that particlar (S,G,intf). The MP will,
therefore, receive the encapsulated data upon the failure and traffic
will resume to all of its downstream receivers. Once the PLR has
given the downstream routers sufficient time to recover from the
failure, it can stop sending the protected traffic, and prune
upstream, if required.
For the PLR to send the protected traffic upon a failure, it requires
the unicast address and an MPLS label (which may be Implicit Null)
for all the Merge Points. Each MP will advertise this information in
a new MP ID Hello Option. If link protection is used, this is
sufficient to reach the PLR. For node protection, the information
for all MPs will be sent to the PLR in a Join Attribute from the
upstream node of the MP (i.e., the Protected Node).
All routers that support this functionality will advertise the Link
or Node capability bits in the MRT Protection Hello Option. Any Node
that is capable of acting as a PLR will advertise the PLR-Replication
capable bit in the MRT Protection Hello Option.
4.1.1. PLR Behavior
The PLR will learn the location of all the MPs in the its Join
Messages (for node protection) and Hello Messages (for link
protection) that it receives from downstream routers. The Merge
Points will be kept per (S,G, downstream-interface). Upon a failure
to the protected interface, the PLR will encapsulate and forward the
multicast data to all the MPs for that downstream interface, and it
will start the Alternate-Tree-Protection-Timer. The Alternate-Tree-
Protection-Timer should be a configurable timer with a default of 10
seconds. The PLR will suppress the PIM Prunes from being sent while
the Protection-Timer is running. Once this timer expires, it will
Kebler, et al. Expires August 19, 2013 [Page 6]
Internet-Draft PIM Protection using MRTs February 2013
stop sending the traffic to MPs, and it can send a Prune upstream if
required.
For a PLR to learn of all MPs, then Join Suppression must be disabled
on the interfaces between the MP and the PLR. In addition, the PLR
must accept all MP-ID Join Attributes that it receives from
downstream neighbors.
4.1.2. Unicast convergence during PLR Replication
Since it is likely for unicast routes to converge before PIM fully
converges, the PLR must still be able to route the traffic to all MPs
while unicast recovers from the original failure. The PLR must not
use stale forwarding information to reach the MPs for the protected
multicast traffic if unicast has already updated it forwarding
entries after the network event. An implementation should use the
same forwarding information that would be used to forward unicast
traffic to that destination. In this way, the PLR will be able to
forward traffic to the MPs.
4.1.3. MP Behavior
As is done today, the MP will forward traffic received on its normal
incoming interface. While the normal RPF interface is up,
encapulated alternate traffic will not be forwarded. If the RPF
interface fails, the MP will forward the encapulated alternate
traffic (if it is received with the correct encapsulation). This
procedure assumes that there is a method for the routers on both
sides of the protected link to determine if the link has gone down.
Such methods are outside the scope of this document.
After the incoming interface changes the MP will start the Alternate-
Tree-Protection-Timer. Once traffic arrives on the new incoming
interface or the Alternate-Tree-Protection-Timer expires, the Merge
Point will advertise the label for the new RPF interface, and it will
stop accepting the encapsulated alternate traffic.
The MP needs to know when it can release the label that it has
advertised and potentially re-use that label for another purpose. If
the interface goes down or the adjacency goes down on an interface
that the MP was advertising a label, it should wait (Protection-
Timeout + PLR_Propagation_Delay) seconds before re-using that label
for any other purpose. If the MP wants to change the label that is
was advertising on a particular interface, it should wait
(2*Hello_timer + 2*JoinPrune_Timer) before re-using the old label.
Kebler, et al. Expires August 19, 2013 [Page 7]
Internet-Draft PIM Protection using MRTs February 2013
4.1.4. Downstream Routers from the MP
Some make-before-break techniques must be used on routers downstream
from the failure to ensure that traffic is not discarded once these
routers learn of the unicast change. For example, if a downstream
router, upon a unicast route change, prunes itself off its old RPF
interface and discards traffic until the new tree is formed back to
the source, then there will be end-to-end loss. The work that the
upstream routers did to repair the local failure will be wasted since
the downstream router is going to discard flowing traffic. The make-
before-breaks procedures needed on the downstream router is outside
the scope of this document.
4.1.5. Protected Node Behavior
For Node Protection, the MP will be one hop away from the Protected
Node and two hops away from the PLR. In this case, there may be
multiple next-next-hops to advertise as Merge Points in the Join
Attribute. The Protected Node will learn the downstream members and
it will gather the MP information from each downstream neighbor's
Merge Point Hello Options. For each Merge Point in the downstream
list, the Protected Node will include a Merge Point Join Attribute in
the Join that is sent upstream to the PLR. The Merge Point
information may change for a route entry before the JoinPrune would
normally be updated or refreshed to the PLR. Upon a change to the
next-next hop list, the router can send a triggered JoinPrune with
the updated Join Attribute, or it can wait for the next periodic
refresh. It would be a tradeoff of increased control messages
against a window of being unprotected. For a PLR to learn of all
MPs, then Join Suppression must be disabled on the interfaces between
the MP and the PLR.
4.2. MP-Initiated Alternate Trees
In order to reduce the load of replication to all Merge Points on the
PLR, alternate trees can be signaled from the MP to the PLR. The MP
needs to learn the address of the PLR and then signal the Join
towards the PLR, avoiding the node or link that is to be protected.
An alternate multicast tree is formed from the MP to the PLR,
avoiding the Protected Node/Link. Upon the failure, the PLR will use
this alternate tree to forward the data to all MPs. The MP can prune
itself off the alternate tree once it reconverges after the failure,
and no longer needs the alternate tree to the given PLR.
Any node that is capable of supporting MP-initiated Backup Trees must
set the Backup-Join capable bit, the Join-Response Capable bit, and
at least one of the node protection or link protection capable bits
in the MRT Protection Hello Option. The PLR needs to advertise an
Kebler, et al. Expires August 19, 2013 [Page 8]
Internet-Draft PIM Protection using MRTs February 2013
Interface Identifier in the Interface Identifier Hello Option as
specified in [RFC6395]. The Router Identifier of this message may be
set to 0.
4.2.1. Building the Backup Trees
The MP will send the Join to it upstream neighbor and indicate in the
Join that it wants to do Node Protection or Link Protection. If Link
Protection is used then the MP has the address and interface id (from
the Interface Identifier Hello Option) of the PLR . If node
Protection is used, then the upstream node of the MP is the Protected
Node. If the MP supports Join Responses, as advertised in the MRT
Protection Hello Option, then the Protected Node must send a Join
Response to the MP. This Join Response has the same format as the
JoinPrune. For each source that requires node protection, the
Protected Node will include an Upstream Address Join Attribute with
the address of the PLR and the interface id advertised in the
Interface Identifier Hello Option of the RPF interface towards the
PLR.
PIM will consult the MRIB to obtain the the alternate upstream
neighbor towards the PLR, given the node or link that it is trying to
avoid. The MP will send a Backup Join to to this alternate upstream
neighbor and it will include a MRT Backup Join Attribute. The Backup
MRT Join attribute contains the PLR, the Protected-Node, the
Protected-Link, and the MPLS label. There will be a unique MPLS
label per backup tree. Additionally, the MP will include a MT-ID
Join Attribute [RFC6420] in the Backup Join indicating the MRT that
it expects to use to reach the PLR, avoiding the Protected-Node.
The Backup Join state must be maintained per (S,G,PLR,Protected-
Node,Protected Interface). If there is at least one downstream
receiver for a given per (S,G,PLR,Protected-Node,Protected
Interface), and the Join state is for the same MRT that this router
would use to reach the PLR, avoiding the Protected-Node, then this
router should propagate its Join upstream. The MRT of the downstream
receivers should match this router's MRT to reach the PLR, except
during transition events. If the MRTs are different, then the router
will wait until it converges or waits until it receives a new Backup
Join, indicating the correct MRT.
Once the last downstream receiver prunes from the (S,G,PLR,Protected-
Node,Protected Interface), then the router should Prune upstream.
Each router will propagate the same PLR, protected-node, and protect-
link info in the Backup MRT Join Attribute that it sends upstream.
Each router will also advertise a label in the Backup MRT Join
Attribute. The router will do a PLR, Protected-Node, Protected-link
lookup to label lookup to determine the label that it should use.
Kebler, et al. Expires August 19, 2013 [Page 9]
Internet-Draft PIM Protection using MRTs February 2013
How this mapping is performed is outside the scope of this document.
Join Suppression is only allowed if a downstream router detects
another Backup Join for the same (S,G,PLR,Protected-Node,Protected-
Interface,label). Otherwise the downstream router must not suppress
its own Backup Join.
The S,G in the Backup Join can be wildcard sources and groups. For
example, if a MP wants to protect all multicast groups, then it will
set the Source to 0/0 and the Group to 224/4. The MP can also
specify more specific S,G's in the Backup Join. For each S,G that
needs to be protected in upon a failure, the PLR will match the S,G
to the most specific backup Join entry when determining the MPs.
Thus, The MPs must all be in agreement if a more specific backup Join
is going to be signaled for a particular S,G. This would be
accomplished, most likely, with consistent configuration on each of
the MPs.
4.2.2. PLR behavior
Upon a failure to the downstream interface, the PLR will send traffic
on the Alternate Tree that is protecting this interface, and it will
start the Alternate-Tree-Protection-Timer for the S,G. The PLR will
not Prune back on its upstream, even if this is the last interface in
the outgoing list, while the Alternate-Tree-Protection-Timer is
running. If all the downstream members of the Protection Tree Prune
themselves, then the PLR can expire the Alternate-Tree-Protection-
Timer. Once this timer expires, then the PLR will stop sending
traffic on the Alternate Tree, and the PLR can Prune upstream, if
appropriate.
4.2.3. MP behavior
As is done today, the MP will forward traffic received on its normal
incoming interface. While the normal RPF interface is up, traffic
from the alternate tree will not be forwarded. If the RPF interface
fails, the MP will forward the encapsulated alternate traffic (if it
is received with the correct label). For a given interface, there
may be multiple backup trees that are using that interface. The
traffic for each of these backup trees must be programmed for
forwarding upon the link failure.
After the incoming interface changes the MP will start the Alternate-
Tree-Protection-Timer. Once traffic arrives on the new incoming
interface or the Alternate-Tree-Protection-Timer expires, the Merge
Point will advertise the label for the new RPF interface, and it will
stop accepting the encapsulated alternate traffic. The MP can then
prune the old alternate Tree for the previous PLR, Protected-Node,
Kebler, et al. Expires August 19, 2013 [Page 10]
Internet-Draft PIM Protection using MRTs February 2013
and protected Link. The MP will learn the new PLR, Protection Node,
and Protected Link from its upstream node and send a Backup Join to
the appropriate upstream neighbor.
5. Packet Formats
5.1. Hello Options
5.1.1. MRT Protection Capabilities
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |P|T|R|B|L|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRT Protection Hello Option Format
Type: TBD.
Length: 4
Value:
Reserved: Sent with 0, ignored on receipt
P: PLR Replication capable. This bit is set if a router is
capable of acting as a PLR-replicating router, as described in
this document. This router must also be capable of receiving a
Merge Point Join Attribute.
T: MRT Topology Capable. This bit is set if the router is
capable of understanding MRT topology IDs sent in the MT-ID
Join Attribute [RFC5384], as defined in this document.
R: Join Response Capable. This bit is set if the Router is
capable of sending and receiving Join Responses and Upstream
Address Join Attributes, as defined in this document.
B: Backup-Join Capable. This bit is set if the router is
capable of sending Backup Joins and MRT Backup Join Attribute,
as defined in this document.
Kebler, et al. Expires August 19, 2013 [Page 11]
Internet-Draft PIM Protection using MRTs February 2013
L: Link Protection Capable. This bit is set if the router is
capable of performing Link Protection, as defined in this
document.
N: Node Protection. This bit is set if the router is capable
of performing Node Protection, as defined in this document.
5.1.2. MP ID For PLR Replication
The following Hello option is used for a Merge Point to advertise its
address label.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MP ID Hello Option Format
Type: TBD.
Length: variable
MP ID: The Encoded-Unicast Address for the Merge Point
Reserved: 12 bits of reserved sent with 0. Ignored on receipt.
Label: 20 bit Label to be used for traffic that is being protected
5.2. Join Attributes
5.2.1. Merge Point Attribute
The following Join attribute is used for node protection, when the
Protected-Node needs to signal the Merge Point information to the
PLR. There will be a separate Merge Point Attribute for each Merge
Point being advertised for the source. This attribute should only be
sent to routers that are PLR-Replication capable, as advertised in
Kebler, et al. Expires August 19, 2013 [Page 12]
Internet-Draft PIM Protection using MRTs February 2013
the MRT Protection Hello Option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Merge Point Join Attribute
F-bit: This bit will be clear as this is a non-transitive
attribute.
E-bit: As defined in [RFC5384]
Type: TBD
Length field: variable
Value:
Reserved: Sent with zero, ignored on receipt
label: the MPLS label associated with this MP
MP: The encoded-Unicast addresses of the Merge Point
5.2.2. MRT Backup Attribute
The Join attribute is included with each source in the Backup Join
message
Kebler, et al. Expires August 19, 2013 [Page 13]
Internet-Draft PIM Protection using MRTs February 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Reserved | # labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | label1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | labeln |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRT Backup Join Attribute Format
F-bit: This bit will be clear as this is a non-transitive
attribute.
E-bit: As defined in [RFC5384]
Type: TBD
Length field: the length of the value field.
Value:
Reserved: Sent with 0, ignored on receipt
# labels: number of labels included in this message
PLR: Encoded-Unicast Address of PLR.
Protected Node: Encoded-Unicast Address of the node which is
being protected. For Link Protection, this is the address of
the MP
Interface ID: a 32-bit identifier of the interface that
connects the PLR to the Protected Node.
Labels: MPLS labels to be used when sending traffic on the
backup
Kebler, et al. Expires August 19, 2013 [Page 14]
Internet-Draft PIM Protection using MRTs February 2013
5.2.3. Upstream Address Join Attribute
This Join attribute is used with MP-initiated node protection to
signal the PLR address from the Protected Node to the MP. If a
router advertises itself capable of capable of handling Join
Responses in the MRT Protection Hello Option, then it MUST be capable
of receiving this Join Attribute
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upstream Address Join Attribute Format
F-bit: This bit will be clear as this is a non-transitive
attribute.
E-bit: End of Attributes. If this bit is set, then this is the
last Join Attribute appearing in this Encoded-Source Address
field.
Type: TBD
Length field: the length of the value
Value:
Reserved: set to all 0's when sent. Ignored on receipt
Upstream Address: Encoded-Unicast Address of Upstream Address
of the Router sending this Join Attribute.
Upstream Link Id: The Interface Id of the PLR
Kebler, et al. Expires August 19, 2013 [Page 15]
Internet-Draft PIM Protection using MRTs February 2013
5.3. Encoded-Source Address Changes
To indicate for a particular flow advertised in the JoinPrune message
should have node or link protection, a bit in the Encoded-Source
Address will be used. These bits are taken from the available
Reserved field of the Encoded-Source Address. These bits should only
be set to an upstream router that advertises the link or node
capability in the MRT Protection Hello Option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type |Rsvd |L|N|S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Encoded-Source Address
Addr Family: As specified in [RFC4601]
Encoding Type: As specified in [RFC4601]
Rsvd: Transmitted as zero, ignored on receipt.
L Link protection requested for this source
N Node protection requested for this source
S As specified in [RFC4601]
W As specified in [RFC4601]
R As specified in [RFC4601]
Mask Len: As specified in [RFC4601]
Source Address: As specified in [RFC4601]
Kebler, et al. Expires August 19, 2013 [Page 16]
Internet-Draft PIM Protection using MRTs February 2013
5.4. New PIM Message Types
5.4.1. Join Response
The Join Response message is identical to the JoinPrune message
except the type field is TBD. The Join Response may contain
additional Join Attributes. A router must not send a Join Response
to an neighbor unless it has advertised this capability in the MRT
Local Protection Hello Option.
5.4.2. PIM Backup JoinPrunes
The Backup JoinPrune Response message is identical to the JoinPrune
message except a new PIM type will be allocated. A router must not
send a Backup JoinPrune to an upstream neighbor unless it has
advertised this capability in the MRT Local Protection Hello Option.
6. IANA Considerations
A new PIM Hello Option type is requested to assign to the MRT
Protection Hello Option and the MP ID Hello Option
A new PIM type is requested for the Join Response and Backup Join/
Prune messages.
A new PIM Join Attribute Types is requested for the Merge Point Join
Attribute, Upstream Address Join Attribute, and MRT Backup Join
Attribute
7. Security Considerations
There are no security considerations for this design other than what
is already in the main PIM specification [RFC4601] .
8. References
8.1. Normative References
[I-D.karan-mofrr]
Karan, A., Filsfils, C., Farinacci, D., Decraene, B.,
Leymann, N., and W. Henderickx, "Multicast only Fast Re-
Route", draft-karan-mofrr-02 (work in progress),
March 2012.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
Kebler, et al. Expires August 19, 2013 [Page 17]
Internet-Draft PIM Protection using MRTs February 2013
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, November 2008.
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
Hello Option for PIM", RFC 6395, October 2011.
[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", RFC 6420, November 2011.
8.2. Informative References
[I-D.atlas-rtwg-mrt-mc-arch-00]
Atlas, A., Kebler, R., Wijnands, IJ., and G. Enyedi, "An
Architecture for Multicast Protection Using Maximally
Redundant Trees", atlas-rtwg-mrt-mc-arch-00 (work in
progress), March 2012.
[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Envedi, G., Csaszar, A.,
Konstantynowicz, M., White, R., and M. Shand, "An
Architecture for IP/LDP Fast-Reroute Using Maximally
Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01
(work in progress), March 2012.
Authors' Addresses
Robert Kebler (editor)
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rkebler@juniper.net
Alia Atlas
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: akatlas@juniper.net
Kebler, et al. Expires August 19, 2013 [Page 18]
Internet-Draft PIM Protection using MRTs February 2013
Naiming Shen
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: naiming@cisco.com
Yiqun Cai
Microsoft
La Avenida
Mountain View, CA 94043
USA
Email: yiqunc@microsoft.com
Kebler, et al. Expires August 19, 2013 [Page 19]