Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

1 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

2 2 IEEE 802.21 presentation release statements This 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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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 and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/board/pat/faq.pdf

3 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 Tunnel NM: Native Multicast NM DHT Algorithms (Chord, etc.) Reliable Multicast Mechanisms draft-ietf-rmt-fcast draft-ietf-rmt-flute-revised 321-12-0093-00-MuGM

4 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 Tunnel NM: Native Multicast NM DHT Algorithms (Chord, etc.) Reliable Multicast Mechanisms draft-ietf-rmt-fcast draft-ietf-rmt-flute-revised 421-12-0093-00-MuGM

5 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

6 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 RELOAD 621-12-0093-00-MuGM

7 RELOAD Architecture SIP Usage XMPP Usage Message TransportStorage Topology Plug-in Forwarding & Link Management TLSDTLS Application Messaging Service Boundary Overlay Link Service Boundary Transport (Routing) Network Link Layers in overlay Join Leave Update RouteQuery Probe Attach AppAttach Ping ConfigUpdate Store Fetch Stat Find 802.21d Usage 721-12-0093-00-MuGM

8 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 HeaderMessage ContentsSecurity Block Each RELOADS message is signed 821-12-0093-00-MuGM

9 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/4 1/2 Finger Table DHT Ring SuccessorPredecessor Neighbor Table Routing Table Self 921-12-0093-00-MuGM

10 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

11 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

12 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 Tunnel NM: Native Multicast NM DHT Algorithms (Chord, etc.) Reliable Multicast Mechanisms draft-ietf-rmt-fcast draft-ietf-rmt-flute-revised 1221-12-0093-00-MuGM

13 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

14 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

15 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 Tunnel NM: Native Multicast NM DHT Algorithms (Chord, etc.) Reliable Multicast Mechanisms draft-ietf-rmt-fcast draft-ietf-rmt-flute-revised 1521-12-0093-00-MuGM

16 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 Member G IMG Member F Member G Member F Member G Reference Model IMG: Inter-domain Multicast Gateway 1621-12-0093-00-MuGM

17 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

18 Multicast API (Contd) 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

19 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

20 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


Download ppt "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."

Similar presentations


Ads by Google