1 / 22

Multicast in Information-Centric Networking

Multicast in Information-Centric Networking. Dirk.Kutscher@neclab.eu SAMRG@IETF83 March 2012. Mobile Data Traffic Prediction. From 2010 to 2015: factor 26 increase expected. Video Data Traffic Prediction. From 2010 to 2015: factor 5 increase expected.

baris
Download Presentation

Multicast in Information-Centric Networking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multicast inInformation-Centric Networking Dirk.Kutscher@neclab.eu SAMRG@IETF83 March 2012

  2. Mobile Data Traffic Prediction From 2010 to 2015: factor 26 increase expected ICN side meeting @ IETF-81

  3. Video Data Traffic Prediction From 2010 to 2015: factor 5 increase expected ICN side meeting @ IETF-81

  4. Popular Conception:Content Distribution Over the Internet Does Not Scale Tier 1 Networks ISPs ICN side meeting @ IETF-81

  5. Attempts to Mitigate • IP-Multicast • Packet-level one-to-many and many-to-many communication • Mostly used in controlled environments (e.g., IPTV distribution) • P2P • Enhancing scalability by distributing serving load • But: traffic management and peer selection control deemed necessary • Also: combining P2P w dedicated in-network storage (DECADE) • CDN • Enhancing scalability and performance by operating dedicated caches close to access networks • But: proprietary, standalone networks – increasing demand for interconnect: CDNI • Evolving specific system architectures • 3GPP EPS: mobile data offload ICN side meeting @ IETF-81

  6. Summary • Massive deployment of P2P, CDN • Represents a need for • Accessing named resources – not hosts • Scalable distribution through replication and caching • Good control of resolution/routing and access • But • We are engineering a lot of overlay infrastructure to make it happen • Using DNS, HTTP in creative ways • Still unresolved problems ICN side meeting @ IETF-81

  7. Problems Trusted Server Connect to Server X and get object B • Security • Can’t trust a copy received from an untrusted server • Trust on object authenticity today based on transport layer security (based on host name certificates) • CDN: ‘proxy TLS’ for enabling HTTPS with DNS rewriting • Application and content provider independence • CDNs focus on web content distributions for major players • What about other applications and other players? • Inefficient information dissemination • Can‘t benefit from existing copies (e.g. local copy on client) • ‏No “anycast”: e.g., get “nearest” copy • Flash-crowd effects, disruptions not well tolerated • Names can depend on location => 404 Not Found Server X B Secure Connection ICN side meeting @ IETF-81

  8. C D A E D A B A B E A B Problems • Security • Can’t trust a copy received from an untrusted server • Trust on object authenticity today based on transport layer security (based on host name certificates) • CDN: ‘proxy TLS’ for enabling HTTPS with DNS rewriting • Application and content provider independence • CDNs focus on web content distributions for major players • What about other applications and other players? • Inefficient information dissemination • Can‘t benefit from existing copies (e.g. local copy on client) • ‏No “anycast”: e.g., get “nearest” copy • Flash-crowd effects, disruptions not well tolerated • Names can depend on location => 404 Not Found A Trustable copy of object B D C B E Get object B Untrusted connection Untrusted server ICN side meeting @ IETF-81

  9. Problems • Security • Can’t trust a copy received from an untrusted server • Trust on object authenticity today based on transport layer security (based on host name certificates) • CDN: ‘proxy TLS’ for enabling HTTPS with DNS rewriting • Application and content provider independence • CDNs focus on web content distributions for major players • What about other applications and other players? • Inefficient information dissemination • Can‘t benefit from existing copies (e.g. local copy on client) • ‏No “anycast”: e.g., get “nearest” copy • Flash-crowd effects, disruptions not well tolerated • Names can depend on location => 404 Not Found ICN side meeting @ IETF-81

  10. Information-Centric Networking • Since we are mostly accessing named resources anyway • Design the network so that this is optimally supported • Considering important requirements • Accessing named data objects– not hosts • Scalable distribution through replication and caching • Good control of resolution/routing and access • With ubiquitous caching • But for all applications • And for all users and content/service providers Content Sources In-Network Caches ICN side meeting @ IETF-81

  11. Information-Centric Networking (ICN) Webbrowser Owner“Joe” OriginalContent “XY1” XY1 ICN side meeting @ IETF-81

  12. ICN Technical Topics • Naming of information objects • Unique object identification • Names as keys for request/content routing • Routing and Name Resolution • Want to locate “best” copy of named objects • Need a mapping/link between named objects and underlying network topology • Transport • Reliable, congestion- and flow-controlled transport of objects from a given location to interested receiver • Receiver-oriented transport – End-to-end vs. hop-by-hop • Security / Trust • Host-based e2e security no longer applies • Receiver is agnostic to object location Webbrowser Owner“Joe” OriginalContent “XY1” XY1

  13. 1) ICN Multicast Service • Multipoint communication as an implicit feature RequestAggregation Webbrowser Owner“Joe” OriginalContent “XY1” XY1

  14. 1) ICN Multicast Service • Multipoint communication as an implicit feature RequestAggregation DistributionTree Webbrowser Owner“Joe” OriginalContent “XY1” XY1

  15. 2) (IP) Multicast for ICN Multicast Domain B Multicast Domain A

  16. 2) (IP) Multicast for ICN Multicast Domain B GET XY1 Multicast Domain A

  17. 2) (IP) Multicast for ICN GET XY1 Multicast Domain B GET XY1 Multicast Domain A

  18. 2) (IP) Multicast for ICN OBJECT XY1 GET XY1 Multicast Domain B OBJECT XY1 GET XY1 Multicast Domain A

  19. Other Possible Multicast Employments • Carrousel-like data object distribution • FLUTE (RFC 3926) • Name resolution (think Multicast DNS) • Resolve data object name to lower layer locator • Locator can be IP address, group communication session specification etc.

  20. Current IETF/IRTF Work on ICN • DECADE • URI format for Named Information • draft-farrell-decade-ni • draft-hallambaker-decade-ni-params • DTNRG • Bundle Protocol Query Extension Block • draft-farrell-dtnrg-bpq • ICN in IRTF • http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

  21. URI Format for Named Information • Motivation: enabling naming of data objects with name-data integrity validation • Internet Draft draft-farrell-decade-ni • Flexible approach: common name format enabling different forms of name resolution and name-based routing • Basic idea: generic URIs for hash function outputs • Naming the hash function and an optional authority • Extensibility mechanism to include locators, decryption keys etc. • Currently text-based URI fomat – working on additional binary representation ni://example.com/sha-256-32;B_K97zTtFuOhug27fke4_Q ni://example.com/sha-256-32;B_K97zTtFuOhug27fke4_Q?alt=ni.example.net

  22. Running Code • https://sourceforge.net/projects/netinf/

More Related