A Common API for Transparent Hybrid Multicast ( draft-waehlisch-sam-common-api-04)
description
Transcript of 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, [email protected]
2
Agenda
1. Motivation
2. Background: Draft common multicast API
3. Status of the draft
4. Open issues
5. Conclusion
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
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
IPv6
Rcv AFF3E:0:0:
0:224:1:2:3
Src 224.1.2.3,FF3E:0:0:
0:224:1:2:3
Rcv B224.1.2.3
IPv4
5
Multicast Application Implementation (2)
IPv6IPv6
Rcv A“CNN”
Src 224.1.2.3,
“CNN”
IPv4
Rcv C“CNN”
Rcv B224.1.2.3
MulticastSocket msock = new MulticastSocket(); msock.send(data,224.1.2.3);
ALMSocket almsock = new ALMSocket(); almsock.send(data,”CNN”);
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 multicasto 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
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
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 addressingo definition of protocol interaction to bridge
multicast data between overlay and underlay
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
Common Multicast API & Middleware
Src my
group.org
MulticastSocket msock = new MulticastSocket(); msock.send(data,”mygroup.org”);
1. Mapping of Group Name to Addresses2. Send data to technology specific interfaces
Application Level
OS Level
hash(mygroup.org) 224.1.2.3
o Mapping of names to technologies during run-time
o Late binding
11
Example Common Multicast API
IPv6IPv6
Rcv Amygroup.org
Src mygroup.org
IPv4
Rcv Cmygroup.org
Rcv Bmygroup.org
MulticastSocket msock = new MulticastSocket(); msock.send(data,mygroup.org);
hash(mygroup.org)
hash(mygroup.org)224.1.2.3
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
requiredo Wise choice is important for mapping functiono A meta-data type that reflects identifier +
namespace is an URI
13
Proposed URI Scheme
o scheme "://" group "@" instantiation ":" port "/" sec-credentials
o scheme: specification of assigned IDo group: identifies the groupo instantiation: ID of the entity that generates
the instance of the group, e.g., for SSMo port: ID of a specific application at a group
instanceo sec-credentials: used for optional
authenticationo Example:
ip://[email protected]:5000/groupkey
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
“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 definitiono 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
o Application programming independent of technologies
o Global identification of groupso Simplified service deployment through generic
gatewayso Mobility-agnostic group communication
17
Status
o Version 00/01 presented at IETF 76, Hiroshimao Update version 02 presented at IETF 77,
Anaheim- Interesting work, but needs extended motivation
o Current version: 04- Version 03 submitted before 78th IETF
o 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
o Renaming of functionso 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
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
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
Thank you …
o Ready to adopt this draft as RG document?o More feedback is needed by RG members!