[SAM] draft-pkll-irtf-sam-alm-api-00
Lim Boon Ping
boonping.lim at my.panasonic.com
Thu Jan 17 05:04:35 EST 2008
Dear all,
Inline with the goal of SAM RG to develop a SAM framework, we have made an
attempt to define a set of wrapper API for ALM topology management and
network layer transparent content distribution. Attached in this email is the
initial draft.
Abstract: This document defines and describes the topology management and
network layer transparent middleware wrapper API for ALM forwarding
table construction, distribution and multimedia content transportation over
IPv4/IPv6 for unicast and xcast.
The proposed draft is intended to compliment SAMTK which proposed a standard
set of API for Group Management and Traffic Management, leaving the Topology
Management module undefined. Additionally, this draft also describes flexible
protocol selection mechanism as proposed in SAMTK's Traffic Management API.
It is understood that defining a set of common API which cover all ALM
protocols is a challenging task. We hope this draft will be a starting point
for further discussion to achieve SAM's goal, common ALM framework. Your
comments and suggestions are much appreciated.
Thank you!
Regards,
Boon Ping
-----Original Message-----
From: Nobuo Kawaguchi [mailto:kawaguti at nagoya-u.jp]
Sent: Sunday, January 06, 2008 10:08 PM
To: sam
Subject: Re: [SAM] SAM RG next steps
Hi John, and all,
I'm one of the SAMTK designer. So I should say my opinion.
As I already presented in IETF-69 SAM-RG, SAMTK is
just a middleware(or toolkit) to ease a development of
applications and multi-point protocols.
This means that, by using SAMTK, application developers can
easily develop a multi-point comm app without considering
multi-point protocols. Also protocol researchers can
utilize real applications just developing a protocol plug-in
for SAMTK.
We also provide a group management API in SAMTK.
We already implement a Web based centralized group management.
But API does not limit the implementation.
(We also planning to implement a P2P/DHT based group management.)
As you already mentioned, API in SAMTK could be more general.
However, we do not know what kind of communication pattern
will be suitable for multi-point group communication and
group management.
This means, definition of "common" API is not easy.
So we start from a implementation.
By using SAMTK as a reference, we can discuss its pros and cons.
We do not hesitate to change the API of SAMTK as a result of
discussions in SAM-RG.
SAMTK is now in beta phase. We are currently preparing English
documents. So please wait a bit.
yours,
Nobuo Kawaguchi
Graduate School of Engineering, Nagoya Univ., Japan.
kawaguti at nagoya-u.jp
John Buford Wrotes,
> Perhaps the SAMTK designers could comment on this discussion?
>
> On Jan 4, 2008 6:54 AM, Matthias Waehlisch <waehlisch at ieee.org> wrote:
>
>> Hi John,
>>
>> On Thu, 3 Jan 2008, John Buford wrote:
>>
>>>> [...]
>>>>> In addition, in the P2P-SIP WG there is a proposal for a universal
>>>>> P2P overlay protocol. (universal in that it is meant to support the
>>>>> operations needed by several multi-hop structured overlays).
>>>>>
>>>>> So, the direction I have in mind for the SAM Framework involves:
>>>>> extended AMT gateways, ALM on P2P overlay, use of a universal P2P
>>>>> overlay protocol. Then, any researcher could plug their own ALM
>>>>> algorithm into this and select their own P2P overlay algorithm as
>>>>> well. Meanwhile, the AMT integration means that native multicast and
>>>>> ALM can co-exist.
>>>>>
>>>> What does a universal P2P overlay protocol mean in detail? Is it
>>>> similar to the common API by Dabek et al. ("Towards a Common API for
>>>> Structured Peer-to-Peer Overlays", 2003)?
>>> I recall the Dabek et al. model is mainly on the DHT level. The protocol
>>> also needs to cover overlay maintenance. It starts from the observation
>>> that many structured overlays have to send the same types of messages
>>> between peers, such as GET, PUT, JOIN, LEAVE, ROUTING-TABLE UPDATE,
>>> PROBE, etc. But the details vary from overlay to overlay. So the
>>> protocol covers the common message types with basic fields plus
>>> extension mechanisms.
>>>
>> there is a detailed description for the KBR (key based routing) layer
>> and some very rough ideas for multicast (CAST).
>>
>> The problem of the Dabek et al. model from my point of view is that it
>> intermingles semantic definitions with algorithmic logic. The CAST
>> abstraction for example provides standard group membership methods (join,
>> leave, ...) on the one hand and tree maintenace description similar to
>> SCRIBE on the other hand.
>>
>>>> Btw: It makes sense to have an interface definition between ALM
>>>> 'stack' and application. But this should be a part of a common group
>>>> membership framework maybe borrowed from IGMP/MLD. That could be also
>>>> an outcome of SAM RG.
>>>
>>> I think there is a proposed ALM API in the RG that was discussed at
>>> IETF-69. Is this what you are thinking of?
>>>
>> Do you mean the SAMTK? Hm, I think partly, because SAMTK is an
>> implementation as far as I understand. It can be seen as a standard stack,
>> however, it would be fine to have a document as a general ALM group
>> membership guidance. This includes definition of group management methods
>> (as done in SAMTK), a general packet format, etc. ... The SAMTK
>> definitions for example differ from the interfaces in the Dabek et al.
>> model. If we are looking on implementations in different ALM simulators we
>> will also find discrepancies, although some of them rely on the Dabek et
>> al. model.
>>
>> Another point is the question of broadcast as a special case of
>> multicast. How should we define it: Should the application developer join
>> a special multicast group - but which one? Or should we define a separate
>> broadcast socket/interface?
>>
>> All of these could be addressed in a common group membership description
>> for ALM. I feel a bit uncomfortable with too many approaches being around
>> on this basic topic.
>>
>> Cheers
>> matthias
>>
>> --
>> Matthias Waehlisch
>> :. HAW Hamburg, Dept. Informatik :. link-lab
>> :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 Berlin
>> :. Germany, mailto:waehlisch at ieee.org :. Germany, mailto:mw at link-lab.net
>> :. http://home.fhtw-berlin.de/~mw :. http://www.link-lab.net
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SAM mailing list
> SAM at irtf.org
> https://www1.ietf.org/mailman/listinfo/sam
_______________________________________________
SAM mailing list
SAM at irtf.org
https://www1.ietf.org/mailman/listinfo/sam
-------------- next part --------------
Scalable Adaptive Multicast Research Group B.P. Lim, K. Ettikan
Internet Draft Panasonic Kuala Lumpur Lab
Intended status: Informational January 17, 2008
Expires: July 2008
ALM API for Topology Management and Network Layer Transparent
Multimedia Transport
draft-pkll-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 17, 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 17, 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
Lim et.al. Expires July 17, 2008 [Page 2]
Internet-Draft ALM Middleware API January 2008
5.1. lookupPath() .......................................... 15
6. Example of Market Bit Placement............................. 16
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 ........................................ 24
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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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,
Penthouse Suite, Level 4,
Quill Building 3, 3501 Jln. Teknokrat 5,
63000 Cyberjaya, Selangor, Malaysia.
Phone: +6 03-83181228
Email: boonping.lim at my.panasonic.com
K. Ettikan
Panasonic Kuala Lumpur Lab,
Panasonic R&D Center Malaysia,
Penthouse Suite, Level 4,
Quill Building 3, 3501 Jln. Teknokrat 5,
63000 Cyberjaya, Selangor, Malaysia.
Phone: +6 03-83181228
Email: ettikank.k at 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 at ietf.org.
Lim et.al. Expires July 17, 2008 [Page 23]
Internet-Draft ALM Middleware API January 2008
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
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 17, 2008 [Page 24]
More information about the SAM
mailing list