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

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!