The Reverse Path Forwarding (RPF) Vector TLV
RFC 5496
|
| Document |
Type |
|
RFC - Proposed Standard
(March 2009; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5496 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
David Ward
|
|
Send notices to |
|
(None)
|
Network Working Group IJ. Wijnands
Request for Comments: 5496 A. Boers
Category: Standards Track E. Rosen
Cisco Systems, Inc.
March 2009
The Reverse Path Forwarding (RPF) Vector TLV
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a use of the Protocol Independent Multicast
(PIM) Join Attribute as defined in RFC 5384, which 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 tree.
Wijnands, et al. Standards Track [Page 1]
RFC 5496 The RPF Vector TLV March 2009
Table of Contents
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Use of the RPF Vector TLV .......................................3
3.1. Attribute and Shared Tree Joins ............................4
3.2. Attribute and Bootstrap Messages ...........................4
3.3. The Vector Attribute .......................................4
3.3.1. Inserting a Vector Attribute in a Join ..............4
3.3.2. Processing a Received Vector Attribute ..............5
3.3.3. Vector Attribute and Asserts ........................5
3.3.4. Vector Attribute and Join Suppression ...............6
4. Vector Attribute TLV Format .....................................6
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................7
8. Normative References ............................................7
1. Introduction
It is sometimes convenient to distinguish the routers of a particular
network into two categories: "edge routers" and "core routers". 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
the network is MPLS-enabled, then any unicast packet that needs to
travel outside the network can be "tunneled" via MPLS from one edge
router to another. To handle a unicast packet that must travel
outside the network, an edge router needs to know which of the other
edge routers is the best exit point from the network for that
packet's destination IP address. The core routers, however, do not
need to have any knowledge of routes that lead outside the network;
as they handle only tunneled packets, they only need to know how to
reach the edge routers and the other core routers.
Consider, for example, the case where the network is an Autonomous
System (AS), the edge routers are External Border Gateway Protocol
(EBGP) speakers, the core routers may be said to constitute a "BGP-
free core". The edge routers distribute BGP routes to each other,
but not to the core routers.
However, when multicast packets are considered, the strategy of
keeping the core routers free of "external" routes is more
problematic. When using PIM Sparse-Mode (PIM-SM) [RFC4601], PIM
Source-Specific Mode (PIM-SSM) [RFC4607], or Bidirectional PIM
(BIDIR-PIM) [RFC5015] to create a multicast distribution tree for a
particular multicast group, one wants the core routers to 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
Wijnands, et al. Standards Track [Page 2]
RFC 5496 The RPF Vector TLV March 2009
Show full document text