[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                         A. Khunger
Internet-Draft                              Flextronics Software Systems
Expires: March 5, 2006                                 September 1, 2005


                Inserting Advertisements in IP multicast
                 draft-akhunger-ad-insert-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 March 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Providing a Standard method for Addition of regional Advertisements
   in the IP Multicast Video Streaming is very important , because the
   equipment deployed would most likely be from different vendors across
   a multicast network.

   The idea is to introduce a special kind of Enhanced IGMP Ad-Insert
   control packet, which is passed from the multicast source to
   intermediate routers and which indicates that the source is going to
   stop sending multicast traffic for a particular group for specified



Khunger                   Expires March 5, 2006                 [Page 1]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


   time and the Regional center can utilize this time to insert its
   regional advertisement.

















































Khunger                   Expires March 5, 2006                 [Page 2]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


1.  Introduction

   The Internet Group Management Protocol (IGMP) is used by IPv4 systems
   to report their IP Multicast group memberships to any neighboring
   Multicast routers.  Typical applications for the IP multicast include
   video streaming , enterprise wide broadcasts, training etc.  Video
   Streaming application has a lot of potential and is being worked upon
   by various vendors

   The idea presented in this draft is to introduce a special kind of
   Enhanced IGMP Ad-Insert control packet for the Video Streaming
   application.

   Television amonuts to 37 percent of total advertising revenue in US
   and 43 percent in Japan.  Video Streaming using IP Multicast has a
   similar potential for generating advertising revenues and thus
   standardization efforts should be put to realize its potential.

   This Ad-Insert message is passed from the multicast source to
   intermediate routers and it indicates that the source is going to
   stop sending multicast traffic for a particular group for specified
   time and the Regional center can utilize this time to insert its
   regional advertisement.




























Khunger                   Expires March 5, 2006                 [Page 3]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


2.  Motivation

   One of the main advantages with Ad-Insert IGMP control packet is
   that, the schedule of when to insert ads in the content remains
   flexible .  Thus if there is a game live telecast going on and you
   have a timeout then you can actually indicate to regional centers to
   utlize that time to insert their Ads.

   Also having this Ad-Insert signalling removes need for huge
   configurations about hundreds of advertising slots in hundreds of
   multicast streams passing through network devices.

   In any multicast, Original Source is the one who knows best the
   correct points when it makes logical sense to introduce
   advertisements.  However regional centers are best suited for launch
   of ads which are targeted to a particular geographical audience.
   Also providing a mechanism to add their own advertisements, provides
   motivation for the regional centres to become intermediate multicast
   forwarders - leading to increase of multicast video streaming
   popularity.

   Providing the coding mechanisms of traffic make it difficult for the
   regional centres to decipher when to insert advertisements without
   disturbing traffic's quality delivery and the mechanisms to do it can
   be quite complex.  Thus providing them with a cue when to insert can
   be helpful.

























Khunger                   Expires March 5, 2006                 [Page 4]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


3.  Applicability

   The source of the multicast will provide for two or multiple levels
   of advertisement slots in the traffic content.  First level of
   advertisements are targeted to the audience of all receivers which
   subscribe to this multicast group.  These are inserted with the
   content by source itself.  Second levels can be based on service
   provider, region or any other criteria.

   Taking an example of regional distribution , regional centres will be
   informed by source, by sending a Enhanced Ad-Insert IGMP control
   packet that the source has stopped or will stop sending the content
   for a particular time period and this time can be used by regional
   center to insert second level/regional advertisements.

   There can be an overall agreement whereby the regional center knows
   that in every cycle period - there will be commericals for how much
   time - for example it could be that every one hour there will be five
   minute commercials - however it depends on the program being streamed
   as to how these five minutes are divided and when do they start.

   The regional centre collects ads beforehand and these are played when
   the Ad-Insert message is received or at the time specified by source
   in Ad-Insert message

   The Ad-Insert message can be used in two ways.  One message is of
   Immediate nature, which indicates that the Ad-Insert message itself
   indicates that traffic from source has already stopped.  The other
   one gives a schedule in terms of Date and Time when the source will
   stop sending content traffic and Regional center can then insert its
   advertisements.

   For Scheduled Ad-Insert messages it is assumed that the there is a
   standard method for obtaining time, adopted by each source and
   regional center

   As there is no need for the regional center to decode content coming
   from source for inserting Ads - the time taken and complexity of
   equipment to insert ads should be much less than existing solutions.

   Regional Center advertisement traffic also has group address as
   destination address.  The destination IP address of the Ad-Insert
   IGMP packet is group multicast address itself, if the ad-insert is
   for a immediate play.

   However if the source needs to send ad-insert information for
   scheduled inserts for multiple groups , it can send the traffic onto
   ALL-ROUTERS destination address.



Khunger                   Expires March 5, 2006                 [Page 5]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


   The Regional Center is only supposed to play the ads to hosts within
   its network.  If the regional center is also forwarding the traffic
   to another regional center (in another network) it will simply pass
   the Enhanced Ad-Insert IGMP message on the port connecting to other
   network.  The regional center of other network will start playing its
   ad to subscribers which belong to its network once it gets Ad-Insert.













































Khunger                   Expires March 5, 2006                 [Page 6]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


4.  Impact on End Applications

   Because the hosts will receive Ad's traffic with same multicast IP
   address they will not be able to seperate it out.  Thus the user cant
   just drop the traffic with those Ads.

   However multicast applications running over IP on host, may have
   their own sequence numbering or ordering mechanisms for displaying
   multicast content - the source can provide this sequencing
   information to regional centers so that they can use these sequence
   numbers to generate traffic.  Another mechanism could be that streams
   before and after the advertisement are considered as two seperate
   sessions and client application is able to do sequencing
   correspondingly.





































Khunger                   Expires March 5, 2006                 [Page 7]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


5.  Message Formats

   The following sections highlight the message formats

5.1.  Ad-Insert IGMP Message

   This message is sent by Source to the Intermediate muticast routers.
   It is processed by routers which act as Regional Centers to insert
   ads to their directly attached customers.  The Ad-Insert message is
   passed as-it-is by these regional centers further on ports which
   connect to other regional centers.




          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         | Start Flag    |   Duration in millisec        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Number of Scheduled Ad-Insert Time Records              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   where each scheduled Ad-Insert Time Record is of the following type.


         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                 Group Address                                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   TimeZone    |   Year        |  Month        |    Day        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Hour        |     Minutes   |   Seconds     | Milliseconds  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Duration in millisec         |   Source Specific Info        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The fields in this enhanced Report include the following information

   Type

   The value of Type indicates that this is a Ad-Insert type of IGMP
   message and distinguishes this message from other IGMP messages

   Start Flag

   This indicates whether the advertisement has to be inserted



Khunger                   Expires March 5, 2006                 [Page 8]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


   immediately or at the scheduled times which are specfied by further
   fields in the packet

   Duration in millisec

   This indicates the duration for which the regional center can play
   their Ads. This field is only relevant if the Start flag has value as
   Immediate Play.

   Number of Scheduled Ad-Insert Time Records

   If the start flag indicates Scheduled Inserts than this field
   indicates the number of Time Records which are present in this Ad-
   Insert message

   Group Address

   This indicates that for which Group Address this Ad-Insert Schedule
   is relevant.

   TimeZone

   Indicates the timezone as per which the following time is described

   Year, Month, Day, Hour, Minute, Second, Millisecond

   These indicate when the Insertion of Ad by regional center should
   start

   Source Specific Info

   This is used by sources if they wish to inform something specific to
   regional center, usage of this field will be developed in future

5.2.  Future Directions

   As the industry evolves there can be future evolution of methods of
   inserting regional advertisements.

   Inserted commercials can be customized as per individual viewers/
   group profiles because regional centers can have better information
   about their viewers

   The commercials can be made more interactive by providing a way for
   viewers to stream back their responses which can then be processed by
   regional centers

   There can also be multiple levels where the hierarchy of who is



Khunger                   Expires March 5, 2006                 [Page 9]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


   allowed to insert and who is not allowed in which timeslot can be
   defined

5.3.  Security Considerations

   As with all other IGMP messages Ad-Insert message will also need
   security provisions to avoid misuse.  Also the cooperation between
   different network operators to pass the Ad-Insert would be crucial
   for success of this approach.

6.  References

   [1]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
        Thyagarajann, "Internet Group Management Protocol, Version 3".





































Khunger                   Expires March 5, 2006                [Page 10]


Internet-Draft  Inserting Advertisements in IP multicast  September 2005


Author's Address

   Ajeet Khunger
   Flextronics Software Systems
   Plot 31 Sector 18 Electronic City,
   Gurgaon, Haryana  122015
   India

   Phone: +1 818 878 4421
   Email: ajeet.khunger@flextronicssoftware.com









































Khunger                   Expires March 5, 2006                [Page 11]


Internet-Draft  Inserting Advertisements in IP multicast  September 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 March 5, 2006                [Page 12]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/