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]