idnits 2.17.1 draft-ietf-pim-rpf-vector-07.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 237: '... vector address MUST be used as addit...' 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 5, 2009) is 5590 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: 4 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 9, 2009 Cisco Systems, Inc. 6 January 5, 2009 8 The RPF Vector TLV 9 draft-ietf-pim-rpf-vector-07 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 9, 2009. 34 Abstract 36 This document describes a use of the PIM Join Attribute as defined in 37 draft-ietf-pim-join-attributes [RFC5384] which enables PIM to build 38 multicast trees through an MPLS-enabled network, even if that 39 network's IGP does not have a route to the source of the tree. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Use of the RPF Vector TLV . . . . . . . . . . . . . . . . . . 4 45 2.1. Attribute and shared tree joins . . . . . . . . . . . . . 4 46 2.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5 47 2.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5 48 2.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5 49 2.3.2. Processing a Received Vector Attribute . . . . . . . . 5 50 2.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 5 51 2.3.4. Vector Attribute and Join suppression . . . . . . . . 6 52 3. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . 7 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 60 Intellectual Property and Copyright Statements . . . . . . . . . . 10 62 1. Introduction 64 It is sometimes convenient to distinguish the routers of a particular 65 network into two categories: "edge routers" and "core routers". The 66 edge routers attach directly to users or to other networks, but the 67 core routers attach only to other routers of the same network. If 68 the network is MPLS-enabled, then any unicast packet which needs to 69 travel outside the network can be "tunneled" via MPLS from one edge 70 router to another. To handle a unicast packet which must travel 71 outside the network, an edge router needs to know which of the other 72 edge routers is the best exit point from the network for that 73 packet's destination IP address. The core routers, however, do not 74 need to have any knowledge of routes which lead outside the network; 75 as they handle only tunneled packets, they only need to know how to 76 reach the edge routers and the other core routers. 78 Consider, for example, the case where the network is an Autonomous 79 System (AS), the edge routers are EBGP speakers, the core routers may 80 be said to constitute a "BGP-free core". The edge routers must 81 distribute BGP routes to each other, but not to the core routers. 83 However, when multicast packets are considered, the strategy of 84 keeping the core routers free of "external" routes is more 85 problematic. When using PIM-SM[RFC4601], PIM-SSM[RFC4607] or PIM- 86 BIDIR[RFC5015] to create a multicast distribution tree for a 87 particular multicast group, one wants the core routers to be full 88 participants in the PIM protocol, so that multicasting can be done 89 efficiently in the core. This means that the core routers must be 90 able to correctly process PIM Join messages for the group, which in 91 turn means that the core routes must be able to send the Join 92 messages towards the root of the distribution tree. If the root of 93 the tree lies outside the network's borders (e.g., is in a different 94 AS), and the core routers do not maintain routes to external 95 destinations, then the PIM Join messages cannot be processed, and the 96 multicast distribution tree cannot be created. 98 In order to allow PIM to work properly in an environment where the 99 core routers do not maintain external routes, a PIM extension is 100 needed. When an edge router sends a PIM Join message into the core, 101 it must include in that message a "Vector" which specifies the IP 102 address of the next edge router along the path to the root of the 103 multicast distribution tree. The core routers can then process the 104 Join message by sending it towards the specified edge router (i.e., 105 toward the Vector). In effect, the Vector serves as an attribute, 106 within a particular network, for the root of the tree. 108 This document defines a new TLV in the PIM Join Attribute message 109 [RFC5384]. It consists of a single Vector which identifies the exit 110 point of the network. 112 2. Use of the RPF Vector TLV 114 Before we can start forwarding multicast packets we need to build a 115 forwarding tree by sending PIM Joins hop by hop. Each router in the 116 path creates a forwarding state and propagates the Join towards the 117 root of the forwarding tree. The building of this tree is receiver 118 driven. See Figure 1. 120 ------------------ BGP ----------------- 121 | | 122 [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] 123 <--- (S,G) Join 125 Figure 1 127 In this example, the 2 edge routers are BGP speakers. The core 128 routers are not BGP speakers and do not have any BGP distributed 129 routes. The route to S is a BGP distributed route, hence is known to 130 the edge but not to the core. The Edge 2 router determines the 131 interface leading to S, and sends a PIM Join to the upstream router. 132 In this example, though, the upstream router is a core router, with 133 no route to S. Without the PIM extensions specified in this document, 134 the core router cannot determine where the send the Join, so the tree 135 cannot be constructed. 137 To allow the core router to participate in the construction of the 138 tree, the Edge 2 router will include an attribute field in the PIM 139 Join. In this example, the Attribute field will contain the IP 140 address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1. 141 The intermediate core routers do their RPF check on the Attribute (IP 142 address of Edge 1) rather than the Source, this allows the tree to be 143 constructed. 145 2.1. Attribute and shared tree joins 147 In the example above we build a source tree to illustrate the 148 attribute behavior. The attribute is however not restricted to 149 source tree only. The tree may also be constructed towards a 150 Rendezvous Point (RP) IP address. The RP IP address is used in a 151 similar way as the Source in the example above. PIM Attribute 152 procedures defined for sources are equally applicable to (*,G) and 153 (*,*,RP) joins unless otherwise noted. 155 2.2. Attribute and Bootstrap messages 157 The RPF vector does not apply to BSR bootstrap messages. To allow 158 BSR messages to be forwarded across a core where the BSR IP address 159 is not routable in the core a solution needs to be developed for BSR. 161 2.3. The Vector Attribute 163 2.3.1. Inserting a Vector Attribute in a Join 165 In the example of Figure 1, when the Edge 2 router looks up the route 166 to the source of the multicast distribution tree, it will find a BGP- 167 distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks 168 up the route to Edge 1 to find interface and PIM adjacency which is 169 the next hop to the source, namely Core 2. 171 When Edge 2 sends a PIM Join to Core 2, it includes a Vector 172 Attribute specifying the address of Edge 1. Core 2, and subsequent 173 core routers, will forwarding the Join along the Vector (i.e, towards 174 Edge 1) instead of trying to forward it towards S. 176 Whether an attribute is actually needed depends on whether the Core 177 routers have a route to the source of the multicast tree. How the 178 Edge router knows whether or not this is the case (and thus how the 179 Edge router determines whether or not to insert an attribute field) 180 is outside the scope of this document. 182 2.3.2. Processing a Received Vector Attribute 184 When processing a received PIM Join which contains a Vector 185 Attribute, a router must first check to see if the Vector IP address 186 is one of its own IP addresses. If so, the Vector Attribute is 187 discarded, and not passed further upstream. Otherwise, the Vector 188 Attribute is used to find the route to the source, and is passed 189 along when a PIM Join is sent upstream. Note that a router which 190 receives a Vector Attribute must use it, even if that router happens 191 to have a route to the source. A router which discards a Vector 192 Attribute may of course insert a new Vector Attribute. This would 193 typically happen if a PIM Join needed to pass through a sequence of 194 Edge routers, each pair of which is separated by a core which does 195 not have external routes. In the absence of periodic refreshment, 196 Vectors expire along with the corresponding (S,G) state. 198 2.3.3. Vector Attribute and Asserts 200 In a PIM Assert message we include the routing protocol's "metric" to 201 the source of the tree. This information is used in the selection of 202 the assert winner. If a PIM Join is being sent towards a Vector, 203 rather than towards the source, the Assert message must have the 204 metric to the Vector instead of the metric to the source. The Assert 205 message however does not have an attribute field and does not mention 206 the Vector. 208 A router may change its upstream neighbor on a particular multicast 209 tree as the result of receiving Assert messages. However a Vector 210 Attribute should not be sent in a PIM Join to an upstream neighbor 211 which is chosen as the result of an assert winner and different from 212 the original upstream neighbor (the upstream neighbor for the 213 multicast route not influenced by the assert). Reachability of the 214 Vector is only guaranteed by the router that advertises reachability 215 to the Vector in its IGP. If the assert winner upstream is not our 216 real preferred next-hop, we can't be sure this router knows the path 217 to the Vector. In the worst case the assert winner has a route to 218 the Vector that is on the same interface where the assert was won. 219 That will point the RPF interface to that interface and will result 220 in the O-list being NULL. The Vector attribute is not inserted if 221 the RPF neighbor was chosen via an assert process and the RPF 222 neighbor is different from the RPF neighbor that would have been 223 selected via the local routing table. In all other cases the Vector 224 has to be included in the Join message. 226 2.3.4. Vector Attribute and Join suppression 228 If a router receives a PIM join on the upstream LAN interface for a 229 particular multicast state, join suppression may be applied if that 230 PIM join is targeted to the same upstream neighbor. Which router(s) 231 will suppress their PIM join is depending on timing and is 232 unpredictable. Downstream routers on a LAN may include different RPF 233 vectors in the PIM joins. Therefore an upstream router on that LAN 234 may receive and use different RPF vectors over time to reach the 235 destination (depending on which downstream router(s) suppressed their 236 Join). To make the upstream router behavior more predictable the RPF 237 vector address MUST be used as additional condition to the join 238 suppression logic. Only if the RPF vector in the PIM join matches 239 the RPF vector in the multicast state, the suppression logic is 240 applied. It is also possible to disable join suppression on that 241 LAN. 243 3. Vector Attribute TLV Format 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |F|S| Type | Length | Value 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... 251 F bit 252 ----- 253 Forward Unknown TLV. If this bit is set the TLV is forwarded 254 regardless of whether the router understands the Type. If the TLV is 255 known the F bit is ignored. 257 S bit 258 ----- 259 Bottom of Stack. If this bit is set then this is the last 260 TLV in the stack. 262 Type 263 ---- 264 The Vector Attribute type is 0. 266 Length 267 ------ 268 Length depending on Address Family of Encoded-Unicast address. 270 Value 271 ----- 272 Encoded-Unicast address. 274 4. IANA Considerations 276 An new attribute type from the "PIM Join Attribute Types" registry 277 needs to be assigned by IANA for the RPF Vector. The propose value 278 is 0. 280 5. Security Considerations 282 Security of the RPF Vector Attribute is only guaranteed by the 283 security of the PIM packet, so the security considerations for PIM 284 join packets as described in PIM-SM [RFC4601] apply here. 286 6. Acknowledgments 288 The authors would like to thank Yakov Rekhter and Dino Farinacci for 289 their initial ideas on this topic and Su Haiyang for the comments on 290 the draft. 292 7. References 294 7.1. Normative References 296 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 297 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 298 Protocol Specification (Revised)", RFC 4601, August 2006. 300 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 301 IP", RFC 4607, August 2006. 303 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 304 "Bidirectional Protocol Independent Multicast (BIDIR- 305 PIM)", RFC 5015, October 2007. 307 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 308 Independent Multicast (PIM) Join Attribute Format", 309 RFC 5384, November 2008. 311 7.2. Informative References 313 Authors' Addresses 315 IJsbrand Wijnands 316 Cisco Systems, Inc. 317 De kleetlaan 6a 318 Diegem 1831 319 Belgium 321 Email: ice@cisco.com 323 Arjen Boers 324 Cisco Systems, Inc. 325 Avda. Diagonal, 682 326 Barcelona 08034 327 Spain 329 Email: aboers@cisco.com 330 Eric Rosen 331 Cisco Systems, Inc. 332 1414 Massachusetts Avenue 333 Boxborough, Ma 01719 335 Email: erosen@cisco.com 337 Copyright and License Notice 339 Copyright (c) 2009 IETF Trust and the persons identified as the 340 document authors. All rights reserved. 342 This document is subject to BCP 78 and the IETF Trust's Legal 343 Provisions Relating to IETF Documents 344 (http://trustee.ietf.org/license-info) in effect on the date of 345 publication of this document. Please review these documents 346 carefully, as they describe your rights and restrictions with respect 347 to this document.