Internet DRAFT - draft-tissa-pim-mcastoam

draft-tissa-pim-mcastoam



Network Working Group                                Tissa Senevirathne
Internet Draft                                           Nataraj Bacthu
Intended status: Standard Tack                         Raghava Sivaramu
                                                          CISCO Systems
                                                             Sam Aldrin
                                                        Donald Eastlake
                                                    HuaWei Technologies

                                                          March 4, 2012
Expires: September 2012



                 IP multicast data plane failure detection
                      draft-tissa-pim-mcastoam-00.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html




Senevirathne          Expires September 4, 2012                [Page 1]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   This Internet-Draft will expire on September 4, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.

Abstract

    ICMP Based multicast messaging infrastructure is presented in this
   document. Messages presented in this document is intended to be
   utilized for troubleshooting multicast data plane connectivity
   issues as well as identify multicast routers performing different
   roles, such as Rendezvous Point (RP), Designated Router etc.

Table of Contents


   1. Introduction...................................................3
   2. Conventions used in this document..............................4
   3. Extensions.....................................................4
      3.1. Receiver Address scope....................................4
         3.1.1. Theory of Operation..................................4
         3.1.2. C-type-Addr-scope....................................5
      3.2. Originator IP Address.....................................5
      3.3. Multicast Router Role.....................................6
         3.3.1. Role Request Use Case Example........................9
      3.4. Incoming and Outgoing Interfaces.........................10
      3.5. Reverse Path Forwarding..................................11
         3.5.1. RPF Response of Data Plane information..............12
         3.5.2. RPF Response of Control Plane information...........14
   4. Security Considerations.......................................15
   5. IANA Considerations...........................................15
   6. References....................................................16
      6.1. Normative References.....................................16
      6.2. Informative References...................................16
   7. Acknowledgments...............................................16


Senevirathne          Expires September 4, 2012                [Page 2]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012



1. Introduction

   Echo Request and Response messages are widely used in
   troubleshooting connectivity faults in unicast IP network. In a
   typical IP unicast network, there is a strict 1-1 relationship
   between an IP address and a device. Hence, Echo request messages can
   uniquely identify the liveliness of the end-device.

   On the other hand single multicast address, also known as multicast
   group address, represents many devices which are interested in
   receiving multicast traffic destined to the specific group address.
   Echo request addressed to a specific multicast group address
   potentially generate large number of responses that may overwhelm
   the requester to the point that information may not be useful. It
   would be very attractive, if there exists a method that would allow
   a user to specify the end station address or addresses from which a
   response is desired. Ability to indicate such a response scope,
   allows user to narrow down the responses only to the desired scope
   (ie end stations).

   In an IP unicast network, there are two classes of devices; end
   stations and routers. In a multicast network, based on the multicast
   routing protocol, devices belong to multiple different classes and
   they perform completely different set of functions/roles. Routers in
   a PIM-SM multicast routed network can belong to the following
   classes; Designated Router, Rendezvous Point Router. Functions of
   each of these classes are  explained in the [RFC-PIMSM]. There are
   no convenient methods a user can utilize to  identify different
   multicast roles routers are performing. Either the user has to hop
   between routers looking for information or use a different tools
   such as SNMP to identify the routers that are performing a specific
   function. Ability to utilize an integrated tool such as Ping to
   discover routers performing specific roles not only convenient but
   can be very efficient, especially when troubleshooting a complex
   problem.

   Currently there are few tools such as "mtrace" that are widely
   utilized in troubleshooting multicast paths. Most of these tools
   only validate the control plane. As such, they may not be able to
   detect failures associated with data plane.

   In this document we propose a framework that extends ICMP messages
   to carry different multicast troubleshooting related extensions. The
   extensions specified in this document utilize approaches presented
   in [RFC4884] and [PING-EXT].



Senevirathne          Expires September 4, 2012                [Page 3]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   "ssmping" and "asmping" are commonly utilized to troubleshoot
   multicast connectivity. These tools require presences of a server at
   the multicast source. In typical deployments, especially in hosting
   services, network operator may be different from the administrator
   of the servers. In such scenarios use of tools such as above provide
   operational and administrative challenges. The tools presented in
   this document can be exercised from first hop routers and allow
   flexibility to masquerade the source address to the address of the
   multicast source. Included in the payload is the originator IP
   address where reply needed to be sent. Originator IP address may be
   different than the source IP address.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

3. Extensions

   We propose to define a new object class  TBD-MUL-OBJ within the ICMP
   Extension Object defined in [RFC4884]. TBD-MUL-OBJ object
   encapsulate extensions related to multicast OAM. Different c-types
   are expected to be defined with the Object type TBD-MUL-OBJ to
   specify specific information related to multicast OAM.

3.1. Receiver Address scope

   Ping (ICMP Echo request) directed to a multicast destination "G" may
   trigger responses from every receiver in the network that is
   receiving multicast traffic for "G". It is convenient to have a
   method to specify subnetwork or end station from which the requester
   is expecting a response.

3.1.1. Theory of Operation

   Requester includes one or more c-type-Addr-scope (Figure 1) within
   the ICMP Echo request message. Each c-type-Addr-scope represents an
   address from which a response is required.

   Each device that that has an active interface with the specified
   destination multicast group address "G", compares the embedded c-
   type-Addr-scope against its local interface  IP addressese. If they


Senevirathne          Expires September 4, 2012                [Page 4]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   match, a response SHOULD be generated. If they do not match request
   MUST BE silently discarded. Absence of the c-type-Addr-scope or
   inclusion of value zero in the IP Address field of the c-type-Addr-
   scope indicates that a response is required from all devices with an
   active interface with address "G".

3.1.2. C-type-Addr-scope



   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IP Address                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Mask                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1 c-type-Addr-scope

     o Length : 8 or 32 octets. 8 octets indicate embedded is an IPv4
        address. 32 octets indicate IPv6 address

     o IP Address : 4 or 16 octets


     o Mask : 4 or 16 octets, represents the associated address mask.

3.2. Originator IP Address

   Source address of the IP header plays an important role in multicast
   packet forwarding. It is highly desirable to have ability generate
   multicast oam packets from the first hop Designated Router, or any
   intermediate routers, with the source IP address field set to the
   source IP address of the multicast server. Originator IP address c-
   type defined in this section allows the originator to include its IP
   address in the payload of the multicast OAM message. Responders are
   required to generate the response addressed to the embedded
   Originator IP address not to the source IP address of the multicast
   OAM packet. When originator IP address c-type is absent in the
   payload, requester may utilize the source address of the multicast
   OAM packet.





Senevirathne          Expires September 4, 2012                [Page 5]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IP Address                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 2 c-type-Originator-IP-Addess

     o Length : 8 or 32 octets. 8 octets indicate embedded is an IPv4
        address. 32 octets indicate IPv6 address

     o IP Address : 4 or 16 octets, IP address of the originator where
        a response is required to be sent.



3.3. Multicast Router Role

   As it was stated earlier identification of the role played by
   routers within the multicast network is very important when
   troubleshooting a problem.

   We propose to define two categories of c-types. C-type-role-request,
   embedded in the request message indicates to responders to include
   c-type-role-response in the response. C-type-role-response MUST be
   included in the response message only when c-type-role-request is
   present in the request message. Multiple c-types are defined for the
   roel-response. Each role-response c-type may carry additional
   information that may be specific to the requested role. In the event
   a given router performing multiple roles, multiples of such role
   responses may be included in a given response.















Senevirathne          Expires September 4, 2012                [Page 6]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Reserved                                |E|D|R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IP Address                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Mask                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 3 c-type-role-request

     o Length : 12 or 36 octets depending on IP address is IPv4 or
        IPv6.

     o Reserved : Transmitted zero and ignored on recipt

     o R : (1 bit), indicates response is requested from Rendezvous
        Point routers. IP Address specifies the Group address(es) that
        the RP is servicing.

     o D : (1 bit), indicates response is requested from Designtated
        Routers. IP Address specifies the subnet that the DR is
        servicing.

     o E : (1 bit) indicates response is requested from an end
        station. IP Address specifies the subnet or the end-station
        address.

     o Only one of the E/D/R bits MUST be set in a single c-type. A
        request MAY contain multiple c-type-role-requests with
        different values of IP Address/Mask and/or  of E/D/R flags.














Senevirathne          Expires September 4, 2012                [Page 7]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RP IP Address                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved              |    Num of Groups                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Multicast Group Address 1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Address Mask 1                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Multicast Group Address n                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Address Mask n                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 4 c-type Role Response of Rendezvous Points


     o Length : 4+4+(4+4)n or 16++4+(16+16)n octets depending on IP
        address is IPv4 or IPv6. Where n is the number of Multicast
        Group addresses.

     o RP IP Address: (4 or 16 octets). Unicast IP address of the
        Rendezvous Point

     o Reserved : Transmitted zero and ignored on recipt

     o Num of Groups: Number of Multicast Groups embedded in the c-
        type.

     o Multicast Group Address: (4 or 16 octets).

     o IP address mask associated with the Group address: (4 or 16
        octets)









Senevirathne          Expires September 4, 2012                [Page 8]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 DR IP Address                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved              |    Num of subnets               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Subnet  Address 1                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Subnet  Mask 1                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Subnet Address n                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Subnet  Mask n                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 5 c-type Role Response of Designated Router


     o Length : 4+4+4n or 16++4+16n octets depending on IP address is
        IPv4 or IPv6. Where n is the number of Multicast Group
        addresses.
     o  DR IP Address : (4 or 16 octets) Management IP Address of the
        Designated Router

     o Reserved : Transmitted zero and ignored on recipt

     o Num of Subnets: Number of subnets embedded in the c-type

     o Subnet Address: (4 or 16 octets) Subnet Address of which this
        Router is a DR

     o Subnet Mask: (4 or 16 octets) Subnet mask


3.3.1. Role Request Use Case Example

   Let's assume an operator desires to identify, for a multicast
   address "G", all Rendezvous Point (RP) routers in the network and
   Designated router servicing subnet 10.10.10.0/24.



Senevirathne          Expires September 4, 2012                [Page 9]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   ICMP echo request message with destination addressed to multicast
   address G with router alert flag is generated. Additionally,
   following role-request c-types are included in the ICMP echo request
   message:

   1. c-type-role-request, with R flag set and IP address field set to G
     and subnet mask set to 255.255.255.255. This indicates response is
     required from RP that are servicing group G.
   2. c-type-role-request with D flag set and IP address field set to
     10.10.10.0/24. This indicates a response is required from routers
     that are functioning as DR for subnet 10.10.10.0/24.

   Each intermediate router along the path receives a copy of the ICMP
   echo request message due to router alert flag in the header.

   Intermediate routers process the ICMP echo request message
   extensions and follow c-type-role-request message processing.

   1. RPs servicing group "G" generate ICMP echo response addressed to
     the requester and include ICMP extension Role Response of
     Rendezvous Points. In the Role Response of Rendezvous Points
     message, IP address is set to the IP address of the RP, Multicast
     Group address and applicable subnet mask are set accordingly.
   2. DR that is servicing subnet 10.10.10.0/24 generate ICMP echo
     response addressed to the requester and include ICMP extension
     Role response of Designated Router. In the ICMP extension Role
     response of Designated Router c-type, IP address is set to the IP
     address of the DR and applicable Subnet Address and Mask are also
     included.



3.4. Incoming and Outgoing Interfaces

   This c-type encodes the IP address of the upstream interface from
   which the ICMP Echo request was received and downstream interfaces
   to which the request would be forwarded.












Senevirathne          Expires September 4, 2012               [Page 10]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Incoming Interface IP address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved                |  Num of OIF                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Outgoing Interface 1 IP Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Outgoing Interface n IP address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 6 c-type Incoming and Outgoing Interfaces


     o Length : 4+4+4n or 16++4+16n octets depending on IP address is
        IPv4 or IPv6. Where n is the number of Multicast Group
        addresses.

     o Incoming Interface IP address: (4 or 16 octets) IP address of
        incoming Interface

     o Reserved : (2 octets) Transmitted zero and ignored on receipt

     o Num of OIF: (2 octets) Number of outgoing Interface.

     o Down Stream neighbor: (4 or 16 octets) IP address of the
        Outgoing Interfaces



3.5. Reverse Path Forwarding

   "mtrace" is the only tool that is currently available to identify
   RPF issues. "mtrace" is a control plane tool and may not always give
   proper fault coverage, especially when control and data plane are
   out of alignment.

   c-type RPF-REQ presented here may be included to request RPF
   information. C-type RPF-RES carries the requested information.



Senevirathne          Expires September 4, 2012               [Page 11]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   As previously mentioned, ICMP ECHO request messages addressed to a
   specific group address G may not be responded by the intermediate
   routers as the intermediate routers may not have an active group G
   on the router. We propose, when response from intermediate routers
   are required, to generate ICMP Echo request messages with Router
   Alert flag set.

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|                             Reserved                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Source Address 1                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Multicast Group Address 1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 7 c-type Role RPF request

     o Length : 4+ 2*4 or 4+2*16 octets depending on IP address is
        IPv4 or IPv6. Where n is the number of Multicast Group
        addresses.

     o Reserved : (15 bits) Transmitted zero and ignored on receipt

     o C (1 bit) indicates that control plane validation requested.


     o Source Address: (4 or 16 octets) Source IP address "S" in
        (S,G). Zero in the source address field represents * notation
        in (*,G). In general this indicates request for information
        related to the shared tree.

     o Multicast Group Address: (4 or 16 octets) multicast group
        Address G

3.5.1. RPF Response of Data Plane information

   The c-type defined in this section provide RPF information contained
   in the data plane of the responding device for the specified (S,G).






Senevirathne          Expires September 4, 2012               [Page 12]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Source Address                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Multicast Group Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Received Interface  IP address                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved                |  Num of Down Stream           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Outgoing Interface IP Address                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Outgoing Interface IP Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 8 c-type RPF response for Data plane information


     o Length : 4+4+4+4+4n or 16+16+16+4+16n octets depending on IP
        address is IPv4 or IPv6. Where n is the number of Multicast
        Group addresses.
     o Source Address : 4 or 16 octets based on IPv4 or IPv6.
        Represents one of the source addresses specified in the RPF
        request c-type. Zero value indicate * notation in (*,G).

     o Multicast Group Address: 4 or 16 octets based on IPv4 or IPv6.
        Represents one of the group specified in the RPF request c-
        type. Source Address and Multicast Group Address pair MUST
        match exactly as specified in the RPF request c-type.

     o Received Interface IP address: 4 or 16 octets, indicates the IP
        address of the received interface.

     o Reserved : (2 octets) Transmitted zero and ignored on receipt

     o Num of Down Stream: (2 octets) Number of Downstream neighbors.

     o Outgoing Interface IP Address: (4 or 16 octets) IP address of
        the outgoing Interfaces.



Senevirathne          Expires September 4, 2012               [Page 13]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012




3.5.2. RPF Response of Control Plane information

   The c-type defined in this section provide RPF information contained
   in the Control plane of the responding device for the specified
   (S,G).

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |   Class-Num   |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Source Address                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Multicast Group Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Received Interface IP address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved                |  Num of Down Stream           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Outgoing Interface IP Address                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Outgoing Interface IP Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 9 c-type RPF response for Control plane information


     o Length : 4+4+4+4+4n or 16+16+16+4+16n octets depending on IP
        address is IPv4 or IPv6. Where n is the number of Multicast
        Group addresses.
     o Source Address : 4 or 16 octets based on IPv4 or IPv6.
        Represents one of the source addresses specified in the RPF
        request c-type. Zero value indicate * notation in (*,G).

     o Multicast Group Address: 4 or 16 octets based on IPv4 or IPv6.
        Represents one of the group specified in the RPF request c-
        type. Source Address and Multicast Group Address pair MUST
        match exactly as specified in the RPF request c-type.





Senevirathne          Expires September 4, 2012               [Page 14]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


     o Received Interface IP address: 4 or 16 octets, indicates the IP
        address of the received interface.


     o Reserved : (2 octets) Transmitted zero and ignored on receipt

     o Num of Down Stream: (2 octets) Number of Downstream neighbors.

     o Outgoing Interface IP Address: (4 or 16 octets) IP address of
        the outgoing Interfaces.


4. Security Considerations

   TBD

5. IANA Considerations

   IANA is requested to provide a new object class to represent ICMP
   Object extension for multicast OAM.

   IANA is requested to maintain a registry within the multicast ICMP
   extension object to include c-types defined under the multicast OAM
   object type.

   c-types defined in this document are:


   +-------------------------------------+--------+------------------+
   |    c-type name                      |number  |  Reference       |
   +-------------------------------------+--------+------------------+
   | Address Scope                       |    1   | 3.1.2.           |
   | Originator IP Address               |    2   | 3.2.             |
   | Role Request                        |    3   | 3.3.             |
   | Role Response Rendezvous Point      |    4   | 3.3.             |
   | Role Response Designated Router     |    5   | 3.3.             |
   | Incoming and Outgoing Interfaces    |    6   | 3.4.             |
   | RPF Information Request             |    7   | 3.5.             |
   | RPF Response Dataplane Infor        |    8   | 3.5.1.           |
   | RPF Response Control Plane Info     |    9   | 3.5.2.           |
   +-------------------------------------+--------+------------------+

               Figure 10   C-types defined in this document






Senevirathne          Expires September 4, 2012               [Page 15]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


6. References

6.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4884] Bonica, R., et.al, "Extended ICMP to support multipart
             Messages",, RFC 4884, April 2007.

   [PINGEXT] Shen, N., et.al, "Traceroute and Ping Message Extensions",
             draft-shen-traceroute-ping-ext-04, Work in Progress,
             February, 2012.

6.2. Informative References

   [RFC6450] Venaas, S. "Multicast Ping Protocol", RFC 6450, December
             2011.

7. Acknowledgments

   <Add any acknowledgements>

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Tissa Senevirathne
   CISCO Systems
   375 East Tasman Drive
   San Jose, CA 95134, USA

   Phone: +1-408-853-2291
   Email: tsenevir@cisco.com


   Nataraj Bacthu
   CISCO Systems
   425 East Tasman Drive
   San Jose, CA 95134, USA

   Email:nbatchu@cisco.com







Senevirathne          Expires September 4, 2012               [Page 16]

Internet-Draft       draft-tissa-pim-mcastoam-00             March 2012


   Raghava Sivaramu
   CISCO Systems
   425 East Tasman Drive
   San Jose, CA 95134, USA

   Email: raghavas@cisco.com


   Sam Aldrin
   HuaWei Technologies
   2330 Central Expressway
   Santa Clara, CA 95951, USA

   Email:aldrin.ietf@gmail.com


   Donald Eastlake
   HuaWei Technologies
   155 Beaver Street
   Milford, MA 01757, USA

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com


























Senevirathne          Expires September 4, 2012               [Page 17]