idnits 2.17.1 draft-ietf-pim-rpf-vector-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 338. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-pim-join-attributes]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 () is 739377 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) == Unused Reference: 'I-D.ietf-ssm-arch' is defined on line 285, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-11 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-07 == Outdated reference: A later version (-06) exists of draft-ietf-pim-join-attributes-00 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-06 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIM WG IJ. Wijnands 2 Internet-Draft A. Boers 3 Expires: April 4, 2006 E. Rosen 4 Cisco Systems, Inc. 5 october 2005 7 The RPF Vector TLV 8 draft-ietf-pim-rpf-vector-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 4, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a use of the PIM Join Attribute as defined in 42 draft-ietf-pim-join-attributes[I-D.ietf-pim-join-attributes] which 43 enables PIM to build multicast trees through an MPLS-enabled network, 44 even if that network's IGP does not have a route to the source of the 45 tree. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Use of the RPF Vector TLV . . . . . . . . . . . . . . . . . . 4 51 2.1. Attribute and shared tree joins . . . . . . . . . . . . . 4 52 2.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5 53 2.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5 54 2.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5 55 2.3.2. Processing a Received Vector Attribute . . . . . . . . 5 56 2.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 5 57 3. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . 7 58 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 61 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 63 Intellectual Property and Copyright Statements . . . . . . . . . . 10 65 1. Introduction 67 It is sometimes convenient to distinguish the routers of a particular 68 network into two categories: "edge routers" and "core routers". The 69 edge routers attach directly to users or to other networks, but the 70 core routers attach only to other routers of the same network. If 71 the network is MPLS-enabled, then any unicast packet which needs to 72 travel outside the network can be "tunneled" via MPLS from one edge 73 router to another. To handle a unicast packet which must travel 74 outside the network, an edge router needs to know which of the other 75 edge routers is the best exit point from the network for that 76 packet's destination IP address. The core routers, however, do not 77 need to have any knowledge of routes which lead outside the network; 78 as they handle only tunneled packets, they only need to know how to 79 reach the edge routers and the other core routers. 81 Consider, for example, the case where the network is an Autonomous 82 System (AS), the edge routers are EBGP speakers, the core routers may 83 be said to constitute a "BGP-free core". The edge routers must 84 distribute BGP routes to each other, but not to the core routers. 86 However, when multicast packets are considered, the strategy of 87 keeping the core routers free of "external" routes is more 88 problematic. When using PIM-SM[I-D.ietf-pim-sm-v2-new], PIM-SSM[I- 89 D.ietf-ssm-arch] or PIM-BIDIR[I-D.ietf-pim-bidir] to create a 90 multicast distribution tree for a particular multicast group, one 91 wants the core routers to be full participants in the PIM protocol, 92 so that multicasting can be done efficiently in the core.This means 93 that the core routers must be able to correctly process PIM Join 94 messages for the group, which in turn means that the core routes must 95 be able to send the Join messages towards the root of the 96 distribution tree. If the root of the tree lies outside the 97 network's borders (e.g., is in a different AS), and the core routers 98 do not maintain routes to external destinations, then the PIM Join 99 messages cannot be processed, and the multicast distribution tree 100 cannot be created. 102 In order to allow PIM to work properly in an environment where the 103 core routers do not maintain external routes, a PIM extension is 104 needed. When an edge router sends a PIM Join message into the core, 105 it must include in that message a "Vector" which specifies the IP 106 address of the next edge router along the path to the root of the 107 multicast distribution tree. The core routers can then process the 108 Join message by sending it towards the specified edge router (i.e., 109 toward the Vector). In effect, the Vector serves as an attribute, 110 within a particular network, for the root of the tree. 112 This document defines a new TLV in the PIM Join Attribute message[I- 113 D.ietf-pim-join-attributes]. It consists of a single Vector which 114 identifies the exit point of the network. 116 2. Use of the RPF Vector TLV 118 Before we can start forwarding multicast packets we need to build a 119 forwarding tree by sending PIM Joins hop by hop. Each router in the 120 path creates a forwarding state and propagates the Join towards the 121 root of the forwarding tree. The building of this tree is receiver 122 driven. See Figure 1. 124 ------------------ BGP ----------------- 125 | | 126 [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] 127 <--- (S,G) Join 129 Figure 1 131 In this example, the 2 edge routers are BGP speakers. The core 132 routers are not BGP speakers and do not have any BGP distributed 133 routes. The route to S is a BGP distributed route, hence is known to 134 the edge but not to the core. The Edge 2 router determines the 135 interface leading to S, and sends a PIM Join to the upstream router. 136 In this example, though, the upstream router is a core router, with 137 no route to S. Without the PIM extensions specified in this document, 138 the core router cannot determine where the send the Join, so the tree 139 cannot be constructed. 141 To allow the core router to participate in the construction of the 142 tree, the Edge 2 router will include an attribute field in the PIM 143 Join. In this example, the Attribute field will contain the IP 144 address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1. 145 The intermediate core router do their RPF check on the Attribute (IP 146 address of Edge 1) rather than the Source, this allows the tree to be 147 constructed. 149 2.1. Attribute and shared tree joins 151 In the example above we build a source tree to illustrate the 152 attribute behavior. The attribute is however not restricted to 153 source tree only. The tree may also be constructed towards a 154 Rendezvous Point (RP) IP address. The RP IP address is used in a 155 similar way as the Source in the example above. PIM Attribute 156 procedures defined for sources are equally applicable to (*,G) and 157 (*,*,RP) joins unless otherwise noted. 159 2.2. Attribute and Bootstrap messages 161 The RPF vector does not apply to BSR bootstrap messages. To allow 162 BSR messages to be forwarded across a core where the RP IP address is 163 not routable in the core a solution has the developed in BSR. 165 2.3. The Vector Attribute 167 2.3.1. Inserting a Vector Attribute in a Join 169 In the example of Figure 1, when the Edge 2 router looks up the route 170 to the source of the multicast distribution tree, it will find a BGP- 171 distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks 172 up the route to Edge 1 to find interface and PIM adjacency which is 173 the next hop to the source, namely Core 2. 175 When Edge 2 sends a PIM Join to Core 2, it includes a Vector 176 Attribute specifying the address of Edge 1. Core 2, and subsequent 177 core routers, will forwarding the Join along the Vector (i.e, towards 178 Edge 1) instead of trying to forward it towards S. 180 Whether an ttribute is actually needed depends on whether the Core 181 routers have a route to the source of the multicast tree. How the 182 Edge router knows whether or not this is the case (and thus how the 183 Edge router determines whether or not to insert an attribute field) 184 is outside the scope of this document. 186 2.3.2. Processing a Received Vector Attribute 188 When processing a received PIM Join which contains a Vector 189 Attribute, a router must first check to see if the Vector IP address 190 is one of its own IP addresses. If so, the Vector Attribute is 191 discarded, and not passed further upstream. Otherwise, the Vector 192 Attribute is used to find the route to the source, and is passed 193 along when a PIM Join is sent upstream. Note that a router which 194 receives a Vector Attribute must use it, even if that router happens 195 to have a route to the source. A router which discards a Vector 196 Attribute may of course insert a new Vector Attribute. This would 197 typically happen if a PIM Join needed to pass through a sequence of 198 Edge routers, each pair of which is separated by a core which does 199 not have external routes. In the absence of periodic refreshment, 200 Vectors expire along with the corresponding (S,G) state. 202 2.3.3. Vector Attribute and Asserts 204 In a PIM Assert message we include the routing protocol's "metric" to 205 the source of the tree. This information is used in the selection of 206 the assert winner. If a PIM Join is being sent towards a Vector, 207 rather than towards the source, the Assert message must have the 208 metric to the Vector instead of the metric to the source. The Assert 209 message however does not have an attribute field and does not mention 210 the Vector. 212 A router may change its upstream neighbor on a particular multicast 213 tree as the result of receiving Assert messages. However a Vector 214 Attribute should not be sent in a PIM Join to an upstream neighbor 215 which is chosen as the result of processing the Assert messages. 216 Reachability of the Vector is only guaranteed by the router that 217 advertises reachability to the Vector in it's IGP. If the assert 218 winner upstream is not our real preferred next-hop, we can't be sure 219 this router knows the path to the Vector. In the worst case the 220 assert winner has a route to the Vector that is on the same interface 221 where the assert was won. That will point the RPF interface to that 222 interface and will result in a O-list being NULL. The Vector 223 attribute is not inserted if the RPF neighbor was chosen via an 224 assert process and the RPF neighbor is different from the RPF 225 neighbor that would have been selected via the local routing table. 226 In all other cases the Vector has to be included in the Join message. 228 3. Vector Attribute TLV Format 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |F|S| Type | Length | IP address 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... 236 F bit 237 ----- 238 Forward Unknown TLV. If this bit is set the TLV is forwarded 239 regardless if the router understands the Type. 241 S bit 242 ----- 243 Bottom of Stack. If this bit is set then this is the last 244 TLV in the stack. 246 Type 247 ---- 248 The Vector Attribute type is 0. 250 Length 251 ------ 252 Length in bytes is 4. 254 Value 255 ----- 256 IPv4 address. 258 4. Acknowledgments 260 The authors would like to thank Yakov Rekhter and Dino Farinacci for 261 their initial ideas on this topic. 263 5. References 265 5.1. Normative References 267 [I-D.ietf-pim-sm-v2-new] 268 Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 269 "Protocol Independent Multicast - Sparse Mode PIM-SM): 270 Protocol Specification (Revised)", 271 draft-ietf-pim-sm-v2-new-11 (work in progress), 272 October 2004. 274 [I-D.ietf-pim-bidir] 275 Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 276 "Bi-directional Protocol Independent Multicast (BIDIR- 277 PIM)", draft-ietf-pim-bidir-07 (work in progress), 278 March 2005. 280 [I-D.ietf-pim-join-attributes] 281 Boers, A., "Format for using TLVs in PIM messages", 282 draft-ietf-pim-join-attributes-00 (work in progress), 283 October 2005. 285 [I-D.ietf-ssm-arch] 286 Holbrook, H. and B. Cain, "Source-Specific Multicast for 287 IP", draft-ietf-ssm-arch-06 (work in progress), 288 September 2004. 290 5.2. Informative References 291 Authors' Addresses 293 IJsbrand Wijnands 294 Cisco Systems, Inc. 295 De kleetlaan 6a 296 Diegem 1831 297 Belgium 299 Email: ice@cisco.com 301 Arjen Boers 302 Cisco Systems, Inc. 303 Avda. Diagonal, 682 304 Barcelona 08034 305 Spain 307 Email: aboers@cisco.com 309 Eric Rosen 310 Cisco Systems, Inc. 311 1414 Massachusetts Avenue 312 Boxborough, Ma 01719 314 Email: erosen@cisco.com 316 Intellectual Property Statement 318 The IETF takes no position regarding the validity or scope of any 319 Intellectual Property Rights or other rights that might be claimed to 320 pertain to the implementation or use of the technology described in 321 this document or the extent to which any license under such rights 322 might or might not be available; nor does it represent that it has 323 made any independent effort to identify any such rights. Information 324 on the procedures with respect to rights in RFC documents can be 325 found in BCP 78 and BCP 79. 327 Copies of IPR disclosures made to the IETF Secretariat and any 328 assurances of licenses to be made available, or the result of an 329 attempt made to obtain a general license or permission for the use of 330 such proprietary rights by implementers or users of this 331 specification can be obtained from the IETF on-line IPR repository at 332 http://www.ietf.org/ipr. 334 The IETF invites any interested party to bring to its attention any 335 copyrights, patents or patent applications, or other proprietary 336 rights that may cover technology that may be required to implement 337 this standard. Please address the information to the IETF at 338 ietf-ipr@ietf.org. 340 Disclaimer of Validity 342 This document and the information contained herein are provided on an 343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 345 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 346 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 347 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 348 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 350 Copyright Statement 352 Copyright (C) The Internet Society (2005). This document is subject 353 to the rights, licenses and restrictions contained in BCP 78, and 354 except as set forth therein, the authors retain all their rights. 356 Acknowledgment 358 Funding for the RFC Editor function is currently provided by the 359 Internet Society.