draft-ietf-pim-explicit-rpf-vector-00.txt   draft-ietf-pim-explicit-rpf-vector-01.txt 
Versions: 00 Versions: 01
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: October 25, 2013 A. Karan Expires: December 22, 2013 A. Karan
Cisco Systems Cisco Systems
V. Arya V. Arya
Directv, Inc. Directv, Inc.
April 26, 2013 June 21, 2013
Explicit RPF Vector Explicit RPF Vector
draft-ietf-pim-explicit-rpf-vector-00 draft-ietf-pim-explicit-rpf-vector-01
Abstract Abstract
This document describes a use of the Reverse Path Forwarding (RPF) This document describes a use of the Reverse Path Forwarding (RPF)
Vector TLV as defined in [RPC 5496] to build multicast trees via an Vector TLV as defined in [RPC 5496] to build multicast trees via an
explicitly configured path sent in the PIM join. explicit path sent in the PIM 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 to IETF 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), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 44 skipping to change at line 44
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire April 15, 2013. 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) 2012 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 carefully,
as they describe your rights and restrictions with respect to this as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in Legal Provisions and are provided without warranty as described in
the Simplified BSD License. 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. Soluton 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. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . . 4
7. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . . 4 7. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .5 8. Join Suppression. . . . . . . . . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. Vector Handling By Unsupported PIM Router . . . . . . . . . . . 5
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 10. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . . 5
11. Normative References . . . . . . . . . . . . . . . . . . . . 6 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 12. Security Considerations . . . . . . . . . . . . . . . . . . . 6
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
14. Normative References . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
In 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 stack 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 In some scenarios we don't want to rely on the unicast reachability
reachability to the RPF vector address and we want to build a to the RPF vector address and we want to build a path strictly
path strictly based on the RPF vectors. In that case the RPF based on the RPF vectors. In that case the RPF vector(s) represent
vector(s) represent a list of directly connected PIM neighbors a list of directly connected PIM neighbors along the path. For
along the path. For these vectors we MUST NOT do a unicast route these vectors we MUST NOT do a unicast route lookup. We call
lookup. We call these 'explicit' RPF vector addresses. If a these 'explicit' RPF vector addresses. If a router receiving an
router receiving an explicit RPF vector does not have a PIM explicit RPF vector does not have a PIM neighbor matching the
neighbor matching the explicit RPF vector address it MUST NOT explicit RPF vector address it MUST NOT fall back to loosely
fall back to loosely routing the JOIN. Since the behavior of routing the JOIN. Instead, it may process the packet and store
the RPF Vector stack so that the explicit rpf vector join may be
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].
skipping to change at line 147 skipping to change at line 151
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 stack based on
a link state database protocol, like OSPF or ISIS. a link state database protocol, like OSPF or ISIS.
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 stack. Which method is
applied depends very much on how the vector stack was determined applied depends very much on how the vector stack was determined
initially. Double failures are not considered and outside the scope initially. Double failures are not considered and outside the
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 R4->R3->R6->R5->R2->R1,
where the multicast JOIN is explicitly routed to the source hop-by-hop where the multicast JOIN is explicitly routed to the source hop-by-hop
using the explicit RPF vector list. 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 vector attribute 4 for specifying an explicit RPF
vector. vector.
6. Conflicting RPF Vectors 6. 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 inconsistency between the
Explicit RPF Vector stacks provided by the downstream PIM neighbor, Explicit RPF Vector stacks provided by the downstream PIM neighbor,
the procedures as documented in RFC5384 section 3.3.3 apply. the procedures as documented in RFC5384 section 3.3.3 apply.
7. Explicit RPF Vector Attribute TLV Format 7. PIM Asserts
RFC5496 section 3.3.3 describes the procedure how to deal with PIM
asserts when RPF vectors are used. The same procedure applies to the
Explicit RPF vector. There is minor behavioural difference, the routing
protocol's Metric that is included in the PIM Assert should be taken
from the first Explicit vector in the stack. However, the first Explicit
vector should always be directly connected, so the Metric will be zero.
The Metric will therefore not be a tie breaker in the PIM Assert
selection procedure.
8. Join Suppression
RFC5496 section 3.3.4 describes the procedure how to apply join
suppression when an RPF Vector attribute is included in the PIM join.
The same procedure applies to the Explicit RPF Vector attribute. The
procedure MUST match against all the Explicit RPF Vectors in the PIM
join before a PIM join can be suppressed.
9. Unsupported Explicit Vector Handling
Routers that don't support the Explicit Vector MUST never forward the
vector to their upstream PIM neighbor. Such router will not be able
to remove the Explicit Vector from stack, causing a PIM control plane
routing loop with the upstream PIM neighbor. For that reason the F bit
MUST be set to 0. See RFC 5384 section 3.3.2.
10. 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|S| 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.
S bit E bit
----- -----
Bottom of Stack. If this bit is set then this is the last End of Attributes. If this bit is set then this is the last
TLV in the stack. TLV in the stack.
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 Address Family of Encoded-Unicast address.
Value Value
----- -----
Encoded-Unicast address. For IPv6, this should be a unique global Encoded-Unicast address. This could be a valid primary or secondary
address and NOT link-local. address.
8. IANA Considerations 11. IANA Considerations
An new attribute type from the "PIM Join Attribute Types" registry An 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. The proposed
value is 4. value is 4.
9. Security Considerations 12. Security Considerations
Security of the RPF Vector Attribute is only guaranteed by the Security of the RPF Vector Attribute is only guaranteed by the
security of the PIM packet, so the security considerations for PIM security of the PIM packet, so the security considerations for PIM
join packets as described in PIM-SM [RFC4601] apply here. join packets as described in PIM-SM [RFC4601] apply here.
10. Acknowledgments 13. Acknowledgments
The authors would like to thank Vatsa Kumar for the comments on The authors would like to thank Vatsa Kumar and Nagendra Kumar
the draft. for the comments on the draft.
11. Normative References 14. 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.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, November 2008.
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. 24 change blocks. 
51 lines changed or deleted 78 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/