Internet DRAFT - draft-akhunger-tod-multicast
draft-akhunger-tod-multicast
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]
