Re: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt

[Dom Robinson <[e-mail]>]

Thanks Ice / Greg  

Ok here is my first n00b stab at extending the text. I possibly need to read up on text formatting (use of brackets and terms like ‘layer4’) but perhaps let me share this as a way to refine the logic of what i feel could be included. My key thinking is that we are trying to avoid specifically involving IGMP and MBGP while still ‘allowing them’ and yet to open up for SDN / application layer control plane over-lay if a CDN operator wants to build that and still support BIER…

< feeling timid among such an esteemed crowd :) >

——

3.3.  IPTV, OTT and CDN Services  
IPTV is a service, well known for its characteristics of allowing both live and on-demand delivery of media traffic over Managed IP networks.  
  
Over The Top (OTT) is a similar service, well known for its characteristics of allowing live and on-demand delivery of media traffic between IP domains, where the source is often on an external network relative to the receivers.
  
Content Delivery Networks (CDN) operators provide layer 4 applications, and often some degree of managed layer 3 IP network, that enable media to be securely and reliably delivered to many receivers. In some models they may place applications within third party networks, or they may place those applications at the edges of their own managed network peerings and similar inter-domain connections. CDNs provide capabilities to help publishers scale to meet large audience demand. Their applications are not limited to audio and video delivery, but may include static and dynamic web content, or optimized delivery for Massive Multiplayer Gaming and similar. Most publishers will use a CDN for public Internet delivery, and some publishers will use a CDN internally within their IPTV networks to resolve layer 4 complexity.
  
  
In a typical IPTV environment the egress routers connecting to the receivers will build the tree towards the ingress router connecting to the IPTV servers.  The egress routers would rely on IGMP/MLD (static or dynamic) to learn about the receiver's interest in one or more multicast group/channels.  Interestingly, BIER could allows provisioning any new multicast group/channel by only modifying the channel mapping on ingress routers.  This is deemed beneficial for the linear IPTV video broadcasting in which every receivers behind every egress PE routers would receive the IPTV video traffic.
  
With BIER, there is no need of tree building from egress to ingress. Further, any addition of new channel or new egress routers can be directly controlled from ingress router.  When a new channel is included, the multicast group is mapped to Bit string that includes all egress routers.  Ingress router would start sending the new channel and deliver it to all egress routers.  As it can be observed, there is no need for static IGMP provisioning in each egress routers whenever a new channel/stream is added.  Instead, it can be controlled from ingress router itself by configuring the new group to Bit Mask mapping on ingress router.
  
In OTT services the receivers will often be on remote domains. These receivers may connect to the egress routers of a managed CDN that supports BIER. This will enable the CDN to efficiently deliver the content to many egress locations, in turn providing internal optimization.  
  
Where these egress routers connect directly to the Ingress BIER routers of downstream domains then a continuity of the scaling that BIER offers could be provided. This may rely on MBGP interoperation (or similar) between the egress of one domain and the ingress of the next domain, or some other SDN control plane may prove a more effective and simpler way to deploy BIER. For a single CDN operator this could be well managed in the Layer 4 applications that they provide and it may be that the initial receiver in a remote domain is actually an application operated by the CDN which in turn acts as a source for the Ingress BIER router in that remote domain, and by doing so keeps the BIER more descrete on a domain by domain basis.

---  

Looking forward to learning (a lot) from the feedback!

Hope it is useful…

Dom

Co-Founder, Director and Creative Firestarter @ id3as-company ltd
Innovation, Development, Architecture, Strategy
for IT, Cloud and StreamingMedia Projects
http://www.linkedin.com/in/domrobinson

Contributing Editor for StreamingMedia
http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm

Book out now on Wiley.com “Advanced Content Delivery, Streaming, and Cloud Services” : http://bit.ly/1r1ttEG (http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118575210,descCd-buy.html?dmmspid=25526142&dmmsmid=88793&dmmsuid=2334962)


On Monday, 2 February 2015 at 11:55, IJsbrand Wijnands wrote:

> Hi Dom,
>  
> Your email made it to the list just fine.
>  
> I think your use-case makes sense. Since the content is driven from the source side, the operator can just identify the CDN’s and push the content to it. What is nice is that you don’t need to make the CDN’s pre-join a multicast tree in order to push the data to it. There could also be a nice SDN user interface to it as well :-)
>  
> Why don’t you go ahead with preparing the text and we’ll add the content with you as co-author, ok?
>  
> Thx,
>  
> Ice.
>  
> > On 02 Feb 2015, at 12:05, Robinson, Dom <[e-mail] (mailto:[e-mail])> wrote:
> > (Greg - I am not sure if i eventually got allowed to post this - i cant see it in my own inbox although i did receive a mail from the BIER mailer asking me to confirm, which i did..  
> >  
> > Perhaps I have to post again: so please see comment below (assuming this makes it) else can you guys perhaps forward my input to the list?
> >  
> > Dom
> >  
> > On 1 February 2015 at 01:23, Robinson, Dom <[e-mail] (mailto:[e-mail])> wrote:
> > > Hi guys - i wonder if it would be worth extending the IPTV section to embrace content pre-placement in not only IPTV, but OTT and even big-software update and other such CDN activity: I stay close to IP Multicast specifically for this use case, and I always think it is interesting that while live/linear is an obvious Multicast candidate, pre-placing content in many caches that is known to be 'about to be heavily requested' is actually an extremely valuable capability - even if it is not live....
> > >  
> > > Just a thought.
> > >  
> > > While i am a n00b to the formality of an IETF draft, if you like i would be happy to try to extend that IPTV paragraph to try to explain that 'CDN' focussed use case...?
> > >  
> > > Let me know - ill try to contribute before the start of next week....
> > >  
> > > Kind regards  
> > >  
> > > Dom
> > >  
> > > On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) <[e-mail] (mailto:[e-mail])> wrote:
> > > > Hi,
> > > >  
> > > > Below is the updated version of BIER use case draft.
> > > >  
> > > > Please read and share your comments.
> > > >  
> > > > Regards,
> > > > Nagendra
> > > >  
> > > >  
> > > >  
> > > > On 1/30/15, 3:40 PM, "[e-mail] (mailto:[e-mail])" <[e-mail] (mailto:[e-mail])>
> > > > wrote:
> > > >  
> > > > >
> > > > >A New Internet-Draft is available from the on-line Internet-Drafts
> > > > >directories.
> > > > >
> > > > >
> > > > >        Title           : BIER Use Cases
> > > > >        Authors         : Nagendra Kumar
> > > > >                          Rajiv Asati
> > > > >                          Mach(Guoyi) Chen
> > > > >                          Xiaohu Xu
> > > > >                          Andrew Dolganow
> > > > >                          Tony Przygienda
> > > > >                          Arkadiy Gulko
> > > > >       Filename        : draft-kumar-bier-use-cases-01.txt
> > > > >       Pages           : 11
> > > > >       Date            : 2015-01-30
> > > > >
> > > > >Abstract:
> > > > >   Bit Index Explicit Replication (BIER) is an architecture that
> > > > >   provides optimal multicast forwarding through a "BIER domain" without
> > > > >   requiring intermediate routers to maintain any multicast related per-
> > > > >   flow state.  BIER also does not require any explicit tree-building
> > > > >   protocol for its operation.  A multicast data packet enters a BIER
> > > > >   domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
> > > > >   BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
> > > > >   The BFIR router adds a BIER header to the packet.  The BIER header
> > > > >   contains a bit-string in which each bit represents exactly one BFER
> > > > >   to forward the packet to.  The set of BFERs to which the multicast
> > > > >   packet needs to be forwarded is expressed by setting the bits that
> > > > >   correspond to those routers in the BIER header.
> > > > >
> > > > >   This document describes some of the use-cases for BIER.
> > > > >
> > > > >
> > > > >The IETF datatracker status page for this draft is:
> > > > >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/
> > > > >
> > > > >There's also a htmlized version available at:
> > > > >http://tools.ietf.org/html/draft-kumar-bier-use-cases-01
> > > > >
> > > > >A diff from the previous version is available at:
> > > > >http://www.ietf.org/rfcdiff?url2=draft-kumar-bier-use-cases-01
> > > > >
> > > > >
> > > > >Please note that it may take a couple of minutes from the time of
> > > > >submission
> > > > >until the htmlized version and diff are available at tools.ietf.org (http://tools.ietf.org/).
> > > > >
> > > > >Internet-Drafts are also available by anonymous FTP at:
> > > > >ftp://ftp.ietf.org/internet-drafts/
> > > > >
> > > > >_______________________________________________
> > > > >I-D-Announce mailing list
> > > > >[e-mail] (mailto:[e-mail])
> > > > >https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > >Internet-Draft directories: http://www.ietf.org/shadow.html
> > > > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >  
> > > > _______________________________________________
> > > > BIER mailing list
> > > > [e-mail] (mailto:[e-mail])
> > > > https://www.ietf.org/mailman/listinfo/bier
> > >  
> > >  
> > >  
> > > --  
> > > Dom Robinson
> > > Co-Founder, Director and Creative Firestarter @ id3as-company ltd
> > > Innovation, Development, Architecture, Strategy
> > > for IT, Cloud and StreamingMedia Projects
> > > uk.linkedin.com/in/domrobinson (http://uk.linkedin.com/in/domrobinson)
> > >  
> > > Also Contributing Editor for www.StreamingMedia.com (http://www.streamingmedia.com/)
> > > http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm
> > >  
> > >  
> > >  
> >  
> >  
> >  
> >  
> >  
> > --  
> > Dom Robinson
> > Co-Founder, Director and Creative Firestarter @ id3as-company ltd
> > Innovation, Development, Architecture, Strategy
> > for IT, Cloud and StreamingMedia Projects
> > uk.linkedin.com/in/domrobinson (http://uk.linkedin.com/in/domrobinson)
> >  
> > Also Contributing Editor for www.StreamingMedia.com (http://www.streamingmedia.com/)
> > http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm
> >  
> >  
> > _______________________________________________
> > BIER mailing list
> > [e-mail] (mailto:[e-mail])
> > https://www.ietf.org/mailman/listinfo/bier
>