draft-ietf-pim-explicit-rpf-vector-03.txt   draft-ietf-pim-explicit-rpf-vector-04.txt 
Versions: 03 Versions: 04
PIM WG J. Asghar PIM WG J. Asghar
Internet-Draft IJ. Wijnands Internet-Draft IJ. Wijnands
Intended status: Informational S. Krishnaswamy Intended status: Informational S. Krishnaswamy
Expires: April 17, 2014 A. Karan Expires: September 29, 2014 A. Karan
Cisco Systems Cisco Systems
V. Arya V. Arya
Directv, Inc. Directv, Inc.
October 18, 2013 March 30, 2014
Explicit RPF Vector Explicit RPF Vector
draft-ietf-pim-explicit-rpf-vector-03 draft-ietf-pim-explicit-rpf-vector-04
Abstract Abstract
This document defines a new Reverse Path Forwarding (RPF) Vector The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
TLV to build multicast trees via an explicit path sent in the PIM can be included in a PIM Join Attribute such that the RPF neighbor is
join. selected based on the unicast reachability of the RPF Vector instead
of the Source or RP associated with the multicast tree.
This document defines a new RPF Vector Attribute type such that an
explicit RPF neighbor list can be encoded in the PIM Join Attribute,
bypassing the unicast route lookup.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2014. This Internet-Draft will expire on September 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Use of the Explicit RPF Vector . . . . . . . . . . . . . . . . 4 4. Use of the Explicit RPF Vector . . . . . . . . . . . . . . . . 4
5. Explicit RPF Vector Attribute . . . . . . . . . . . . . . . . . 4 5. Explicit RPF Vector Attribute . . . . . . . . . . . . . . . . . 4
6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . . 4 6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . . 4
7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . . 4 7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . . 4
8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 4
9. Join Suppression. . . . . . . . . . . . . . . . . . . . . . . . 5 9. Join Suppression. . . . . . . . . . . . . . . . . . . . . . . . 5
10. Vector Handling By Unsupported PIM Router . . . . . . . . . . 5 10. Vector Handling By Unsupported PIM Router . . . . . . . . . . 5
11. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5 11. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
13. Security Considerations . . . . . . . . . . . . . . . . . . . 6 13. Security Considerations . . . . . . . . . . . . . . . . . . . 6
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
15. Normative References . . . . . . . . . . . . . . . . . . . . 6 15. Normative References . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
For some applications, it might be useful to have a way to specify
the explicit path along which the PIM join is propagated.
This document defines a new TLV in the PIM Join Attribute message
[RFC5384] for specifying the explicit path.
The procedures in [RFC5496] define how a RPF vector can be used The procedures in [RFC5496] define how a RPF vector can be used
to influence the path selection in the absence of a route to the to influence the path selection in the absence of a route to the
source. However, the same procedures can be used to override a source. The same procedures can be used to override a route to
route to the source when it exists. It is possible to include the source when it exists. It is possible to include multiple
multiple RPF vectors in the list where each router along the RPF vectors in the list where each router along the path will
path will perform a unicast route lookup on the first vector in perform a unicast route lookup on the first vector in the attribute
the attribute list. Once the router owning the address of the RPF list. Once the router owning the address of the RPF vector is
vector is reached, following the procedures in [RFC5496], the RPF reached, following the procedures in [RFC5496], the RPF vector
vector will be removed from the attribute list. This will result will be removed from the attribute list. This will result in a
in a 'loosely' routed path based on the unicast reachability of 'loosely' routed path based on the unicast reachability of the
the RPF vector(s). We call this 'loosely' because we still depend RPF vector(s). We call this 'loosely' because we still depend
on unicast routing reachability to the RPF Vector. on unicast routing reachability to the RPF Vector.
In some scenarios we don't want to rely on the unicast reachability In some scenarios we don't want to rely on the unicast reachability
to the RPF vector address and we want to build a path strictly to the RPF vector address and we want to build a path strictly
based on the RPF vectors. In that case the RPF vectors represent based on the RPF vectors. In that case the RPF vectors represent
a list of directly connected PIM neighbors along the path. For a list of directly connected PIM neighbors along the path. For
these vectors we MUST NOT do a unicast route lookup. We call these vectors we MUST NOT do a unicast route lookup. We call
these 'explicit' RPF vector addresses. If a router receiving an these 'Explicit' RPF Vector addresses. If a router receiving an
Explicit RPF Vector does not have a PIM neighbor matching the Explicit RPF Vector does not have a PIM neighbor matching the
Explicit RPF Vector address it MUST NOT fall back to loosely Explicit RPF Vector address it MUST NOT fall back to loosely
routing the join. Instead, it may process the packet and store routing the join. Instead, it may process the packet and store
the RPF Vector list so that the PIM join may be sent out as soon the RPF Vector list so that the PIM join may be sent out as soon
as the neighbor comes up. Since the behavior of the Explicit RPF as the neighbor comes up. Since the behavior of the Explicit RPF
Vector differs from the loose RPF vector as defined [RFC5496], Vector differs from the loose RPF vector as defined [RFC5496],
we're defining a new attribute called the Explicit RPF Vector. we're defining a new attribute called the Explicit RPF Vector.
This document defines a new TLV in the PIM Join Attribute message
[RFC5384] for specifying the explicit path.
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL" The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described document are to be interpreted as described in [RFC2119].
in [RFC2119].
3. Solution Requirements 3. Motivation
Some broadcast video transport networks use a multicast PIM Some broadcast video transport networks use a multicast PIM
Live-Live resiliency model for video delivery based on PIM SSM Live-Live resiliency model for video delivery based on PIM SSM
or PIM ASM. Live-Live implies using 2 active spatially diverse or PIM ASM. Live-Live implies using 2 active spatially diverse
multicast trees to transport video flows from root to leaf multicast trees to transport video flows from root to leaf
multicast routers. The leaf multicast router receives 2 copies multicast routers. The leaf multicast router receives 2 copies
from the PIM multicast core and will replicate 1 copy towards from the PIM multicast core and will replicate 1 copy towards
the receivers [draft-mofrr-karan]. the receivers [draft-ietf-rtgwg-mofrr-03].
One of the requirements of the PIM Live-Live resiliency model One of the requirements of the PIM Live-Live resiliency model
is to ensure path-diversity of the 2 active PIM trees in the is to ensure path-diversity of the 2 active PIM trees in the
core such that they do not intersect to avoid a single point core such that they do not intersect to avoid a single point
of failure. IGP routed RPF paths of 2 PIM trees could be routed of failure. IGP routed RPF paths of 2 PIM trees could be routed
over the same transit router and create a single point of failure. over the same transit router and create a single point of failure.
It might be useful to have a way to specify the explicit path It is useful to have a way to specify the explicit path along
along which the PIM join is propagated. which the PIM join is propagated.
How the Explicit RPF Vector list is determined is outside the How the Explicit RPF Vector list is determined is outside the
scope of this document. It may either be manually configured by scope of this document. For example, it may either be manually
the network operator or procedures may be implemented on the configured by the network operator or procedures may be implemented
egress router to dynamically calculate the vector list based on on the egress router to dynamically calculate the vector list based
a link state database protocol, like OSPF or IS-IS. on a link state database protocol, like OSPF or IS-IS.
Due to the fact that the leaf router receives two copies of the Due to the fact that the leaf router receives two copies of the
multicast stream via two diverse paths, there is no need for PIM multicast stream via two diverse paths, there is no need for PIM
to repair the broken path immediately. It is up to the egress to repair the broken path immediately. It is up to the egress
router to either wait for the broken path to be repaired or build router to either wait for the broken path to be repaired or build
a new explicit path using a new RPF vector list. Which method is a new explicit path using a new RPF vector list. Which method is
applied depends very much on how the vector list was determined applied depends very much on how the vector list was determined
initially. Double failures are not considered and are outside the initially. Double failures are not considered and are outside the
scope of this document. scope of this document.
4. Use of the PIM Explicit RPF Vector 4. Use of the PIM Explicit RPF Vector
Figure 1 provides an example multicast join path Figure 1 provides an example multicast join path
R4->R3->R6->R5->R2->R1, where the multicast join is explicitly R4->R3->R6->R5->R2->R1, where the multicast join is explicitly
routed to the source hop-by-hop using the Explicit RPF Vector routed to the source hop-by-hop using the Explicit RPF Vector
list. list. When R5-R6 link fails the join will NOT take an alternate
path.
[S]---(R1)--(R2)---(R3)--(R4)---[R] [S]---(R1)--(R2)---(R3)--(R4)---[R]
<--- | | --- <---- | | ---
| | | | | | | |
| (R5)---(R6) | |-(S,G) Join-|
- (S,G) Join - (R5)---(R6)
| |
| |
(R7)---(R8)
Figure 1 Figure 1
In comparison, when [RFC5496] procedures are used, if R5-R6
link fails then the join may be re-routed using R6-R8-R7 path
to reach R5.
5. Explicit RPF Vector Attribute 5. Explicit RPF Vector Attribute
This draft uses PIM join attribute type 4 for specifying an Explicit This draft uses PIM join attribute type TBD by IANA for specifying
RPF Vector. an Explicit RPF Vector.
6. Mixed Vector Processing 6. Mixed Vector Processing
Explicit RPF Vector attribute does not impact or restrict the Explicit RPF Vector attribute does not impact or restrict the
functionality of other RPF vector attributes in a PIM join. It is functionality of other RPF vector attributes in a PIM join. It is
possible to mix vectors of different types, such that some part of possible to mix vectors of different types, such that some part of
the tree is explicit and other parts are loosely routed. RPF vectors the tree is explicit and other parts are loosely routed. RPF vectors
are processed in the order in which they are specified. That is, the are processed in the order in which they are specified. That is, the
first RPF vector attribute is looked at and processed, it can be first RPF vector attribute is looked at and processed, it can be
either loose or explicit. either loose or explicit.
skipping to change at line 198 skipping to change at line 207
with PIM asserts when RPF vectors are used. The same procedures apply with PIM asserts when RPF vectors are used. The same procedures apply
to the Explicit RPF Vector. There is minor behavioral difference, to the Explicit RPF Vector. There is minor behavioral difference,
the route metric that is included in the PIM Assert should be the the route metric that is included in the PIM Assert should be the
route metric of the first Explicit RPF vector address in the list. route metric of the first Explicit RPF vector address in the list.
However, the first Explicit vector should always be directly connected, However, the first Explicit vector should always be directly connected,
so the Metric may likely be zero. The Metric will therefore not be a so the Metric may likely be zero. The Metric will therefore not be a
tie breaker in the PIM Assert selection procedure. tie breaker in the PIM Assert selection procedure.
9. Join Suppression 9. Join Suppression
Section 3.3.4 of [RFC5496] specifies the procedures how to apply join Section 3.3.4 of [RFC5496] specifies the procedures how to apply
suppression when an RPF Vector attribute is included in the PIM join. join suppression when an RPF Vector attribute is included in the
The same procedure applies to the Explicit RPF Vector attribute. The PIM join. The same procedure applies to the Explicit RPF Vector
procedure MUST match against all the Explicit RPF Vectors in the PIM attribute. The procedure MUST match against all the Explicit RPF
join before a PIM join can be suppressed. Vectors in the PIM join before a PIM join can be suppressed.
10. Unsupported Explicit Vector Handling 10. Unsupported Explicit Vector Handling
The F bit MUST be set to 0 by a downstream router in the join that The F bit MUST be set to 0 in all Explicit RPF vectors in case the
is sent to the upstream router that does not support Explicit RPF upstream router receiving the join does not support the TLV. As
vector. See section 3.3.2 of [RFC5384]. Routers that don't support described in section 3.3.2 of [RFC5384], routers that do not
the Explicit RPF Vector attribute MUST NOT forward the vector to understand the type of a particular attribute that has the F bit
their upstream PIM neighbor and if required send a PIM join with clear will discard it and continue to process the join.
these attributes removed. This router will not be able to process
the Explicit Vector attribute from the list and cause a PIM control This processing is particularly important when the routers that
plane routing loop with the upstream PIM neighbor. do not support the Explicit RPF TLV are identified as hops in the
explicit RPF list, because failing to remove the RPF vectors could
cause upstream routers to send the join back toward these routers
causing loops.
11. Explicit RPF Vector Attribute TLV Format 11. Explicit RPF Vector Attribute TLV Format
0 1 2 3 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 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 | Value |F|E| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
F bit F bit
skipping to change at line 254 skipping to change at line 266
address. address.
12. IANA Considerations 12. IANA Considerations
A new attribute type from the "PIM Join Attribute Types" registry A new attribute type from the "PIM Join Attribute Types" registry
needs to be assigned by IANA for the Explicit RPF Vector attribute. needs to be assigned by IANA for the Explicit RPF Vector attribute.
The proposed value is 4. The proposed value is 4.
13. Security Considerations 13. Security Considerations
This document describes Explicit RPF Vector Attribute only which by Security of the Explicit RPF Vector Attribute is only guaranteed by
itself does not modify the security of PIM join packet or PIM-SM the security of the PIM packet, so the security considerations for
operation and shares the security considerations described in PIM Join packets as described in PIM-SM {RFC4601] apply here.
[RFC4601]. Additionally, the Explicit RPF Vector list should be subject to a
policy to validate the list consists of a valid path before its used
by a receiver to build a multicast tree.
14. Acknowledgments 14. Acknowledgments
The authors would like to thank Vatsa Kumar and Nagendra Kumar for The authors would like to thank Vatsa Kumar, Nagendra Kumar and
the comments on the document. Bharat Joshi for the comments on the document.
15. Normative References 15. Normative References
[RFC5496] Wijnands, IJ., Boers, A., Rosen, E., "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., Rosen, E., "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5384] Boers, A., Wijnands, IJ., Rosen, E., "The Protocol [RFC5384] Boers, A., Wijnands, IJ., Rosen, E., "The Protocol
Independent Multicast (PIM) Join Attribute Format", Independent Multicast (PIM) Join Attribute Format",
RFC 5384, Nov 2008. RFC 5384, Nov 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August Protocol Specification (Revised)", RFC 4601, August
2006. 2006.
[draft-mofrr-karan] Karan, A., Filsfils, C., Farinacci, D.,
Wijnands, IJ., Decraene B., Joorde, U.,
Henderickx, W., "Multicast only Fast Re-Route",
draft-ietf-rtgwg-mofrr-03, January 17, 2014
Authors' Addresses Authors' Addresses
Javed Asghar Javed Asghar
Cisco Systems, Inc. Cisco Systems, Inc.
725, Alder Drive 725, Alder Drive
Milpitas, CA 95035 Milpitas, CA 95035
Email: jasghar@cisco.com Email: jasghar@cisco.com
IJsbrand Wijnands IJsbrand Wijnands
 End of changes. 27 change blocks. 
65 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/