Network Working Group Keyur Patel
Internet Draft AYR Networks
Expiration Date: January 2003 Radia Perlman
Sun Microsystems
Host Extensions to Protocol Independent Multicast
draft-keyur-pim-host-extensions-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
2. Abstract
This document defines host extensions to Protocol Independent
Multicast - PIM protocol. These host extensions allows endnodes
to join/leave any multicast (S/*,G) groups. This helps in easing
SSM-style multicast deployment that does not have to depend on
IGMP (v1/v2/v3), in either endnodes or the routers.
Patel, Perlman [Page 1]
Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002
3. Introduction
An impediment to getting SSM Multicast deployed is that, as currently
specified, it depends on IGMPv3. Since IGMPv3 is in the IP stack, it
requires endnodes to upgrade to an OS that supports IGMPv3 and it
requires IGMPv3 support on the first hop multicast capable routers as
well. This document proposes host extensions to PIM protocol which
eliminate the requirement of running IGMPv3 both on endnodes as well
as first hop multicast capable routers. This draft is solely for the
purpose of joining SSM-style groups, i.e., groups in which the IP
address of the root is explicitly known by the joining host. This
draft allows hosts to join SSM-style groups even if
* the host's OS stack does not support IGMPv3
* the local routers do not support IGMPv3, or even multicast, and/or
* some routers along the path to the root do not support multicast.
This is achieved by defining a new user level process that runs host
extensions for PIM. All that is really required to join an SSM-style
group with this mechanism is for the joining host and the root (the
"Source") to support this. As more routers are upgraded to supporting
this, bandwidth use is minimized by utilizing multicast rather than
tunnels.
Although in theory this style of host join could be used instead of
IGMP to join a non-SSM group, for non-SSM groups this design offers
no advantage over IGMP, since only IGMPv2, which is already widely
deployed, is required for joining non-SSM groups.
A router that does not support the messages in this draft
will simply forward such messages towards the destination specified
in the messages. The first multicast capable router that supports
these PIM host extensions will notice these messages and will form a
tunnel with the end node that generated the message.
Patel, Perlman [Page 2]
Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002
4 Host extensions for PIM
We propose a new PIM Host-Join/Prune message that is similar to the
PIM Join/Prune message, except that the destination address in the
IP header is the "Source" (root of the tree) address. PIM routers
with host extension support will process these messages without
requiring an exchange of the PIM hello messages or establishing the
PIM neighbor adjacencies. PIM routers should treat the receipt of
Host-Join/Prunes messages as intended for them, even though the
destination address in the IP header is the unicast address
of the tree root. To allow a router to recognize a PIM Host-Joins
addressed to the unicast root address, and place it on the slow
path, rather than simply forwarding it towards the specified
destination, the packet will have the router alert option, and the IP
protocol type="PIM" with version 2.
PIM routers with host extension support receiving such PIM
Host-Join/Prune messages will process them in similar way as PIM
Join/Prune messages. PIM routers however will create tunnel interfaces
(refer section 6) in their (S, G) oif lists when receiving
Host-Join/Prune messages from receivers that are not directly connected.
For all the directly connected receivers, PIM routers will create
interfaces in their (S, G) oif lists in the same way as if an IGMP (S,G)
join or a PIM Join/Prune message were received. An implementation must
have a configured upper bound on number of tunnel interfaces that it can
put in oif lists of any multicast route. PIM routers receiving such
PIM Host-Join/Prune messages will process them exactly as PIM Join/Prune
messages and will have similar state-machine generated by these messages
(as described in [PIM-SM]). It is suggested that an implementation must
have a seperate mechanism for processing all the PIM Host-Join/Prune
messages within a PIM process in order to prevent any kind of interference
with PIM router messages. All the non-multicast PIM capable routers
will simply forward such packets towards the unicast source address.
Current routers which receive an ip unicast packet with ip options
process these packets and forward them towards the unicast destination
address specified in the ip packet if the destination is not one of the
ip addresses of the routers. Otherwise, these routers forward these
packets up the local stack for local delivery. Therefore, current
routers will forward the packets destined for the unicast address of the
root, to the root, which is the desired behavior.
All end-hosts willing to subscribe to a particular (S/*, G) group
will be periodically sending PIM Host-Join messages. All the PIM
Host-Join/Prune messages will be sent with unicast source address
as the destination address. All the PIM Host-Join/Prune messages
will be sent with IP Router Alert option.
Patel, Perlman [Page 3]
Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002
5 PIM Host-Join/Prune message format
PIM Host-Joins are sent to assist building source trees (SPT). PIM
Host-Prunes are sent to prune source trees when members leave groups.
Encoded-Unicast address
An Encoded-Unicast address takes the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family
The PIM address family of the 'Unicast Address' field of this
address.
Values of 0-127 are as assigned by the IANA for Internet Address
Families in [8]. Values 128-250 are reserved to be assigned by the
IANA for PIM-specific Address Families. Values 251 though 255 are
designated for private use. As there is no assignment authority
for this space, collisions should be expected.
Encoding Type
The type of encoding used within a specific Address Family. The
value `0' is reserved for this field, and represents the native
encoding of the Address Family.
Unicast Address
The unicast address as represented by the given Address Family and
Encoding Type.
Patel, Perlman [Page 4]
Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver
PIM Version number is 2.
Type
Types for specific PIM messages. PIM Types are:
Message Type Destination
-------------------------------------------------------------------------
0 = Hello Multicast to ALL-PIM-ROUTERS
1 = Register Unicast to RP
2 = RegisterStop Unicast to source of Register packet
3 = Join/Prune Multicast to ALL-PIM-ROUTERS
4 = Bootstrap Multicast to ALL-PIM-ROUTERS
5 = Assert Multicast to ALL-PIM-ROUTERS
6 = Graft (used in PIM-DM only) Multicast to ALL-PIM-ROUTERS
7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft packet
8 = Candidate-RP-Advertisement Unicast to Domain's BSR
9 = Host-Join/Prune Unicast to Source
Reserved
Set to zero on transmission. Ignored upon receipt.
Checksum
The checksum is a standard IP checksum, i.e. the 16-bit one's
complement of the one's complement sum of the entire PIM message.
For computing the checksum, the checksum field is zeroed.
For IPv6, the checksum also includes the IPv6 "pseudo-header", as
specified in RFC 2460, section 8.1 [5]. This "pseudo-header" is
prepended to the PIM header for the purposes of calculating the
checksum. The "Upper-Layer Packet Length" in the pseudo-header is
set to the length of the PIM message. The Next Header value used
in the pseudo-header is 103. If the packet's length is not an
integral number of 16-bit words, the packet is padded with a byte
of zero before performing the checksum.
Reserved
Transmitted as zero, ignored on receipt.
Patel, Perlman [Page 5]
Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002
Holdtime
The amount of time a receiver must keep the Join/Prune state alive,
in seconds. If the Holdtime is set to `0xffff', the receiver of
this message should hold the state until canceled by the
appropriate canceling Join/Prune message, or timed out according to
local policy. This may be used with dial-on-demand links, to avoid
keeping the link up with periodic Join/Prune messages.
Note that the Holdtime must be larger than the
J/P_Override_Interval(I) (refer to [PIM-SM]).
Number of Groups
The number of multicast group sets contained in the message.
Multicast group address
For format description refer to Encoded-Unicast address.
Number of Joined Sources
Number of join source addresses listed for a given group.
Join Source Address 1 .. n
This list contains the sources that the sending router will forward
multicast datagrams for if received on the interface this message
is sent on.
See Encoded-Source-Address format.
Number of Pruned Sources
Number of prune source addresses listed for a group.
Prune Source Address 1 .. n
This list contains the sources that the sending router does not
want to forward multicast datagrams for when received on the
interface this message is sent on.
Within one PIM local-Join/Prune message, all the Multicast Group
Addresses, Joined Source addresses and Pruned Source addresses MUST
be of the same address family. It is NOT PERMITTED to mix IPv4 and
IPv6 addresses within the same message. In addition, the address
family of the fields in the message SHOULD be the same as the IP
source and destination addresses of the packet. This permits
maximum implementation flexibility for dual-stack IPv4/IPv6 routers.
Patel, Perlman [Page 6]
Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002
6. Tunnel Interfaces
Because not all intermediate routers support native ip multicast, PIM
host extensions requires all the oifs on which it receives
Host-Join/Prunes messages from receivers which are not directly
connected to be created as tunnel interfaces. In practice, tunnels
typically use either IP-IP [Perk96] or Generic Routing Encapsulation
(GRE) [Han94a,Han94b], although, other encapsulation methods are
acceptable.
7. Security Considerations
This extension to PIM does not change the underlying security issues.
8. Acknowledgements
We express our thanks to Alex Zinin, Dino Farinacci, Tom Pusateri,
and Nidhi Bhaskar for their review and comments.
9. References
[PIM-SM] Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)".
[Han94a] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic
Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and
cisco Systems, October 1994.
[Han94b] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702,
NetSmiths, Ltd., cisco Systems, October 1994.
[Perk96] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
10. Author Information
Keyur Patel
AYR Networks. Inc.
3977 East Bayshore Road, suite 200
Palo Alto, CA 94303
email: keyur@ayrnetworks.com
Radia Perlman
Sun Microsystems. Inc.
2 Elizabeth Drive
Chelmsford, MA 01824
email: Radia.Perlman@sun.com