Post on 27-Mar-2015
transcript
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