idnits 2.17.1 draft-farinacci-msdp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 25, 1998) is 9435 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: '1' is defined on line 357, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 362, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 366, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 369, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 372, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 375, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-ietf-idmr-pim-sm-specv2 (ref. '1') == Outdated reference: A later version (-04) exists of draft-ietf-idmr-gum-01 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 1771 (ref. '3') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2283 (ref. '4') (Obsoleted by RFC 2858) -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-05 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. '6') Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dino Farinacci 3 INTERNET DRAFT Yakov Rekhter 4 cisco Systems 5 Peter Lothberg 6 Sprint 7 Hank Kilmer 8 Digex 9 Jeremy Hall 10 UUnet 11 June 25, 1998 13 Multicast Source Discovery Protocol (MSDP) 14 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This proposal describes a mechanism to connect multiple PIM-SM 37 domains together. Each PIM-SM domain uses it's own independent RP(s) 38 and do not have to depend on RPs in other domains. 40 This proposal is being submitted as a method for the initial phase of 41 Inter-Domain Multicast deployment in the Internet and may be upward 42 compatible with the IDMR protocols being proposed for subsequent 43 phases. 45 1.0 Introduction 47 This proposal describes a mechanism to connect multiple PIM-SM 48 domains together. Each PIM-SM domain uses it's own independent RP(s) 49 and do not have to depend on RPs in other domains. 51 Some advantages of this proposal: 53 o PIM-SM domains can rely on their own RPs only. 54 o Domains with only receivers get data without globally advertising 55 group membership. 56 o Global source state is not required. 58 2.0 Overview 60 An RP in a PIM-SM domain will have a MSDP peering relationship with 61 an RP in another domain. The peering relationship will be made up of 62 a TCP connection in which only control information is primarily 63 exchanged. Each domain will have a connection to this virtual 64 topology. 66 The purpose of this topology is to have domains discover multicast 67 sources from other domains. If the multicast sources are of interest 68 to a domain which has receivers, the normal source-tree building 69 mechanism in PIM-SM will be used to deliver multicast data over an 70 inter-domain distribution tree. 72 We envision this virtual topology will essentially be congruent to 73 the existing BGP topology used in the unicast-based Internet today. 74 That is the TCP connections between RPs can be realized by the 75 underlying BGP routing system. 77 3.0 Procedure 79 A source in a PIM-SM domain originates traffic to a multicast group. 80 The PIM DR which is directly connected to the source sends the data 81 encapsulated in a PIM Register message to the RP in the domain. 83 The RP will construct a "Source-Active" (SA) message and send it to 84 it's MSDP peers. The SA message contains the following fields: 86 o Source address of the data source. 87 o Group address the data source sends to. 88 o IP address of the RP. 90 Each MSDP peer receives and forwards the message away from the RP 91 address in a "peer-RPF flooding" fashion. The notion of peer-RPF 92 flooding is with respect to forwarding SA messages. The BGP routing 93 table is examined to determine which peer is the next hop towards the 94 originating RP of the SA message. Such a peer is called an "RPF 95 peer". 97 If the MSDP peer receives the SA from a non-RPF peer towards the 98 originating RP, it will drop the message. Otherwise, it forwards the 99 message to all it's MSDP peers. 101 The flooding can be further constrained to children of the peer by 102 interrogating BGP reachability information. That is, if a peer 103 advertises a route (back to you) and you are the next to last AS in 104 the AS-path, the peer is using you as the next-hop. In this case, you 105 *should* forward an SA message (which was originated from the RP 106 address covered by that route) to the peer. This is known in other 107 circles as Split-Horizon with Poison Reverse. 109 When each MSDP peer (which are also RPs for their own domain) receive 110 an SA message, they determine if they have any group members 111 interested in the group the SA message describes. If the (*,G) entry 112 exists with an non-empty outgoing interface list, the domain is 113 interested in the group, and the RP triggers an (S,G) join towards 114 the data source. This sets up a branch of the source-tree to this 115 domain. Subsequent data packets arrive at the RP which are forwarded 116 down the shared-tree inside the domain. If leaf routers choose to 117 join the source-tree they have the option to do so according to 118 existing PIM-SM conventions. 120 This procedure has been affectionately named flood-and-join because 121 if any RP is not interested in the group, they can ignore the SA 122 message. Otherwise, they join a distribution tree. 124 4.0 Controlling State 126 RPs which receive SA messages are not required to keep MSDP (S,G) 127 state. However, if they do, newly formed MSDP peers can get MSDP 128 (S,G) state sooner and therefore reduce join latency for new joiners. 130 RPs which originate SA messages do it periodically as long as there 131 is data being sent by the source. RPs will not send more than 1 SA 132 message for a given (S,G) within a 1 minute interval. Originating 133 periodic SA messages are important so new receivers who join after a 134 source has been active can get data quickly via the receiver's own RP 135 when it is not caching SA state. 137 Intermediate RPs do not send periodic SA messages on behalf of 138 sources in other domains. They only do for their own sources. 140 As the number of (source,group) pairs increases in the Internet, an 141 RP may want to filter what sources it describes in SA messages. Also, 142 filtering may be used as a matter of policy which at the same time 143 can reduce state. Only the RP colocated in the same domain as the 144 source can restrict SA messages. Other RPs should not filter or the 145 flood-and-join model becomes broken. 147 If an MSDP peer decides to cache SA state, it may accept SA-Requests 148 from other MSDP peers. When a MSDP peer receives an SA-Request for a 149 group range, it will respond to the peer with a set of SA entries, in 150 a SA-Response message, for all active sources sending to the group 151 range requested in the SA-Request message. The peer that sends the 152 request will not flood the responding SA-Response message to other 153 peers. 155 5.0 SA Encapsulated Data Packets 157 For bursty sources, the SA message may contain multicast data from 158 the source. Interested RPs can decapsulate the SA message and forward 159 the original data packet down the shared-tree inside of a domain. We 160 recommend this not be the default setting. 162 6.0 Auto-configuration versus Manual-configuration of MSDP Peers 164 MSDP peers can be configured manually or can be learned 165 automatically. The two automatic mechanisms can be achieved by: 167 o PIM Query/Hello messages 168 o BGP capability parameter negotiation 170 In either case, each side of the peering relationship will indicate 171 it's desire to participate in the MSDP protocol. If so, the TCP peer 172 relationship is set up. 174 7.0 Other Scenarios 176 MSDP is not limited to deployment across different routing domains. 177 It can be used within a routing domain when it is desired to deploy 178 multiple RPs for different group ranges. As long as all RPs have a 179 interconnected MSDP topology, each can learn about active sources as 180 well as RPs in other domains. 182 MSDP can be used in domains that operate a dense-mode multicast 183 routing protocol. However, in some cases SA messages with 184 encapsulated source data may be required. 186 8.0 Packet Formats 188 MSDP messages will be encapsulated in a TCP connection using well- 189 known port 639. The one side of the MSDP peering relationship will 190 listen on the well-known port and the other side will do an active 191 connect on the well-known port. The side with the higher IP address 192 will do the listen. This connection establishment algorithm avoids 193 call collision. Therefore, there is no need for a call collision 194 procedure. 196 MSDP messages will be encoded in TLV format: 198 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | Value .... | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Type (8 bits) 205 Describes the format of the Value field. 207 Length (16 bits) 208 Length of Type, Length, and Value fields in octets. Minimum length 209 required is 3 octets. 211 Value (variable length) 212 Format is based on the Type value. See below. The length of the 213 value field is Length field minus 3. 215 Documented Types: 217 IPv4 Source-Active TLV 219 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | 1 | x + y | Entry Count | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | RP Address | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Reserved | Gprefix Len | Sprefix Len | \ 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 228 | Group Address Prefix | ) z 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 230 | Source Address Prefix | / 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Type 234 IPv4 Source-Active TLV is type 1. 236 Length x 237 Is the length of the control information in the message. x is 8 238 octets (for the first two 32-bit quantities) plus 12 times Entry 239 Count octets. 241 Length y 242 If 0, then there is no data encapsulated. Otherwise an IPv4 packet 243 follows and y is the length of the total length field of the IPv4 244 header encapsulated. If there are multiple SA TLVs in a message, 245 and data is also included, y must be 0 in all SA TLVs except the 246 last one. And the last SA TLV must reflect the source and destination 247 addresses in the IP header of the encapsulated data. 249 Entry Count 250 Is the count of z entries (note above) which follow the RP address 251 field. This is so multiple (S,G)s from the same domain can be 252 encoded efficiently for the same RP address. 254 RP Address 255 The address of the RP in the domain the source has become active in. 257 Gprefix Len and Sprefix Len 258 The route prefix length associated with the group address prefix 259 and source address prefix, respectively. 261 Group Address Prefix 262 The group address the active source has sent data to. 264 Source Address Prefix 265 The route prefix associated with the active source. 267 Multiple SA TLVs can appear in the same message and can be batched for 268 efficiency at the expense of data latency. This would typically occur 269 on intermediate forwarding of SA messages. 271 IPv4 Source-Active Request TLV 273 Used to request SA-state from a caching MSDP peer. If an RP in a domain 274 receives a PIM Join message for a group, creates (*,G) state and wants to 275 know all active sources for group G, and it has been configured to peer 276 with an SA-state caching peer, it may send an SA-Request message 277 for the group. 279 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | 2 | 8 | Gprefix Len | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Group Address Prefix | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Type 288 IPv4 Source-Active Request TLV is type 2. 290 Gprefix Len 291 The route prefix length associated with the group address prefix. 293 Group Address Prefix 294 The group address prefix the MSDP peer is requesting. 296 IPv4 Source-Active Response TLV 298 Sent in response to a Source-Active Request message. The Source-Active 299 Response message has the same format as a Source-Active message but 300 does not allow encapsulation of multicast data. 302 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | 3 | x | .... | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Type 309 IPv4 Source-Active Response TLV is type 3. 311 Length x 312 Is the length of the control information in the message. x is 8 313 octets (for the first two 32-bit quantities) plus 12 times Entry 314 Count octets. 316 9.0 Acknowledgements 318 The authors would like to thank David Meyer, John Meylor, Liming Wei, 319 Manoj Leelanivas, Mark Turner, and John Zwiebel for their design 320 feedback and comments. 322 10.0 Author's Address: 324 Dino Farinacci 325 Cisco Systems, Inc. 326 170 Tasman Drive 327 San Jose, CA, 95134 328 Email: dino@cisco.com 330 Yakov Rehkter 331 Cisco Systems, Inc. 332 170 Tasman Drive 333 San Jose, CA, 95134 334 Email: yakov@cisco.com 336 Peter Lothberg 337 Sprint 338 VARESA0104 339 12502 Sunrise Valley Drive 340 Reston VA, 20196 341 Email: roll@sprint.net 343 Hank Kilmer 344 Digex Inc. 345 One DIGEX Plaza 346 Beltsville, Maryland 20705 347 Email: hank@rem.com 349 Jeremy Hall 350 UUnet Technologies 351 3060 Williams Drive 352 Fairfax, VA 22031 353 Email: jhall@uu.net 355 11.0 References 357 [1] Estrin D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 358 Handley M., Jacobson, V., Liu C., Sharma, P., Wei, L., "Protocol 359 Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", 360 draft-ietf-idmr-pim-sm-specv2-00.txt, September 9, 1997. 362 [2] Thaler, D., Estrin, D., Meyer, D., "Border Gateway Multicast Protocol 363 (BGMP): Protocol Specification", draft-ietf-idmr-gum-01.txt, October 30, 364 1997. 366 [3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, 367 March 1995. 369 [4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter., "Multiprotocol 370 Extensions for BGP-4", RFC 2283, February 1998. 372 [5] Deering, S., "Multicast Routing in a Datagram Internetwork", PhD thesis, 373 Electric Engineering Dept., Stanford University, December 1991. 375 [6] Pusateri, T., "Distance Vector Multicast Routing Protocol", 376 draft-ietf-idmr-dvmrp-v3-05.txt, October 1997.