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]
