Network Working Group A. Khunger Internet-Draft Flextronics Software System Expires: February 18, 2006 August 17, 2005 Day and Time based IP Multicast draft-akhunger-tod-multicast-00 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 February 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies enhancement to the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP Multicast group memberships to neighboring Multicast routers. This enhancement for IGMP adds support for "specifying day, time and duration with Multicast reports", that is, the ability for a system to report interest in receiving traffic for a particular Multicast address at a particular day, time and for a specific duration. This information may be used by intermediate routers and switches to ensure providing better Quality of Service. Also Khunger Expires February 18, 2006 [Page 1] Internet-Draft Day and Time based IP Multicast August 2005 specifying such information in a consolidated packet may help reduce signaling load on the multicast routers. Khunger Expires February 18, 2006 [Page 2] Internet-Draft Day and Time based IP Multicast August 2005 1. Introduction The Internet Group Management Protocol (IGMP) is used by IPv4 systems (hosts and routers) to report their IP Multicast group memberships to any neighboring Multicast routers. Typical applications for the protocol include video streaming , enterprise wide broadcasts, training etc. These applications are going to require huge bandwidth and thus guarantying QoS would be a challenge. Also zapping requirements for applications like video streaming, leads to a lot of burden on the nodes for signaling. Multicast applications and business models are evolving and it becomes important to provide maximum flexibility to service providers through protocol support.One such initiative could be to provide option where in some scenarios, the IGMP hosts/proxies may be able to define some of their subscriptions in advance, helping the intermediate routers to distribute signaling load and manage QoS in a better way. This propsal allows the hosts to specify the day, time and duration for each multicast session, when the host wants to receive traffic for particular multicast group address. In such scenario, even though the IGMP hosts would have specified their choice of multicast groups for particular time and duration in advance, they are still allowed to change their pre stated subscriptions at that time and choose to receive packets for some other multicast address by giving a new join, but service providers can charge them extra for doing so. The solution being proposed is interoperable with existing IGMP versions as these fields are optional. Khunger Expires February 18, 2006 [Page 3] Internet-Draft Day and Time based IP Multicast August 2005 2. Motivation The importance of bandwidth management is going to realized much more seriously, with the success of Multicast traffic and resulting applications. Also the load of zapping will start becoming visible when millions of people start swapping channels using applications like Multicast video streaming. The fact that many users are accustomed to watching some programmes on TV in a periodic manner and they at times, are well aware of what they are going to wish to view well in advance. Or the fact that Broadcasts and trainings are mostly scheduled for a particular time of day and duration - makes one think whether this special characteristic of multicast traffic patterns can be utilized to provide better bandwidth management and signaling response time for Multicast applications. Also there has to be realization that the resources used by a host, who changes channels too often is too high, than a user who knows what he/she wants to see well in advance. Thus the network provider has the authority to get extra revenue for this additional resource usage. We could think of a business model wherein users can be given a discount for telling their preferences in advance and these preferences could be in terms of [ GA, Src, Time of Day, Duration] type of tuples. Khunger Expires February 18, 2006 [Page 4] Internet-Draft Day and Time based IP Multicast August 2005 3. Applicability A sample scenario could be that in a network a service provider asks all possible IGMP users to submit their preferences by Saturday or Sunday, for the forthcoming week. So these new fields of time of day and duration are only accepted in IGMP messages - for these two days from hosts and this cycle repeats every week. The users already have the Guide to what all is going to be available on what all multicast channnels at what time in the coming week and they make a choice and send that list across to the multicast provider through Enhanced IGMP Join message. The Multicast Service provider now has a lot of time to process these requests and decide on the most efficient routes for the traffic flow. By knowing "most likely" traffic pattern for the next week - now the Service providers are in a position for guiding customers who are still looking for scheduling their multicast sessions - about the best possible times where they can gurantee fast and reliable data transfer. Only one Enhanced IGMP Message will be accepted from a host during one collection cycle period [ Saturday/ Sunday in this example]. Any changes in preference will have to be done by indiviual join for multicast traffic at the intended time of reception. Khunger Expires February 18, 2006 [Page 5] Internet-Draft Day and Time based IP Multicast August 2005 4. Implications on Quality of Service Service Providers can plan to route the traffic in better once they have information in advance - for example they can have a knowledge about what the traffic pattern is going to be in next one week , based on inputs from subscribers - they can decide on thier options for providing quality service more efficiently. Network operators may configure routes manually as per traffic needs displayed by the advance information, or the Routing Protocol path computation algorithms may also undergo a change to utilize this information. Knowing the traffic patterns in advance doesnt only allow efficient usage of resources but can help the service providers offer premium services with QoS SLAs Khunger Expires February 18, 2006 [Page 6] Internet-Draft Day and Time based IP Multicast August 2005 5. Implications on signaling load This enhancement allows service providers to have the subscription information in advance for a period , which could be decided by the network provider - it could be a day , it could be week or whatever. IGMP Host sends the list of subscriptions that for period and the network devices have a lot of time to process such information completely - thus the load of signaling is less. Also because many subscriptions are going to be consolidated in a message - the total number of packets for join will reduce. Another advantage is that the duration is alrfeady specfied at the time of join - thus an explicit leave is not necssary, removing some more extra protocol traffic. Also this feature allows an extra pricing on users just browsing through various channels thus leading to extra revenue generation proportional to amount of signaling load generated by users on network devices. Khunger Expires February 18, 2006 [Page 7] Internet-Draft Day and Time based IP Multicast August 2005 6. Message Formats The following sections highlight the message formats 6.1. Membership Query Message Membership Queries are sent by IP Multicast routers to query the Multicast reception state of neighboring interfaces. Queries have the following format, which is same as defined by IGMPv3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x11 | Max Resp Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv |S| QRV | QQIC | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address [1] | +- -+ | Source Address [2] | +- . -+ . . . . . . +- -+ | Source Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2. Membership Report Message Khunger Expires February 18, 2006 [Page 8] Internet-Draft Day and Time based IP Multicast August 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x22 | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Group Records (M) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [M] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of session Time (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Session Time 1 . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Session Time N . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Khunger Expires February 18, 2006 [Page 9] Internet-Draft Day and Time based IP Multicast August 2005 where each Group Record has the following internal format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Type | Aux Data Len | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address [1] | +- -+ | Source Address [2] | +- -+ . . . . . . . . . +- -+ | Source Address [N] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Auxiliary Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each Session Time Information has the following internal format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Group Record Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeZone | Year | Month | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Show Day | Show Hour | Show Minutes| Show Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration Day | Dur Hour | Dur Minutes | Dur Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in this enhanced Report include the following information Number of Session Time This indicates the number of session for which information is included in the message TimeZone Khunger Expires February 18, 2006 [Page 10] Internet-Draft Day and Time based IP Multicast August 2005 This is used to identify the timezone when host has shown interest to receive traffic Year, Month Indicates year and month for receiving multicast traffic for that group Show day, hour, minutes, seconds This indicates the day and time of day when the host wishes to receive multicast traffic for this group. These timings have to be wihin Cycle period. Duration Day, hour, minutes, seconds This indicates the duration for which Host wishes to receive the multicast traffic for this group. 6.3. Compatibility with earlier versions This enhancement in no way tries to rule out any of the features possible with earlier IGMP versions. Even if a user utilizes the new "Session Time" information option - IGMP host still has the flexibility to change the preference of channel at the time by giving a leave and a join - however this enhancement allows the service provider to charge them extra - for using such privilege. 6.4. Security Considerations The data provided in enhanced multicast joins is very sensitive as it nearly highlights a person's proposed schedule to some extent - thus it is important that it is passed in a secure manner. Thus Encryption and authentication mechanisms must be employed on the Enhanced IGMP messages. 7. References [1] Cain B., Deering S., Kouvelas I., Fenner B., and A. Thyagarajann, "Internet Group Management Protocol, Version 3". Khunger Expires February 18, 2006 [Page 11] Internet-Draft Day and Time based IP Multicast August 2005 Author's Address Ajeet Khunger Flextronics Software System Plot 31 Sector 18 Electronic City, Gurgaon, Haryana 122015 India Phone: +1 818 878 4421 Email: ajeet.khunger@flextronicssoftware.com Khunger Expires February 18, 2006 [Page 12] Internet-Draft Day and Time based IP Multicast August 2005 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Khunger Expires February 18, 2006 [Page 13]