idnits 2.17.1 draft-ietf-pim-rpf-vector-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5384]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 15, 2009) is 5574 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG IJ. Wijnands 3 Internet-Draft A. Boers 4 Intended status: Standards Track E. Rosen 5 Expires: July 19, 2009 Cisco Systems, Inc. 6 January 15, 2009 8 The RPF Vector TLV 9 draft-ietf-pim-rpf-vector-08 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 19, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document describes a use of the PIM Join Attribute as defined in 49 draft-ietf-pim-join-attributes [RFC5384] which enables PIM to build 50 multicast trees through an MPLS-enabled network, even if that 51 network's IGP does not have a route to the source of the tree. 53 Table of Contents 55 1. Specification of Requirements . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Use of the RPF Vector TLV . . . . . . . . . . . . . . . . . . . 4 58 3.1. Attribute and shared tree joins . . . . . . . . . . . . . . 4 59 3.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5 60 3.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5 61 3.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5 62 3.3.2. Processing a Received Vector Attribute . . . . . . . . 5 63 3.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 6 64 3.3.4. Vector Attribute and Join suppression . . . . . . . . . 6 65 4. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Specification of Requirements 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Introduction 80 It is sometimes convenient to distinguish the routers of a particular 81 network into two categories: "edge routers" and "core routers". The 82 edge routers attach directly to users or to other networks, but the 83 core routers attach only to other routers of the same network. If 84 the network is MPLS-enabled, then any unicast packet which needs to 85 travel outside the network can be "tunneled" via MPLS from one edge 86 router to another. To handle a unicast packet which must travel 87 outside the network, an edge router needs to know which of the other 88 edge routers is the best exit point from the network for that 89 packet's destination IP address. The core routers, however, do not 90 need to have any knowledge of routes which lead outside the network; 91 as they handle only tunneled packets, they only need to know how to 92 reach the edge routers and the other core routers. 94 Consider, for example, the case where the network is an Autonomous 95 System (AS), the edge routers are EBGP speakers, the core routers may 96 be said to constitute a "BGP-free core". The edge routers distribute 97 BGP routes to each other, but not to the core routers. 99 However, when multicast packets are considered, the strategy of 100 keeping the core routers free of "external" routes is more 101 problematic. When using PIM Sparse-Mode (PIM-SM) [RFC4601], PIM 102 Source-Specific Mode (PIM-SSM) [RFC4607] or Bidirectional PIM (BIDIR- 103 PIM) [RFC5015] to create a multicast distribution tree for a 104 particular multicast group, one wants the core routers to be full 105 participants in the PIM protocol, so that multicasting can be done 106 efficiently in the core. This means that the core routers must be 107 able to correctly process PIM Join messages for the group, which in 108 turn means that the core routers must be able to send the Join 109 messages towards the root of the distribution tree. If the root of 110 the tree lies outside the network's borders (e.g., is in a different 111 AS), and the core routers do not maintain routes to external 112 destinations, then the PIM Join messages cannot be processed, and the 113 multicast distribution tree cannot be created. 115 In order to allow PIM to work properly in an environment where the 116 core routers do not maintain external routes, a PIM extension is 117 needed. When an edge router sends a PIM Join message into the core, 118 it MUST include in that message a "Vector" which specifies the IP 119 address of the next edge router along the path to the root of the 120 multicast distribution tree. The core routers can then process the 121 Join message by sending it towards the specified edge router (i.e., 122 toward the Vector). In effect, the Vector serves as an attribute, 123 within a particular network, for the root of the tree. 125 This document defines a new TLV in the PIM Join Attribute message 126 [RFC5384]. It consists of a single Vector which identifies the exit 127 point of the network. 129 3. Use of the RPF Vector TLV 131 Before a router can start forwarding multicast packets, it is 132 necessary to build a forwarding tree by sending PIM Joins hop by hop. 133 Each router in the path creates a forwarding state and propagates the 134 Join towards the root of the forwarding tree. The building of this 135 tree is receiver driven. See Figure 1. 137 ------------------ BGP ----------------- 138 | | 139 [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] 140 <--- (S,G) Join 142 Figure 1 144 In this example, the 2 edge routers are BGP speakers. The core 145 routers are not BGP speakers and do not have any BGP distributed 146 routes. The route to S is a BGP distributed route, hence is known to 147 the edge but not to the core. The Edge 2 router determines the 148 interface leading to S, and sends a PIM Join to the upstream router. 149 In this example, though, the upstream router is a core router, with 150 no route to S. Without the PIM extensions specified in this document, 151 the core router cannot determine where the send the Join, so the tree 152 cannot be constructed. 154 To allow the core router to participate in the construction of the 155 tree, the Edge 2 router will include an attribute field in the PIM 156 Join. In this example, the Attribute field will contain the IP 157 address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1. 158 The intermediate core routers do their RPF (Reverse Path Forwarding) 159 check [RFC4601] on the Attribute (IP address of Edge 1) rather than 160 the Source, this allows the tree to be constructed. 162 3.1. Attribute and shared tree joins 164 In the example above we build a source tree to illustrate the 165 attribute behavior. The attribute is however not restricted to 166 source tree only. The tree may also be constructed towards a 167 Rendezvous Point (RP) IP address. The RP IP address is used in a 168 similar way as the Source in the example above. PIM Attribute 169 procedures defined for sources are equally applicable to (*,G) and 170 (*,*,RP) joins unless otherwise noted. 172 3.2. Attribute and Bootstrap messages 174 The RPF vector does not apply to BSR bootstrap messages. To allow 175 BSR messages to be forwarded across a core where the BSR IP address 176 is not routable in the core a solution needs to be developed for BSR. 178 3.3. The Vector Attribute 180 3.3.1. Inserting a Vector Attribute in a Join 182 In the example of Figure 1, when the Edge 2 router looks up the route 183 to the source of the multicast distribution tree, it will find a BGP- 184 distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks 185 up the route to Edge 1 to find interface and PIM adjacency which is 186 the next hop to the source, namely Core 2. 188 When Edge 2 sends a PIM Join to Core 2, it includes a Vector 189 Attribute specifying the address of Edge 1. Core 2, and subsequent 190 core routers, will forwarding the Join along the Vector (i.e, towards 191 Edge 1) instead of trying to forward it towards S. 193 Whether an attribute is actually needed depends on whether the Core 194 routers have a route to the source of the multicast tree. How the 195 Edge router knows whether or not this is the case (and thus how the 196 Edge router determines whether or not to insert an attribute field) 197 is outside the scope of this document. 199 3.3.2. Processing a Received Vector Attribute 201 When processing a received PIM Join which contains a Vector 202 Attribute, a router MUST first check to see if the Vector IP address 203 is one of its own IP addresses. If so, the Vector Attribute is 204 discarded, and not passed further upstream. Otherwise, the Vector 205 Attribute is used to find the route to the source, and is passed 206 along when a PIM Join is sent upstream. Note that a router which 207 receives a Vector Attribute MUST use it, even if that router happens 208 to have a route to the source. A router which discards a Vector 209 Attribute MAY of course insert a new Vector Attribute. This would 210 typically happen if a PIM Join needed to pass through a sequence of 211 Edge routers, each pair of which is separated by a core which does 212 not have external routes. In the absence of periodic refreshment, 213 Vectors expire along with the corresponding (S,G) state. 215 3.3.3. Vector Attribute and Asserts 217 A PIM Assert message includes the routing protocol's "metric" to the 218 source of the tree. This information is used in the selection of the 219 assert winner. If a PIM Join is being sent towards a Vector, rather 220 than towards the source, the Assert message MUST have the metric to 221 the Vector instead of the metric to the source. The Assert message 222 however does not have an attribute field and does not mention the 223 Vector. 225 A router may change its upstream neighbor on a particular multicast 226 tree as the result of receiving Assert messages. However a Vector 227 Attribute MUST NOT be sent in a PIM Join to an upstream neighbor 228 which is chosen as the result of an Assert processing, if that 229 neighbor is different than the original upstream neighbor. 230 Reachability of the Vector is only guaranteed by the router that 231 advertises reachability to the Vector in its IGP. If the assert 232 winner upstream is not the real preferred next-hop, it is possible 233 that the assert winner does not know the path to the Vector. In the 234 worst case the assert winner has a route to the Vector that is on the 235 same interface where the assert was won. That will point the RPF 236 interface to that interface and will result in the O-list being NULL. 237 The Vector attribute therefore MUST NOT be inserted if the RPF 238 neighbor was chosen via an assert process and the RPF neighbor is 239 different from the RPF neighbor that would have been selected via the 240 local routing table. In all other cases the Vector MUST be included 241 in the Join message. 243 3.3.4. Vector Attribute and Join suppression 245 If a router receives a PIM join on the upstream LAN interface for a 246 particular multicast state, join suppression may be applied if that 247 PIM join is targeted to the same upstream neighbor. Which router(s) 248 will suppress their PIM join is dependant on timing and is 249 unpredictable. Downstream routers on a LAN MAY include different RPF 250 vectors in the PIM joins. Therefore an upstream router on that LAN 251 may receive and use different RPF vectors over time to reach the 252 destination (depending on which downstream router(s) suppressed their 253 Join). To make the upstream router behavior more predictable the RPF 254 vector address MUST be used as additional condition to the join 255 suppression logic. Only if the RPF vector in the PIM join matches 256 the RPF vector in the multicast state, the suppression logic is 257 applied. It is also possible to disable join suppression on that 258 LAN. 260 4. Vector Attribute TLV Format 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |F|S| Type | Length | Value 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... 268 F bit 269 ----- 270 Forward Unknown TLV. If this bit is set the TLV is forwarded 271 regardless of whether the router understands the Type. If the TLV is 272 known the F bit is ignored. 274 S bit 275 ----- 276 Bottom of Stack. If this bit is set then this is the last 277 TLV in the stack. 279 Type 280 ---- 281 The Vector Attribute type is 0. 283 Length 284 ------ 285 Length depending on Address Family of Encoded-Unicast address. 287 Value 288 ----- 289 Encoded-Unicast address. 291 5. IANA Considerations 293 An new attribute type from the "PIM Join Attribute Types" registry 294 needs to be assigned by IANA for the RPF Vector. The proposed value 295 is 0. 297 6. Security Considerations 299 Security of the RPF Vector Attribute is only guaranteed by the 300 security of the PIM packet, so the security considerations for PIM 301 join packets as described in PIM-SM [RFC4601] apply here. 303 7. Acknowledgments 305 The authors would like to thank Yakov Rekhter and Dino Farinacci for 306 their initial ideas on this topic and Su Haiyang for the comments on 307 the draft. 309 8. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 315 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 316 Protocol Specification (Revised)", RFC 4601, August 2006. 318 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 319 IP", RFC 4607, August 2006. 321 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 322 "Bidirectional Protocol Independent Multicast (BIDIR- 323 PIM)", RFC 5015, October 2007. 325 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 326 Independent Multicast (PIM) Join Attribute Format", 327 RFC 5384, November 2008. 329 Authors' Addresses 331 IJsbrand Wijnands 332 Cisco Systems, Inc. 333 De kleetlaan 6a 334 Diegem 1831 335 Belgium 337 Email: ice@cisco.com 339 Arjen Boers 340 Cisco Systems, Inc. 341 Avda. Diagonal, 682 342 Barcelona 08034 343 Spain 345 Email: aboers@cisco.com 346 Eric Rosen 347 Cisco Systems, Inc. 348 1414 Massachusetts Avenue 349 Boxborough, Ma 01719 351 Email: erosen@cisco.com