The Reverse Path Forwarding (RPF) Vector TLV
RFC 5496

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

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

   able to correctly process PIM Join messages for the group, which in
   turn means that the core routers must be able to send the Join
   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