draft-ietf-pim-rpf-vector-00.txt   draft-ietf-pim-rpf-vector-01.txt 
PIM WG IJ. Wijnands PIM WG IJ. Wijnands
Internet-Draft A. Boers Internet-Draft A. Boers
Expires: August 5, 2005 E. Rosen Expires: April 4, 2006 E. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
february 2005 october 2005
The RPF Vector Proxy The RPF Vector TLV
draft-ietf-pim-rpf-vector-00 draft-ietf-pim-rpf-vector-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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-
Internet-Drafts. Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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 on August 5, 2005. This Internet-Draft will expire on April 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a use of the PIM Proxy as defined in This document describes a use of the PIM Join Attribute as defined in
draft-pim-proxy [Forthcoming] which enables PIM to build multicast draft-ietf-pim-join-attributes[I-D.ietf-pim-join-attributes] which
trees through an MPLS-enabled network, even if that network's IGP enables PIM to build multicast trees through an MPLS-enabled network,
does not have a route to the source of the tree. even if that network's IGP does not have a route to the source of the
tree.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of the RPF Vector TLV . . . . . . . . . . . . . . . . . . 4 2. Use of the RPF Vector TLV . . . . . . . . . . . . . . . . . . 4
2.1 Proxy and shared tree joins . . . . . . . . . . . . . . . 4 2.1. Attribute and shared tree joins . . . . . . . . . . . . . 4
2.2 The Vector Proxy . . . . . . . . . . . . . . . . . . . . . 4 2.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5
2.2.1 Inserting a Vector Proxy in a Join . . . . . . . . . . 5 2.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5
2.2.2 Processing a Received Vector Proxy . . . . . . . . . . 5 2.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5
2.2.3 Vector Proxy and Asserts . . . . . . . . . . . . . . . 5 2.3.2. Processing a Received Vector Attribute . . . . . . . . 5
3. Vector Proxy TLV Format . . . . . . . . . . . . . . . . . . . 6 2.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 5
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 3. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Informative References . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
It is sometimes convenient to distinguish the routers of a particular It is sometimes convenient to distinguish the routers of a particular
network into two categories: "edge routers" and "core routers". The network into two categories: "edge routers" and "core routers". The
edge routers attach directly to users or to other networks, but the edge routers attach directly to users or to other networks, but the
core routers attach only to other routers of the same network. If core routers attach only to other routers of the same network. If
the network is MPLS-enabled, then any unicast packet which needs to the network is MPLS-enabled, then any unicast packet which needs to
travel outside the network can be "tunneled" via MPLS from one edge travel outside the network can be "tunneled" via MPLS from one edge
router to another. To handle a unicast packet which must travel router to another. To handle a unicast packet which must travel
skipping to change at page 3, line 28 skipping to change at page 3, line 28
as they handle only tunneled packets, they only need to know how to as they handle only tunneled packets, they only need to know how to
reach the edge routers and the other core routers. reach the edge routers and the other core routers.
Consider, for example, the case where the network is an Autonomous Consider, for example, the case where the network is an Autonomous
System (AS), the edge routers are EBGP speakers, the core routers may System (AS), the edge routers are EBGP speakers, the core routers may
be said to constitute a "BGP-free core". The edge routers must be said to constitute a "BGP-free core". The edge routers must
distribute BGP routes to each other, but not to the core routers. distribute BGP routes to each other, but not to the core routers.
However, when multicast packets are considered, the strategy of However, when multicast packets are considered, the strategy of
keeping the core routers free of "external" routes is more keeping the core routers free of "external" routes is more
problematic. When using PIM [I-D.ietf-pim-sm-v2-new] to create a problematic. When using PIM-SM[I-D.ietf-pim-sm-v2-new], PIM-SSM[I-
D.ietf-ssm-arch] or PIM-BIDIR[I-D.ietf-pim-bidir] to create a
multicast distribution tree for a particular multicast group, one multicast distribution tree for a particular multicast group, one
wants the core routers to be full participants in the PIM protocol, wants the core routers to be full participants in the PIM protocol,
so that multicasting can be done efficiently in the core.This means so that multicasting can be done efficiently in the core.This means
that the core routers must be able to correctly process PIM Join that the core routers must be able to correctly process PIM Join
messages for the group, which in turn means that the core routes must messages for the group, which in turn means that the core routes must
be able to send the Join messages towards the root of the be able to send the Join messages towards the root of the
distribution tree. If the root of the tree lies outside the distribution tree. If the root of the tree lies outside the
network's borders (e.g., is in a different AS), and the core routers network's borders (e.g., is in a different AS), and the core routers
do not maintain routes to external destinations, then the PIM Join do not maintain routes to external destinations, then the PIM Join
messages cannot be processed, and the multicast distribution tree messages cannot be processed, and the multicast distribution tree
cannot be created. cannot be created.
In order to allow PIM to work properly in an environment where the In order to allow PIM to work properly in an environment where the
core routers do not maintain external routes, a PIM extension is core routers do not maintain external routes, a PIM extension is
needed. When an edge router sends a PIM Join message into the core, needed. When an edge router sends a PIM Join message into the core,
it must include in that message a "Vector" which specifies the IP it must include in that message a "Vector" which specifies the IP
address of the next edge router along the path to the root of the address of the next edge router along the path to the root of the
multicast distribution tree. The core routers can then process the multicast distribution tree. The core routers can then process the
Join message by sending it towards the specified edge router (i.e., Join message by sending it towards the specified edge router (i.e.,
toward the Vector). In effect, the Vector serves as a proxy, within toward the Vector). In effect, the Vector serves as an attribute,
a particular network, for the root of the tree. within a particular network, for the root of the tree.
This document defines a new TLV in the PIM Proxy This document defines a new TLV in the PIM Join Attribute message[I-
message[draft-pim-proxy]. It consists of a single Vector which D.ietf-pim-join-attributes]. It consists of a single Vector which
identifies the exit point of the network. identifies the exit point of the network.
2. Use of the RPF Vector TLV 2. Use of the RPF Vector TLV
Before we can start forwarding multicast packets we need to build a Before we can start forwarding multicast packets we need to build a
forwarding tree by sending PIM Joins hop by hop. Each router in the forwarding tree by sending PIM Joins hop by hop. Each router in the
path creates a forwarding state and propagates the Join towards the path creates a forwarding state and propagates the Join towards the
root of the forwarding tree. The building of this tree is receiver root of the forwarding tree. The building of this tree is receiver
driven. See Figure 1. driven. See Figure 1.
skipping to change at page 4, line 27 skipping to change at page 4, line 28
<--- (S,G) Join <--- (S,G) Join
Figure 1 Figure 1
In this example, the 2 edge routers are BGP speakers. The core In this example, the 2 edge routers are BGP speakers. The core
routers are not BGP speakers and do not have any BGP distributed routers are not BGP speakers and do not have any BGP distributed
routes. The route to S is a BGP distributed route, hence is known to routes. The route to S is a BGP distributed route, hence is known to
the edge but not to the core. The Edge 2 router determines the the edge but not to the core. The Edge 2 router determines the
interface leading to S, and sends a PIM Join to the upstream router. interface leading to S, and sends a PIM Join to the upstream router.
In this example, though, the upstream router is a core router, with In this example, though, the upstream router is a core router, with
no route to S. Without the PIM extensions specified in this no route to S. Without the PIM extensions specified in this document,
document, the core router cannot determine where the send the Join, the core router cannot determine where the send the Join, so the tree
so the tree cannot be constructed. cannot be constructed.
To allow the core router to participate in the construction of the To allow the core router to participate in the construction of the
tree, the Edge 2 router will include a Proxy field in the PIM Join. tree, the Edge 2 router will include an attribute field in the PIM
In this example, the Proxy field will contain the IP address of Edge Join. In this example, the Attribute field will contain the IP
1. Edge 2 then forwards the PIM Join towards Edge 1. The address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1.
intermediate core router do their RPF check on the Proxy (IP address The intermediate core router do their RPF check on the Attribute (IP
of Edge 1) rather than the Source, this allows the tree to be address of Edge 1) rather than the Source, this allows the tree to be
constructed. constructed.
2.1 Proxy and shared tree joins 2.1. Attribute and shared tree joins
In the example above we build a source tree to illustrate the proxy In the example above we build a source tree to illustrate the
behavior. The proxy is however not restricted to source tree only. attribute behavior. The attribute is however not restricted to
The tree may also be constructed towards a Rendezvous Point (RP) IP source tree only. The tree may also be constructed towards a
address. The RP IP address is used in a similar way as the Source in Rendezvous Point (RP) IP address. The RP IP address is used in a
the example above. PIM Proxy procedures defined for sources are similar way as the Source in the example above. PIM Attribute
equally applicable to RPs unless otherwise noted. procedures defined for sources are equally applicable to (*,G) and
(*,*,RP) joins unless otherwise noted.
2.2 The Vector Proxy 2.2. Attribute and Bootstrap messages
2.2.1 Inserting a Vector Proxy in a Join The RPF vector does not apply to BSR bootstrap messages. To allow
BSR messages to be forwarded across a core where the RP IP address is
not routable in the core a solution has the developed in BSR.
2.3. The Vector Attribute
2.3.1. Inserting a Vector Attribute in a Join
In the example of Figure 1, when the Edge 2 router looks up the route In the example of Figure 1, when the Edge 2 router looks up the route
to the source of the multicast distribution tree, it will find a to the source of the multicast distribution tree, it will find a BGP-
BGP-distributed route whose "BGP next-hop" is Edge 1. Edge 2 then distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks
looks up the route to Edge 1 to find interface and PIM adjacency up the route to Edge 1 to find interface and PIM adjacency which is
which is the next hop to the source, namely Core 2. the next hop to the source, namely Core 2.
When Edge 2 sends a PIM Join to Core 2, it includes a Vector Proxy When Edge 2 sends a PIM Join to Core 2, it includes a Vector
specifying the address of Edge 1. Core 2, and subsequent core Attribute specifying the address of Edge 1. Core 2, and subsequent
routers, will forwarding the Join along the Vector (i.e, towards Edge core routers, will forwarding the Join along the Vector (i.e, towards
1) instead of trying to forward it towards S. Edge 1) instead of trying to forward it towards S.
Whether a Proxy is actually needed depends on whether the Core Whether an ttribute is actually needed depends on whether the Core
routers have a route to the source of the multicast tree. How the routers have a route to the source of the multicast tree. How the
Edge router knows whether or not this is the case (and thus how the Edge router knows whether or not this is the case (and thus how the
Edge router determines whether or not to insert a Proxy field) is Edge router determines whether or not to insert an attribute field)
outside the scope of this document. is outside the scope of this document.
2.2.2 Processing a Received Vector Proxy 2.3.2. Processing a Received Vector Attribute
When processing a received PIM Join which contains a Vector Proxy, a When processing a received PIM Join which contains a Vector
router must first check to see if the Vector IP address is one of its Attribute, a router must first check to see if the Vector IP address
own IP addresses. If so, the Vector Proxy is discarded, and not is one of its own IP addresses. If so, the Vector Attribute is
passed further upstream. Otherwise, the Vector Proxy is used to find discarded, and not passed further upstream. Otherwise, the Vector
the route to the source, and is passed along when a PIM Join is sent Attribute is used to find the route to the source, and is passed
upstream. Note that a router which receives a Vector Proxy must use along when a PIM Join is sent upstream. Note that a router which
it, even if that router happens to have a route to the source. A receives a Vector Attribute must use it, even if that router happens
router which discards a Vector Proxy may of course insert a new to have a route to the source. A router which discards a Vector
Vector Proxy. This would typically happen if a PIM Join needed to Attribute may of course insert a new Vector Attribute. This would
pass through a sequence of Edge routers, each pair of which is typically happen if a PIM Join needed to pass through a sequence of
separated by a core which does not have external routes. In the Edge routers, each pair of which is separated by a core which does
absence of periodic refreshment, Vectors expire along with the not have external routes. In the absence of periodic refreshment,
corresponding (S,G) state. Vectors expire along with the corresponding (S,G) state.
2.2.3 Vector Proxy and Asserts 2.3.3. Vector Attribute and Asserts
In a PIM Assert message we include the routing protocol's "metric" to In a PIM Assert message we include the routing protocol's "metric" to
the source of the tree. This information is used in the selection of the source of the tree. This information is used in the selection of
the assert winner. If a PIM Join is being sent towards a Vector, the assert winner. If a PIM Join is being sent towards a Vector,
rather than towards the source, the Assert message must have the rather than towards the source, the Assert message must have the
metric to the Vector instead of the metric to the source. The Assert metric to the Vector instead of the metric to the source. The Assert
message however does not have a Proxy field and does not mention the message however does not have an attribute field and does not mention
Vector. the Vector.
A router may change its upstream neighbor on a particular multicast A router may change its upstream neighbor on a particular multicast
tree as the result of receiving Assert messages. However a Vector tree as the result of receiving Assert messages. However a Vector
Proxy should not be sent in a PIM Join to an upstream neighbor which Attribute should not be sent in a PIM Join to an upstream neighbor
is chosen as the result of processing the Assert messages. which is chosen as the result of processing the Assert messages.
Reachability of the Vector is only guaranteed by the router that Reachability of the Vector is only guaranteed by the router that
advertises reachability to the Vector in it's IGP. If the assert advertises reachability to the Vector in it's IGP. If the assert
winner upstream is not our real preferred next-hop, we can't be sure winner upstream is not our real preferred next-hop, we can't be sure
this router knows the path to the Vector. this router knows the path to the Vector. In the worst case the
assert winner has a route to the Vector that is on the same interface
where the assert was won. That will point the RPF interface to that
interface and will result in a O-list being NULL. The Vector
attribute is not inserted if the RPF neighbor was chosen via an
assert process and the RPF neighbor is different from the RPF
neighbor that would have been selected via the local routing table.
In all other cases the Vector has to be included in the Join message.
3. Vector Proxy TLV Format 3. 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| Type | Length | IP address |F|S| Type | Length | IP address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
F bit F bit
----- -----
Forward Unknown TLV. If this bit is set the TLV is forwarded Forward Unknown TLV. If this bit is set the TLV is forwarded
regardless if the router understands the Type. regardless if the router understands the Type.
S bit
-----
Bottom of Stack. If this bit is set then this is the last
TLV in the stack.
Type Type
---- ----
The Vector Proxy type is 0. The Vector Attribute type is 0.
Length Length
------ ------
Length in bytes is 4. Length in bytes is 4.
Value Value
----- -----
IPv4 address. IPv4 address.
4. Acknowledgments 4. Acknowledgments
The authors would like to thank Yakov Rekhter and Dino Farinacci for The authors would like to thank Yakov Rekhter and Dino Farinacci for
their initial ideas on this topic. their initial ideas on this topic.
5. References 5. References
5.1 Normative References 5.1. Normative References
[I-D.ietf-pim-sm-v2-new] [I-D.ietf-pim-sm-v2-new]
Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, 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)", Protocol Specification (Revised)",
Internet-Draft draft-ietf-pim-sm-v2-new-11, October 2004. draft-ietf-pim-sm-v2-new-11 (work in progress),
October 2004.
5.2 Informative References [I-D.ietf-pim-bidir]
Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bi-directional Protocol Independent Multicast (BIDIR-
PIM)", draft-ietf-pim-bidir-07 (work in progress),
March 2005.
[I-D.ietf-pim-join-attributes]
Boers, A., "Format for using TLVs in PIM messages",
draft-ietf-pim-join-attributes-00 (work in progress),
October 2005.
[I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-06 (work in progress),
September 2004.
5.2. Informative References
Authors' Addresses Authors' Addresses
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
 End of changes. 35 change blocks. 
89 lines changed or deleted 126 lines changed or added

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