Subject: [SAM] draft-pkll-irtf-sam-alm-api-00

From: "Lim Boon Ping" <[email-masked]>
Date: Thu, 17 Jan 2008 18:04:35 +0800

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:[email-masked]] 
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.
[email-masked]

John Buford Wrotes,
> Perhaps the SAMTK designers could comment on this discussion?
> 
> On Jan 4, 2008 6:54 AM, Matthias Waehlisch <[email-masked]> 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:[email-masked]   :. Germany, mailto:[email-masked]
>> :. http://home.fhtw-berlin.de/~mw       :. http://www.link-lab.net
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> SAM mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sam

_______________________________________________
SAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sam

_______________________________________________
SAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sam