1. 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. 2 Agenda 1. Motivation 2. Background: Draft common multicast API 3. Status of the draft 4. Open issues 5. Conclusion

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

4. 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. 5 Multicast Application Implementation (2) MulticastSocket msock = new MulticastSocket(); msock.send(data,224.1.2.3); ALMSocket almsock = new ALMSocket(); almsock.send(data,”CNN”);

6. 6 Implications o Programmers decide on technology at coding time - How do they know about the multicast deployment state at this time? o Lack of efficiency - Reasonable to assume no global IP-layer multicast o 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. 7 Intermediate Summary o APIs for specific group communication services are around o No common identification of multicast group beyond technologies o Easy development of global multicast applications requires a common interface to all multicast stacks

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

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

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

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

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

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

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

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

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

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

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

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

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

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