idnits 2.17.00 (12 Aug 2021) /tmp/idnits63381/draft-ietf-msdp-spec-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. Found some kind of copyright notice around line 47 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2022-05-20) 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) 2022 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 48 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** 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 120: '... implementation SHOULD forward an SA ...' RFC 2119 keyword, line 147: '...,G) state, an RP SHOULD cache SA messa...' RFC 2119 keyword, line 162: '...e. The SA Advertisement Period MUST be...' RFC 2119 keyword, line 174: '...ing MSDP speaker SHOULD NOT forward a ...' RFC 2119 keyword, line 176: '... SHOULD be set 30 seconds....' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 310 has weird spacing: '... change or |...' == Line 702 has weird spacing: '...cluding this ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '2' is defined on line 803, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 813, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 817, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2362 (ref. '1') (Obsoleted by RFC 4601, RFC 5059) == 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-09 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. '6') == Outdated reference: A later version (-06) exists of draft-ietf-msdp-traceroute-00 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: draft-ietf-mboned-anycast-rp has been published as RFC 3446 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-anycast-rp (ref. '8') -- No information found for draft-ietf-meyer-gre-update - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 1825 (ref. '11') (Obsoleted by RFC 2401) ** Downref: Normative reference to an Historic RFC: RFC 1828 (ref. '12') Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dino Farinacci 2 INTERNET DRAFT Procket Networks 3 Yakov Rekhter 4 David Meyer 5 Cisco Systems 6 Peter Lothberg 7 Sprint 8 Hank Kilmer 9 Jeremy Hall 10 UUnet 12 Category Standards Track 13 Decemeber, 1999 15 Multicast Source Discovery Protocol (MSDP) 16 18 1. Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC Internet-Drafts. 23 2026 are working documents of the Internet Engineering Task Force 24 (IETF), its areas, and its working groups. Note that other groups 25 may also distribute working documents as Internet- Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The Multicast Source Discovery Protocol, MSDP, describes a mechanism 41 to connect multiple PIM-SM domains together. Each PIM-SM domain uses 42 it's own independent RP(s) and do not have to depend on RPs in other 43 domains. 45 2. Copyright Notice 47 Copyright (C) The Internet Society (1999). All Rights Reserved. 49 3. Introduction 51 The Multicast Source Discovery Protocol, MSDP, describes a mechanism 52 to connect multiple PIM-SM domains together. Each PIM-SM domain uses 53 its own independent RP(s) and does not have to depend on RPs in other 54 domains. 56 Advantages of this approach include: 58 3.1. No Third-party resource dependencies on RP 60 PIM-SM domains can rely on their own RPs only. 62 3.2. Receiver only Domains 64 Domains with only receivers get data without globally advertising 65 group membership. 67 3.3. Global Source State 69 Global source state is not required, since a router need not cache 70 Source Active (SA) messages (see below). MSDP is a periodic protocol. 72 4. Overview 74 An RP (or other MSDP SA originator) in a PIM-SM domain will have a 75 MSDP peering relationship with an RP in another domain. The peering 76 relationship will be made up of a TCP connection in which control 77 information is primarily exchanged. Each domain will have a 78 connection to this virtual topology. 80 The purpose of this topology is to have domains discover multicast 81 sources from other domains. If the multicast sources are of interest 82 to a domain which has receivers, the normal source-tree building 83 mechanism in PIM-SM will be used to deliver multicast data over an 84 inter-domain distribution tree. 86 We envision this virtual topology will essentially be congruent to 87 the existing BGP topology used in the unicast-based Internet today. 88 That is the TCP connections between RPs can be realized by the 89 underlying BGP routing system. 91 5. Procedure 93 A source in a PIM-SM domain originates traffic to a multicast group. 94 The PIM DR which is directly connected to the source sends the data 95 encapsulated in a PIM Register message to the RP in the domain. 97 The RP will construct a "Source-Active" (SA) message and send it to 98 its MSDP peers. The SA message contains the following fields: 100 o Source address of the data source. 101 o Group address the data source sends to. 102 o IP address of the RP. 104 Each MSDP peer receives and forwards the message away from the RP 105 address in a "peer-RPF flooding" fashion. The notion of peer-RPF 106 flooding is with respect to forwarding SA messages. The BGP routing 107 table is examined to determine which peer is the next hop towards the 108 originating RP of the SA message. Such a peer is called an "RPF 109 peer". See the section on "MSDP Peer-RPF Forwarding" for more 110 details. 112 If the MSDP peer receives the SA from a non-RPF peer towards the 113 originating RP, it will drop the message. Otherwise, it forwards the 114 message to all it's MSDP peers. 116 The flooding can be further constrained to children of the peer by 117 interrogating BGP reachability information. That is, if a BGP peer 118 advertises a route (back to you) and you are the next to last AS in 119 the AS-path, the peer is using you as the next-hop. In this case, an 120 implementation SHOULD forward an SA message (which was originated 121 from the RP address covered by that route) to the peer. This is known 122 in other circles as Split-Horizon with Poison Reverse. 124 When an MSDP peer which is also an RP for its own domain receives an 125 SA message, it determines if it has any group members interested in 126 the group which the SA message describes. That is, the RP checks for 127 an (*,G) entry with a non-empty outgoing interface list; this implies 128 that the domain is interested in the group. In this case, the RP 129 triggers an (S,G) join event towards the data source as if a 130 Join/Prune message was received addressed to the RP itself (See [1] 131 Section 3.2.2). This sets up a branch of the source-tree to this 132 domain. Subsequent data packets arrive at the RP which are forwarded 133 down the shared-tree inside the domain. If leaf routers choose to 134 join the source-tree they have the option to do so according to 135 existing PIM-SM conventions. Finally, if an RP in a domain receives 136 a PIM Join message for a new group G, and it is caching SA's, then 137 the RP should trigger an (S,G) join event for each SA for that group 138 in its cache. 140 This procedure has been affectionately named flood-and-join because 141 if any RP is not interested in the group, they can ignore the SA 142 message. Otherwise, they join a distribution tree. 144 6. Controlling State 146 While RPs which receive SA messages are not required to keep MSDP 147 (S,G) state, an RP SHOULD cache SA messages by default. The advantage 148 of caching is that newly formed MSDP peers can get MSDP (S,G) state 149 sooner and therefore reduce join latency for new joiners. In 150 addition, caching greatly aids in diagnosis and debugging of various 151 problems. 153 6.1. Timers 155 The main timers for MSDP are: SA Advertisement period, SA Hold-down 156 period, the SA Cache timeout period, KeepAlive, HoldTimer, and 157 ConnectRetry. Each is described below. 159 6.1.1. SA Advertisement Period 161 RPs which originate SA messages do it periodically as long as there 162 is data being sent by the source. The SA Advertisement Period MUST be 163 60 seconds. An RP will not send more than one SA message for a given 164 (S,G) within an SA Advertisment period. Originating periodic SA 165 messages is important so that new receivers who join after a source 166 has been active can get data quickly via the receiver's own RP when 167 it is not caching SA state. Finally, if an RP in a domain receives a 168 PIM Join message for a new group G, and it is caching SAs, then the 169 RP should trigger an (S,G) join for each SA for that group in its 170 cache. 172 6.1.2. SA Hold-down Period 174 A caching MSDP speaker SHOULD NOT forward a SA message it has 175 received in the last SA-Hold-down period. The SA-Hold-down period 176 SHOULD be set 30 seconds. 178 6.1.3. SA Cache Timeout 180 A caching MSDP speaker times out it's SA cache at SA-State-Timer. 181 The SA-State-Timer MUST NOT be less than 90 seconds minutes. 183 6.1.4. KeepAlive, HoldTimer, and ConnectRetry 185 The KeepAlive, HoldTimer, and ConnectRetry timers are defined in 186 RFC1771 [3]. 188 6.2. Intermediate MSDP Speakers 190 Intermediate RPs do not originate periodic SA messages on behalf of 191 sources in other domains. In general, an RP MUST only originate an SA 192 for its own sources. 194 6.3. SA Filtering 196 As the number of (S,G) pairs increases in the Internet, an RP may 197 want to filter which sources it describes in SA messages. Also, 198 filtering may be used as a matter of policy which at the same time 199 can reduce state. Only the RP colocated in the same domain as the 200 source can restrict SA messages. Other MSDP peers in transit domains 201 should not filter or the flood-and-join model does not guarantee that 202 sources will be known throughout the Internet. An exception occurs at 203 an administrative scope [13] boundary. In particular, a SA message 204 for an (S,G) MUST NOT be sent to peers which are on the other side of 205 an administrative scope boundary for G. 207 6.4. Caching 209 If an MSDP peer decides to cache SA state, it may accept SA-Requests 210 from other MSDP peers. When a MSDP peer receives an SA-Request for a 211 group range, it will respond to the peer with a set of SA entries, in 212 a SA-Response message, for all active sources sending to the group 213 range requested in the SA-Request message. The peer that sends the 214 request will not flood the responding SA-Response message to other 215 peers. 217 If an implementation receives an SA-Request message and is not 218 caching SA messages, it sends a notification with Error code 7 219 subcode 1, as defined in section 11.2.7. 221 7. Encapsulated Data Packets 223 For bursty sources, the RP may encapsulate multicast data from the 224 source. An interested RP may decapsulate the packet, which SHOULD be 225 forwarded as if a PIM register encapsulated packet was received. That 226 is, if packets are already arriving over the interface toward the 227 source, then the packet is dropped. Otherwise, if the outgoing 228 interface list is non-null, the packet is forwarded appropriately. 229 Note that when doing data encapsulation, an implementation MUST bound 230 the number of packets from the source which are encapsulated. 232 This allows for small bursts to be received before the multicast tree 233 is built back toward the source's domain. For example, an 234 implementation SHOULD encapsulate at least the first packet to 235 provide service to bursty sources. 237 Finally, if an implementation supports an encapsulation of SA data 238 other than default TCP encapsulation, then it MUST support GRE 239 encapsulation. In addition, an implementation MUST learn about not 240 TCP encapsulations via capability advertisment (see section 11.2.5). 242 8. Other Scenarios 244 MSDP is not limited to deployment across different routing domains. 245 It can be used within a routing domain when it is desired to deploy 246 multiple RPs for different group ranges. As long as all RPs have a 247 interconnected MSDP topology, each can learn about active sources as 248 well as RPs in other domains. Another example is the Anycast RP 249 mechanism [8]. 251 9. MSDP Peer-RPF Forwarding 253 The MSDP Peer-RPF Forwarding rules are used for forwarding SA 254 messages throughout an MSDP enabled internet. An SA message 255 originated by a MSDP originator R and received by a MSDP router from 256 MSDP peer N in AS A is accepted if any of the following are true: 258 (i). If N is R. 260 (ii). If A is the first AS in the AS-Path of the BGP 261 route towards R. 263 (iii). If N is the iBGP advertiser of the BGP route 264 towards R. 266 (iv). If N is the MSDP default-peer. 268 If none of the conditions above is met, the SA message is discarded. 269 This is the case where the SA message was received on a redundant 270 MSDP peering path. 272 Note that these rules are evaluated in the order shown here. This 273 selects a "peer-RPF neighbor" for the SA message, and allows for the 274 construction of diagnostic tools such as MSDP-traceroute [7]. 276 9.1. MSDP default-peer semantics 278 A MSDP default-peer is much like a default route. It is intended to 279 be used in those cases where a stub network isn't running BGP or 280 MBGP. In this case, the MSDP speaker accepts all SA messages from the 281 default-peer. Of course, if multiple default peers are configured, 282 the possibility of looping exists, so care must be taken. Finally, a 283 router running BGP or multiprotol BGP [4] SHOULD NOT allow 284 configuration of default peers. 286 10. MSDP Connection Establishment 288 MSDP speakers establish peering sessions according to the following 289 state machine: 291 Deconfigured or 292 disabled 293 +-------------------------------------------+ 294 | | 295 +-----|--------->+----------+ | 296 | | +->| INACTIVE |----------------+ | 297 | | | +----------+ | | 298 Deconf'ed | | | /|\ /|\ | Timer + Higher Address 299 or | | | | | | | 300 disabled | | | | | \|/ | 301 | | | | | | +-------------+ 302 | | | | | +---------------| CONNNECTING | 303 | | | | | Timeout or +-------------+ 304 | | | | | Router ID Change | 305 \|/ \|/ | | | | 306 +----------+ | | | | 307 | DISABLED | | | +---------------------+ | TCP Established 308 +----------+ | | | | 309 /|\ /|\ | | Connection Timeout or | | 310 | | | | Router ID change or | | 311 | | | | Authorization Failure | | 312 | | | | | | 313 | | | | | \|/ 314 | | | | +-------------+ 315 | | Router ID | | Timer + | ESTABLISHED | 316 | | Change | | Low Addresss +-------------+ 317 | | | \|/ /|\ | 318 | | | +--------+ | | 319 | | +--| LISTEN |--------------------+ | 320 | | +--------+ TCP Accept | 321 | | | | 322 | | | | 323 | +---------------+ | 324 | Deconfigured or | 325 | disabled | 326 | | 327 +------------------------------------------------------+ 328 Deconfigured or 329 disabled 331 11. Packet Formats 333 MSDP messages will be encapsulated in a TCP connection using well- 334 known port 639. One side of the MSDP peering relationship will listen 335 on the well-known port and the other side will do an active connect 336 on the well-known port. The side with the higher IP address will do 337 the listen. This connection establishment algorithm avoids call 338 collision. Therefore, there is no need for a call collision 339 procedure. It should be noted, however, that the disadvantage of this 340 approach is that it may result in longer startup times at the passive 341 end. 343 Finally, if an implementation receives a TLV that has length that is 344 longer than expected, the TLV SHOULD be accepted. Any additional data 345 SHOULD be ignored. 347 11.1. MSDP messages will be encoded in TLV format: 349 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | Value .... | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Type (8 bits) 356 Describes the format of the Value field. 358 Length (16 bits) 359 Length of Type, Length, and Value fields in octets. Minimum 360 length required is 3 octets. 362 Value (variable length) 363 Format is based on the Type value. See below. The length of 364 the value field is Length field minus 3. 366 11.2. The following TLV Types are defined: 368 Code Type 369 ================================================================ 370 1 IPv4 Source-Active 371 2 IPv4 Source-Active Request 372 3 IPv4 Source-Active Response 373 4 KeepAlive 374 5 Encapsulation Capability Advertisement 375 6 Encapsulation Capability Request 376 7 Notification 377 8 GRE Encapsulation 379 Each TLV is described below. 381 11.2.1. IPv4 Source-Active TLV 383 The maximum size SA message that can be sent is 1400 bytes. If an 384 MSDP peer needs to originate a message with information greater than 385 1400 bytes, it sends successive 1400-byte messages. The 1400 byte 386 size does not include the TCP, IP, layer-2 headers. 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | 1 | x + y | Entry Count | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | RP Address | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Reserved | Gprefix Len | Sprefix Len | \ 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 396 | Group Address Prefix | ) z 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 398 | Source Address Prefix | / 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Type 402 IPv4 Source-Active TLV is type 1. 404 Length x 405 Is the length of the control information in the message. x is 406 8 octets (for the first two 32-bit quantities) plus 12 times 407 Entry Count octets. 409 Length y 410 If 0, then there is no data encapsulated. Otherwise an IPv4 411 packet follows and y is the length of the total length field 412 of the IPv4 header encapsulated. If there are multiple SA TLVs 413 in a message, and data is also included, y must be 0 in all SA 414 TLVs except the last one. And the last SA TLV must reflect the 415 source and destination addresses in the IP header of the 416 encapsulated data. 418 Entry Count 419 Is the count of z entries (note above) which follow the RP 420 address field. This is so multiple (S,G)s from the same domain 421 can be encoded efficiently for the same RP address. 423 RP Address 424 The address of the RP in the domain the source has become 425 active in. 427 Gprefix Len and Sprefix Len 428 The route prefix length associated with the group address 429 prefix and source address prefix, respectively. 431 Group Address Prefix 432 The group address the active source has sent data to. 434 Source Address Prefix 435 The route prefix associated with the active source. 437 Multiple SA TLVs MAY appear in the same message and can be batched 438 for efficiency at the expense of data latency. This would typically 439 occur on intermediate forwarding of SA messages. 441 11.2.2. IPv4 Source-Active Request TLV 443 Used to request SA-state from a caching MSDP peer. If an RP in a 444 domain receives a PIM Join message for a group, creates (*,G) state 445 and wants to know all active sources for group G, and it has been 446 configured to peer with an SA-state caching peer, it may send an SA- 447 Request message for the group. 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | 2 | 8 | Gprefix Len | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Group Address Prefix | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Type 457 IPv4 Source-Active Request TLV is type 2. 459 Gprefix Len 460 The route prefix length associated with the group address prefix. 462 Group Address Prefix 463 The group address prefix the MSDP peer is requesting. 465 11.2.3. IPv4 Source-Active Response TLV 467 Sent in response to a Source-Active Request message. The Source- 468 Active Response message has the same format as a Source-Active 469 message but does not allow encapsulation of multicast data. 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | 3 | x | .... | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Type 477 IPv4 Source-Active Response TLV is type 3. 479 Length x 480 Is the length of the control information in the message. x is 8 481 octets (for the first two 32-bit quantities) plus 12 times Entry 482 Count octets. 484 11.2.4. KeepAlive TLV 486 Sent to an MSDP peer if and only if there were no MSDP messages sent 487 to the peer after a period of time. This message is necessary for the 488 active connect side of the MSDP connection. The passive connect side 489 of the connection knows that the connection will be reestablished 490 when a TCP SYN packet is sent from the active connect side. However, 491 the active connect side will not know when the passive connect side 492 goes down. Therefore, the KeepAlive timeout will be used to reset the 493 TCP connection. 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | 4 | 3 | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 The length of the message is 3 bytes which encompasses the 1-byte 501 Type field and the 2-byte Length field. 503 11.2.5. Encapsulation Capability Advertisement TLV 505 This TLV implements encapsulation capability advertisement. This TLV 506 is sent by an MSDP speaker to advertise its ability to receive data 507 packets encapsulated as described by the TLV (in addition to the 508 default TCP encapsulation). 510 A MSDP speaker receiving this TLV can choose to either default TCP 511 encapsulation, or may send a IPv4 Encapsulation Request to change to 512 the advertised encapsulation type. 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | 5 | 8 | ENCAP_TYPE | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Source Port | Reserved | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Type 522 IPv4 Encapsulation Advertisement TLV is type 5. 524 Length 525 Length is a two byte field with value 8. 527 ENCAP_TYPE 528 The following data encapsulation types are defined for MSDP: 530 Value Meaning 531 ------------------------------------- 532 0 TCP Encapsulation 534 1 UDP Encapsulation [10] 536 2 GRE Encapsulation [9] 538 Soure Port 539 Port for use by the requester. 541 Note that since the TLV does not carry endpoint addresses for the GRE 542 or UDP tunnels, an implementation using these encapsulations MUST use 543 the endpoints that are used for the MSDP peering. 545 11.2.6. Encapsulation Capability Request TLV 547 This TLV implements encapsulation capability request. This TLV should 548 be sent in response to a capability advertisement. 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | 6 | 4 | ENCAP_TYPE | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Type 556 IPv4 Encapsulation Request TLV is type 6. 558 Length 559 Length is a two byte field with value 4. 561 ENCAP_TYPE 562 ENCAP_TYPE is described above. 564 A requester MAY also provide a source port, in which case 565 the TLV has the following form: 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | 6 | 8 | ENCAP_TYPE | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Source Port | Reserved | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 11.2.7. NOTIFICATION TLV 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | 7 | x + 5 | Error Code | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Error subcode | ... | 581 +-+-+-+-+-+-+-+-+ | 582 | Data | 583 | ... | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Type 587 The Notification TLV is type 7. 589 Length 590 Length is a two byte field with value x + 5, where x is 591 the length of the notification data field. 593 Error code 594 See [3]. In addition, Error code 7 indicates an 595 a SA-Request Error. 597 Error subcode 598 See [3]. In addition, Error code 7 subcode 1 indicates 599 the receipt of a SA-Request message by a non-caching 600 MSDP speaker. 602 Data 603 See [3]. In addition, for Error code 7 subcode 1 (receipt of 604 a SA-Request message by a non-caching MSDP speaker), the TLV 605 has the follwing form: 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | 7 | 20 | 7 | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | 1 | Reserved | Gprefix Len | Sprefix Len | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Advertising RP Address | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Group Address Prefix | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Source Address Prefix | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 See [3] for NOTIFICATION error handling. 622 11.2.8. Encapsulation Capability State Machine 624 The active connect side of an MSDP peering SHALL begin in ADVERTISING 625 state, and the passive side of the TCP connection begins in DEFAULT 626 state. This will cause the state machine to behave deterministically. 628 +-------+ 629 | | Receive TLV which isn't 630 | | understood or 631 | | Receive Request (TLV 6) or 632 | | Receive Advertisement (TLV 5) 633 \|/ | that isn't understood 634 +---------+----+ 635 | DEFAULT |----------------+ 636 +---------+ | 637 | 638 +-------------+ | 639 | ADVERTISING | | 640 +-------------+ | 641 | | 642 Timeout +--------+ | | 643 +-------->| FAILED | | Send Advertisement | Receive Advertisement 644 | +--------+ | (TLV 5) | (TLV 5) 645 | | | 646 | | | 647 | | | 648 | | | 649 | Receive non-matching | | 650 | Request (TLV 6) | | 651 | +----+ | | 652 | | | | | 653 | | | | | 654 | | \|/ | \|/ 655 | | +------+ | +----------+ 656 | +-| SENT |<-------------+ | RECEIVED | 657 +---+------+ +----------+ 658 | \|/ 659 | | 660 | Receive matching | Send matching 661 | Request (TLV 6) | Request (TLV 6) 662 | +--------+ | 663 +------------>| AGREED |<------------------+ 664 +--------+ 666 Note that if an advertiser transitions into the FAILED state, it 667 SHOULD assume that it has an old-style peer which can only support 668 TCP encapsulation. If an implementation wishes to be backwardly 669 compatible, it SHOULD support TCP encapsulation. In addition, a 670 requester in any state other than AGREED MUST only encapsulate data 671 in the TCP stream. 673 11.2.9. UDP Data Encapsulation 675 When using UDP encapsulation, the UDP psuedo-header has the following 676 form: 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Source Port | Dest Port | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Length | Checksum | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Origin RP Address | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 o Source Port 689 When using UDP encapsulation, a capability requester 690 uses the advertiser's Source Port as its destination 691 port. The advertiser MUST provide a Source Port. 693 o Destination Port 695 When using UDP encapsulation, a capability advertiser 696 uses the well known port 639 as the destination port. 697 A capability requester MUST listen on this well-known 698 port. The requester MAY provide a Source Port in it's 699 reply to the advertiser. 701 o Length is the length in octets of this user datagram 702 including this header and the data. The minimum value 703 of the length is twelve. 705 o Checksum is computed according to RFC768 [10]. 707 o Originating RP Address is the address of the RP sending 708 the encapsulated data. 710 11.2.10. GRE Encapsulation TLV 712 A TLV is defined to describe GRE encapsulated data packets. The TLV 713 has the following form: 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | 8 | 8 + x | Reserved | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Originating RP IPv4 Address | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | (S,G) Data Packet .... 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Type 725 GRE encapsulated data packet TLV is type 8. 727 Length 728 Length is a two byte field with value 8 + x, where 729 x is the length of the (S,G) Data packet. 731 The entire GRE header, then, will have the following form: 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Delivery Headers ..... | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 |C| Reserved | Ver | Protocol Type |\ 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header 739 | Checksum (optional) | Reserved |/ 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 741 | 8 | 8 + x | Reserved | \ 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload 743 | Originating RP IPv4 Address | / 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 745 | (S,G) Data Packet .... . 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 11.3. MTU Exeeded 750 If the outbound link MTU is execeeded by the newly encapsulated 751 packet, the packet SHOULD be dropped. 753 12. Security Considerations 755 A MSDP implementation MAY use IPsec [11] or keyed MD5 [12] to secure 756 control messages. Encapsulated data packets rely on the underlying 757 security model. 759 13. Acknowledgments 761 The authors would like to thank Dave Thaler, Bill Fenner, Bill 762 Nickless, John Meylor, Liming Wei, Manoj Leelanivas, Mark Turner, and 763 John Zwiebel for their design feedback and comments. 765 14. Author's Address: 767 Dino Farinacci 768 Procket Networks 769 Email: dino@procket.com 771 Yakov Rehkter 772 Cisco Systems, Inc. 773 170 Tasman Drive 774 San Jose, CA, 95134 775 Email: yakov@cisco.com 777 David Meyer 778 Cisco Systems, Inc. 779 170 Tasman Drive 780 San Jose, CA, 95134 781 Email: dmm@cisco.com 783 Peter Lothberg 784 Sprint 785 VARESA0104 786 12502 Sunrise Valley Drive 787 Reston VA, 20196 788 Email: roll@sprint.net 790 Hank Kilmer 791 Email: hank@rem.com 792 Jeremy Hall 793 UUnet Technologies 794 3060 Williams Drive 795 Fairfax, VA 22031 796 Email: jhall@uu.net 798 15. REFERENCES 800 [1] Estrin D., et al., "Protocol Independent Multicast - Sparse Mode 801 (PIM-SM): Protocol Specification", RFC 2362, June 1998. 803 [2] Thaler, D., Estrin, D., Meyer, D., "Border Gateway Multicast Protocol 804 (BGMP): Protocol Specification", draft-ietf-idmr-gum-01.txt, 805 October 30, 1997. 807 [3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 808 RFC 1771, March 1995. 810 [4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter., "Multiprotocol 811 Extensions for BGP-4", RFC 2283, February 1998. 813 [5] Deering, S., "Multicast Routing in a Datagram Internetwork", PhD 814 thesis, Electric Engineering Dept., Stanford University, December 815 1991. 817 [6] Pusateri, T., "Distance Vector Multicast Routing Protocol", 818 draft-ietf-idmr-dvmrp-v3-09.txt, October 1997. 820 [7] Meyer, et. al, "MSDP Traceroute", 821 draft-ietf-msdp-traceroute-00.txt, November, 1999. 823 [8] Meyer, et. al, "Anycast RP mechanism using PIM and MSDP", 824 draft-ietf-mboned-anycast-rp-04.txt, November, 1999. 826 [9] Farinacci, D., at el., "Generic Routing Encapsulation (GRE)", 827 draft-ietf-meyer-gre-update-01.txt, December, 1999. 829 [10] Postel, J. "User Datagram Protocol", RFC768, August, 1980. 831 [11] Atkinson, R., "Security architecture for the internet protocol", 832 RFC1825, August, 1995. 834 [12] P. Metzger and W. Simpson, "IP Authentication using Keyed 835 MD5", RFC 1828, August, 1995. 837 [13] Meyer, D. "Administratively Scoped IP Multicast", RFC2365, 838 July, 1998.