draft-ietf-pim-explicit-rpf-vector-01.txt   draft-ietf-pim-explicit-rpf-vector-02.txt 
Versions: 01 Versions: 02
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: December 22, 2013 A. Karan Expires: January 1, 2013 A. Karan
Cisco Systems Cisco Systems
V. Arya V. Arya
Directv, Inc. Directv, Inc.
June 21, 2013 July 12, 2013
Explicit RPF Vector Explicit RPF Vector
draft-ietf-pim-explicit-rpf-vector-01 draft-ietf-pim-explicit-rpf-vector-02
Abstract Abstract
This document describes a use of the Reverse Path Forwarding (RPF) This document defines a new Reverse Path Forwarding (RPF) Vector
Vector TLV as defined in [RPC 5496] to build multicast trees via an TLV to build multicast trees via an explicit path sent in the PIM
explicit path sent in the PIM join. join.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as working documents as Internet-Drafts. The list of current Internet-
Internet-Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 12, 2013.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire December 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 carefully, publication of this document. Please review these documents
as they describe your rights and restrictions with respect to this carefully, as they describe your rights and restrictions with respect
document. Code Components extracted from this document must include to this document. Code Components extracted from this document must
Simplified BSD License text as described in Section 4.e of the Trust include Simplified BSD License text as described in Section 4.e of
Legal Provisions and are provided without warranty as described in the Trust Legal Provisions and are provided without warranty as
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. Solution Requirements . . . . . . . . . . . . . . . . . . . . 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. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . . 4 6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . . 4
7. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . . 4
8. Join Suppression. . . . . . . . . . . . . . . . . . . . . . . . 5 8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 4
9. Vector Handling By Unsupported PIM Router . . . . . . . . . . . 5 9. Join Suppression. . . . . . . . . . . . . . . . . . . . . . . . 5
10. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . . 5 10. Vector Handling By Unsupported PIM Router . . . . . . . . . . 5
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 11. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5
12. Security Considerations . . . . . . . . . . . . . . . . . . . 6 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 13. Security Considerations . . . . . . . . . . . . . . . . . . . 6
14. Normative References . . . . . . . . . . . . . . . . . . . . 6 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
15. Normative References . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
For some applications, it might be useful to have a way to specify For some applications, it might be useful to have a way to specify
the explicit path along which the PIM join is propagated. the explicit path along which the PIM join is propagated.
This document defines a new TLV in the PIM Join Attribute message This document defines a new TLV in the PIM Join Attribute message
[RFC5384] for specifying the explicit path. [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. However, the same procedures can be used to override a
route to the Source when it exists. It is possible to include route to the source when it exists. It is possible to include
multiple RPF vectors in the stack where each router along the multiple RPF vectors in the list where each router along the
path will perform a unicast route lookup on the first vector in path will perform a unicast route lookup on the first vector in
the attribute list. Once the router owning the address of the RPF the attribute list. Once the router owning the address of the RPF
vector is reached, following the procedures in [RFC5496], the RPF vector is reached, following the procedures in [RFC5496], the RPF
vector will be removed from the attribute list. This will result vector will be removed from the attribute list. This will result
in a 'loosely' routed path based on the unicast reachability of in a 'loosely' routed path based on the unicast reachability of
the RPF vector(s). We call this 'loosely' because we still depend the 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 vector(s) 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 stack so that the explicit rpf vector join may be the RPF Vector list so that the Explicit RPF Vector join may be
sent out as soon as the neighbor comes up. Since the behavior of sent out as soon as the neighbor comes up. Since the behavior of
the explicit RPF vector differs from the loose RPF vector as the Explicit RPF Vector differs from the loose RPF vector as
defined [RFC5496], we're defining a new attribute called the defined [RFC5496], we're defining a new attribute called the
explicit RPF Vector. Explicit RPF Vector.
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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. in [RFC2119].
3. Solution Requirements 3. Solution Requirements
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-active spatially or PIM ASM. Live-Live implies using 2 active spatially diverse
diverse multicast trees to transport video flows from root to multicast trees to transport video flows from root to leaf
leaf multicast routers. The leaf multicast router receives 2 multicast routers. The leaf multicast router receives 2 copies
copies from the PIM multicast core and will replicate 1 copy from the PIM multicast core and will replicate 1 copy towards
towards the receivers [draft-mofrr-karan]. the receivers [draft-mofrr-karan].
One of the main requirements of PIM live-live resiliency model One of the requirements of the PIM Live-Live resiliency model
is to ensure path-diversity of the active-active PIM trees in is to ensure path-diversity of the 2 active PIM trees in the
the core such that they do not intersect to avoid a single core such that they do not intersect to avoid a single point
point of failure. IGP routed RPF paths of active-active PIM of failure. IGP routed RPF paths of 2 PIM trees could be routed
trees could be routed over the same transit router and create over the same transit router and create a single point of failure.
a single point of failure. It might be useful to have a way to It might be useful to have a way to specify the explicit path
specify the explicit path along which the PIM join is propagated. along which the PIM join is propagated.
How the explicit RPF vector stack 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. It may either be manually configured by
the network operator or procedures may be implemented on the the network operator or procedures may be implemented on the
egress router to dynamically calculate the vector stack based on egress router to dynamically calculate the vector list based on
a link state database protocol, like OSPF or ISIS. 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 stack. Which method is a new explicit path using a new RPF vector list. Which method is
applied depends very much on how the vector stack was determined applied depends very much on how the vector list was determined
initially. Double failures are not considered and 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 R4->R3->R6->R5->R2->R1, Figure 1 provides an example multicast join path
where the multicast JOIN is explicitly routed to the source hop-by-hop R4->R3->R6->R5->R2->R1, where the multicast join is explicitly
using the explicit RPF vector list. routed to the source hop-by-hop using the Explicit RPF Vector
list.
[S]---(R1)--(R2)---(R3)--(R4)---[R] [S]---(R1)--(R2)---(R3)--(R4)---[R]
<--- | | --- <--- | | ---
| | | | | | | |
| (R5)---(R6) | | (R5)---(R6) |
- (S,G) Join - - (S,G) Join -
Figure 1 Figure 1
5. Explicit RPF Vector Attribute 5. Explicit RPF Vector Attribute
This draft uses vector attribute 4 for specifying an explicit RPF This draft uses PIM join attribute type 4 for specifying an Explicit
vector. RPF Vector.
6. Conflicting RPF Vectors 6. Mixed Vector Processing
Explicit RPF Vector attribute does not impact or restrict the
functionality of other RPF vector attributes in a PIM join. It is
possible to mix vectors of different types, such that some part of
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
first RPF vector attribute is looked at and processed, it can be
either loose or explicit.
7. Conflicting RPF Vectors
It is possible that a PIM router has multiple downstream neighbors. It is possible that a PIM router has multiple downstream neighbors.
If for the same multicast route there is inconsistency between the If for the same multicast route there is an inconsistency between the
Explicit RPF Vector stacks provided by the downstream PIM neighbor, Explicit RPF Vector lists provided by the downstream PIM neighbor,
the procedures as documented in RFC5384 section 3.3.3 apply. the procedures as documented in section 3.3.3 [RFC5384] apply.
7. PIM Asserts 8. PIM Asserts
RFC5496 section 3.3.3 describes the procedure how to deal with PIM Section 3.3.3 of [RFC5496] specifies the procedures for how to deal
asserts when RPF vectors are used. The same procedure applies to the with PIM asserts when RPF vectors are used. The same procedures apply
Explicit RPF vector. There is minor behavioural difference, the routing to the Explicit RPF Vector. There is minor behavioral difference,
protocol's Metric that is included in the PIM Assert should be taken the routing protocol's Metric that is included in the PIM Assert
from the first Explicit vector in the stack. However, the first Explicit should be taken from the first Explicit vector in the list. However,
vector should always be directly connected, so the Metric will be zero. the first Explicit vector should always be directly connected, so
The Metric will therefore not be a tie breaker in the PIM Assert the Metric may likely be zero. The Metric will therefore not be a tie
selection procedure. breaker in the PIM Assert selection procedure.
8. Join Suppression 9. Join Suppression
RFC5496 section 3.3.4 describes the procedure how to apply join Section 3.3.4 of [RFC5496] specifies the procedures how to apply join
suppression when an RPF Vector attribute is included in the PIM join. suppression when an RPF Vector attribute is included in the PIM join.
The same procedure applies to the Explicit RPF Vector attribute. The The same procedure applies to the Explicit RPF Vector attribute. The
procedure MUST match against all the Explicit RPF Vectors in the PIM procedure MUST match against all the Explicit RPF Vectors in the PIM
join before a PIM join can be suppressed. join before a PIM join can be suppressed.
9. Unsupported Explicit Vector Handling 10. Unsupported Explicit Vector Handling
Routers that don't support the Explicit Vector MUST never forward the Routers that don't support the Explicit Vector attribute MUST NOT
vector to their upstream PIM neighbor. Such router will not be able forward the vector to their upstream PIM neighbor and if required
to remove the Explicit Vector from stack, causing a PIM control plane send a PIM join with these attributes removed. Such router will not
routing loop with the upstream PIM neighbor. For that reason the F bit be able to remove the Explicit Vector attribute from the list,
MUST be set to 0. See RFC 5384 section 3.3.2. causing a PIM control plane routing loop with the upstream PIM
neighbor. For that reason the F bit MUST be set to 0. See section
3.3.2 of [RFC5384].
10. 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
----- -----
The F bit MUST be set to 0. Otherwise there could be loops. The F bit MUST be set to 0. Otherwise there could be loops.
E bit E bit
----- -----
End of Attributes. If this bit is set then this is the last End of Attributes. If this bit is set then this is the last TLV
TLV in the stack. specified in the list.
Type Type
---- ----
The Vector Attribute type is 4. The Vector Attribute type is 4.
Length Length
------ ------
Length depending on Address Family of Encoded-Unicast address. Length depending on the Address Family of the Encoded-Unicast
address.
Value Value
----- -----
Encoded-Unicast address. This could be a valid primary or secondary Encoded-Unicast address. This could be a valid primary or secondary
address. address.
11. IANA Considerations 12. IANA Considerations
An 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 RPF Vector. The proposed needs to be assigned by IANA for the RPF Vector attribute. The
value is 4. proposed value is 4.
12. Security Considerations 13. Security Considerations
Security of the RPF Vector Attribute is only guaranteed by the This document describes Explicit RPF Vector Attribute only which by
security of the PIM packet, so the security considerations for PIM itself does not modify the security of PIM join packet or PIM-SM
join packets as described in PIM-SM [RFC4601] apply here. operation and shares the security considerations described in
[RFC4601].
13. Acknowledgments 14. Acknowledgments
The authors would like to thank Vatsa Kumar and Nagendra Kumar The authors would like to thank Vatsa Kumar and Nagendra Kumar for
for the comments on the draft. the comments on the document.
14. 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.
 End of changes. 42 change blocks. 
109 lines changed or deleted 119 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/