draft-ietf-pim-rpf-vector-04.txt   draft-ietf-pim-rpf-vector-05.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: January 10, 2008 Cisco Systems, Inc. Expires: May 21, 2008 Cisco Systems, Inc.
July 9, 2007 November 18, 2007
The RPF Vector TLV The RPF Vector TLV
draft-ietf-pim-rpf-vector-04 draft-ietf-pim-rpf-vector-05
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 January 10, 2008. This Internet-Draft will expire on May 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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,
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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. Attribute and shared tree joins . . . . . . . . . . . . . 4 2.1. Attribute and shared tree joins . . . . . . . . . . . . . 4
2.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5 2.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5
2.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5 2.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5
2.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5 2.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5
2.3.2. Processing a Received Vector Attribute . . . . . . . . 5 2.3.2. Processing a Received Vector Attribute . . . . . . . . 5
2.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 5 2.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 5
2.3.4. Vector Attribute and Join suppression . . . . . . . . 6
3. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . 7 3. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10 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
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-SM[RFC4601], PIM-SSM[I-D.ietf-ssm-arch] problematic. When using PIM-SM[RFC4601], PIM-SSM[RFC4607] or PIM-
or PIM-BIDIR[I-D.ietf-pim-bidir] to create a multicast distribution BIDIR[RFC5015] to create a multicast distribution tree for a
tree for a particular multicast group, one wants the core routers to particular multicast group, one wants the core routers to be full
be full participants in the PIM protocol, so that multicasting can be participants in the PIM protocol, so that multicasting can be done
done efficiently in the core. This means that the core routers must efficiently in the core. This means that the core routers must be
be able to correctly process PIM Join messages for the group, which able to correctly process PIM Join messages for the group, which in
in turn means that the core routes must be able to send the Join 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 7, line 5 skipping to change at page 6, line 25
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 the 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 2.3.4. Vector Attribute and Join suppression
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|S| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
F bit
-----
Forward Unknown TLV. If this bit is set the TLV is forwarded
regardless of whether 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
----
The Vector Attribute type is 0.
Length If a router receives a PIM join on the upstream LAN interface for a
------ particular multicast state, join suppression may be applied if that
Length depending on Address Family of Encoded-Unicast address. PIM join is targeted to the same upstream neighbor. Which router(s)
will suppress their PIM join is depending on timing and is
unpredictable. Downstream routers on a LAN may include different RPF
vectors in the PIM joins. Therefore an upstream router on that LAN
may receive and use different RPF vectors over time to reach the
destination (depending on which downstream router(s) suppressed their
Join). To make the upstream router behavior more predictable the RPF
vector address MUST be used as additional condition to the join
suppression logic. Only if the RPF vector in the PIM join matches
the RPF vector in the multicast state, the suppression logic is
applied. It is also possible to disable join suppression on that
LAN.
Value 3. Vector Attribute TLV Format
-----
Encoded-Unicast address, see PIM-SM
[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 | Value |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 of whether the router understands the Type. regardless of whether the router understands the Type. If the TLV is
known the F bit is ignored.
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.
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, see PIM-SM Encoded-Unicast address.
4. IANA Considerations 4. IANA Considerations
An attribute type needs to be assigned. For now we propose the value An attribute type needs to be assigned. For now we propose the value
0. 0.
5. Security Considerations 5. 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.
6. Acknowledgments 6. 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 and Su Haiyang for the comments on
the draft.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[I-D.ietf-pim-bidir] [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, IP", RFC 4607, August 2006.
"Bi-directional Protocol Independent Multicast (BIDIR-
PIM)", draft-ietf-pim-bidir-07 (work in progress), [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
March 2005. "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[I-D.ietf-pim-join-attributes] [I-D.ietf-pim-join-attributes]
Boers, A., "Format for using TLVs in PIM messages", Boers, A., "Format for using TLVs in PIM messages",
draft-ietf-pim-join-attributes-00 (work in progress), draft-ietf-pim-join-attributes-03 (work in progress),
October 2005. May 2007.
[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.
7.2. Informative References 7.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
 End of changes. 15 change blocks. 
58 lines changed or deleted 45 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/