IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-12-0093-00-MuGM

Title: A Survey on Hybrid Multicast Mechanisms

Date Submitted: July 17, 2012

Presented at IEEE 802.21 session #51 in San Diego

Authors or Source(s):

 Yoshihiro Ohba (Toshiba)

Abstract: This document provides a survey of hybrid multicast mechanisms including application layer multicast.

121-12-0093-00-MuGM

21-12-0093-00-MuGM 2

IEEE 802.21 presentation release statementsThis document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis

for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21.

The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 

Multicast Architecture

ALM(RELOAD)

Common Multicast API

Hybrid Multicast API

draft-ietf-p2psip-base

draft-irtf-sam-hybrid-overlay-framework

draft-irtf-samrg-common-api

AMT

draft-ietf-mboned-auto-multicast

Multicast Applications

ALM: Application Layer Multicast AMT: Automated Multicast TunnelNM: Native Multicast

NM

DHTAlgorithms

(Chord, etc.)

Reliable Multicast

Mechanisms

draft-ietf-rmt-fcastdraft-ietf-rmt-flute-revised

321-12-0093-00-MuGM

ALM(RELOAD)

Common Multicast API

Hybrid Multicast API

draft-ietf-p2psip-base

draft-irtf-sam-hybrid-overlay-framework

draft-irtf-samrg-common-api

AMT

draft-ietf-mboned-auto-multicast

Multicast Applications

ALM: Application Layer Multicast AMT: Automated Multicast TunnelNM: Native Multicast

NM

DHTAlgorithms

(Chord, etc.)

Reliable Multicast

Mechanisms

draft-ietf-rmt-fcastdraft-ietf-rmt-flute-revised

421-12-0093-00-MuGM

ALM (Application Layer Multicast)• Implemented in RELOAD-based overlays

• Support for a variety of ALM control algorithms

• Providing a basis for defining a separate hybrid-ALM RELOAD Usage

521-12-0093-00-MuGM

RELOAD (REsource LOcation And Discovery )

• draft-ietf-p2psip-base

• RELOAD is a P2P signaling protocol providing a generic, self-organizing overlay network service

• A RELOAD node has a Node ID and stores Kinds in its storage• A RELOAD application (e.g., SIP, XMPP) defines a Usage

• RELOAD routing supports both node-based routing and resource-based routing• Both types of routing use a mandatory algorithm: DHT (Distributed Hash

Table) based on Chord• Other DHT algorithms can also be used if defined, such as CAN, Kademilia,

Pastry and Tapestry

• RELOAD provides a source routing capability in the form of Destination List. • A RELOAD message contains a Via List that records the route of the message

• TCP/UDP port 6084 is assigned for RELOAD621-12-0093-00-MuGM

RELOAD Architecture

SIPUsage

XMPPUsage

Message Transport Storage

Topology Plug-in

Forwarding & Link Management

TLS DTLS

Application

Messaging Service Boundary

Overlay Link Service Boundary

Transport

(Routing)

Network

Link

Layers in overlay

JoinLeaveUpdate

RouteQueryProbe

AttachAppAttach

Ping ConfigUpdate

StoreFetchStatFind

802.21dUsage

721-12-0093-00-MuGM

RELOAD Message Format

struct { uint32 relo_token; uint32 overlay; uint16 configuration_sequence; uint8 version; uint8 ttl; uint32 fragment; uint32 length; uint64 transaction_id; uint32 max_response_length; uint16 via_list_length; uint16 destination_list_length; uint16 options_length; Destination via_list[via_list_length]; Destination destination_list [destination_list_length]; ForwardingOptions options[options_length]; } ForwardingHeader;

Forwarding Header Message Contents Security Block

Each RELOADS message is signed

821-12-0093-00-MuGM

Modified Chord Algorithm in RELOAD• Chord consistently maps a key (Resource ID) onto a

node

• Each node keeps track of a finger table and a neighbor table

• The union of both tables forms a routing table

• The neighbor table contains at least the three peers before and after this peer in the DHT (Distributed Hash Table) ring where each peer is 1/2,1/4 and 1/8 of the way around the DHT ring.

• The Chord data structure can be thought of a doubly-linked list of successors and predecessor peers in the neighbor table, sorted by the Node-ID.

• Unlike the original Chord, a node with RELOAD-Chord can have multiple successors and predecessors

• A peer, n, is responsible for a particular key k if k is less than or equal to n and k is greater than p, where p is the Node-ID of the previous peer in the neighbor table

1/8 1/8

1/41/4

1/2

Finger Table

DHT Ring

SuccessorPredecessor

Neighbor TableRouting Table

Self

921-12-0093-00-MuGM

Routing• Default Algorithm

• If the receiving node n is responsible for a key k, then process it

• Otherwise, if n is directly connected to a node k, then send the message to node k

• Otherwise, if a node m that is the largest in nodes (n, k] is found, send the message to m.

• Otherwise, send the message to the smallest node > k

• RELOAD-Chord does recursive routing• In addition to the performance implications, the cost of NAT

traversal dictates recursive routing

• Iterative routing is supported through the RouteQuery mechanism and is primarily intended for debugging

1021-12-0093-00-MuGM

Joining the overlay network• JP connects to its chosen bootstrap node

• JP sends an Attach request to the admitting peer (AP) through the bootstrapping node. AP is currently responsible for the section of the overlay the JP will be responsible for.

• JP connects to AP. AP sends Update to populate its routing table.

• JP sends Attach requests to initiate connections to each of the peers in the desired routing table entries

• JP enters all the peers it has contacted into its routing table

• JP sends a Join to AP. AP sends Store requests to JP. JP store the received data that JP will be responsible for

• AP sends an Update to all of its neighbors with the new values of its neighbor set (including JP). At this point, JP becomes part of the overlay DHT ring as the predecessor of AP

• The JP sends Updates to all the peers in its neighbor table. The Update operation will be propagated to other overlay network nodes 1121-12-0093-00-MuGM

ALM(RELOAD)

Common Multicast API

Hybrid Multicast API

draft-ietf-p2psip-base

draft-irtf-sam-hybrid-overlay-framework

draft-irtf-samrg-common-api

AMT

draft-ietf-mboned-auto-multicast

Multicast Applications

ALM: Application Layer Multicast AMT: Automated Multicast TunnelNM: Native Multicast

NM

DHTAlgorithms

(Chord, etc.)

Reliable Multicast

Mechanisms

draft-ietf-rmt-fcastdraft-ietf-rmt-flute-revised

1221-12-0093-00-MuGM

Scalable Adaptive Multicast• draft-irtf-sam-hybrid-overlay-framework-02

• An experimental framework for constructing SAM sessions using hybrid combinations of Application Layer Multicast (ALM), native multicast (NM), and automated multicast tunnels (AMT)

• Multicast trees for hybrid multicast is maintained over RELOAD-based P2P

• The concept of SAM includes both scaling properties and adaptability properties

• Scalability:• large group size• large numbers of small groups• rate of group membership change• admission control for QoS• use with network layer QoS mechanisms• varying degrees of reliability• trees connect nodes over global internet

• Adaptability• use of different control mechanisms for different multicast trees depending on

initial application parameters or application class• changing multicast tree structure depending on changes in application

requirements, network conditions, and membership

1321-12-0093-00-MuGM

RELOAD-based Overlay Multicast Tree• For ALM, Scribe multicast defined in Pastry paper [6] is used:

• Group ID is a key (Resource ID)

• The root node for a group G is the node that has Group ID for G as a key

• A group G receiver joins the G tree

• The join request is routed using the overlay routing towards the root

• Some additional adaptations defined to support NM and AMT

1421-12-0093-00-MuGM

ALM(RELOAD)

Common Multicast API

Hybrid Multicast API

draft-ietf-p2psip-base

draft-irtf-sam-hybrid-overlay-framework

draft-irtf-samrg-common-api

AMT

draft-ietf-mboned-auto-multicast

Multicast Applications

ALM: Application Layer Multicast AMT: Automated Multicast TunnelNM: Native Multicast

NM

DHTAlgorithms

(Chord, etc.)

Reliable Multicast

Mechanisms

draft-ietf-rmt-fcastdraft-ietf-rmt-flute-revised

1521-12-0093-00-MuGM

Multicast API• draft-irtf-samrg-common-api-04

• This document describes a common multicast API suitable for underlay and overlay, and grants access to the different multicast flavors

• The API supports multiple multicast domains/technologies

• The API uses URI for multicast group identification

Multicast Technology

C

Multicast Technology B

Multicast Technology A

MemberG

IMG

IMG

MemberF

MemberG

MemberFMember

G

Reference Model

IMG: Inter-domain Multicast Gateway

1621-12-0093-00-MuGM

Multicast API• int createMSocket(int* result, size_t num_ifs, const uint32_t* ifs);• int deleteMSocket(int s);

• int join(int msock, const char* group_uri);• int leave(int msock, const char* group_uri);

• int srcRegister(int msock, const char* group_uri, size_t num_ifs, const uint32_t *ifs);• int srcDeregister(int msock, const char* group_uri, size_t num_ifs, const uint32_t *ifs);

• int send(int msock, const char* group_uri, size_t buf_len, const void* buf);• int receive(int msock, const char* group_uri, size_t buf_len, void* buf);

• int getInterfaces(int msock, size_t* num_ifs, uint32_t** ifs);• int addInterface(int msock, uint32_t iface);• int delInterface(int msock, uint32_t iface);

• int setTTL(int msock, uint8_t value, size_t num_ifs, uint32_t* ifs);• int getTTL(int msock, uint8_t* result);

1721-12-0093-00-MuGM

Multicast API (Cont’d)• typedef struct

• char* group_uri; /* registered mcast group */

• int type; /* 0: listener state, 1: sender state; 2: sender and listener state */

• } GroupSet;

• int groupSet(uint32_t iface, size_t* num_groups, GroupSet** groups);

• int neighborSet(uint32_t iface, const char* group_name, size_t* num_neighbors, char** neighbor_uris);

• int childrenSet(uint32_t iface, const char* group_name, size_t* num_children, char** children_uris);

• int parentSet(uint32_t iface, const char* group_name, size_t* num_parents, char** parents_uris);

• int designatedHost(uint32_t iface, const char* group_name);

• typedef void (*MembershipEventCallback)(int, /* event type */

• uint32_t, /* interface id */

• const char*); /* group uri */

• int registerEventCallback(MembershipEventCallback callback);

• int disableEvents();

1821-12-0093-00-MuGM

Example Use of Multicast API -- Application above middleware:

//Initialize multicast socket; //the middleware selects all available interfaces MulticastSocket m = new MulticastSocket();

m.join(URI("ip://224.1.2.3:5000")); m.join(URI("ip://[FF02:0:0:0:0:0:0:3]:6000")); m.join(URI("sip://news@cnn.com"));

-- Middleware:

join(URI mcAddress) { //Select interfaces in use for all this.interfaces { switch (interface.type) { case "ipv6": //... map logical ID to routing address Inet6Address rtAddressIPv6 = new Inet6Address(); mapNametoAddress(mcAddress,rtAddressIPv6); interface.join(rtAddressIPv6); case "dht": //... map logical ID to routing address DHTAddress rtAddressDHT = new DHTAddress(); mapNametoAddress(mcAddress,rtAddressDHT); interface.join(rtAddressDHT); //... } } }

1921-12-0093-00-MuGM

References[1] draft-irtf-samrg-common-api

[2] draft-irtf-sam-hybrid-overlay-framework

[3] draft-ietf-p2psip-base

[4] draft-ietf-mboned-auto-multicast

[5] I. Stoica, et al, “Chord: A Scalable Peer-to-peer Lookup service for Internet applications, SIGCOMM 2001

[6] M. Castro, et al, “SCRIBE: A large-scale and decentralized application-level multicast infrastructure”, IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 20, NO. 8, OCTOBER 2002.

2021-12-0093-00-MuGM