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

21
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]

description

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]. Agenda. Motivation Background: Draft common multicast API Status of the draft Open issues Conclusion. - PowerPoint PPT Presentation

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

Page 1: 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]

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

2

Agenda

1. Motivation

2. Background: Draft common multicast API

3. Status of the draft

4. Open issues

5. Conclusion

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

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

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

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

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

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”);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

21

Thank you …

o Ready to adopt this draft as RG document?o More feedback is needed by RG members!