idnits 2.17.00 (12 Aug 2021) /tmp/idnits35710/draft-tissa-pim-mcastoam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 118 has weird spacing: '...ses are expla...' == Line 119 has weird spacing: '...lize to ident...' == Line 292 has weird spacing: '... and/or of E/...' -- The document date (March 4, 2012) is 3723 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC-PIMSM' is mentioned on line 118, but not defined == Missing Reference: 'PING-EXT' is mentioned on line 136, but not defined == Unused Reference: 'PINGEXT' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'RFC6450' is defined on line 646, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tissa Senevirathne 2 Internet Draft Nataraj Bacthu 3 Intended status: Standard Tack Raghava Sivaramu 4 CISCO Systems 5 Sam Aldrin 6 Donald Eastlake 7 HuaWei Technologies 9 March 4, 2012 10 Expires: September 2012 12 IP multicast data plane failure detection 13 draft-tissa-pim-mcastoam-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, and it may not be 23 published except as an Internet-Draft. 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, except to publish it 28 as an RFC and to translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on September 4, 2012. 47 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Abstract 64 ICMP Based multicast messaging infrastructure is presented in this 65 document. Messages presented in this document is intended to be 66 utilized for troubleshooting multicast data plane connectivity 67 issues as well as identify multicast routers performing different 68 roles, such as Rendezvous Point (RP), Designated Router etc. 70 Table of Contents 72 1. Introduction...................................................3 73 2. Conventions used in this document..............................4 74 3. Extensions.....................................................4 75 3.1. Receiver Address scope....................................4 76 3.1.1. Theory of Operation..................................4 77 3.1.2. C-type-Addr-scope....................................5 78 3.2. Originator IP Address.....................................5 79 3.3. Multicast Router Role.....................................6 80 3.3.1. Role Request Use Case Example........................9 81 3.4. Incoming and Outgoing Interfaces.........................10 82 3.5. Reverse Path Forwarding..................................11 83 3.5.1. RPF Response of Data Plane information..............12 84 3.5.2. RPF Response of Control Plane information...........14 85 4. Security Considerations.......................................15 86 5. IANA Considerations...........................................15 87 6. References....................................................16 88 6.1. Normative References.....................................16 89 6.2. Informative References...................................16 90 7. Acknowledgments...............................................16 92 1. Introduction 94 Echo Request and Response messages are widely used in 95 troubleshooting connectivity faults in unicast IP network. In a 96 typical IP unicast network, there is a strict 1-1 relationship 97 between an IP address and a device. Hence, Echo request messages can 98 uniquely identify the liveliness of the end-device. 100 On the other hand single multicast address, also known as multicast 101 group address, represents many devices which are interested in 102 receiving multicast traffic destined to the specific group address. 103 Echo request addressed to a specific multicast group address 104 potentially generate large number of responses that may overwhelm 105 the requester to the point that information may not be useful. It 106 would be very attractive, if there exists a method that would allow 107 a user to specify the end station address or addresses from which a 108 response is desired. Ability to indicate such a response scope, 109 allows user to narrow down the responses only to the desired scope 110 (ie end stations). 112 In an IP unicast network, there are two classes of devices; end 113 stations and routers. In a multicast network, based on the multicast 114 routing protocol, devices belong to multiple different classes and 115 they perform completely different set of functions/roles. Routers in 116 a PIM-SM multicast routed network can belong to the following 117 classes; Designated Router, Rendezvous Point Router. Functions of 118 each of these classes are explained in the [RFC-PIMSM]. There are 119 no convenient methods a user can utilize to identify different 120 multicast roles routers are performing. Either the user has to hop 121 between routers looking for information or use a different tools 122 such as SNMP to identify the routers that are performing a specific 123 function. Ability to utilize an integrated tool such as Ping to 124 discover routers performing specific roles not only convenient but 125 can be very efficient, especially when troubleshooting a complex 126 problem. 128 Currently there are few tools such as "mtrace" that are widely 129 utilized in troubleshooting multicast paths. Most of these tools 130 only validate the control plane. As such, they may not be able to 131 detect failures associated with data plane. 133 In this document we propose a framework that extends ICMP messages 134 to carry different multicast troubleshooting related extensions. The 135 extensions specified in this document utilize approaches presented 136 in [RFC4884] and [PING-EXT]. 138 "ssmping" and "asmping" are commonly utilized to troubleshoot 139 multicast connectivity. These tools require presences of a server at 140 the multicast source. In typical deployments, especially in hosting 141 services, network operator may be different from the administrator 142 of the servers. In such scenarios use of tools such as above provide 143 operational and administrative challenges. The tools presented in 144 this document can be exercised from first hop routers and allow 145 flexibility to masquerade the source address to the address of the 146 multicast source. Included in the payload is the originator IP 147 address where reply needed to be sent. Originator IP address may be 148 different than the source IP address. 150 2. Conventions used in this document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC-2119 [RFC2119]. 156 In this document, these words will appear with that interpretation 157 only when in ALL CAPS. Lower case uses of these words are not to be 158 interpreted as carrying RFC-2119 significance. 160 3. Extensions 162 We propose to define a new object class TBD-MUL-OBJ within the ICMP 163 Extension Object defined in [RFC4884]. TBD-MUL-OBJ object 164 encapsulate extensions related to multicast OAM. Different c-types 165 are expected to be defined with the Object type TBD-MUL-OBJ to 166 specify specific information related to multicast OAM. 168 3.1. Receiver Address scope 170 Ping (ICMP Echo request) directed to a multicast destination "G" may 171 trigger responses from every receiver in the network that is 172 receiving multicast traffic for "G". It is convenient to have a 173 method to specify subnetwork or end station from which the requester 174 is expecting a response. 176 3.1.1. Theory of Operation 178 Requester includes one or more c-type-Addr-scope (Figure 1) within 179 the ICMP Echo request message. Each c-type-Addr-scope represents an 180 address from which a response is required. 182 Each device that that has an active interface with the specified 183 destination multicast group address "G", compares the embedded c- 184 type-Addr-scope against its local interface IP addressese. If they 185 match, a response SHOULD be generated. If they do not match request 186 MUST BE silently discarded. Absence of the c-type-Addr-scope or 187 inclusion of value zero in the IP Address field of the c-type-Addr- 188 scope indicates that a response is required from all devices with an 189 active interface with address "G". 191 3.1.2. C-type-Addr-scope 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Length | Class-Num | C-Type | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | IP Address | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Mask | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1 c-type-Addr-scope 205 o Length : 8 or 32 octets. 8 octets indicate embedded is an IPv4 206 address. 32 octets indicate IPv6 address 208 o IP Address : 4 or 16 octets 210 o Mask : 4 or 16 octets, represents the associated address mask. 212 3.2. Originator IP Address 214 Source address of the IP header plays an important role in multicast 215 packet forwarding. It is highly desirable to have ability generate 216 multicast oam packets from the first hop Designated Router, or any 217 intermediate routers, with the source IP address field set to the 218 source IP address of the multicast server. Originator IP address c- 219 type defined in this section allows the originator to include its IP 220 address in the payload of the multicast OAM message. Responders are 221 required to generate the response addressed to the embedded 222 Originator IP address not to the source IP address of the multicast 223 OAM packet. When originator IP address c-type is absent in the 224 payload, requester may utilize the source address of the multicast 225 OAM packet. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Length | Class-Num | C-Type | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | IP Address | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2 c-type-Originator-IP-Addess 237 o Length : 8 or 32 octets. 8 octets indicate embedded is an IPv4 238 address. 32 octets indicate IPv6 address 240 o IP Address : 4 or 16 octets, IP address of the originator where 241 a response is required to be sent. 243 3.3. Multicast Router Role 245 As it was stated earlier identification of the role played by 246 routers within the multicast network is very important when 247 troubleshooting a problem. 249 We propose to define two categories of c-types. C-type-role-request, 250 embedded in the request message indicates to responders to include 251 c-type-role-response in the response. C-type-role-response MUST be 252 included in the response message only when c-type-role-request is 253 present in the request message. Multiple c-types are defined for the 254 roel-response. Each role-response c-type may carry additional 255 information that may be specific to the requested role. In the event 256 a given router performing multiple roles, multiples of such role 257 responses may be included in a given response. 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Length | Class-Num | C-Type | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Reserved |E|D|R| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | IP Address | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Mask | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 3 c-type-role-request 273 o Length : 12 or 36 octets depending on IP address is IPv4 or 274 IPv6. 276 o Reserved : Transmitted zero and ignored on recipt 278 o R : (1 bit), indicates response is requested from Rendezvous 279 Point routers. IP Address specifies the Group address(es) that 280 the RP is servicing. 282 o D : (1 bit), indicates response is requested from Designtated 283 Routers. IP Address specifies the subnet that the DR is 284 servicing. 286 o E : (1 bit) indicates response is requested from an end 287 station. IP Address specifies the subnet or the end-station 288 address. 290 o Only one of the E/D/R bits MUST be set in a single c-type. A 291 request MAY contain multiple c-type-role-requests with 292 different values of IP Address/Mask and/or of E/D/R flags. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Length | Class-Num | C-Type | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | RP IP Address | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Reserved | Num of Groups | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Multicast Group Address 1 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Address Mask 1 | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 . . 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Multicast Group Address n | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Address Mask n | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 4 c-type Role Response of Rendezvous Points 317 o Length : 4+4+(4+4)n or 16++4+(16+16)n octets depending on IP 318 address is IPv4 or IPv6. Where n is the number of Multicast 319 Group addresses. 321 o RP IP Address: (4 or 16 octets). Unicast IP address of the 322 Rendezvous Point 324 o Reserved : Transmitted zero and ignored on recipt 326 o Num of Groups: Number of Multicast Groups embedded in the c- 327 type. 329 o Multicast Group Address: (4 or 16 octets). 331 o IP address mask associated with the Group address: (4 or 16 332 octets) 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Length | Class-Num | C-Type | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | DR IP Address | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Reserved | Num of subnets | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Subnet Address 1 | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Subnet Mask 1 | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 . . 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Subnet Address n | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Subnet Mask n | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 5 c-type Role Response of Designated Router 358 o Length : 4+4+4n or 16++4+16n octets depending on IP address is 359 IPv4 or IPv6. Where n is the number of Multicast Group 360 addresses. 361 o DR IP Address : (4 or 16 octets) Management IP Address of the 362 Designated Router 364 o Reserved : Transmitted zero and ignored on recipt 366 o Num of Subnets: Number of subnets embedded in the c-type 368 o Subnet Address: (4 or 16 octets) Subnet Address of which this 369 Router is a DR 371 o Subnet Mask: (4 or 16 octets) Subnet mask 373 3.3.1. Role Request Use Case Example 375 Let's assume an operator desires to identify, for a multicast 376 address "G", all Rendezvous Point (RP) routers in the network and 377 Designated router servicing subnet 10.10.10.0/24. 379 ICMP echo request message with destination addressed to multicast 380 address G with router alert flag is generated. Additionally, 381 following role-request c-types are included in the ICMP echo request 382 message: 384 1. c-type-role-request, with R flag set and IP address field set to G 385 and subnet mask set to 255.255.255.255. This indicates response is 386 required from RP that are servicing group G. 387 2. c-type-role-request with D flag set and IP address field set to 388 10.10.10.0/24. This indicates a response is required from routers 389 that are functioning as DR for subnet 10.10.10.0/24. 391 Each intermediate router along the path receives a copy of the ICMP 392 echo request message due to router alert flag in the header. 394 Intermediate routers process the ICMP echo request message 395 extensions and follow c-type-role-request message processing. 397 1. RPs servicing group "G" generate ICMP echo response addressed to 398 the requester and include ICMP extension Role Response of 399 Rendezvous Points. In the Role Response of Rendezvous Points 400 message, IP address is set to the IP address of the RP, Multicast 401 Group address and applicable subnet mask are set accordingly. 402 2. DR that is servicing subnet 10.10.10.0/24 generate ICMP echo 403 response addressed to the requester and include ICMP extension 404 Role response of Designated Router. In the ICMP extension Role 405 response of Designated Router c-type, IP address is set to the IP 406 address of the DR and applicable Subnet Address and Mask are also 407 included. 409 3.4. Incoming and Outgoing Interfaces 411 This c-type encodes the IP address of the upstream interface from 412 which the ICMP Echo request was received and downstream interfaces 413 to which the request would be forwarded. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Length | Class-Num | C-Type | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Incoming Interface IP address | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Reserved | Num of OIF | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Outgoing Interface 1 IP Address | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 . . 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Outgoing Interface n IP address | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 6 c-type Incoming and Outgoing Interfaces 435 o Length : 4+4+4n or 16++4+16n octets depending on IP address is 436 IPv4 or IPv6. Where n is the number of Multicast Group 437 addresses. 439 o Incoming Interface IP address: (4 or 16 octets) IP address of 440 incoming Interface 442 o Reserved : (2 octets) Transmitted zero and ignored on receipt 444 o Num of OIF: (2 octets) Number of outgoing Interface. 446 o Down Stream neighbor: (4 or 16 octets) IP address of the 447 Outgoing Interfaces 449 3.5. Reverse Path Forwarding 451 "mtrace" is the only tool that is currently available to identify 452 RPF issues. "mtrace" is a control plane tool and may not always give 453 proper fault coverage, especially when control and data plane are 454 out of alignment. 456 c-type RPF-REQ presented here may be included to request RPF 457 information. C-type RPF-RES carries the requested information. 459 As previously mentioned, ICMP ECHO request messages addressed to a 460 specific group address G may not be responded by the intermediate 461 routers as the intermediate routers may not have an active group G 462 on the router. We propose, when response from intermediate routers 463 are required, to generate ICMP Echo request messages with Router 464 Alert flag set. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Length | Class-Num | C-Type | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 |C| Reserved | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Source Address 1 | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Multicast Group Address 1 | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 7 c-type Role RPF request 480 o Length : 4+ 2*4 or 4+2*16 octets depending on IP address is 481 IPv4 or IPv6. Where n is the number of Multicast Group 482 addresses. 484 o Reserved : (15 bits) Transmitted zero and ignored on receipt 486 o C (1 bit) indicates that control plane validation requested. 488 o Source Address: (4 or 16 octets) Source IP address "S" in 489 (S,G). Zero in the source address field represents * notation 490 in (*,G). In general this indicates request for information 491 related to the shared tree. 493 o Multicast Group Address: (4 or 16 octets) multicast group 494 Address G 496 3.5.1. RPF Response of Data Plane information 498 The c-type defined in this section provide RPF information contained 499 in the data plane of the responding device for the specified (S,G). 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Length | Class-Num | C-Type | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Source Address | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Multicast Group Address | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Received Interface IP address | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Reserved | Num of Down Stream | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Outgoing Interface IP Address | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 . . 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Outgoing Interface IP Address | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 8 c-type RPF response for Data plane information 525 o Length : 4+4+4+4+4n or 16+16+16+4+16n octets depending on IP 526 address is IPv4 or IPv6. Where n is the number of Multicast 527 Group addresses. 528 o Source Address : 4 or 16 octets based on IPv4 or IPv6. 529 Represents one of the source addresses specified in the RPF 530 request c-type. Zero value indicate * notation in (*,G). 532 o Multicast Group Address: 4 or 16 octets based on IPv4 or IPv6. 533 Represents one of the group specified in the RPF request c- 534 type. Source Address and Multicast Group Address pair MUST 535 match exactly as specified in the RPF request c-type. 537 o Received Interface IP address: 4 or 16 octets, indicates the IP 538 address of the received interface. 540 o Reserved : (2 octets) Transmitted zero and ignored on receipt 542 o Num of Down Stream: (2 octets) Number of Downstream neighbors. 544 o Outgoing Interface IP Address: (4 or 16 octets) IP address of 545 the outgoing Interfaces. 547 3.5.2. RPF Response of Control Plane information 549 The c-type defined in this section provide RPF information contained 550 in the Control plane of the responding device for the specified 551 (S,G). 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Length | Class-Num | C-Type | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Source Address | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Multicast Group Address | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Received Interface IP address | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Reserved | Num of Down Stream | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Outgoing Interface IP Address | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | | 569 . . 570 | | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Outgoing Interface IP Address | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 9 c-type RPF response for Control plane information 577 o Length : 4+4+4+4+4n or 16+16+16+4+16n octets depending on IP 578 address is IPv4 or IPv6. Where n is the number of Multicast 579 Group addresses. 580 o Source Address : 4 or 16 octets based on IPv4 or IPv6. 581 Represents one of the source addresses specified in the RPF 582 request c-type. Zero value indicate * notation in (*,G). 584 o Multicast Group Address: 4 or 16 octets based on IPv4 or IPv6. 585 Represents one of the group specified in the RPF request c- 586 type. Source Address and Multicast Group Address pair MUST 587 match exactly as specified in the RPF request c-type. 589 o Received Interface IP address: 4 or 16 octets, indicates the IP 590 address of the received interface. 592 o Reserved : (2 octets) Transmitted zero and ignored on receipt 594 o Num of Down Stream: (2 octets) Number of Downstream neighbors. 596 o Outgoing Interface IP Address: (4 or 16 octets) IP address of 597 the outgoing Interfaces. 599 4. Security Considerations 601 TBD 603 5. IANA Considerations 605 IANA is requested to provide a new object class to represent ICMP 606 Object extension for multicast OAM. 608 IANA is requested to maintain a registry within the multicast ICMP 609 extension object to include c-types defined under the multicast OAM 610 object type. 612 c-types defined in this document are: 614 +-------------------------------------+--------+------------------+ 615 | c-type name |number | Reference | 616 +-------------------------------------+--------+------------------+ 617 | Address Scope | 1 | 3.1.2. | 618 | Originator IP Address | 2 | 3.2. | 619 | Role Request | 3 | 3.3. | 620 | Role Response Rendezvous Point | 4 | 3.3. | 621 | Role Response Designated Router | 5 | 3.3. | 622 | Incoming and Outgoing Interfaces | 6 | 3.4. | 623 | RPF Information Request | 7 | 3.5. | 624 | RPF Response Dataplane Infor | 8 | 3.5.1. | 625 | RPF Response Control Plane Info | 9 | 3.5.2. | 626 +-------------------------------------+--------+------------------+ 628 Figure 10 C-types defined in this document 630 6. References 632 6.1. Normative References 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, March 1997. 637 [RFC4884] Bonica, R., et.al, "Extended ICMP to support multipart 638 Messages",, RFC 4884, April 2007. 640 [PINGEXT] Shen, N., et.al, "Traceroute and Ping Message Extensions", 641 draft-shen-traceroute-ping-ext-04, Work in Progress, 642 February, 2012. 644 6.2. Informative References 646 [RFC6450] Venaas, S. "Multicast Ping Protocol", RFC 6450, December 647 2011. 649 7. Acknowledgments 651 653 This document was prepared using 2-Word-v2.0.template.dot. 655 Authors' Addresses 657 Tissa Senevirathne 658 CISCO Systems 659 375 East Tasman Drive 660 San Jose, CA 95134, USA 662 Phone: +1-408-853-2291 663 Email: tsenevir@cisco.com 665 Nataraj Bacthu 666 CISCO Systems 667 425 East Tasman Drive 668 San Jose, CA 95134, USA 670 Email:nbatchu@cisco.com 671 Raghava Sivaramu 672 CISCO Systems 673 425 East Tasman Drive 674 San Jose, CA 95134, USA 676 Email: raghavas@cisco.com 678 Sam Aldrin 679 HuaWei Technologies 680 2330 Central Expressway 681 Santa Clara, CA 95951, USA 683 Email:aldrin.ietf@gmail.com 685 Donald Eastlake 686 HuaWei Technologies 687 155 Beaver Street 688 Milford, MA 01757, USA 690 Phone: +1-508-333-2270 691 Email: d3e3e3@gmail.com