Scalable Adaptive Multicast Research Group B.P. Lim, K. Ettikan Internet Draft Panasonic Kuala Lumpur Lab Intended status: Informational January 18, 2008 Expires: July 2008 ALM API for Topology Management and Network Layer Transparent Multimedia Transport draft-lim-irtf-sam-alm-api-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines and describes the topology management and network layer transparent middleware wrapper API for ALM forwarding table construction, distribution and multimedia transport over IPv4/IPv6 for unicast and xcast. Lim et al. Expires July 18, 2008 [Page 1] Internet-Draft ALM Middleware API January 2008 Conventions used in this document "Xcast" [RFC5058] indicates a type of datagram delivery system with explicit list of destinations embedded in each datagram. "ALMcast" indicates an application layer IP multimedia relay concept where end nodes does forwarding by referring to pre-computed local forwarding table. No explicit list of destinations addresses are embedded in IP datagram. Each relay node must lookup the local forwarding table, duplicate if necessary and forward the datagram based on source and destination IP/transport protocol/port number. A marker bit can be set in packet to identify if packet duplication/relay is required at receiving node. "ALM topology" indicates network connectivity between network nodes formed based on network metrics and node capabilities. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction ................................................ 3 1.1. Needs for ALM Topology Management Wrapper API ........... 4 1.1.1. Limitation of Protocol-specific API ................ 4 1.1.2. Lack of complete coverage of different ALM APIs..... 4 1.2. Needs for Network Layer Transparent Wrapper API ......... 6 1.2.1. Lack of multimedia network/transport layer selection 6 1.2.2. Kernel space vs. User space content duplication and relay.................................................... 6 1.3. Standardizing API for SAM Framework ..................... 7 2. Middleware API for Forwarding Path Construction & Distribution 8 2.1. constructPath() ........................................ 9 2.2. releasePath() ......................................... 10 2.3. sendPath() ............................................ 10 2.4. updatePath() .......................................... 11 3. Middleware API for Content Transmission / Receiving ......... 11 3.1. send() ................................................ 12 3.1.1. Transport Mode ................................... 12 3.2. recv() ................................................ 13 4. Middleware API for Content Relay............................ 14 4.1. relay() ............................................... 14 5. Middleware API for Relay Path Lookup........................ 15 5.1. lookupPath() .......................................... 15 6. Example of Market Bit Placement............................. 16 Lim et.al. Expires July 18, 2008 [Page 2] Internet-Draft ALM Middleware API January 2008 7. Usecase Description ........................................ 16 8. Summary .................................................... 19 9. Acknowledgments ............................................ 20 10. References ................................................ 21 10.1. Normative References.................................. 21 10.2. Informative References................................ 21 Author's Addresses ............................................ 23 Intellectual Property Statement................................ 23 Disclaimer of Validity ........................................ 23 1. Introduction Many Application Layer Multicast (ALM) protocols have been developed in the past. Some of which are ALMI[1], Narada[2], NICE[3], YOID[4], HMTP[5], Bayeux[6], SCRIBE[7], Borg[8]. These protocols, combined with ALM-based multimedia application (such as media streaming [9], video conferencing [10]) were built on top of ALM application or leverages on existing overlay infrastructure [11,12], providing a common set of functionalities, which include: - ALM topology construction (at initial stage), - ALM topology re-construction (upon membership change), - ALM topology refinement (upon network condition or performance metrics change), - ALM topology distribution (for centralized approach), - ALM forwarding table lookup (upon data delivery/relay), and - Content distribution based on ALM topology. Despite sharing a set of similar functionalities, these protocols have been independently developed and integrated into network simulator or individual application for performance benchmarking, deployment testing (either local or Internet-based testbed) or actual usage. Lack of common set of wrapper API leads to redundant application layer development, thus diluting effort for underlying ALM protocol enhancement and integration on a common application platform. Lim et.al. Expires July 18, 2008 [Page 3] Internet-Draft ALM Middleware API January 2008 1.1. Needs for ALM Topology Management Wrapper API 1.1.1. Limitation of Protocol-specific API Currently, each ALM protocols export different set of protocol- specific APIs despite providing common services. These topology management APIs provide common functions to trigger topology construction, topology distribution, topology update, path lookup, content sending and receiving. Often, an ALM middleware (or application controller) exists as a gluing module to coordinate the invocation of this Topology Management module APIs with Group Management and Transport Management modules APIs. Due to lack of standardized set of wrapper APIs, the ALM middleware is restricted to access only one ALM protocol by interfacing with protocol-specific APIs. This also does not enable interoperability between or integration with other ALM protocols. For example, in ALMI [1, 16], ALMI client calls register() to initiate a join request to ALMI server; ALMI server interfaces with initTopo() to trigger path construction, sendTopo() to distribute path, sentMstUpdate() to distribute updated path. In YOID [4, 17], the Yoid Tree Management Protocol (YTMP) module API's ytmp_rp_start() is called to initiate a node as Rendezvous Point (RP) and ytmp_member_start() is called to initiate a YOID client. The RP node is later queried by Yoid client for a list of neighbor nodes whom are potential parent for topology construction/reconstruction/refinement. Based on the given examples, with each ALM protocols exporting different set of APIs, the ALM middleware looses the flexibility to leverage on or access different ALM protocols based on the application needs within the same architecture. Interoperability is only possible with another layer of interfacing code for each ALM protocols, which is a redundant step. 1.1.2. Lack of complete coverage of different ALM APIs Existing ALM protocols can be largely divided into two groups: centralized topology management [1] and overlay-based distributed topology management [2,3,4,5,6,7,8]. In centralized approach, topology construction/reconstruction/refinement is triggered at centralized server node and the constructed forwarding path information is subsequently distributed to all client nodes e.g in the form of forwarding table. On the other hand, in overlay-based distributed approach, the underlying peer-to-peer overlay provides Lim et.al. Expires July 18, 2008 [Page 4] Internet-Draft ALM Middleware API January 2008 topology information for path construction and content distribution. Client node initiates join request to root/parent node in order to setup forwarding path. The role of topology construction/ reconstruction/refinement can be triggered or performed by the parent/child/root node. Prior researches [14,15] have been carried-out to identify common set of API for overlay-based ALM. RelayCast [14] proposes MakeTree(), Find(), SendDat(), RecvDat() to trigger different ALM protocols for topology construction based on network overlay information, path lookup, content distribution, respectively. Dabek et. al.[15] introduces a set of common API for structured peer-to-peer overlays, covering distributed hash tables (DHT), group anycast and multicast (CAST) and decentralized object location and routing (DOLR) on top of key-based routing (KBR). DHT and DOLR are out of the scope of ALM thus will not be discussed here. Nevertheless a list of common API such as forward(), join(), leave(), local_lookup(), multicast() and anycast() are defined for CAST protocols built on top of KBR peer-to- peer overlay. These APIs may be applicable for existing overlay-based ALM protocols such as Bayeux[6], SCRIBE[7], Borg[8] (eg. built on top of Tapestry, Pastry etc), but not applicable to ALM protocols which is non-overlay-based, such as ALMI [1] and etc. The latter adopts client-server architecture, which requires another set of common APIs for ALM middleware access to perform topology construction/ reconstruction/refinement, topology distribution, topology update and path lookup, separately at ALM server and ALM client side. The requirement for centralized ALM protocols slight differs compared to overlay-based distributed ALM protocols. In the formal approach, an ALM server exists to monitor group membership, gather metrics information, construct/update/distribute topology (a.k.a forwarding table) on centralized ALM protocols. The ALM client in-turn collect/update metrics information to the ALM server, receive forwarding table from ALM server, receive content from source/upstream ALM node, perform forwarding table lookup to identify next destination ALM node for content relay. The aforementioned prior research do not consider these requirements, and thus a set of common API for centralized ALM protocols are required to provide complete coverage. Lim et.al. Expires July 18, 2008 [Page 5] Internet-Draft ALM Middleware API January 2008 1.2. Needs for Network Layer Transparent Wrapper API 1.2.1. Lack of multimedia network/transport layer selection Various IP layer and transport layer protocols exist as a mean to deliver ALM content within a topology. Different ALM protocols define different set of API for content distribution. However neither of these APIs allows selection of IP protocol, transport protocol or casting type specifically from the ALM middleware. This limits the flexible selection of TCP/UDP,IPv4/IPv6,IP Multicast/Multi- Unicast/Anycast/Xcast-based options for multimedia content distribution. For example ALMI [1] provides sendTcpPkt(), sendUdpPkt(), recvUdpData() and recvTcpData() to trigger different transport protocols for content sending and receiving, while multicast() for content relay. The transport protocol can be selected by calling separate packet sending/receiving functions. However, there is no specific indication whether the content is transmitted via IPv4 and/or IPv6 at present. RelayCast[14] offers a rather generic API SendDat() and RecvDat(), leaving the implementation details to Traffic Management module, and thus limiting choice of protocols selection from ALM middleware. It is envisioned that the ALM middleware should have flexibility to select the aforementioned network and transport layer protocols, and the underlying Traffic Management module to switch dynamically based on network capability and application need as targeted by SAMTK [13,18]. 1.2.2. Kernel space vs. User space content duplication and relay It is to our understanding that all of the ALM protocols aforementioned perform forwarding table lookup, content duplication and distribution at user space in each ALM relay node. Currently, there is no implementation specific information about selection of kernel space processing or user space processing from ALM middleware. While line-speed processing is crucial for delay-sensitive ALM application such as real-time video conferencing, media streaming etc, it is envisioned that the ALM middleware should be granted the flexibility to decide whether the forwarding table lookup and content duplication should be performed in kernel space or user space. The selection shall affect the design of forwarding table placement (forwarding table construction at user space and writing the table Lim et.al. Expires July 18, 2008 [Page 6] Internet-Draft ALM Middleware API January 2008 into volatile memory in kernel space), patching of new system call to perform ALM forwarding table lookup, adding new kernel module to perform content duplication, configuring appropriate source/destination IP address/port based on forwarding table. 1.3. Standardizing API for SAM Framework Aligning with the goal of SAM RG to develop a SAM framework, our goal focuses on providing a set of wrapper API for ALM topology management and network layer transparent content distribution as a common platform for ALM application development and testing. This will allow researchers to focus on ALM topology protocol enhancement which is the key component of ALM technology. The proposed wrapper API for network topology management intends to support both centralized and distributed topology management protocols. It is intended to compliment SAMTK [13,18] which has proposed a standard set of API for Group Management and Traffic Management, but leaving the Topology Management module undefined. The network layer transparent wrapper API aims to hide detail of socket configuration, distribution list configuration and packet duplication method from application developer. It is intended to support both IPv4 and IPv6 data transmission on top of conventional unicast protocol or XCast [RFC5058] protocol with flexibility to select either TCP or UDP-based tranmission. Meanwhile the API shall also provide interfaces to trigger user space or kernel space forwarding table lookup for ALM source and relay nodes. It is intended to compliment SAMTK [13,18]'s proposed Traffic Management API with additional support on flexible protocols selection. Figure 1 illustrates the envisioned architecture with compliment to SAMTK [13,18]. Lim et.al. Expires July 18, 2008 [Page 7] Internet-Draft ALM Middleware API January 2008 +-------------------------------------------------------------------+ | SAM Application | +-------------------------------------------------------------------+ | SAMTK Core Module (Middleware) | | +---------------------+ +-------------------+ +------------------+| | | Topology Management | | Group Management | |Traffic Management|| | | Module/Wrapper API | | Module | | Module || | +---------------------+-+-------------------+-+------------------+| | |ALMI |Narada |Yoid |NICE |Bayeux |SCRIBE |Proprietary protocols || | +----------------------------------------------------------------+| +-------------------------------------------------------------------+ | OS (Linux, Windows, BSD) | +-------------------------------------------------------------------+ Figure 1 Proposed middleware architecture design. 2. Middleware API for Forwarding Path Construction & Distribution This section introduces the basic API for forwarding path construction and distribution. In ALM services, AV data streams are distributed from source to destinations based on pre-constructed forwarding path. The forwarding path may be constructed based on different metrics defined by different ALM path construction algorithms. Typical metrics are latency, available bandwidth, jitter etc between ALM nodes. Over time, the forwarding path may be reconstructed or refined upon member join/leave or network condition change. Newly added and updated forwarding path are sent to each source/relay nodes for further update on their forwarding table. Only the changes should be sent out in update/refinement stage for lesser traffic generation These typical operations can be facilitated by list of forwarding path construction and distribution wrapper API. The wrapper API serves as an interface to trigger ALM topology management plugin API or network layer API, making the ALM application transparent towards underlying ALM algorithms. The wrapper API includes constructPath() releasePath() sendPath() updatePath() Lim et.al. Expires July 18, 2008 [Page 8] Internet-Draft ALM Middleware API January 2008 These API shall be called by ALM middleware upon notification of group membership change from group membership module (such as upon join() or leave() functions being triggered) or network condition change from metrics collection module. We will discuss the wrapper API in more details in the following subsections. 2.1. constructPath() ALM middleware calls constructPath() to trigger path construction API in topology management plugin API. The syntax is, ret = constructPath(const int actionMode, struct AlmPathLst* almPaths, struct AlmMetricsLst* almMetrics); actionMode - indicates action requested by node, whether an ALM server node or an ALM client node. Both nodes with different role shall trigger different operation to underlying ALM plugin API. BUILDTREE mode is set by ALM server node to trigger function call to local ALM plugin for topology construction in centralized approach. JOIN mode is set by ALM client node to trigger function call to join a group and find a parent in overlay approach. almPath - serves as an output parameter which provides path information in AlmPath struct format to ALM server and ALM client node. If this function is triggered by ALM server node, this parameter returns forwarding path for all sources (for further distribution to each source/relay nodes). If function is triggered by ALM client node, this parameter returns selected parent to ALM client (for further data path setup). almMetrics - serves as an optional input parameter which provides metrics information in AlmMetrics struct format from metrics collection module to topology construction module. In centralized approach, if metrics collection module is external and indirectly interfacing with ALM topology management module via ALM middleware, the metrics information is passing via this parameter. Otherwise if ALM plugin has built in metrics collection module, this parameter is unused. In distributed overlay approach, the ALM client node invokes JOIN request to parent or root node via this function, without required to provide metrics information, need not use this parameter as well. Lim et.al. Expires July 18, 2008 [Page 9] Internet-Draft ALM Middleware API January 2008 2.2. releasePath() ALM middleware calls releasePath () to trigger path destruction API in topology management plugin API. The syntax is, ret = releasePath(const int actionMode); actionMode - indicates action requested by node, whether an ALM server node or an ALM client node. Both nodes with different role shall trigger different operation to underlying ALM topology management API. DESTROYTREE mode is set by ALM server node to trigger function call to local ALM plugin to destroy constructed forwarding path and release resources allocated. LEAVE mode is set by ALM client node to trigger function call to inform quitting message to its parent, disconnect its connection to the parent and free resources allocated. 2.3. sendPath() ALM middleware calls sendPath() to trigger path distribution API in topology management plugin API. The syntax is, ret = sendPath(const int transportMode, const in sendMode, struct AlmPathLst* almPaths); transportMode - indicates transport mode to send path. IPV4 mode is set to send using IPv4. IPV6 mode is set to send using IPv6. AUTO mode is set when application layer requires transport layer middleware to select appropriate transport protocol. sendMode - indicates level of path information to be sent to each source/relay nodes. NODESPECIFIED mode is set to send only node- specific forwarding path. FULL mode is set to send all paths to all node. almPaths - serves as an input parameter with forwarding paths constructed at Section 2.1. This function is applicable for centralized approach where forwarding paths are built by server node and need to be distributed to other source/relay nodes. Lim et.al. Expires July 18, 2008 [Page 10] Internet-Draft ALM Middleware API January 2008 In overlay approach, after constructPath() is triggered by ALM client node, parent/root/rendezvous point is assumed to have protocol specific path request/acknowledgement mechanism for intermediate relay node(s) negotiation, thus this function may not be used. 2.4. updatePath() ALM middleware calls updatePath() to trigger path update API in topology management plugin API. The syntax is, ret = updatePath(struct AlmPathLst* almPaths) almPaths - serves as an input parameter with forwarding paths received from sendPath()at Section 2.1.3. This function is applicable for centralized approach where forwarding paths are built by server node and need to be updated to other source/relay nodes. At ALM server node, sendPath() is called to distribute updated ALM path. At ALM source/relay nodes, updatePath() API is called from network layer API, via ALM middleware, to update forwarding path. This API manipulates forwarding table (insert/delete/update) based on its input parameter. 3. Middleware API for Content Transmission / Receiving This section introduces the basic API for AV stream transmission and receiving via network layer transparent API. AV streams can be transmitted via either IPv4/v6 unicast or IPv6 Xcast [RFC5058]. The wrapper API serves as an interface to trigger BSD/XCast network socket API, making the ALM application transparent towards network layer. The wrapper API includes send() recv() These API shall be called by ALM middleware upon receiving captured AV stream from ALM application, and upon receiving AV stream to be playback from the network. We will discuss the wrapper API in more details in the following subsections. Lim et.al. Expires July 18, 2008 [Page 11] Internet-Draft ALM Middleware API January 2008 3.1. send() ALM middleware calls send() to trigger network socket API for data transmission. The syntax is, ret = send(const int transportMode, struct AlmData* data) transportMode - indicates transport mode to send AV content. ALMCASTV4UDP mode is set to send using IPv4 unicast UDP stream. ALMCASTV4TCP mode is set to send using IPv4 unicast TCP stream. ALMCASTV6UDP mode is set to send using IPv6 unicast UDP stream. ALMCASTV6TCP mode is set to send using IPv6 unicast TCP stream. XCAST6-1 mode is set to send using IPv6 Xcast with only next receiver destination address given. XCAST6-2 mode is set to send using IPv6 Xcast with full receivers list of destination address given from source. IPMULTICAST mode is set to send using IP multicast. AUTO mode is set when application layer requires transport layer middleware to select appropriate transport protocol. Refer to Section 3.1.1 for differences between transport modes. data - serves as an input parameter which provides AV data information in AlmData struct format. This API is invoked by ALM source node from user space. Upon invocation, it triggers lookupPath() as described later on in Section 4.1 to seek for next designated receiver(s). Based on transportMode, it shall create appropriate socket type, set socket options, add member into group (for Xcast), trigger XcastSend() system call for IPv6-based Xcast or BSD send() for IPv4/v6 data transmission. 3.1.1. Transport Mode This section describes 4 different transport modes as mentioned in Section 3.1 and later on in 4.1. ALMCASTV4 - an IPv4 AV stream relay mechanism with end node forwarding by referring to local forwarding table. No explicit list of destinations addresses embedded in IP datagram. Each relay node must lookup the local forwarding table, duplicate and forward the AV stream based on source and destination IP in the forwarding table. *This is a proprietary transport protocol developed in-house. ALMCASTV4UDP - an IPv4 UDP version of ALMCAST concept. ALMCASTV4TCP - an IPv4 TCP version of ALMCAST concept. Lim et.al. Expires July 18, 2008 [Page 12] Internet-Draft ALM Middleware API January 2008 ALMCASTV6UDP - an IPv6 UDP version of ALMCAST concept. ALMCASTV6TCP - an IPv6 TCP version of ALMCAST concept. XCAST6-1 - an alternative of Xcast-based AV stream relay mechanism. Original Xcast packet format are used. Source node constructs Xcast packet. Xcast packet header contains one next receiver at Outer IP Destination field, based on ALM forwarding table. Each relay node must lookup the local ALM forwarding table, update the Xcast header with current Source IP at Outer IP Source field and next Destination fields at Outer IP Destination field, duplicate and forward the AV stream based on source and destination IP in the forwarding table. XCAST6-2 - an alternative of Xcast-based AV stream relay mechanism. Original Xcast packet format are used. Source node constructs Xcast packet. Source node adds explicit list of receivers into Xcast header, based on ALM forwarding table. In this case, XCAST6-2 is different compared to XCAST6-1 where in the formal case, relay node need not maintain a local ALM forwarding table and need not lookup forwarding table upon receiving packet. When an XCAST packet arrives, first entry in XCAST packet Outer IP Destination field, which denotes the current node, is removed. The next destination of receiver is determined by referring to the second entry in XCAST Outer IP Destination field. Packet is then duplicated and forwarded based on Outer IP Destination field in XCAST header. IPMULTICAST - an IP multicast based AV stream relay mechanism with intermediate routers are assumed to be multicast-enabled. 3.2. recv() ALM middleware calls recv() to relay content received from network to ALM application. The syntax is, ret = recv(struct AlmData* data) data - serves as an input parameter which provides AV data information in AlmData struct format. This API is called from network layer API, either IPv4/v6 BSD recv() or IPv6 XcastRecv() system call, via ALM middleware, to convey AV data to ALM application. Lim et.al. Expires July 18, 2008 [Page 13] Internet-Draft ALM Middleware API January 2008 4. Middleware API for Content Relay This section introduces the basic API for AV stream relay at ALM intermediate relay node via network layer transparent API. AV streams are transmitted to ALM relay node via either IPv4/v6-based ALMcast or IPv6-based Xcast. The wrapper API serves as an interface to trigger ALM path lookup and duplicate a copy of AV stream automatically at intermediate relay node, making the ALM application transparent towards network layer and ALM algorithms. The wrapper API includes relay() This API shall be called by ALM middleware upon receiving AV stream to be relayed from the network. We will discuss the wrapper API in more details in the following subsections. 4.1. relay() ALM middleware calls relay() to trigger network socket API for data relay. The syntax is, ret = relay(const int transportMode, struct AlmData* data) transportMode - indicates transport mode to send AV content. ALMCASTV4UDP mode is set to send using IPv4 unicast UDP stream. ALMCASTV4TCP mode is set to send using IPv4 unicast TCP stream. ALMCASTV6UDP mode is set to send using IPv6 unicast UDP stream. ALMCASTV6TCP mode is set to send using IPv6 unicast TCP stream. XCAST6-1 mode is set to send using IPv6 Xcast with only next receiver destination address given. XCAST6-2 mode is set to send using IPv6 Xcast with full receivers list of destination address given from source. IPMULTICAST mode is set to send using IP multicast. AUTO mode is set when application layer requires transport layer middleware to select appropriate transport protocol. Refer to Section 3.1.1 for differences between transport modes. data - serves as an input parameter which provides AV data information in AlmData struct format. If either ALMCASTV4UDP, ALMCASTV4TCP, ALMCASTV6UDP or ALMCASTV6TCP transport mode is used, this API checks marker bit in packet (Refer Lim et.al. Expires July 18, 2008 [Page 14] Internet-Draft ALM Middleware API January 2008 to Section 4.1.1 for market bit placement example) to identify if packet duplication/relay is required to designated destination. If marker bit is set, it extracts originator (source) IP address from packet, lookup to its ALM local forwarding table and invoke v4/v6 BSD send(). If XCAST6-1 transport mode is used, this API extracts originator IP address from packet, lookup to its ALM forwarding table for next destination(s), create Xcast group, set socket option, add member into Xcast group and invokes Xcast kernel API XcastSend(). If XCAST6-2 transport mode is used, this API need not refer to forwarding table at relay node. Instead, it creates Xcast group, set socket option, add member into Xcast group and invokes Xcast kernel API XcastSend(). 5. Middleware API for Relay Path Lookup This section introduces the basic API for ALM path lookup at ALM source and intermediate relay node. This API is used at source only when transportMode is set to XCAST6- 2, as this transportMode includes all receivers' addresses in XCAST header at source. Nevertheless, for other transport mode, upon receiving AV stream at source/relay node, ALM path lookup is required to determine destination of next receiver(s). The wrapper API serves as an interface to trigger ALM path lookup at source and intermediate relay node, making the ALM application transparent towards network layer and ALM algorithms. The wrapper API includes lookupPath() This API shall be called by ALM middleware upon receiving AV stream to be transmitted or relayed. It may be called from send() (Section 3.1) or relay() (Section 4.1). We will discuss the wrapper API in more details in the following subsections. 5.1. lookupPath() ALM middleware calls lookupPath() to perform forwarding path lookup. The syntax is, Lim et.al. Expires July 18, 2008 [Page 15] Internet-Draft ALM Middleware API January 2008 ret = lookupPath (uint32_t key, struct AlmDistLst* almDist) key - indicates primary key to lookup in forwarding table. In this draft, source IP address is used. almDist - serves as output parameter which provides branch information in AlmDist struct format consists of branch info and one destination IP address per branch. 6. Example of Market Bit Placement A marker bit is used to distinguish the packet for duplication and relay. In our implementation, the market bit offset is set at first bit of IP payload. If either ALMCASTV4UDP, ALMCASTV4TCP, ALMCASTV6UDP or ALMCASTV6TCP transport mode is used, the first bit of IP payload for every packet will be checked. 7. Usecase Description In an ALM-based application (for e.g. multi-party video conferencing, file download etc), the proposed wrapper API can be used to provide transparency towards ALM algorithms and network layer. For centralized approach with an ALM server constructs N distribution trees for N source nodes, the API usage is illustrated in Figure 2. A group membership module and a metric collection module are assumed to co-exist in ALM Middleware. Lim et.al. Expires July 18, 2008 [Page 16] Internet-Draft ALM Middleware API January 2008 ALM ALM ALM ALM Server Client A Client B Client C +-----------+ . +-----------+ +-----------+ +-----------+ | ALM VC | . | ALM VC | | ALM VC | | ALM VC | | Server | . | Client | | Client | | Client | |application| . |application| |application| |application| +-----------+ . +-----------+ +-----------+ +-----------+ | ALM | . | ALM | | ALM | | ALM | |Middleware | . |Middleware | |Middleware | |Middleware | | | | . | | | | | | | |construct| . | | | | | | | |Path()/ | . | | | | | | | |send | . | | | | | | | |Path()/ | . | | | | | | | |release | . | | | | | | | |Path() | . | | | | | | | V | . |+--------+ | |+--------+ | |+--------+ | |+--------+ | . ||Topology| | ||Topology| | ||Topology| | ||Topology| | . || Plugin | | || Plugin | | || Plugin | | || Plugin | | . |+--------+ | |+--------+ | |+--------+ | |+--------+ | . | ^ | | ^ | | ^ | | | | . | |update | | |update | | |update | | | | . | |Path() | | |Path() | | |Path() | +-|---------+ . +-|---------+ +-|---------+ +-|---------+ | V TCP/UDP/| . | | TCP/UDP | | | TCP/UDP| | | TCP/UDP| | RTP /IP | | RTP /IP | | RTP /IP | | RTP /IP | +-----------+ . +-----------+ +-----------+ +-----------+ || . || || || || || ==========.====== ============= =========== | <------------ ALM Control Path flow --------------> | Figure 2 Middleware API usage for Centralized ALM Tree Construction Approach For distributed approach with ALM client requests root node (rendezvous point) for a parent node, the API usage is illustrated in Figure 3. Lim et.al. Expires July 18, 2008 [Page 17] Internet-Draft ALM Middleware API January 2008 Leaf Root Parent Parent ALM Client A ALM Client B ALM Client C +-----------+ . +-----------+ +-----------+ +-----------+ | ALM VC | . | ALM VC | | ALM VC | | ALM VC | |application| . |application| |application| |application| +-----------+ . +-----------+ +-----------+ +-----------+ | ALM | . | ALM | | ALM | | ALM | |Middleware | . |Middleware | |Middleware | |Middleware | | | | . | | | | | | | |construct| . | | | | | | | |Path()/ | . | | | | | | | |release | . | | | | | | | |Path()/ | . | | | | | | | V | . |+--------+ | |+--------+ | |+--------+ | |+--------+ | . ||Topology| | ||Topology| | ||Topology| | ||Topology| | . || Plugin | | || Plugin | | || Plugin | | || Plugin | | . |+--------+ | |+--------+ | |+--------+ | |+--------+ | . | ^ | | ^ | | ^ | +-|---------+ . +-|---------+ +-|---------+ +-|---------+ | V TCP/UDP/| . | V TCP/UDP | | V TCP/UDP| | V TCP/UDP| | RTP /IP | | RTP /IP | | RTP /IP | | RTP /IP | +-----------+ . +-----------+ +-----------+ +-----------+ || || . || || || || ====||====.====== || =========== ============================= | <------------ ALM Control Path flow --------------> | Figure 3 Middleware API usage for Overlay Tree Construction Approach For ALM content distribution, source streams are captured from multiple VC node and send to the next designated receiver(s). Upon receiving the stream, receiver keeps a copy for local playback. Next it performs lookup and relay the stream to the next designated receiver(s). The API usage for content distribution is illustrated in Figure 4. Lim et.al. Expires July 18, 2008 [Page 18] Internet-Draft ALM Middleware API January 2008 ALM ALM ALM Source A Relay B Receiver C +-----------+ +-------------+ +-------------+ | ALM VC | | ALM VC | | ALM VC | | Client | | Client | | Client | |application| |application | |application | +-----------+ +-------------+ +-------------+ | ALM | | ALM | | ALM | | Middleware| | Middleware | |Middleware | | | || | ^ | || | ^ | | |lookup || | |recv() | || | |recv() | | |Path()/ || | | lookup| || | | | | V || | | Path()V || | | | |+--------+|| | |+--------+|| | |+--------+ | ||Topology||| | ||Topology||| | ||Topology| | || Plugin ||| | || Plugin ||| | || Plugin | | |+--------+|| | |+--------+|| | |+--------+ | +----------|+ +-|----------|+ +-|-----------+ | send()|| | | relay()|| | | | | --|| | | ---|| | | | |+-------|+ | |+|-------|+ | |+|-------+ | ||XCast/ V| | || XCast/ V| | || XCast/ | | ||Unicast | | || Unicast | | || Unicast| | |+--------+ | |+---------+ | |+--------+ | +-----------+ +-------------+ +-------------+ || || || || ============= ============= | <------------ ALM Data Path flow --------------> | Figure 4 Middleware API usage for ALM content transmission, relay and receive. 8. Summary This draft defines a list of wrapper API to access ALM protocols and network transport layer modules. Given set of wrapper API, ALM application developer is granted with (1) flexibility to trigger operations in the ALM plugin/component according to application needs and (2) transparency to detail of socket configuration, distribution list configuration and packet duplication method. This will allow researchers to focus on ALM topology protocol enhancement which is the key component of ALM technology. Lim et.al. Expires July 18, 2008 [Page 19] Internet-Draft ALM Middleware API January 2008 9. Acknowledgments The authors would like to acknowledge Eiichi Muramoto, Tan Pek Yew for their helpful comments. This document was prepared using 2-Word-v2.0.template.dot. Lim et.al. Expires July 18, 2008 [Page 20] Internet-Draft ALM Middleware API January 2008 10. References 10.1. Normative References [RFC5058] R. Boivie, N. Feldman , Y. Imai , W. Livens , D. Ooms, O. Paridaens,, " Explicit Multicast (Xcast) Concepts and Options", RFC 5058, November 2007. 10.2. Informative References [1] Dimitrios Pendarakis, Sherlia Shi, Dinesh Verma, and Marcel Waldvogel, "ALMI: An application level multicast infrastructure", Proc. of Third USNIX Symposium on Internet Technologies and Systems (USITS '01), March 2001. [2] Yang hua Chawathe, Sanjoy G. Rao, and Hui Zhang, "A case for end system multicast", In ACM SIGMETRICS, June 2000. [3] Suman Banerjee, Bobby Bhattacharjee, and Christopher Kommareddy, "Scalable application layer multicast", Proc. of ACM SIGCOMM, 2002. [4] Paul Francis, "Yoid: extending the internet multicast architecture", Unreferred Report, http://www.yallcast.com, April 2000. [5] Beichuan Zhang, Sugih Jamin, and Lixia Zhang, "Host multicast: a framework for delivering multicast to end users", Proc. IEEE INFOCOM, June 2002. [6] Shelly Q. Zhuang, Ben Y. Zhao, Anthony D. Joseph, Randy H. Katz, and John Kubiatowicz, "Bayeux: An architecture for scalable and fault-tolerant wide-area data dissemination", Proc. of International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV 2001), June 2001. [7] Miguel Castro, Peter Druschel, Anne-Marie Kermarrec, and Antony Rowstron, "Scribe: a large-scale and decentralised application- level multicast infrastructure", IEEE Journal on Selected Areas in Communications (JSAC)(Special issue on Network Support for Multicast Communications), 20(8), October 2002. [8] R. Zhang, Y.C. Hu, "Borg: A hybrid protocol for scalable application-level multicast in peer-to-peer networks", Proc. of International Workshop on Network and operating systems support for digital audio and video, 2003. Lim et.al. Expires July 18, 2008 [Page 21] Internet-Draft ALM Middleware API January 2008 [9] S. Banerjee, S. Lee, B. Bhattacharjee, A. Srinivasan, and R. Braud, "Scalable resilient media streaming", Unreferred Report, http://www.cs.umd.edu/projects/nice/papers/cs-tr- 4482.pdf, May 2003. [10] "End System Multicast", http://esm.cs.cmu.edu/. [11] Ben Y. Zhao, Ling Huang, Jeremy Stribling, Sean C. Rhea, Anthony D. Joseph, and John Kubiatowicz, " Tapestry: A resilient global-scale overlay for service deployment", IEEE Journal on Selected Areas in Communications, 2003. [12] A. Rowstron and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems", Proc. International Conference on Distributed Systems Platforms (Middleware), November 2001. [13] Nobuo Kawaguchi, "SAMTK: A Toolkit for Scalable Adaptive Multicast", Unreferred Report, http://www3.ietf.org/proceedings/07jul/slides/SAMRG-2/samrg- 2.ppt. [14] Mimura, N., Nakauchi, K., Morikawa, H. and Aoyama, T., "RelayCast: A Middleware for Application-level Multicast Services", Proc. of IEEE/ACM International Symposium on Cluster Computing and the Grid, 2003. [15] F. Dabek, B. Zhao, P. Druschel, and I. Stoica, "Towards a Common API for Structured Peer-to-Peer Overlays", Proc. Of 2nd International Workshop on Peer-to-Peer Systems, 2003. [16] ALMI source code, http://www.arl.wustl.edu/~sherlia/almi/ [17] YOID2 source code, http://www.isi.edu/div7/yoid/releases/index.html [18] N. Kawaguchi, Y. Imai, E. Muramoto, S. Sakurai, D. Matsui, F. Kan, "XCAST on PlanetLab", Workshop on Peer-to-Peer Multicasting 2007 (P2PM'07),Demonstration(2007). Lim et.al. Expires July 18, 2008 [Page 22] Internet-Draft ALM Middleware API January 2008 Author's Addresses Boon Ping Lim Panasonic Kuala Lumpur Lab, Panasonic R&D Center Malaysia Phone: +6 03-83181228 Email: boonping.lim@my.panasonic.com K. Ettikan Panasonic Kuala Lumpur Lab, Panasonic R&D Center Malaysia Phone: +6 03-83181228 Email: ettikank.k@my.panasonic.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS Lim et.al. Expires July 18, 2008 [Page 23] Internet-Draft ALM Middleware API January 2008 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lim et.al. Expires July 18, 2008 [Page 24]