idnits 2.17.00 (12 Aug 2021) /tmp/idnits64803/draft-ietf-msdp-spec-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC2362]), 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: RPs which originate SA messages do so periodically as long as there is data being sent by the source. There is one SA-Advertisement-Timer covering the sources that an RP may advertise. [SA-Advertisement-Period] MUST be 60 seconds. An RP MUST not send more than one periodic SA message for a given (S,G) within an SA Advertisement interval. Originating periodic SA messages is required to keep announcements alive in caches. Finally, an originating RP SHOULD trigger the transmission of an SA message as soon as it receives data from an internal source for the first time. This initial SA message may be in addition to the periodic sa-message forwarded in that first 60 seconds for that (S,G). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If an MSDP message is received with a TLV format error, the session SHOULD be reset with that peer. MSDP messages with other errors, such as unrecognized type code, received from MSDP peers, SHOULD be silently discarded and the session SHOULD not be reset. -- 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 (May 2003) is 6945 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) == Missing Reference: 'SG-State-Period' is mentioned on line 241, but not defined == Missing Reference: 'SA-Hold-Down-Period' is mentioned on line 242, but not defined == Missing Reference: 'HoldTime-Period' is mentioned on line 509, but not defined == Missing Reference: 'KeepAlive-Period' is mentioned on line 654, but not defined == Missing Reference: 'ConnectRetry-Period' is mentioned on line 481, but not defined == Unused Reference: 'RFC2119' is defined on line 842, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1142 (Obsoleted by RFC 7142) ** Obsolete normative reference: RFC 2178 (Obsoleted by RFC 2328) ** Obsolete normative reference: RFC 2283 (Obsoleted by RFC 2858) ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 3446 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Bill Fenner (Editor) 2 draft-ietf-msdp-spec-16.txt David Meyer (Editor) 3 Category Informational 4 Expires: November 2003 May 2003 6 Multicast Source Discovery Protocol (MSDP) 7 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a product of an individual. Comments are solicited 31 and should be addressed to the author(s). 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 The Multicast Source Discovery Protocol, MSDP, describes a mechanism 40 to connect multiple IP Version 4 Protocol Independent Multicast 41 Sparse-Mode (PIM-SM) [RFC2362] domains together. Each PIM-SM domain 42 uses its own independent Rendezvous Point (RP) and does not have to 43 depend on RPs in other domains. This draft is intended to document 44 existing MSDP implementations in the field. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 4. Caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 5. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 5.1. SA-Advertisement-Timer. . . . . . . . . . . . . . . . . . . 7 54 5.2. SA-Advertisement-Timer Processing . . . . . . . . . . . . . 8 55 5.3. SA Cache Timeout (SA-State Timer) . . . . . . . . . . . . . 8 56 5.4. Peer Hold Timer . . . . . . . . . . . . . . . . . . . . . . 8 57 5.5. KeepAlive Timer . . . . . . . . . . . . . . . . . . . . . . 9 58 5.6. ConnectRetry Timer. . . . . . . . . . . . . . . . . . . . . 9 59 6. Intermediate MSDP Peers. . . . . . . . . . . . . . . . . . . . 9 60 7. SA Filtering and Policy. . . . . . . . . . . . . . . . . . . . 10 61 8. Encapsulated Data Packets. . . . . . . . . . . . . . . . . . . 10 62 9. Other Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 10 63 10. MSDP Peer-RPF Forwarding. . . . . . . . . . . . . . . . . . . 11 64 10.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . 11 65 10.1.1. Multicast RPF Routing Information Base (MRIB). .. . . . 11 66 10.1.2. Peer-RPF Route. . . . . . . . . . . . . . . . . . . . . 11 67 10.1.3. Peer-RPF Forwarding Rules . . . . . . . . . . . . . . . 11 68 10.2. MSDP mesh-group semantics. . . . . . . . . . . . . . . . . 13 69 11. MSDP Connection State Machine . . . . . . . . . . . . . . . . 14 70 11.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 11.2. Actions. . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 11.3. Peer-specific Events . . . . . . . . . . . . . . . . . . . 16 73 11.4. Peer-independent Events. . . . . . . . . . . . . . . . . . 17 74 12. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . . 17 75 12.1. MSDP TLV format. . . . . . . . . . . . . . . . . . . . . . 17 76 12.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . . 18 77 12.2.1. IPv4 Source-Active TLV. . . . . . . . . . . . . . . . . 18 78 12.2.2. KeepAlive TLV . . . . . . . . . . . . . . . . . . . . . 20 79 13. MSDP Error Handling . . . . . . . . . . . . . . . . . . . . . 20 80 14. SA Data Encapsulation . . . . . . . . . . . . . . . . . . . . 21 81 15. Applicability Statement . . . . . . . . . . . . . . . . . . . 21 82 15.1. Between PIM Domains. . . . . . . . . . . . . . . . . . . . 21 83 15.2. Between Anycast-RPs. . . . . . . . . . . . . . . . . . . . 21 84 16. Intellectual Property . . . . . . . . . . . . . . . . . . . . 21 85 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 86 18. Security Considerations . . . . . . . . . . . . . . . . . . . 23 87 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 20. References. . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 20.1. Normative References . . . . . . . . . . . . . . . . . . . 24 90 20.2. Informative References . . . . . . . . . . . . . . . . . . 25 91 21. Editor's Addresses. . . . . . . . . . . . . . . . . . . . . . 25 92 22. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 25 94 1. Introduction 96 The Multicast Source Discovery Protocol, MSDP, describes a mechanism 97 to connect multiple PIM Sparse-Mode (PIM-SM) [RFC2362] domains 98 together. Each PIM-SM domain uses its own independent RP(s) and does 99 not have to depend on RPs in other domains. Advantages of this 100 approach include: 102 o No Third-party resource dependencies on a domain's RP 104 PIM-SM domains can rely on their own RPs only. 106 o Receiver only Domains 108 Domains with only receivers get data without globally 109 advertising group membership. 111 Note that MSDP may be used with protocols other than PIM-SM, but such 112 usage is not specified in this memo. 114 2. Overview 116 MSDP-speaking routers in a PIM-SM domain have a MSDP peering 117 relationship with MSDP peers in another domain. The peering 118 relationship is made up of a TCP connection in which control 119 information is exchanged. Each domain has one or more connections to 120 this virtual topology. 122 The purpose of this topology is to allow domains to discover 123 multicast sources from other domains. If the multicast sources are of 124 interest to a domain which has receivers, the normal source-tree 125 building mechanism in PIM-SM will be used to deliver multicast data 126 over an inter-domain distribution tree. 128 3. Procedure 130 When an RP in a PIM-SM domain first learns of a new sender, e.g. via 131 PIM register messages, it constructs a "Source-Active" (SA) message 132 and sends it to its MSDP peers. All RPs, which intend to originate or 133 receive SA messages, must establish MSDP peering with other RPs, 134 either directly or via an intermediate MSDP peer. The SA message 135 contains the following fields: 137 o Source address of the data source. 139 o Group address the data source sends to. 141 o IP address of the RP. 143 Note that an RP that isn't a DR on a shared network SHOULD NOT 144 originate SA's for directly connected sources on that shared network; 145 it should only originate in response to receiving Register messages 146 from the DR. 148 Each MSDP peer receives and forwards the message away from the RP 149 address in a "peer-RPF flooding" fashion. The notion of peer-RPF 150 flooding is with respect to forwarding SA messages. The Multicast RPF 151 Routing Information Base (MRIB) is examined to determine which peer 152 towards the originating RP of the SA message is selected. Such a peer 153 is called an "RPF peer". See section 13 for the details of peer-RPF 154 forwarding. 156 If the MSDP peer receives the SA from a non-RPF peer towards the 157 originating RP, it will drop the message. Otherwise, it forwards the 158 message to all its MSDP peers (except the one from which it received 159 the SA message). 161 When an MSDP peer which is also an RP for its own domain receives a 162 new SA message, it determines if there are any group members within 163 the domain interested in any group described by an (Source, Group), 164 or (S,G) entry within the SA message. That is, the RP checks for a 165 (*,G) entry with a non-empty outgoing interface list; this implies 166 that some system in the domain is interested in the group. In this 167 case, the RP triggers a (S,G) join event towards the data source as 168 if a Join/Prune message was received addressed to the RP itself. This 169 sets up a branch of the source-tree to this domain. Subsequent data 170 packets arrive at the RP via this tree branch, and are forwarded down 171 the shared-tree inside the domain. If leaf routers choose to join the 172 source-tree they have the option to do so according to existing PIM- 173 SM conventions. Finally, if an RP in a domain receives a PIM Join 174 message for a new group G, the RP SHOULD trigger a (S,G) join event 175 for each active (S,G) for that group in its SA cache. 177 This procedure has been affectionately named flood-and-join because 178 if any RP is not interested in the group, they can ignore the SA 179 message. Otherwise, they join a distribution tree. 181 4. Caching 183 A MSDP speaker MUST cache SA messages. Caching allows pacing of MSDP 184 messages as well as reducing join latency for new receivers of a 185 group G at an originating RP which has existing MSDP (S,G) state. In 186 addition, caching greatly aids in diagnosis and debugging of various 187 problems. 189 An MSDP speaker must provide a mechanism to reduce the forwarding of 190 new SA's. The SA-cache is used to reduce storms and performs this by 191 not forwarding SA's unless they are in the cache or are new SA 192 packets that the MSDP speaker will cache for the first time. The SA- 193 cache also reduces storms by advertising from the cache at a period 194 of no more than twice per SA-Advertisement-Timer interval and not 195 less than 1 time per SA Advertisement period. 197 5. Timers 199 The main timers for MSDP are: SA-Advertisement-Timer, SA Cache Entry 200 timer, Peer Hold Timer, KeepAlive timer, and ConnectRetry timer. Each 201 is considered below. 203 5.1. SA-Advertisement-Timer 205 RPs which originate SA messages do so periodically as long as there 206 is data being sent by the source. There is one SA-Advertisement-Timer 207 covering the sources that an RP may advertise. [SA-Advertisement- 208 Period] MUST be 60 seconds. An RP MUST not send more than one 209 periodic SA message for a given (S,G) within an SA Advertisement 210 interval. Originating periodic SA messages is required to keep 211 announcements alive in caches. Finally, an originating RP SHOULD 212 trigger the transmission of an SA message as soon as it receives data 213 from an internal source for the first time. This initial SA message 214 may be in addition to the periodic sa-message forwarded in that first 215 60 seconds for that (S,G). 217 5.2. SA-Advertisement-Timer Processing 219 An RP MUST spread the generation of periodic SA messages (i.e. 220 messages advertising the active sources for which it is the RP) over 221 its reporting interval (i.e. SA-Advertisement-Period). An RP starts 222 the SA-Advertisement-Timer when the MSDP process is configured. When 223 the timer expires, an RP resets the timer to [SA-Advertisement- 224 Period] seconds, and begins the advertisement of its active sources. 225 Active sources are advertised in the following manner: An RP packs 226 its active sources into an SA message until the largest MSDP packet 227 that can be sent is built or there are no more sources, and then 228 sends the message. This process is repeated periodically within the 229 SA-Advertisement-Period in such a way that all of the RP's sources 230 are advertised. Note that since MSDP is a periodic protocol, an 231 implementation SHOULD send all cached SA messages when a connection 232 is established. Finally, the timer is deleted when the MSDP process 233 is de-configured. 235 5.3. SA Cache Timeout (SA-State Timer) 237 Each entry in an SA Cache has an associated SA-State Timer. A 238 (S,G)-SA-State-Timer is started when an (S,G)-SA message is initially 239 received by an MSDP peer. The timer is reset to [SG-State-Period] if 240 another (S,G)-SA message is received before the (S,G)-SA-State Timer 241 expires. [SG-State-Period] MUST NOT be less than [SA-Advertisement- 242 Period] + [SA-Hold-Down-Period]. 244 5.4. Peer Hold Timer 246 The Hold Timer is initialized to [HoldTime-Period] when the peer's 247 transport connection is established, and is reset to [HoldTime- 248 Period] when any MSDP message is received. Finally, the timer is 249 deleted when the peer's transport connection is closed. [HoldTime- 250 Period] MUST be at least three seconds. The recommended value for 251 [HoldTime-Period] is 75 seconds. 253 5.5. KeepAlive Timer 255 Once an MSDP transport connection is established, each side of the 256 connection sends a KeepAlive message and sets a KeepAlive timer. If 257 the KeepAlive timer expires, the local system sends a KeepAlive 258 message and restarts its KeepAlive timer. 260 The KeepAlive timer is set to [KeepAlive-Period] when the peer comes 261 up. The timer is reset to [KeepAlive-Period] each time an MSDP 262 message is sent to the peer, and reset when the timer expires. 264 Finally, the KeepAlive timer is deleted when the peer's transport 265 connection is closed. 267 [KeepAlive-Period] MUST be less than [HoldTime-Period], and MUST be 268 at least one second. The recommended value for [KeepAlive-Period] is 269 60 seconds. 271 5.6. ConnectRetry Timer 273 The ConnectRetry timer is used by the MSDP peer with the lower IP 274 address to transition from INACTIVE to CONNECTING states. There is 275 one timer per peer, and the [ConnectRetry-Period] SHOULD be set to 30 276 seconds. The timer is initialized to [ConnectRetry-Period] when an 277 MSDP speaker attempts to actively open a TCP connection to its peer 278 (see section 15, event E2, action A2 ). When the timer expires, the 279 peer retries the connection and the timer is reset to [ConnectRetry- 280 Period]. It is deleted if either the connection transitions into 281 ESTABLISHED state or the peer is de-configured. 283 6. Intermediate MSDP Peers 285 Intermediate MSDP speakers do not originate periodic SA messages on 286 behalf of sources in other domains. In general, an RP MUST only 287 originate an SA for a source which would register to it, and ONLY RPs 288 may originate SA messages. 290 7. SA Filtering and Policy 292 As the number of (S,G) pairs increases in the Internet, an RP may 293 want to filter which sources it describes in SA messages. Also, 294 filtering may be used as a matter of policy which at the same time 295 can reduce state. MSDP peers in transit domains should not filter SA 296 messages or the flood-and-join model can not guarantee that sources 297 will be known throughout the Internet (i.e., SA filtering by transit 298 domains may cause undesired lack of connectivity). In general, policy 299 should be expressed using MBGP [RFC2283]. This will cause MSDP 300 messages to flow in the desired direction and peer-RPF fail 301 otherwise. An exception occurs at an administrative scope [RFC2365] 302 boundary. In particular, a SA message for a (S,G) MUST NOT be sent to 303 peers which are on the other side of an administrative scope boundary 304 for G. 306 8. Encapsulated Data Packets 308 The RP MAY encapsulate multicast data from the source. An interested 309 RP may decapsulate the packet, which SHOULD be forwarded as if a PIM 310 register encapsulated packet was received. That is, if packets are 311 already arriving over the interface toward the source, then the 312 packet is dropped. Otherwise, if the outgoing interface list is non- 313 null, the packet is forwarded appropriately. Note that when doing 314 data encapsulation, an implementation MUST bound the time during 315 which packets are encapsulated. 317 This allows for small bursts to be received before the multicast tree 318 is built back toward the source's domain. For example, an 319 implementation SHOULD encapsulate at least the first packet to 320 provide service to bursty sources. 322 9. Other Scenarios 324 MSDP is not limited to deployment across different routing domains. 325 It can be used within a routing domain when it is desired to deploy 326 multiple RPs for the same group ranges such as with Anycast RP's. As 327 long as all RPs have a interconnected MSDP topology, each can learn 328 about active sources as well as RPs in other domains. 330 10. MSDP Peer-RPF Forwarding 332 The MSDP Peer-RPF Forwarding rules are used for forwarding SA 333 messages throughout an MSDP enabled internet. Unlike the RPF check 334 used when forwarding data packets, which generally compares the 335 packet's source address against the interface upon which the packet 336 was received, the Peer-RPF check compares the RP address carried in 337 the SA message against the MSDP peer from which the message was 338 received. 340 10.1. Definitions 342 The following definitions are used in the description of the Peer-RPF 343 Forwarding Rules: 345 10.1.1. Multicast RPF Routing Information Base (MRIB) 347 The MRIB is the multicast topology table. It is typically derived 348 from the unicast routing table or from other routing protocols such 349 as multi-protocol BGP [RFC2283]. 351 10.1.2. Peer-RPF Route 353 The Peer-RPF route is the route that the MRIB chooses for a given 354 address. The Peer-RPF route for a SA's originating RP is used to 355 select the peer from which the SA is accepted. 357 10.1.3. Peer-RPF Forwarding Rules 359 An SA message originated by R and received by X from N is accepted if 360 N is the peer-RPF neighbor for X, and is discarded otherwise. 362 MPP(R,N) MP(N,X) 363 R ---------....-------> N ------------------> X 364 SA(S,G,R) SA(S,G,R) 366 MP(N,X) is an MSDP peering between N and X. MPP(R,N) is an MSDP 367 peering path (zero or more MSDP peers) between R and N, e.g. MPP(R,N) 368 = MP(R, A) + MP(A, B) + MP(B, N). SA(S,G,R) is an SA message for 369 source S on group G originated by an RP R. 371 The peer-RPF neighbor N is chosen deterministically, using the first 372 of the following rules that matches. In particular, N is the RPF 373 neighbor of X with respect to R if 374 (i). N == R (X has an MSDP peering with R). 376 (ii). N is the eBGP NEXT_HOP of the Peer-RPF route for R. 378 (iii). The Peer-RPF route for R is learned through a 379 distance-vector or path-vector routing protocol 380 (e.g. BGP, RIP, DVMRP) and N is the neighbor that 381 advertised the Peer-RPF route for R (e.g. N is the iBGP 382 advertiser of the route for R), or N is the IGP next hop 383 for R if the route for R is learned via a link-state 384 protocol (e.g. OSPF [RFC2178] or IS-IS [RFC1142]). 386 (iv). N resides in the closest AS in the best path towards 387 R. If multiple MSDP peers reside in the closest AS, the 388 peer with the highest IP address is the rpf-peer. 390 (v). N is configured as the static RPF-peer for R. 392 MSDP peers, which are NOT in state ESTABLISHED (i.e., down peers), 393 are not eligible for peer RPF consideration. 395 10.2. MSDP mesh-group semantics 397 An MSDP mesh-group is a operational mechanism for reducing SA 398 flooding, typically in an intra-domain setting. In particular, when 399 some subset of a domain's MSDP speakers are fully meshed, they can be 400 configured into a mesh-group. 402 Note that mesh-groups assume that a member doesn't have to forward an 403 SA to other members of the mesh-group because the originator will 404 forward to all members. To be able for the originator to forward to 405 all members (and to have each member also be a potential originator), 406 the mesh-group must be a full mesh of MSDP peering among all members. 408 The semantics of the mesh-group are as follows: 410 (i). If a member R of a mesh-group M receives a SA message 411 from an MSDP peer that is also a member of mesh-group M, 412 R accepts the SA message and forwards it to all of its 413 peers that are not part of mesh-group M. R MUST NOT 414 forward the SA message to other members of mesh-group M. 416 (ii). If a member R of a mesh-group M receives an SA message 417 from an MSDP peer that is not a member of mesh-group M, 418 and the SA message passes the peer-RPF check, then R 419 forwards the SA message to all members of mesh-group M 420 and to any other msdp peers. 422 11. MSDP Connection State Machine 424 MSDP uses TCP as its transport protocol. In a peering relationship, 425 one MSDP peer listens for new TCP connections on the well-known port 426 639. The other side makes an active connect to this port. The peer 427 with the higher IP address will listen. This connection establishment 428 algorithm avoids call collision. Therefore, there is no need for a 429 call collision procedure. It should be noted, however, that the 430 disadvantage of this approach is that the startup time depends 431 completely upon the active side and its connect retry timer; the 432 passive side cannot cause the connection to be established. 434 An MSDP peer starts in the DISABLED state. MSDP peers establish 435 peering sessions according to the following state machine: 437 --------------->+----------+ 438 / | DISABLED |<---------- 439 | ------>+----------+ \ 440 | / |E1->A1 | 441 | | | | 442 | | V |E7->A7 443 | | +----------+ E3->A3 +--------+ 444 | | | INACTIVE |------->| LISTEN | 445 | | +----------+ +--------+ 446 | | E2->A2| ^ |E5->A5 447 | | | | | 448 | |E7->A6 V |E6 | 449 | \ +------------+ | 450 | ------| CONNECTING | | 451 | +------------+ | 452 E7->A8 | |E4->A4 | 453 E8->A8 | | | 454 E9->A8 | V | 455 \ +-------------+ / 456 --------------| ESTABLISHED |<--------- 457 +-------------+ 458 | ^ 459 | | 460 E10->A9 \______/ 462 11.1. Events 464 E1) Enable MSDP peering with P 465 E2) Own IP address < P's IP address 466 E3) Own IP address > P's IP address 467 E4) TCP established (active side) 468 E5) TCP established (passive side) 469 E6) ConnectRetry timer expired 470 E7) Disable MSDP peering with P (e.g. when one's own address is 471 changed) 472 E8) Hold Timer expired 473 E9) MSDP TLV format error detected 474 E10) Any other error detected 476 11.2. Actions 478 A1) Allocate resources for peering with P Compare one's own and 479 peer's IP addresses 480 A2) TCP active OPEN Set ConnectRetry timer to 481 [ConnectRetry-Period] 482 A3) TCP passive OPEN (listen) 483 A4) Delete ConnectRetry timer Send KeepAlive TLV 484 Set KeepAlive timer to [KeepAlive-Period] 485 Set Hold Timer to [HoldTime-Period] 486 A5) Send KeepAlive TLV 487 Set KeepAlive timer to [KeepAlive-Period] 488 Set Hold Timer to [HoldTime-Period] 489 A6) Abort TCP active OPEN attempt 490 Release resources allocated for peering with P 491 A7) Abort TCP passive OPEN attempt 492 Release resources allocated for peering with P 493 A8) Close the TCP connection 494 Release resources allocated for peering with P 495 A9) Drop the packet 497 11.3. Peer-specific Events 499 The following peer-specific events can occur in the ESTABLISHED 500 state, they do not cause a state transition. Appropriate actions are 501 listed for each event. 503 *) KeepAlive timer expired: 504 -> Send KeepAlive TLV 505 -> Set KeepAlive timer to [KeepAlive-Period] 506 *) KeepAlive TLV received: 507 -> Set Hold Timer to [HoldTime-Period] 508 *) Source-Active TLV received: 509 -> Set Hold Timer to [HoldTime-Period] 510 -> Run Peer-RPF Forwarding algorithm 511 -> Set KeepAlive timer to [KeepAlive-Period] for those peers 512 the Source-Active TLV is forwarded to 513 -> Send information to PIM-SM 514 -> Store information in cache 516 11.4. Peer-independent Events 518 There are also a number of events that affect more than one peering 519 session, but still require actions to be performed on a per-peer 520 basis. 522 *) SA-Advertisement-Timer expired: 523 -> Start periodic transmission of Source-Active TLV(s) 524 -> Set KeepAlive timer to [KeepAlive-Period] each time a 525 Source-Active TLV is sent 526 *) MSDP learns of a new active internal source (e.g. PIM-SM 527 register received for a new source): 528 -> Send Source-Active TLV 529 -> Set KeepAlive timer to [KeepAlive-Period] 530 *) SG-State-Timer expired (one timer per cache entry): 531 -> Implementation specific, typically mark the cache entry 532 for deletion 534 12. Packet Formats 536 MSDP messages are encoded in TLV format. If an implementation 537 receives a TLV that has length that is longer than expected, the TLV 538 SHOULD be accepted. Any additional data SHOULD be ignored and the 539 MSDP session should not be reset. 541 12.1. MSDP TLV format 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | Value .... | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Type (8 bits) 550 Describes the format of the Value field. 552 Length (16 bits) 553 Length of Type, Length, and Value fields in octets. 554 Minimum length required is 4 octets, except for 555 Keepalive messages. The maximum TLV length is 9192. 557 Value (variable length) 558 Format is based on the Type value. See below. The length of 559 the value field is Length field minus 3. All reserved fields 560 in the Value field MUST be transmitted as zeros and ignored on 561 receipt. 563 12.2. Defined TLVs 565 The following TLV Types are defined: 567 Code Type 568 =================================================== 569 1 IPv4 Source-Active 570 2 IPv4 Source-Active Request 571 3 IPv4 Source-Active Response 572 4 KeepAlive 573 5 Reserved (Previously: Notification) 575 Each TLV is described below. 577 In addition, the following TLV Types are assigned but not described 578 in this memo: 580 Code Type 581 ==================================================== 582 6 MSDP traceroute in progress 583 7 MSDP traceroute reply 585 12.2.1. IPv4 Source-Active TLV 587 The maximum size SA message that can be sent is 9192 octets. The 9192 588 octet size does not include the TCP, IP, layer-2 headers. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | 1 | x + y | Entry Count | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | RP Address | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Reserved | Sprefix Len | \ 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 599 | Group Address | ) z 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 601 | Source Address | / 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Type 605 IPv4 Source-Active TLV is type 1. 607 Length x 608 Is the length of the control information in the message. x is 609 8 octets (for the first two 32-bit quantities) plus 12 times 610 Entry Count octets. 612 Length y 613 If 0, then there is no data encapsulated. Otherwise an IPv4 614 packet follows and y is the value of the total length field 615 in the header of the encapsulated IP packet. If there are 616 multiple (S,G) entries in an SA message, only the last entry 617 may have encapsulated data and it must reflect the source and 618 destination addresses in the header of the encapsulated IP 619 packet. 621 Entry Count 622 Is the count of z entries (note above) which follow the RP 623 address field. This is so multiple (S,G)s from the same domain 624 can be encoded efficiently for the same RP address. An 625 SA message containing encapsulated data typically has an 626 entry count of 1 (i.e. only contains a single entry, for 627 the (S,G) representing the encapsulated packet). 629 RP Address 630 The address of the RP in the domain the source has become 631 active in. 633 Reserved 634 The Reserved field MUST be transmitted as zeros and MUST be 635 ignored by a receiver. 637 Sprefix Len 638 The route prefix length associated with source address. 639 This field MUST be transmitted as 32 (/32). 641 Group Address 642 The group address the active source has sent data to. 644 Source Address 645 The IP address of the active source. 647 Multiple (S,G) entries MAY appear in the same SA and can be batched 648 for efficiency at the expense of data latency. This would typically 649 occur on intermediate forwarding of SA messages. 651 12.2.2. KeepAlive TLV 653 A KeepAlive TLV is sent to an MSDP peer if and only if there were no 654 MSDP messages sent to the peer within [KeepAlive-Period] seconds. 655 This message is necessary to keep the MSDP connection alive. 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | 4 | 3 | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 The length of the message is 3 octets which encompasses the one octet 664 Type field and the two octet Length field. 666 13. MSDP Error Handling 668 If an MSDP message is received with a TLV format error, the session 669 SHOULD be reset with that peer. MSDP messages with other errors, such 670 as unrecognized type code, received from MSDP peers, SHOULD be 671 silently discarded and the session SHOULD not be reset. 673 14. SA Data Encapsulation 675 As discussed earlier, TCP encapsulation of data in SA messages MAY be 676 supported for backwards compatibility with legacy MSDP peers. 678 15. Applicability Statement 680 MSDP is used primarily in two deployment scenarios: 682 15.1. Between PIM Domains 684 MSDP can be used between PIM domains to convey information about 685 active sources available in other domains. MSDP peering used in such 686 cases is generally one to one peering, and utilizes the deterministic 687 peer-RPF rules described in this spec (i.e., does not use mesh- 688 groups). Peerings can be aggregated on a single MSDP peer, typically 689 from one to hundreds of peerings, similar in scale, although not 690 necessarily consistent, with BGP peerings. 692 15.2. Between Anycast-RPs 694 MSDP is also used between Anycast-RPs [RFC3446] within a PIM domain 695 to synchronize information about the active sources being served by 696 each Anycast-RP peer (by virtue of IGP reachability). MSDP peering 697 used in this scenario is typically based on MSDP mesh groups, where 698 anywhere from two to tens of peers can comprise a given mesh group, 699 although more than ten is not typical. One or more of these mesh- 700 group peers may then also have additional one-to-one peering with 701 msdp peers outside that PIM domain as described in scenario A, for 702 discovery of external sources. MSDP for anycast-RP without external 703 MSDP peering is a valid deployment option and common. 705 16. Intellectual Property 707 The IETF takes no position regarding the validity or scope of any 708 intellectual property or other rights that might be claimed to 709 pertain to the implementation or use of the technology described in 710 this document or the extent to which any license under such rights 711 might or might not be available; neither does it represent that it 712 has made any effort to identify any such rights. Information on the 713 IETF's procedures with respect to rights in standards-track and 714 standards-related documentation can be found in BCP-11. Copies of 715 claims of rights made available for publication and any assurances of 716 licenses to be made available, or the result of an attempt made to 717 obtain a general license or permission for the use of such 718 proprietary rights by implementors or users of this specification can 719 be obtained from the IETF Secretariat. 721 The IETF invites any interested party to bring to its attention any 722 copyrights, patents or patent applications, or other proprietary 723 rights which may cover technology that may be required to practice 724 this standard. Please address the information to the IETF Executive 725 Director. 727 17. Acknowledgments 729 The editors would like to thank the original authors, Dino Farinacci, 730 Yakov Rehkter, Peter Lothberg, Hank Kilmer, and Jermey Hall for their 731 original contribution to the MSDP specification. In addition, Bill 732 Nickless, John Meylor, Liming Wei, Manoj Leelanivas, Mark Turner, 733 John Zwiebel, Cristina Radulescu-Banu, Brian Edwards, Selina 734 Priestley, IJsbrand Wijnands, Tom Pusateri, Kristofer Warell, Henning 735 Eriksson, Thomas Eriksson, Dave Thaler, and Ravi Shekhar provided 736 useful and productive design feedback and comments. Mike McBride, 737 Leonard Giuliano, Swapna Yelamanchi, Toerless Eckert, John Meylor and 738 Ishan Wu contributed to the final version of the draft. 740 18. Security Considerations 742 An MSDP implementation MAY use IPsec [RFC2401] or MD5 to secure 743 control messages. In particular, the TCP connection between MSDP 744 peers MAY be secured using IPsec or MD5. Implementations MUST be 745 capable of working with peers which do not provide IPsec or MD5 746 security. SA Filters and limits should always be used with MSDP to 747 limit the sources and groups that will be passed between RPs. For 748 example, MSDP SA messages announcing the following (S,G) ranges that 749 SHOULD NOT be globally routed: 751 (*,224.0.1.2/32) SGI-Dogfight 752 (*,224.0.1.3/32) Rwhod 753 (*,224.0.1.22/32) SVRLOC 754 (*,224.0.1.22/32) Microsoft-DS 755 (*,224.0.1.35/32) SVRLOC-DA 756 (*,224.0.1.39/32) CISCO-RP-ANNOUNCE 757 (*,224.0.1.40/32) CISCO-RP-DISCOVERY 758 (*,224.0.2.2/32) SUN-RPC 759 (*,224.77.0.0/16) Norton Ghost 760 (*,224.128.0.0/24) Control plane of IGMP snoopers 761 (*,225.0.0.0/24) Control plane of IGMP snoopers 762 (*,225.1.2.3/32) Altiris 763 (*,225.128.0.0/24) Control plane of IGMP snoopers 764 (*,226.0.0.0/24) Control plane of IGMP snoopers 765 (*,226.77.0.0/16) Norton Ghost 766 (*,226.128.0.0/24) Control plane of IGMP snoopers 767 (*,227.0.0.0/24) Control plane of IGMP snoopers 768 (*,227.128.0.0/24) Control plane of IGMP snoopers 769 (*,228.0.0.0/24) Control plane of IGMP snoopers 770 (*,228.128.0.0/24) Control plane of IGMP snoopers 771 (*,229.0.0.0/24) Control plane of IGMP snoopers 772 (*,229.128.0.0/24) Control plane of IGMP snoopers 773 (*,230.0.0.0/24) Control plane of IGMP snoopers 774 (*,230.128.0.0/24) Control plane of IGMP snoopers 775 (*,231.0.0.0/24) Control plane of IGMP snoopers 776 (*,231.128.0.0/24) Control plane of IGMP snoopers 777 (*,232.0.0.0/24) Control plane of IGMP snoopers 778 (*,232.128.0.0/24) Control plane of IGMP snoopers 779 (*,233.0.0.0/8) Source-Specific Multicast 780 (*,233.0.0.0/24) Control plane of IGMP snoopers 781 (*,233.128.0.0/24) Control plane of IGMP snoopers 782 (*,234.0.0.0/24) Control plane of IGMP snoopers 783 (*,234.42.42.42/32) Phoenix/StorageSoft ImageCast 784 (*,234.128.0.0/24) Control plane of IGMP snoopers 785 (*,234.142.142.42/31) Phoenix/StorageSoft ImageCast 786 (*,234.142.142.44/30) Phoenix/StorageSoft ImageCast 787 (*,234.142.142.48/28) Phoenix/StorageSoft ImageCast 788 (*,234.142.142.64/26) Phoenix/StorageSoft ImageCast 789 (*,234.142.142.128/29) Phoenix/StorageSoft ImageCast 790 (*,234.142.142.136/30) Phoenix/StorageSoft ImageCast 791 (*,234.142.142.140/31) Phoenix/StorageSoft ImageCast 792 (*,234.142.142.142/32) Phoenix/StorageSoft ImageCast 793 (*,235.0.0.0/24) Control plane of IGMP snoopers 794 (*,235.128.0.0/24) Control plane of IGMP snoopers 795 (*,236.0.0.0/24) Control plane of IGMP snoopers 796 (*,236.128.0.0/24) Control plane of IGMP snoopers 797 (*,237.0.0.0/24) Control plane of IGMP snoopers 798 (*,237.128.0.0/24) Control plane of IGMP snoopers 799 (*,238.0.0.0/24) Control plane of IGMP snoopers 800 (*,238.128.0.0/24) Control plane of IGMP snoopers 801 (*,239.0.0.0/8) Administratively Scoped Groups 802 (*,239.0.0.0/24) Control plane of IGMP snoopers 803 (*,239.128.0.0/24) Control plane of IGMP snoopers 805 19. IANA Considerations 807 This document defines seven MSDP TLV values. Values for new MSDP TLV 808 types are to be allocated using an IESG Approval or Standards Action 809 processes. The policy for assigning new MSDP TLV values SHOULD BE 810 defined in the document defining the new TLV values. 812 20. References 814 20.1. Normative References 816 [RFC1142] Oran, D. "OSI IS-IS Intra-domain Routing 817 Protocol", RFC 1142, February 1990. 819 [RFC2178] Moy, J., "OSPF Version 2", RFC 2178, April, 1998. 821 [RFC2283] Bates, T., Chandra, R., Katz, D., and 822 Y. Rekhter., "Multiprotocol Extensions for 823 BGP-4", RFC 2283, February 1998. 825 [RFC2362] Estrin D., et al., "Protocol Independent 826 Multicast - Sparse Mode (PIM-SM): Protocol 827 Specification", RFC 2362, June 1998. 829 [RFC2365] Meyer, D. "Administratively Scoped IP Multicast", 830 RFC 2365, July, 1998. 832 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture 833 for the Internet Protocol", RFC 2401, November 1998. 835 [RFC3446] Kim, D., et al., "Anycast Rendezvous Point (RP) 836 Mechanism using Protocol Independent Multicast 837 (PIM) and Multicast Source Discovery Protocol 838 (MSDP)", RFC 3446, January, 2003. 840 20.2. Informative References 842 [RFC2119] S. Bradner, "Key words for use in RFCs to 843 Indicate Requirement Levels", RFC 2119, March, 844 1997. 846 21. Editor's Addresses 848 Bill Fenner 849 AT&T Labs -- Research 850 75 Willow Road 851 Menlo Park, CA 94025 852 Email: fenner@research.att.com 854 David Meyer 855 Email: dmm@maoz.com 857 22. Full Copyright Statement 859 Copyright (C) The Internet Society (2003). All Rights Reserved. 861 This document and translations of it may be copied and furnished to 862 others, and derivative works that comment on or otherwise explain it 863 or assist in its implementation may be prepared, copied, published 864 and distributed, in whole or in part, without restriction of any 865 kind, provided that the above copyright notice and this paragraph are 866 included on all such copies and derivative works. However, this 867 document itself may not be modified in any way, such as by removing 868 the copyright notice or references to the Internet Society or other 869 Internet organizations, except as needed for the purpose of 870 developing Internet standards in which case the procedures for 871 copyrights defined in the Internet Standards process must be 872 followed, or as required to translate it into languages other than 873 English. 875 The limited permissions granted above are perpetual and will not be 876 revoked by the Internet Society or its successors or assigns. 878 This document and the information contained herein is provided on an 879 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 880 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 881 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 882 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 883 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.