draft-ietf-pim-rpf-vector-03.txt   draft-ietf-pim-rpf-vector-04.txt 
PIM WG IJ. Wijnands PIM WG IJ. Wijnands
Internet-Draft A. Boers Internet-Draft A. Boers
Intended status: Informational E. Rosen Intended status: Informational E. Rosen
Expires: April 4, 2007 Cisco Systems, Inc. Expires: January 10, 2008 Cisco Systems, Inc.
october 2006 July 9, 2007
The RPF Vector TLV The RPF Vector TLV
draft-ietf-pim-rpf-vector-03 draft-ietf-pim-rpf-vector-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 April 4, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a use of the PIM Join Attribute as defined in This document describes a use of the PIM Join Attribute as defined in
draft-ietf-pim-join-attributes[I-D.ietf-pim-join-attributes] which draft-ietf-pim-join-attributes[I-D.ietf-pim-join-attributes] which
enables PIM to build multicast trees through an MPLS-enabled network, enables PIM to build multicast trees through an MPLS-enabled network,
even if that network's IGP does not have a route to the source of the even if that network's IGP does not have a route to the source of the
tree. tree.
Table of Contents Table of Contents
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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-SM[RFC4601], PIM-SSM[I-D.ietf-ssm-arch] problematic. When using PIM-SM[RFC4601], PIM-SSM[I-D.ietf-ssm-arch]
or PIM-BIDIR[I-D.ietf-pim-bidir] to create a multicast distribution or PIM-BIDIR[I-D.ietf-pim-bidir] to create a multicast distribution
tree for a particular multicast group, one wants the core routers to tree for a particular multicast group, one wants the core routers to
be full participants in the PIM protocol, so that multicasting can be be full participants in the PIM protocol, so that multicasting can be
done efficiently in the core.This means that the core routers must be done efficiently in the core. This means that the core routers must
able to correctly process PIM Join messages for the group, which in be able to correctly process PIM Join messages for the group, which
turn means that the core routes must be able to send the Join in turn means that the core routes must be able to send the Join
messages towards the root of the distribution tree. If the root of messages towards the root of the distribution tree. If the root of
the tree lies outside the network's borders (e.g., is in a different the tree lies outside the network's borders (e.g., is in a different
AS), and the core routers do not maintain routes to external AS), and the core routers do not maintain routes to external
destinations, then the PIM Join messages cannot be processed, and the destinations, then the PIM Join messages cannot be processed, and the
multicast distribution tree cannot be created. multicast distribution tree 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
skipping to change at page 4, line 35 skipping to change at page 4, line 35
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 document, no route to S. Without the PIM extensions specified in this document,
the core router cannot determine where the send the Join, so the tree the core router cannot determine where the send the Join, 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 an attribute field in the PIM tree, the Edge 2 router will include an attribute field in the PIM
Join. In this example, the Attribute field will contain the IP Join. In this example, the Attribute field will contain the IP
address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1. address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1.
The intermediate core router do their RPF check on the Attribute (IP The intermediate core routers do their RPF check on the Attribute (IP
address 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. Attribute and shared tree joins 2.1. Attribute and shared tree joins
In the example above we build a source tree to illustrate the In the example above we build a source tree to illustrate the
attribute behavior. The attribute is however not restricted to attribute behavior. The attribute is however not restricted to
source tree only. The tree may also be constructed towards a source tree only. The tree may also be constructed towards a
Rendezvous Point (RP) IP address. The RP IP address is used in a Rendezvous Point (RP) IP address. The RP IP address is used in a
similar way as the Source in the example above. PIM Attribute similar way as the Source in the example above. PIM Attribute
procedures defined for sources are equally applicable to (*,G) and procedures defined for sources are equally applicable to (*,G) and
(*,*,RP) joins unless otherwise noted. (*,*,RP) joins unless otherwise noted.
2.2. Attribute and Bootstrap messages 2.2. Attribute and Bootstrap messages
The RPF vector does not apply to BSR bootstrap messages. To allow 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 BSR messages to be forwarded across a core where the BSR IP address
not routable in the core a solution has the developed in BSR. is not routable in the core a solution needs to be developed for BSR.
2.3. The Vector Attribute 2.3. The Vector Attribute
2.3.1. Inserting a Vector Attribute in a Join 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 BGP- to the source of the multicast distribution tree, it will find a BGP-
distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks
up the route to Edge 1 to find interface and PIM adjacency which is up the route to Edge 1 to find interface and PIM adjacency 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 When Edge 2 sends a PIM Join to Core 2, it includes a Vector
Attribute specifying the address of Edge 1. Core 2, and subsequent Attribute specifying the address of Edge 1. Core 2, and subsequent
core routers, will forwarding the Join along the Vector (i.e, towards core routers, will forwarding the Join along the Vector (i.e, towards
Edge 1) instead of trying to forward it towards S. Edge 1) instead of trying to forward it towards S.
Whether an ttribute is actually needed depends on whether the Core Whether an attribute 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 an attribute field) Edge router determines whether or not to insert an attribute field)
is outside the scope of this document. is outside the scope of this document.
2.3.2. Processing a Received Vector Attribute 2.3.2. Processing a Received Vector Attribute
When processing a received PIM Join which contains a Vector When processing a received PIM Join which contains a Vector
Attribute, a router must first check to see if the Vector IP address Attribute, a router must first check to see if the Vector IP address
is one of its own IP addresses. If so, the Vector Attribute is is one of its own IP addresses. If so, the Vector Attribute is
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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 an attribute field and does not mention message however does not have an attribute field and does not mention
the 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
Attribute should not be sent in a PIM Join to an upstream neighbor Attribute should not be sent in a PIM Join to an upstream neighbor
which 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 its 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. In the worst case the 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 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 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 interface and will result in the O-list being NULL. The Vector
attribute is not inserted if the RPF neighbor was chosen via an attribute is not inserted if the RPF neighbor was chosen via an
assert process and the RPF neighbor is different from the RPF assert process and the RPF neighbor is different from the RPF
neighbor that would have been selected via the local routing table. 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. In all other cases the Vector has to be included in the Join message.
3. Vector Attribute 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|S| Type | Length | Encoded-Unicast address |F|S| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
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 of whether the router understands the Type.
S bit S bit
----- -----
Bottom of Stack. If this bit is set then this is the last Bottom of Stack. 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 0. The Vector Attribute type is 0.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
Length depending on Address Family of Encoded-Unicast address. Length depending on Address Family of Encoded-Unicast address.
Value Value
----- -----
Encoded-Unicast address, see PIM-SM Encoded-Unicast address, see PIM-SM
[RFC4601] [RFC4601]
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 | Encoded-Unicast address |F|S| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
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 of whether the router understands the Type.
S bit S bit
----- -----
Bottom of Stack. If this bit is set then this is the last Bottom of Stack. 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 0. The Vector Attribute type is 0.
skipping to change at page 10, line 7 skipping to change at page 10, line 7
Eric Rosen Eric Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, Ma 01719 Boxborough, Ma 01719
Email: erosen@cisco.com Email: erosen@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 16 change blocks. 
23 lines changed or deleted 23 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/