Internet DRAFT - draft-musthafa-pim-unrouted-data-handling
draft-musthafa-pim-unrouted-data-handling
Network Working Group Musthafa.A.S
Internet Draft Prince Sunny
FutureSoft, A Flextronics
Company
Masato Aketo
Document: Anritsu Corporation
draft-musthafa-pim-unrouted-data-handling-00.txt
Expires: March 1, 2006 Sept 1, 2005
Unrouted Data Handling in PIM-SM
draft-musthafa-pim-unrouted-data-handling-00.txt
Status of this memo
By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on March 1 2006.
Abstract
A shared-media LAN like Ethernet may have multiple PIM-SM routers
connected to it. In a scenario where two or more routers are connected
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 1]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
to the same LAN and if only one of the PIM-SM Routers has members
joined for a particular group, all the other routers will receive the
same traffic. Since no members are joined for this group in the
routers, each time when data is received, the PIM-SM has the overhead
of processing all these data packets in the control plane to decide
where to route the packet.
To avoid this, an (S, G) or (*, G) Entry with NULL Oif list is
created so that discarding of the packets will be handled efficiently
in the data plane as opposed to searching the route entry in the
control plane and then dropping the packet.
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.
1. Introduction
This document specifies efficient management of unrouted data handling
by PIM-SM which span wide-area (and inter-domain) internets. Protocol
Independent Multicast - Sparse Mode (PIM-SM), although may use the
underlying unicast routing to provide reverse-path information for
multicast tree building, it is not dependent on any particular unicast
routing protocol. PIM-SM version 2 was originally specified in RFC2117,
and revised in RFC 2362 [1].
The data packets destined to a group for which there are no members
joined is called Unrouted data. This document is intended to explain
a way to solve the inefficient way of handling unrouted data.
Routers implemented according to the specification in this document
will be able to successfully interoperate with routers implemented
according to RFC 2362.
2. Overview of PIM
This section provides an overview of PIM-SM behavior. It is intended
as an introduction on PIM-SM, and is NOT definitive.
PIM relies on an underlying topology-gathering protocol to populate a
routing table with routes. This routing table is called the MRIB or
Multicast Routing Information Base. The routes in this table may be
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 2]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
taken directly from the unicast routing table, or it may be different
and provided by a separate routing protocol such as MBGP. Regardless
of how it is created, the primary role of the MRIB in the PIM protocol
is to provide the next hop router along a multicast-capable path to
each destination subnet. The MRIB is used to determine the next hop
neighbor to which any PIM Join/Prune message is sent. Data flows along
the reverse path of the Join messages. Thus, in contrast to the
unicast RIB which specifies the next hop that a data packet would take
to get to some subnet, the MRIB gives reverse-path information, and
indicates the path that a multicast data packet would take from its
origin subnet to the router that has the MRIB. PIM-SM gathers
membership information through MLD [4] or IGMP [6] messages.
Like all multicast routing protocols that implement the service model
from RFC 1112 [3], PIM-SM must be able to route data packets from
sources to receivers without either the sources or receivers knowing
a priori of the existence of the others.
3. Unrouted data handling in PIM
In a Local area network where two or more PIM-SM routers are
inter-connected and if only one of the PIM-SM Routers has members
joined for a particular group then all the other routers will receive
the same traffic. Since no members are joined for this group in all the
other routers, each time when data is received, the PIM-SM has to take
decision as to what to do with this data.
To improve the efficiency of the system, depending on from where it
received the traffic PIM-SM can create (*, G) or (S, G), with NULL Oif
list.
The per-interface state-machine for receiving unrouted data from
the Source is described below. There are three states:
NoInfo (NI)
The interface has not received any data, no joins are there
and no timers running.
Unrouted Data ( UD )
The interface has received data from a source and no joins are
there, then it will create an (S, G) State with NULL Oif List
which will cause to drop packets destined for G from this
interface. The (S, G) Keep Alive Timer is started. (S, G) entry
will be deleted on the expiry of this Timer.
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 3]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
Join ( J )
The Router has received a membership report or (*, G) Join, then
it will create a (*, G) Entry with Oif List so that the packets
destined for G will be forwarded on this interface and if any
(S,G) with NULL Oif entry present, then it should update the oif
list and trigger the (S,G) Join.
If the Router has received a (S, G) Join, then (S,G) with NULL
Oif entry should be updated with the oif list and trigger (S,G)
Join towards the source.
+----------++---------------------------------------------------------+
| || Event |
|Prev State++------------------+----------+--------------+------------+
| || Received Unrouted| Timer | (*,G) Join | (S,G) Join |
| || Data | Expired | Recvd | Recvd |
+----------++------------------+----------+--------------+------------+
| || -> UD state | - |->J State |-> J State |
|NoInfo || (S,G) Entry with | | | |
| || Null Oif.Start | | | |
| || Timer. | | | |
+----------++------------------+----------+--------------+------------+
| || -> UD state |-> NoInfo |->J State |-> J State |
| || | |- (*,G) |- update |
| || | |entry created |(S,G) with |
|UD State || | |- update |Oif |
| || | |(S,G) with Oif| |
+----------++------------------+----------+--------------+------------+
The per-interface state-machine for receiving unrouted data from the RP
is described below. There are three states:
NoInfo (NI)
The interface has not received any data, no joins are there
and no timers running.
Unrouted Data ( UD )
The interface has received data from RP and when no joins are
received, then it will create a (*, G) State with NULL Oif
List which will cause to drop packets destined for G from
this interface. We will make use of the Keep Alive Timer here
as in (S, G) State and the (*, G) entry will be deleted on the
expiry of this Timer.
Join ( J )
The Router has received a membership report, then it will add
that interface to the Oif List so that the packets destined
for G will be forwarded on this interface.
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 4]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
+-----------++----------------------------------------------------+
| || Event |
|Prev State ++-------------------+-------------------+------------+
| || Received Unrouted | Receive Join | Timer |
| || Data | (*, G). | Expired |
+-----------++-------------------+-------------------+------------+
| || -> UD state | -> J State | |
| NoInfo || (*,G) Entry with | | - |
| || Null Oif.Start | | |
| || Timer | | |
+-----------++-------------------+-------------------+------------+
| || -> UD state | -> J State with | -> NoInfo |
| UD State || | Oif List Updated.| |
| || | | |
| || | | |
+-----------++-------------------+-------------------+------------+
The criteria for determining whether (S, G) or (*, G) route entry
creation depends on from where the PIM-SM Router received the data
packet. If it is from the Source DR or from the Sender itself, then
(S, G) with NULL Oif is created. If it is from the RP, then a (*, G)
with NULL Oif is created. This method of handling unrouted data has the
following advantages:
Efficient Processing of data Packets:
- Multicast traffic routing in unrouted data handling will be
effective in case of forwarding the multicast data traffic in the data
plane and the route determination through the control plane
- Whenever a Router receives data packets, the forwarding is
determined depending on the corresponding group route entry in the
forwarding table present in the data plane. If it does not find one,
processing of this packet will happen in the control plane and
subsequently discard the packet. In a shared media LAN, where there are
a number of Routers connected and only one among them has a member
joined for a particular group G, then all the other Routers will receive
the same packets and have the overhead of processing all these data
packets. To avoid this, an (S, G) or (*, G) Entry with NULL Oif list is
created so that discarding of the packets will be handled efficiently in
the data plane rather than searching the route entry in the control
plane and then dropping the packet.
In the scenario represented by Figure 1, Router 3 is configured as RP
for the Group G, and Router 1 receives a membership report for G. Sender
starts sending data packets for group G. Router 3 which is configured
as RP for the group will forward the data packet to the shared media
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 5]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
LAN. Since Router 2 is also in the same LAN, it will receive all the
data packets destined to Router 1. Hence Router 2 will create a (*, G)
Entry with NULL Oif List, so that from the next time it receives packets
destined to group G, it will discard.
In case if Receiver 2 sends a membership report for group G, then Router
2 PIM Implementation MUST update the Oif list so that the subsequent
packets will be forwarded to Receiver 2.
Figure 1:
+-------+
| |
| Sndr |
| |
+---+---+
|
|
+--------+-------+
| |
| |
| Router 3 |
| |
| |
+--------+-------+
|
|
|
|
+-----------------+ | +-----------------+
| |<---------+-------->| |
| | | |
| | | |
| Router 2 | | Router 1 |
| | | |
| | | |
+-------+---------+ +--------+--------+
| |
| |
| |
| |
+---+---+ +---+---+
| | | |
| Rcv 2 | | Rcv 1 |
| | | |
+-------+ +-------+
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 6]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
In another scenario, where RP does not exists and if Sender is sending
data destined to Group G, then Router 3 will create an (S, G) entry
with NULL Oif list. This will make Router 3 discard subsequent packets
for Group G, if there are no RP for the group exists in the subnet.
In a similar case where Router1 is configured as RP for the group and
Router3 is the Source DR and when the sender starts sending data, the
multicast data packets destined to Router 1, will be received by Router
2 also and since there are no members joined, Router2 should create an
(S,G) entry with NULL Oif as the source of data packet is Source DR
and not RP.
An example for implementing the Unrouted data handling is explained as
follows:
In the scenario represented by Figure 1, all the routers are PIM-SM
enable and initially in No Info State, as described above by the
per-interface state machine. RP for the group G is configured as
Router 1. Since sender is connected to Router 3, it is the Source DR.
When Source DR starts sending data to RP, since Router 2 is also in the
same LAN, it will receive data packets and will change to UD State where
it will create an (S, G) Entry with NULL Oif. A timer is started and
upon the expiration of this timer, Router 2 will change to No Info
state. If Rcv 2 sends a membership report to Router 2 when it is in UD
State, it will change to J State and creates a (*, G) Entry and sends
(*, G) join toward RP i.e. Router 1. Router 2 also updates the (S, G)
Entry with oif list and trigger an (S, G) join towards Sender DR i.e.
Router 3. In case if Rcv 2 stop sending membership report, then both
the (S, G) and (*, G) will time out and Router 2 will change to No Info
state.
In another scenario where all the routers are initially in No Info state
and when Rcv 2 sends a membership report, (*, G) entry will be created
in Router 2 and Router 1 since RP for the group G is Router 1. When the
sender starts sending data, after a period of time, (S, G) path will be
created in Router 2 and Router 3. In this case, when RP i.e. Router 1
receives data, it should create an (S, G) entry with NULL oif and
changes to UD state. When Rcv 1 joins group G, the entry will be updated
with Oif list.
It should be noted that, other PIM-SM Control messages like Register
stop, Hello messages etc will have no effect on this implementation.
The (S, G) or (*, G) with NULL oif entry will be deleted only on the
expiration of the timer which will be started upon creation. The default
value for this timer can be set as 180 Secs which can be changed
according to requirements. The unrouted data handling assumes the timer
will not be restarted in any case unless otherwise the Router changes
the state from UD to J state.
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 7]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
4. Security
All PIM control messages may use IPsec [6] to address security concerns.
Security mechanisms are likely to be enhanced in the near future.
5. References
[1] D. Estrin, D. Farinacci, A. Helmy, D. Thalar, S. Deering,
M. Handley, V. Jacobson, C. Liu, P. Sharma, L. wei," Protocol
Independent Multicast- Sparse Mode", RFC 2362.
[2] Bill Fenner, Mark Handley, Hugh Holbrook,Isidor Kouvelas,
draft-ietf-pim-sm-v2-new-08.txt.
[3] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug
1989.
[4] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery
(MLD) for IPv6", RFC 2710.
[5] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan,
"Internet Group Management Protocol, Version 3", RFC 3376.
[6] Atkinson, R., "Security Architecture for the Internet Protocol",
RFC 1825(-> 2401prop).
6. Acknowledgements
The mechanism described in this document has been inspired by prior
work about supporting protocol independent multicast - sparse mode.
Specifically the draft authored by Bill Fenner, Mark Handley, Hugh
Holbrook, Isidor Kouvelas on protocol independent multicast - sparse
mode, most of the introduction inputs of this document has been taken
from the above draft and also which provided the motivation to come
up with this contribution.
We also wish to place on record the suggestions given by Sridhar T,
Anton Basil for this work. The support given by other well wishers
and friends during this work is recalled with gratitude.
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 8]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
7. Authors' Address
Musthafa A.S.
FutureSoft, a Flextronics Company,
480-481, Anna salai, Nandanam,
Chennai - 600 035, India
Phone : +91-44-24330550
Email : musthafaa@future.futsoft.com
Prince Sunny.
FutureSoft, a Flextronics Company,
480-481, Anna salai, Nandanam,
Chennai - 600 035, India
Phone : +91-44-24330550
Email : princes@future.futsoft.com
Masato Aketo.
Anritsu Corporation,
1800 Onna, Atsugi-shi,
Kanagawa-Prf.,
243-8555 Japan
Phone : +81-46-2966620
Email : aketo.masato@hh.anritsu.co.jp
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license under
such rights might or might not be available; nor does it represent
that it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 9]
INTERNET DRAFT Unrouted Data Handling in PIM August 2005
9. Full copyright statement
"Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights."
"This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Musthafa,Prince & Masato Aketo Expires March 1, 2006 [Page 10]
