[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/