idnits 2.17.00 (12 Aug 2021) /tmp/idnits51483/draft-keyur-amap-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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 17 longer pages, the longest (page 4) being 81 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 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 163 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 178 instances of lines with control characters in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 124 -- Looks like a reference, but probably isn't: '8' on line 739 == Unused Reference: 'PIM-SM' is defined on line 1159, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-SM' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. 'Han94a') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. 'Han94b') Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keyur Patel 2 Internet Draft Cisco Systems 3 Expiration Date: April 2004 Radia Perlman 4 Sun Microsystems 5 Dino Farinacci 6 Greg Shepherd 7 Procket Networks 8 Marshall Eubanks 9 Multicast Technologies 11 Automatic Multicast Access Protocol 13 draft-keyur-amap-00.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 This document describes a new multicast signaling protocol for 39 solving the "last-mile connectivity" problem for multicast. This 40 protocol is called Automatic Multicast Access Protocol (AMAP). It 41 is intended to facilitate an endnode that resides in a portion of 42 the Internet infrastructure without multicast support, or whose OS 43 does not support IGMPv3 (SSM stype groups). 45 3. Introduction 47 An impediment to getting end-to-end multicast connectivity is that, 48 currently, ISPs seldom enable multicast routing within an entire 49 AS. This makes end-to-end multicast content provision difficult, 50 particularly with respect to Last Mile Multicast. 52 This document proposes a new multicast signaling protocol known as 53 Automatic Multicast Access Protocol (AMAP) which allows endnodes 54 residing in portions of the Internet infrastucture without any 55 multicast support to join multicast groups. AMAP allows endnodes 56 which run multicast applications to get the efficiencies of a 57 multicast enabled infrastructure without being directly attached 58 to such an infrastructure. This is achieved using a tunneling mechanism. 59 As the multicast infrastructure deployment moves towards the edge of 60 the network, the tunnel diameter is reduced to a point where it is 61 either minimised or no longer needed. 63 AMAP could be used for both SSM as well as ASM style multicast. 64 For endnodes residing in a portion of the Internet without any support 65 for multicast, this mechanism could be used for ASM groups by using 66 a Replicator address in place of an explicit root address. A 67 Replicator address is an address of a router which serves as a tunnel 68 endpoint for all/set of receivers within an AS. A well known anycast 69 address, which is a valid unicast address assigned to multiple routers 70 to get "closest replicator capability" defined by IANA, can be used as 71 a Replicator address within an AS. 73 Any router that does not support this protocol will simply unicast 74 forward the messages according to the rules for forwarding a packet with 75 the Router Alert set. The first multicast capable router that supports 76 AMAP will notice these messages and may form a tunnel with the endnode 77 that generated the message. 79 4. AMAP Messages 81 This section defines different message formats for AMAP. AMAP messages 82 are sent unicast to a particular source or an endnode, or towards a 83 Replicator address. AMAP messages are sent as IP protocol type = "UDP" 84 with the port number TBD by IANA. 86 An implementation of AMAP must support all the message types described 87 below. Any unrecognized messages should be logged with a fatal warning. 88 Each AMAP message has a fixed size header. The layout of this header is 89 shown below: 91 0 1 2 3 92 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 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Ver | Res | Type | Checksum | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 AMAP Ver 98 AMAP Version number is 1. 100 Reserved 101 Set to zero on transmission. Ignored upon receipt. 103 Type 104 Types for specific AMAP messages. AMAP Types are: 106 Message Type Source Destination 107 ------------------------------------------------------------------------- 108 0 = Query Message Router Unicast to Endnodes 109 1 = Join Message Endnode Unicast to Source/ 110 Replicator address 111 2 = Join-Ack Message Router Unicast to Endnodes 112 3 = Auth Ack Router/Endnode Unicast to Source/Endnodes 113 4 = Prune Message Router/Endnode Unicast to Source/Endnodes 114 5 = Prune-Ack Message Router/Endnode Unicast to Source/Endnodes 115 6 = Data Message Router Unicast to Endnodes 116 7 = Notification Message Router/Endnode Unicast to Source/Endnodes 118 Checksum 119 The checksum is a standard IP checksum, i.e. the 16-bit one's 120 complement of the one's complement sum of the entire AMAP message. 121 For computing the checksum, the checksum field is zeroed. 123 For IPv6, the checksum also includes the IPv6 "pseudo-header", as 124 specified in RFC 2460, section 8.1 [5]. This "pseudo-header" is 125 prepended to the AMAP header for the purposes of calculating the 126 checksum. The "Upper-Layer Packet Length" in the pseudo-header is 127 set to the length of the AMAP message. The Next Header value used 128 in the pseudo-header is 103. If the packet's length is not an 129 integral number of 16-bit words, the packet is padded with a byte 130 of zero before performing the checksum. 132 Encoded format for Unicast Source and Group address is shown below: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Addr Family | Encoding Type | Unicast Address 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 140 Addr Family 141 The AMAP address family of the 'Unicast Address' field of this 142 address. 144 Values of 0-127 are as assigned by the IANA for Internet Address 145 Families in [8]. Values 128-250 are reserved to be assigned by the 146 IANA for PIM-specific Address Families. Values 251 though 255 are 147 designated for private use. As there is no assignment authority 148 for this space, collisions should be expected. 150 Encoding Type 151 The type of encoding used within a specific Address Family. The 152 value `0' is reserved for this field, and represents the native 153 encoding of the Address Family. 155 Unicast Address 156 The unicast address as represented by the given Address Family and 157 Encoding Type. 159 4.1 AMAP Router Query message format 161 Query messages are sent by AMAP routers to its tunnel endpoints 162 for periodic refresh of their multicast state. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Unicast Router address (Encoded-Source format) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Unicast Router Address 171 Unicast address of an AMAP router generating Query messages. For 172 format description refer to Encoded-Unicast address. 174 4.2 AMAP Host Join message format 176 Host Join messages are sent to assist building and maintainence of tunnel 177 states for (S/*, G) entries. Host Join messages are sent by endnodes 178 towards a Source address/Replicator address. For all (S, G) Host Join 179 messages, the Multicast Source Address will have a non-zero unicast 180 address field. For all (*, G) Host Join messages, the Multicast 181 Source Address will have a zero unicast address field. AMAP 182 implementations are suggested to send seperate Host Join messages for 183 (S, G) and (*, G) entries. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Reserved | Num Jn groups | Holdtime | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Tn Format | Replicator Address (Encoded format) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Multicast Source Address (Encoded-Group format) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Joined Group Address 1 (Encoded-Group format) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | . | 197 | . | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Joined Group Address n (Encoded-Group format) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Variable length TLVs | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Reserved 205 Transmitted as zero, ignored upon receipt. 207 Number of Join Groups 208 The number of multicast group sets contained in the message. 210 Holdtime 211 The amount of time a receiver must keep the tunnel state alive 212 in seconds. If the Holdtime is set to `0xffff', the receiver of 213 this message should hold the state until canceled by the 214 Prune message, or timed out according to local policy. This may be 215 used with dial-on-demand links, to avoid keeping the link up with 216 the periodic Join or Prune messages. 218 Tunnel Type 219 A specific type of tunnel that an endnode wants to use with an AMAP 220 Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload). 222 Replicator address 223 Address assigned to an AMAP router. When used in anycast-mode, it is an 224 address assigned to multiple AMAP routers to get "closest replicator 225 capability". For format description refer to Encoded-Unicast address. 227 Multicast Source address 228 Sender address that the endnode is interested in receiving data from. 229 For format description refer to Encoded-Unicast address. 231 Join Group Address 1 .. n 232 This list contains the Groups that the endnode is interested in receiving 233 data from. For format description refer to Encoded-Unicast address. 235 Variable length TLVs 236 The Encoded format for TLVs is defined as follows: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type | Length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Capabilities | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Type 247 A 16 bit field set to 1. 249 Length 250 A 16 bit field that indicates the length of the value portion in bytes. 252 Capabilities 253 This comprises one or more capability values. 255 4.3 AMAP Router Join-Ack message format 257 Router Join-Ack messages are sent to acknowledge the receipt of 258 the Host Join message by AMAP routers. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Reserved | Num Jn groups | Holdtime | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Tn Format | Multicast Source Address (Encoded format) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Joined Group Address 1 (Encoded-Group format) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | . | 270 | . | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Joined Group Address n (Encoded-Group format) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Cookie Value | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Variable length TLVs | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Reserved 280 Transmitted as zero, ignored upon receipt. 282 Number of Join Groups 283 The number of multicast group sets contained in the message. 285 Holdtime 286 The amount of time a receiver must keep the tunnel state alive 287 in seconds. If the Holdtime is set to `0xffff', the receiver of 288 this message should hold the state until canceled by the 289 Prune message, or timed out according to local policy. This may be 290 used with dial-on-demand links, to avoid keeping the link up with 291 the periodic Join or Prune messages. 293 Tunnel Type 294 A specific type of tunnel that an endnode wants to use with an AMAP 295 Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload). 297 Multicast Source address 298 Sender address that the endnode is interested in receiving data from. 299 For format description refer to Encoded-Unicast address. 301 Join Group Address 1 .. n 302 This is an accepted list of Groups for which the sending router may 303 establish tunnel connection with an endnode. For format description 304 refer to Encoded-Unicast address. 306 Cookie Value 307 Router cookie value that is reflected back in Auth-Ack message. 309 Variable length TLVs 310 See Encoded-TLV format. 312 4.4 AMAP Prune message format 314 Prune messages are sent to terminate existing tunnel connections for 315 (S/*, G) entries. Prune messages are sent by endnodes/AMAP routers 316 towards a source/replicator address or an endnode address. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Reserved | Holdtime | Tn Format | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Replicator Address (Encoded format) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Multicast Source Address (Encoded-Group format) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Joined Group Address (Encoded-Group format) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Reserved 331 Transmitted as zero, ignored upon receipt. 333 Holdtime 334 The amount of time a receiver must keep the tunnel state alive 335 in seconds. If the Holdtime is set to `0xffff', the receiver of 336 this message should hold the state until canceled by the 337 Prune message, or timed out according to local policy. This may be 338 used with dial-on-demand links, to avoid keeping the link up with 339 the periodic Join or Prune messages. 341 Tn Format 342 A specific type of tunnel that an endnode wants to use with an AMAP 343 Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload). 345 Replicator address 346 Address assigned to an AMAP router. When used in anycast-mode, it is an 347 address assigned to multiple AMAP routers to get "closest replicator 348 capability". For format description refer to Encoded-Unicast address. 350 Multicast Source address 351 For format description refer to Encoded-Unicast address. 353 Prune Group Address 354 Group address to be pruned. For format description refer to 355 Encoded-Unicast address. 357 4.5 AMAP Prune-Ack message format 359 Prunes-Ack messages are sent to acknowlege the receipt of 360 the Prune messages. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Reserved | Holdtime | Tn Format | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Replicator Address (Encoded format) | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Multicast Source Address (Encoded-Group format) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Joined Group Address (Encoded-Group format) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Cookie Value | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Reserved 377 Transmitted as zero, ignored upon receipt. 379 Holdtime 380 The amount of time a receiver must keep the tunnel state alive 381 in seconds. If the Holdtime is set to `0xffff', the receiver of 382 this message should hold the state until canceled by the 383 Prune message, or timed out according to local policy. This may be 384 used with dial-on-demand links, to avoid keeping the link up with 385 the periodic Join or Prune messages. 387 Tn Format 388 A specific type of tunnel that an endnode wants to use with an AMAP 389 Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload). 391 Replicator address 392 Address assigned to an AMAP router. When used in anycast-mode, it is an 393 address assigned to multiple AMAP routers to get "closest replicator 394 capability". For format description refer to Encoded-Unicast address. 396 Multicast Source address 397 Sender address to be pruned. For format description refer to 398 Encoded-Unicast address. 400 Prune Group Address 401 This contains the Group address to be pruned. For format description 402 refer to Encoded-Unicast address. 404 Cookie Value 405 Sender's cookie value that is reflected back in an Auth-Ack message. 407 4.6 AMAP Host Auth-Ack message format 409 Auth-Ack messages are sent to acknowledge the receipt of a Join-Ack message 410 or a Prune-Ack message. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Reserved | Prune/Join | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Cookie Value | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Prune-Ack/Join-Ack message / 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Reserved 423 Transmitted as zero, ignored upon receipt. 425 Prune/Join 426 Auth message sent in respone to 0 (Join-Ack) 1 (Prune-Ack). 428 Cookie Value 429 Sender's cookie value that is reflected back in Auth-Ack message. 431 Prune-Ack/Join-Ack message 432 Received AMAP Prune-Ack message/Join-Ack message triggering the Auth-Ack 433 message. 435 4.7 AMAP Notification message format 437 Notification messages are sent either by an AMAP router or an endnode 438 intiating a tunnel connection. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type | Subtype | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Multicast Source Address (Encoded-Group format) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Joined Group Address (Encoded-Group format) | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Destination Cookie Value (Optional) | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Source Cookie Value (Optional) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Type/Subtype 455 AMAP Notification message are of following types: 456 Type: 1 Error Message 457 Subtype: 1 Incorrect Version Number 458 2 Incorrect Cookie Value 459 3 Incorrect Message Type 460 4 Incorrect Address Encoding format 461 5 Incorrect Message Length 462 6 Unrecognised Route Entry Pruned 463 7 Unrecognised Capability 464 8 Incorrect Capability length 465 9 Incorrect Tunnel format 466 10 Incorrect Destination 468 Multicast Source address 469 Multicast Source address for which the Notification is sent. 470 For format description refer to Encoded-Unicast address. 472 Prune Group Address 473 Multicast Group address for which the Notification is sent. 474 This contains the Group address to be pruned. 476 Destination Cookie Value 477 Destination receiving Notification message's Cookie value. This 478 field is optional 480 Source Cookie Value 481 Source generating Notification message's Cookie value. This field 482 is optional. 484 All Notification messages must be logged. An implementation can 485 choose to terminate tunnel connections for (S/*, G) route entries for 486 which a Notification message received has cookie values successfully 487 verified. 489 5. Protocol Description for Endnodes 491 AMAP has a seperate protocol behavior for endnodes initiating 492 the tunnel connections to join multicast (S/*, G) channels and AMAP 493 routers terminating tunnel connections. This section describes the 494 protocol behavior for the endnodes initiating the tunnel connections. 496 5.1 Generating Join Messages 498 There are two main events that trigger generation of the Join messages 499 for initiating (S/*, G) tunnel connections: 501 * Applications residing on an endnode wanting to join a particular/set of 502 (S/*, G) groups. 504 * Reception of a Query message. 506 The following subsections describe actions to be taken for each of the 507 above cases. 509 5.1.1 Applications triggering a Join message 511 Whenever an endnode running multicast applications in a non-multicast 512 network wishes to join a particular (S/*, G) channel, it signals AMAP 513 with relevant parameters: (S/*, G) sets, a Replication address, and a 514 configured cookie value. 516 AMAP schedules a Join-expire timer with a configured/(default holdtime 517 interval)/3. AMAP creates an appropriate Join message and sends it 518 towards a Replication address if specified, or the Source address. 520 5.1.2 Reception of a Query message 522 Whenever an endnode running AMAP receives a Query message, it processes 523 the message. It verifies the querier's router address with the stored router 524 address in the tunnel interface information. It [re-]schedules the 525 Join-expire timer to the join-expire interval. The suggested default 526 value for the join-expire interval is set to the AMAP router's (Holdtime 527 interval)/3 (received in a Join-Ack message). It also [re-]schedules the 528 query-expire timer to an query-expire interval. The suggested default 529 value for the query-expire interval is set to the AMAP router's (Holdtime 530 interval)/3 (received in a Join-Ack message). It then sends a Join 531 message for all (S/*, G) entries for which the querier acts as a 532 tunnel endpoint. 534 5.2 Generating Prune message 536 Whenever a particular (S/*, G) channel is no longer required, a Prune 537 message is sent to the tunnel endpoint. An endnode running AMAP schedules 538 the Prune-expire timer to the prune-expire interval. The suggested 539 default value for the prune-expire interval is set to the AMAP router's 540 (Holdtime interval)/3 (received in a Join-Ack message). It then sends a 541 Prune message for a (S/*, G) channel to the AMAP router that acts as a 542 tunnel endpoint. 544 5.3 Generation of an Auth-Ack message 546 Auth-Ack message is sent in response to the received Join-Ack message or 547 a Prune-Ack message. An Auth-Ack message is sent with the cookie value 548 received in a Join-Ack/Prune-Ack message from the AMAP router. Tunnel 549 connection is either considered functional (if sent in response to 550 the Join-Ack message) or deleted (if sent in response to the Prune-Ack 551 message) once an Auth-Ack message is sent by an endnode to the AMAP router. 553 5.4 Reception of Data message 555 Data messages are encapsulated in an negotiated tunnel format by AMAP 556 routers. Whenever an endnode receives a data message, its encapsulated 557 format is verified with the stored negotiated format. If the tunnel format 558 differs, then a Notification message is sent and the tunnel connection is 559 terminated. Otherwise, data packets received are decapsulated and sent 560 to appropriate applications. 562 5.5 Reception of Prune message 564 Whenever an endnode receives a Prune message for a given (S/*, G) entry 565 from an AMAP router, it checks to verify if the sending AMAP router is 566 acting as a tunnel endpoint. In case of an error, the Prune message is 567 ignored and a Notification message is sent to an AMAP router. Otherwise, 568 the PruneAck-expire timer is scheduled for the prune-expire interval and 569 a Prune-Ack message is sent to an AMAP router. An endnode cookie is passed 570 in the Prune-Ack message. 572 5.6 Reception of an Auth-Ack message 574 An Auth-Ack message is received in response to any Prune-Ack message sent 575 by an endnode. Whenever an endnode receives an Auth-Ack message, it 576 processes the message. It verifies cookie values sent within an 577 Auth-Ack message. In the event of an error, a Notification message is 578 sent and an Auth-Ack message is ignored. Otherwise, the 579 PruneAck-expire timer is stopped for all (S/*, G) entries mentioned 580 in the Auth-Ack message. At this point the tunnel is disconnected and 581 the state is removed as described in [6.7]. 583 5.7 Timer expiry 585 In the event of a join-expire, prune-expire, or a query-expire timeout, a 586 Notification message is sent and the tunnel connection is disconnected. 588 6. Protocol Description for AMAP Routers 590 This section describes the protocol behavior for AMAP routers. Multicast 591 routers implementing AMAP will process Join messages according 592 to rules defined in this specification even when the IP destination 593 address is not assigned to the router. To allow a router to 594 recognize AMAP messages addressed to the unicast root address, and 595 place it on the slow path, rather than simply forwarding it towards 596 the specified destination, Join messages will have the router alert 597 option, and the IP protocol type="UDP" with port number TBD by IANA. 599 6.1 Reception of a Join message 601 Whenever an AMAP router intercepts a Join message it verifies them with 602 its locally configured policies. If the locally configured policies 603 disallow the router from intercepting Join messages, then it 604 simply forwards the message towards the destination. All the multicast 605 routers forwarding AMAP packets towards the desired destination must 606 use unicast RIB to resolve destination address. Otherwise, the 607 intercepting router processes the received Join message. In the 608 event of an error, the intercepting router should drop the received 609 Join message and send a Notification message to an endnode. Otherwise, 610 the intercepting router schedules a JoinAck-expire timer for join-expire 611 interval and sends a Join-Ack message to the endnode. The suggested 612 default value for the join-expire interval is set to the endnode's 613 (Holdtime interval)/3 (received in a Join message). A router based cookie 614 value is sent in the Join-Ack message. 616 In an event where an AMAP router processes and resolves a subset of the 617 (S/*, G) entries received in a Join message, the AMAP router should send a 618 Join-Ack message for only those entries which are resolved. For all 619 unresolved (S/*, G) entries, the AMAP router forwards them towards the 620 direction of the Source address/Replication address in the IP destination 621 of the Join message. 623 6.2 Reception of a Prune message 625 Whenever an AMAP router receives a Prune message for a given (S/*, G) 626 entry, it checks to verify if the sending endnode is a tunnel endpoint. 627 In case of an error the Prune message is ignored and a Notification message 628 is sent to an endpoint. Otherwise, the PruneAck-expire timer is scheduled 629 for the prune-expire interval and the Prune-Ack message is sent to an 630 endnode. The suggested default value for the Prune-expire interval is 631 set to the endnode's (Holdtime interval)/3 (received in a Prune message). 632 A router based cookie value is sent in the Prune-Ack message. 634 6.3 Reception of an Auth-Ack message 636 Auth-Ack messages are received in response of: 638 * AMAP router's Join-Ack message sent 640 * AMAP router's Prune-Ack message sent 642 The following subsections describe actions to be taken for each of the 643 above cases. 645 6.3.1 Auth-Ack message in response of a Join-Ack message 647 Whenever an AMAP router receives an Auth-Ack message, it processes the 648 message. It verifies cookie values sent within an Auth-Ack message. In 649 the event of an error, a Notification message is sent and an Auth-Ack 650 message is ignored. Otherwise, the JoinAck-expire timer is stopped for 651 all (S/*, G) entries mentioned in the Auth-Ack message. This signals the 652 successful completion of the tunnel signaling between an endnode intiating 653 the tunnel connection and an AMAP router terminating the tunnel 654 connection. At this point the tunnel is setup and the state is 655 created as described in [6.7]. An AMAP router starts to send multicast 656 packets over the tunnel. 658 6.3.2 Auth-Ack message in response of a Prune-Ack message 660 Whenever an AMAP router receives an Auth-Ack message, it processes the 661 message. It verifies cookie values sent within an Auth-Ack message. In 662 the event of an error, a Notification message is sent and an Auth-Ack 663 message is ignored. Otherwise, the PruneAck-expire timer is stopped for 664 all (S/*, G) entries mentioned in the Auth-Ack message. At this point 665 the tunnel is disconnected and the state is removed as described in [6.7]. 666 An AMAP router stops sending multicast packets over the tunnel for all 667 (S/*, G) entries metioned in the Auth-Ack message. 669 6.4 Generation of an Auth-Ack message 671 Auth-Ack message is sent in response to the received Join-Ack message or 672 a Prune-Ack message. An Auth-Ack message is sent with the cookie value 673 received in the Join-Ack/Prune-Ack message from the AMAP router. The 674 tunnel connection is either considered functional (if sent in response to 675 a Join-Ack message) or deleted (if sent in response to a Prune-Ack 676 message) once an Auth-Ack message is sent by an endnode to the AMAP router. 678 6.5 Generating a Prune message 680 AMAP routers can generate Prune messages whenever they loose upstream 681 connectivity or due to some local policy reasons. An AMAP router schedules 682 the Prune-expire timer to the prune-expire interval. The suggested 683 default value for the prune-expire interval is set to endnodes's 684 (Holdtime interval)/3. It then sends a Prune message for (S/*, G) entry 685 to all/a subset of endnodes listed in the oif-list of (S/*, G) entry. 687 6.6 Generating a Query message 689 AMAP routers acting as a tunnel endpoint for various (S/*, G) entries 690 will periodically query all its interested tunnel endnodes by sending a 691 Query message. An AMAP router sends Query messages every query-expire 692 interval. The suggested default for the query-expire interval is set 693 to an endnode's (Holdtime interval)/3 (received in a Join message). 694 AMAP routers keeps track of all the tunnel destinations (regardless if 695 the tunnel destination is joined to one or more route entries). 697 Any (S/*, G) entries not refreshed by the endnodes in their Join 698 messages sent in response to Query messages within a join-expire 699 interval will be immediately dropped. This assists AMAP routers sending 700 the Query messages and endpoints replying with the Join messages to detect 701 any unwanted tunnel breakages. 703 The holdtime used in Join messages and Join-Ack messages determines the 704 maximum waiting time that an AMAP router and an endnode should 705 wait before terminating a tunnel at each end. If an endnode fails to 706 receive a Query message for more than the Holdtime interval advertised 707 by an AMAP router in its Join-Ack message, then it terminates and 708 re-initiates tunnel connection. Similarly if the Join messages are not 709 received for more than the Holdtime interval advertised in the previous 710 Join message, then the router removes the tunnel interface from its 711 (S/*, G) entries. 713 Any (S/*, G) entries created with a holdtime value of '0xffff' need not be 714 refreshed periodically using Query messages. Such (S/*, G) entries can 715 only be explicitly removed using Prune messages or timed out using local 716 policies. 718 6.7 Reception of Data messages 720 Data messages are either received as native multicast, or as encapsulated 721 in a negotiated tunnel format. Whenever an AMAP router receives 722 encapsulated data messages, its encapsulated format is verified with 723 the stored negotiated format. If the tunnel format differs, then the 724 Notification message is sent and tunnel connection is terminated. 726 If an (S/*, G) entry exists for data messages received, then the messages 727 are encapsulated with a negotiated tunnel format and forwarded to all 728 the AMAP tunnel endpoints listed in the oif-lists. Otherwise, data 729 messages are dropped and a Prune message is sent to the upstream 730 router. 732 6.8 Timer expiry 734 In the event of join-expire, prune-expire, or a query-expire timeout, a 735 Notification message is sent and the tunnel connection is disconnected. 737 6.9 State Creation and Deletion 739 AMAP routers will add the tunnel interfaces [8] in its (S/*, G) oif-lists 740 when it receives an Auth-Ack message in response to a Join-Ack message 741 from the endnodes. An implementation must have a configured upper bound 742 on the number of the tunnel interfaces that it can put in oif-lists of 743 any (S/*, G) entry. 745 If a tunnel interface added is the first interface in an oif-list, and if 746 Multicast router has PIM enabled, then the PIM Protocol should be 747 signaled for generation of a PIM Join message. 749 AMAP routers will delete the tunnel interfaces from their (S, G) 750 oif-lists when: 752 * It receives an Auth-Ack message in response to a Prune-Ack messages 753 from endnodes. 755 * Any of the Join-expire, or Prune-expire, timers for the tunnel interfaces 756 expire and its state is not refreshed. 758 * If a Join message (in reponse to a Query message) is not received 759 within a Holdtime interval. 761 * If a Query message is not received from a tunnel endpoint within 762 a query-expire interval. 764 * AMAP routers sends an Auth-Ack message in response to a Prune-Ack 765 message received from endnodes. 767 6.10 Signaling and Forwarding Rules: 769 Whenever multicast routers implementing AMAP receive Join messages 770 from any endnodes, the following is done: 772 The received (S/*, G) entry is looked up in the Multicast 773 Routing Table. If the entry does not exist, then the (S/*, G) entry 774 is created. 776 * If a Join message or a Prune message has a non-zero Source address, 777 (i.e (S, G) and not (*, G)) then the next hop for the Source address check 778 is done. If the next hop is a PIM neighbor, or it is directly connected 779 (and PIM enabled) then a JoinAck-expire timer is scheduled for the 780 join-expire interval and a Join-Ack message is sent to an endnode. 782 * If the next hop is neither a PIM neighbor nor directly connected, 783 then the packet is forwarded towards the ip destination address. If the 784 (S/*, G) entry was created as a result of a lookup, then delete the 785 (S/*, G) entry from the Multicast Routing Table. 787 * If there is no source address (i.e (*, G)), then check for the group 788 mapping in the RP cache. If the group mapping is found for a particular 789 entry then schedule a JoinAck-expire timer for the join-expire interval 790 and send a Join-Ack message to an endnode. Otherwise, forward the Join 791 message towards the ip destination address. If the (*, G) entry was 792 created as a result of lookup, then delete the (*, G) entry from the 793 Multicast Routing Table. 795 Whenever Multicast routers implementing AMAP receive an Auth-Ack message 796 for a Join message, the following is done: 798 * Stop the JoinAck-expire timer. 800 * Add the tunnel interface to the Outgoing Interface List (oif-list) of 801 (S/*, G) entry. 803 * For all (S, G) route entries, signal PIM to send a PIM Join message 804 towards the Source address if PIM is enabled. 806 * For all (*, G) route entries, signal PIM to send a PIM Join message 807 towards the RPL address if PIM is enabled. 809 Whenever multicast routers implementing AMAP receive Prune messages 810 from any endnodes, the following is done: 812 The received (S/*, G) entry is looked up in the Multicast Routing Table. 813 If the entry does not exist, then a Notification message is sent for 814 the received (S/*, G) entry. 816 * If the entry is found, then a PruneAck-expire timer is scheduled for 817 the prune-expire interval and a Prue-Ack message is sent to an endnode. 819 Whenever multicast routers implementing AMAP receive an Auth-Ack message 820 for Prune messages, the following is done: 822 The received (S/*, G) entry is looked up in the Multicast Routing Table. 823 If the entry does not exist, then a Notification message is sent for 824 the received (S/*, G) entry. 826 * Stop the PruneAck-expire timer. 828 * Remove the tunnel interface to the Outgoing Interface List (oif-list) of 829 (S/*, G) entry. 831 * For all (S, G) route entries, signal PIM to send a PIM Prune message 832 towards the Source address if PIM is enabled. 834 * For all (*, G) route entries, signal PIM to send a PIM Prune message 835 towards the RPL address if PIM is enabled. 837 6.11 Aggregation 838 TBD 840 6.12 Tunnel Chaining 841 TBD 843 7. AMAP Message Processing 845 7.1 Router receiving AMAP Join message 847 Endnode Router 848 ------- ------ 849 Send AMAP Join ------------------> Receive AMAP Join message 850 message for 851 interested (S, G) 852 groups 853 if (error in message processing) 854 Receive AMAP <------------- Send Notification message with 855 Notification message Type="Error", Subtype= 856 "Appropriate Message Error 857 Code" 859 For each (S, G) received entry, 861 Lookup (S, G) entry. 863 if (entry found) { 865 schedule Join-expire Timer 866 for a received interface 868 if (cookie value != old cookie 869 value) { 871 store the received cookie 872 value 873 } 875 Receive AMAP Join-Ack <------------- send AMAP Join-Ack message 876 message with router cookie value 878 } else { 880 create (S, G) entry 882 Nexthop Lookup for (S). 884 if ((S == Pim Nbr) || 885 (S == directly connected) { 887 schedule Join-expire Timer 888 for a received interface 890 store the received cookie value 892 Receive AMAP Join-Ack <------------- send AMAP Join-Ack message 893 message with router cookie value 895 } else if (!S && 896 group mapping found in RP Cache) { 898 schedule Join-expire Timer 899 for a received interface 901 store the received cookie value 903 Receive AMAP Join-Ack <------------- send AMAP Join-Ack message 904 message with router cookie value 906 } else if (destination in IP (!local 907 interface)) { 909 stop the Join-expire Timer 911 if (multicast enabled) { 913 lookup in MRIB and 915 forward the Join towards 916 source. 918 } else { 920 lookup in unicast RIB and 922 forward the Join towards 923 the source. 924 } 925 } else { 926 Receive AMAP <------------- Send Notification message with 927 Notification message Type="Error", Subtype= 928 "Incorrect Destination" 929 } 930 } 932 7.2 Router receiving AMAP Auth-Ack for the Join-Ack message 934 Endnode Router 935 ------- ------ 936 Send AMAP Auth-Ack ----------------> Receive AMAP Auth-Ack for 937 for the Join-Ack the Join-Ack message 938 message 939 if (error in message processing) 940 Receive AMAP <------------- Send Notification message with 941 Notification message Type="Error", Subtype= 942 "Appropriate Message Error 943 Code" 945 if (error in cookie received) 946 Receive AMAP <------------- Send Notification message with 947 Notification message Type="Error", Subtype= 948 "Incorrect Cookie Value" 950 Lookup received (S, G) entry 952 if (found) { 953 Stop the Join-expire Timer 955 Add the tunnel interface to 956 outgoing list. 958 if (PIM enabled && 959 first interface) { 960 Send PIM Join message 961 } 962 } else { 963 Receive AMAP <------------- Send Notification message with 964 Notification message Type="Error", Subtype= 965 "Unrecognised Route Entry 966 Pruned" 967 } 969 7.3 Router receiving AMAP Prune message 971 Endnode Router 972 ------- ------ 973 Send AMAP Prune ------------------> Receive AMAP Prune message 974 message 976 if (error in message processing) 977 Receive AMAP <------------- Send Notification message with 978 Notification message Type="Error", Subtype= 979 "Appropriate Message Error 980 Code" 982 Lookup received (S, G) entry and 983 tunnel interface in oif-list 985 if (found) { 986 Start the Prune-expire Timer 987 for received interface 989 Receive AMAP Prune-Ack <------------- Send Prune-Ack message with 990 message the router cookie value 992 } else { 993 Receive AMAP <------------- Send Notification message with 994 Notification message Type="Error", Subtype= 995 "Unrecognised Route Entry 996 Pruned" 997 } 999 7.4 Router receiving AMAP Auth-Ack message for the Prune-Ack message 1001 Endnode Router 1002 ------- ------ 1003 Send AMAP Auth-Ack ----------------> Receive AMAP Auth-Ack for 1004 for the Prune-Ack the Prune-Ack message 1005 message 1006 if (error in message processing) 1007 Receive AMAP <------------- Send Notification message with 1008 Notification message Type="", Subtype= 1009 "Appropriate Message Error 1010 Code" 1012 if (error in cookie received) 1013 Receive AMAP <------------- Send Notification message with 1014 Notification message Type="Error", Subtype= 1015 "Incorrect Cookie Value" 1017 Lookup received (S, G) entry and 1018 tunnel interface in oif-list 1020 if (found) { 1021 Stop the Prune-expire Timer 1022 for a received interface 1024 Remove the tunnel interface to 1025 outgoing list. 1027 if (PIM enabled && 1028 last interface) { 1029 Send PIM Prune message 1030 Remove (S, G) entry 1031 } 1032 } else { 1033 Receive AMAP <------------- Send Notification message with 1034 Notification message Type="Error", Subtype= 1035 "Unrecognised Route Entry 1036 Pruned" 1037 } 1039 7.5 Hosts receiving AMAP Join-Ack or Prune-Ack messages 1041 Endnode Router 1042 ------- ------ 1043 Receive AMAP Join/Prune-Ack <-------- Send Join/Prune-Ack message with 1044 message the router cookie value 1045 Send Auth-Ack message 1046 with Router's cookie value ---------> Receive Auth-Ack messages 1047 received in Join/Prune message 1049 7.6 Hosts receiving AMAP Query messages 1051 Endnode Router 1052 ------- ------ 1053 Re-schedule Query time 1055 schedule Join-expire Timer 1056 for a received interface 1058 Receive AMAP Query <------------- Send Query message 1059 message 1061 Send AMAP Join message 1062 for interested (S, G) -------------> Receive AMAP Join messages 1063 groups 1065 7.7 Routers sending AMAP Prune messages 1067 Endnode Router 1068 ------- ------ 1069 Start the Prune-expire Timer 1070 for a tunnel interface 1072 Receive an <------------------ Send an AMAP Prune message with 1073 AMAP Prune message the router cookie value 1075 if (error in message processing) 1076 Send Notification message with -> Receive AMAP Notification message 1077 Type="Error", Subtype= if (cookie value matches stored 1078 "Appropriate Message Error cookie value) { 1079 Code" Lookup received (S, G) entry and 1080 tunnel interface in oif-list 1082 if (found) { 1083 Stop the Prune-expire Timer 1084 for a received interface 1086 Remove the tunnel interface to 1087 outgoing list. 1089 } 1090 } 1091 Send AMAP Prune-Ack -------------> Receive Prune-Ack message with 1092 message the host cookie value 1094 Lookup received (S, G) entry and 1095 tunnel interface in oif-list 1097 if (found) { 1098 Stop the Prune-expire Timer 1099 for a received interface 1101 Remove the tunnel interface to 1102 outgoing list. 1104 } else { 1105 Receive AMAP <------------- Send Notification message with 1106 Notification message Type="Error", Subtype= 1107 "Unrecognised Route Entry 1108 Pruned" 1109 } 1110 8. Tunnel Interfaces 1111 Because not all intermediate routers support native ip multicast, 1112 AMAP requires all the oifs on which it receives Host Join or Prune 1113 messages from receivers which are not directly connected to be created 1114 as tunnel interfaces. In practice, tunnels typically use either IP-IP 1115 [Perk96] or Generic Routing Encapsulation (GRE) [Han94a,Han94b], 1116 although, other encapsulation methods are acceptable. 1118 9. Security Considerations 1120 AMAP does not change any multicast security issues. PIM is open to many 1121 types of resource overload. For instance, a node which transmits from 1122 many bogus source addresses will cause PIM routers to join to many (S, G) 1123 pairs, eventually exhausting the state. PIM routers must protect themselves 1124 by limiting the amount of state for multicast, so that a denial of 1125 service attack on multicast will not destroy unicast. 1127 With LAN-based IGMP join message, only nodes on the LAN can initiate 1128 a join message, so if the LAN is physically protected, and all 1129 routers along the path to the RP (or S in an (S, G) join) are trusted, 1130 it might be somewhat harder for a node to create a join state 1131 untraceably than it would with this tunnel proposal. With this 1132 tunnel proposal, the join message is sent over a multi-hop path. 1134 As stated in the document, a router is configured with a maximum 1135 number of tunnels it is willing to accept, so an attack to deplete 1136 its tunnel resources will only affect attempts to create tunnels, 1137 and not cause any other denial of service. 1139 Additionally, the router to whom tunnels will be created is likely 1140 to be the entry router at an ISP, and it can consider an entire customer 1141 network to be a LAN. If suspiciously large number of tunnels are 1142 being created from that customer network, then the router can start 1143 discriminating against join messages from that customer network, 1144 when resources are being depleted. 1146 Eventually, cryptographic authentication can be added between the 1147 joiner and the router, by having potential joiners obtain a key (or 1148 certificate) from the router before they are allowed to join, and 1149 having join messages cryptographically authenticated. 1151 10. Acknowledgements 1153 We express our thanks to Alex Zinin, Lorenzo Vicisano, liming Wei, 1154 Tom Pusateri, and Nidhi Bhaskar for their review and comments on the 1155 earlier versions of the draft. 1157 11. References 1159 [PIM-SM] Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, 1160 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1161 Protocol Specification (Revised)". 1163 [Han94a] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 1164 Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and 1165 cisco Systems, October 1994. 1167 [Han94b] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1168 Routing Encapsulation over IPv4 networks", RFC 1702, 1169 NetSmiths, Ltd., cisco Systems, October 1994. 1171 [Perk96] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1172 October 1996. 1174 12. Author Information 1176 Keyur Patel 1177 Cisco Systems. Inc. 1178 email: keyupate@cisco.com 1180 Radia Perlman 1181 Sun Microsystems. Inc. 1182 email: Radia.Perlman@sun.com 1184 Dino Farinacci 1185 Procket Networks Inc. 1186 email: dino@procket.com 1188 Greg Shepherd 1189 Procket Networks Inc. 1190 email: shep@procket.com 1192 Marshall Eubanks 1193 Multicast Technologies Inc. 1194 email: tme@multicasttech.com