1 / 21

A Common API for Transparent Hybrid Multicast ( draft-waehlisch-sam-common-api-04)

A Common API for Transparent Hybrid Multicast ( draft-waehlisch-sam-common-api-04). Matthias Wählisch, Thomas C. Schmidt Stig Venaas {waehlisch, t.schmidt}@ieee.org, stig@cisco.com. Agenda. Motivation Background: Draft common multicast API Status of the draft Open issues Conclusion.

carver
Download Presentation

A Common API for Transparent Hybrid Multicast ( draft-waehlisch-sam-common-api-04)

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. A Common API for Transparent Hybrid Multicast(draft-waehlisch-sam-common-api-04) Matthias Wählisch, Thomas C. Schmidt Stig Venaas {waehlisch, t.schmidt}@ieee.org, stig@cisco.com

  2. Agenda • Motivation • Background: Draft common multicast API • Status of the draft • Open issues • Conclusion

  3. Current Multicast Diversity Group communication services exist in a variety of: • Different flavors • Any Source Multicast vs. Source-specific Multicast • Different technologies • IPv4 vs. IPv6, multicast tunnels, etc. • Different layers • Native multicast vs. overlay distribution

  4. Multicast Application Implementation (1) MulticastSocket msock = new MulticastSocket(); msock.send(data,224.1.2.3); msock.send(data,ff3e:0:0:0:224:1:2:3); Additional problem: No global multicast deployment

  5. Multicast Application Implementation (2) ALMSocket almsock = new ALMSocket(); almsock.send(data,”CNN”); MulticastSocket msock = new MulticastSocket(); msock.send(data,224.1.2.3);

  6. Implications • Programmers decide on technology at coding time • How do they know about the multicast deployment state at this time? • Lack of efficiency • Reasonable to assume no global IP-layer multicast • Applications provide their own solutions to overcome inter-domain deployment problem • Increases complexity & introduce redundancy • Difficult to write multicast applications that run everywhere& use most efficient group service

  7. Intermediate Summary • APIs for specific group communication services are around • No common identification of multicast group beyond technologies • Easy development of global multicast applications requires a common interface to all multicast stacks

  8. Recall: Common Multicast API Draft Idea: Move complexity from application to the system level The current draft provides … • a common multicast API on app. layer that abstracts group communication from distribution technologies • abstract naming and addressing by multicast URIs • mapping between naming and addressing • definition of protocol interaction to bridge multicast data between overlay and underlay

  9. Terminology • Group Name: application identifier that is used by applications to manage a multicast group • Group Address: routing identifier that is used to distribute multicast data • Interface: forwarding instance of a distribution technology on a given node

  10. Common Multicast API & Middleware • Mapping of names to technologies during run-time • Late binding

  11. Example Common Multicast API MulticastSocket msock = new MulticastSocket(); msock.send(data,mygroup.org); hash(mygroup.org) 224.1.2.3 hash(mygroup.org)

  12. Group Name • Applications subscribe to Group Name(s) • Group Communication stack maps Name toGroup Address How do we encode the Group Name? • Consistent encoding for flavors & technologies required • Wise choice is important for mapping function • A meta-data type that reflects identifier + namespace is an URI

  13. Proposed URI Scheme • scheme "://" group "@" instantiation ":" port "/" sec-credentials • scheme:specification of assigned ID • group: identifies the group • instantiation: ID of the entity that generates the instance of the group, e.g., for SSM • port: ID of a specific application at a group instance • sec-credentials: used for optional authentication • Example: ip://224.10.20.30@1.2.3.4:5000/groupkey

  14. Ups … Your scheme includes technology-specific IDs? • Scheme does not predefine routing layer • It is only used on the application side • Applications use context-specific names, anyway • Programming library may provide parsing functions • Automatic namespace identification • Again: Knowledge about the naming context may facilitate mapping significantly

  15. “Why is this beyond SourceForge?” • Extension of current multicast socket API • Standard API/functions enable global deployment • Introduces a common naming to access mcast content • Consistent mapping requires definition • Propose protocol interaction using API to implement hybrid multicast gateways • This is beyond an open software library

  16. Use Cases for the Common Multicast API • Application programming independent of technologies • Global identification of groups • Simplified service deployment through generic gateways • Mobility-agnostic group communication

  17. Status • Version 00/01 presented at IETF 76, Hiroshima • Update version 02 presented at IETF 77, Anaheim • Interesting work, but needs extended motivation • Current version: 04 • Version 03 submitted before 78th IETF • Ongoing work on prototype implementation (C++) • Demo will be presented at EuroView’10, Würzburg, next week

  18. Changes from Version 02 to 03/04 • Renaming of functions • Rephrased API calls in C-style • No pseudo code used: Does this help? • Additional service calls added for inquiring on the multicast distribution system • Many editorial improvements

  19. Open Issues • Definition of mapping scheme including ASM/SSM consideration • More detailed description of the URI scheme usage • Use case for security credentials • Description of corporate usage of current and common group communication API • Regarding implementation: Are there any convenience functions that would be useful? • More detailed error codes?

  20. Conclusion • Programmers need a common access to different multicast flavors and technologies • Move complexity from application to the system level • Architecture allows for adaptive selection of group communication services at run-time • Accounts for deployment characteristics

  21. Thank you … • Ready to adopt this draft as RG document? • More feedback is needed by RG members!

More Related