Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification for draft-bryan-p2psip-reload-02

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Jan 2008 10:13:04 -0800

I've been meaning to reply to you forever on this but, I like this  
idea, thanks.

On Nov 21, 2007, at 7:59 AM, Michael Chen wrote:

> Hi,
>
> I have a practical suggestion for the forwarding header. The last  
> two paragraphs of section 4.1 of the draft describe how the Route- 
> List shrinks while Via-List grow as the Reload message passes  
> through intermediate peers.  If you flip the order of these two  
> lists such that Via-List comes first followed by the Route-list:
>
>   24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Via       |    Route      |                               |
>      |     List      |      List     |            Flags              |
>      |     Length    |     Length    |                               |
>   28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      //                          Via List                           //
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      //                          Route List                         //
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      //                          Route Log                          //
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Then as the message passes the pre-selected list of peers in Route- 
> list, intermediate peer can simply increment the via-list-length  
> field and decrement the route-list-length field, in effect shrink  
> the route-list by 1 while growing the via-list by 1 without  
> touching the actual Via-List and Route-list that follows.
>
> By the way, I do believe the header should indicate the size of the  
> IDs.
>
> Thanks
>
> --Michael
>
> Cullen Jennings wrote:
>>
>> The various authors of ASP and RELOAD have managed to get these  
>> two proposal merged together into one and we are pretty happy with  
>> the result.
>>
>> You can find it at
>> http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-02.txt
>>
>>
>> Begin forwarded message:
>>
>>> From: IETF I-D Submission Tool <[email-masked]>
>>> Date: November 18, 2007 8:57:03 PM PST
>>> To: [email-masked]
>>> Cc: [email-masked], [email-masked],  
>>> [email-masked]
>>> Subject: New Version Notification for draft-bryan-p2psip-reload-02
>>>
>>>
>>> A new version of I-D, draft-bryan-p2psip-reload-02.txt has been  
>>> successfuly submitted by Cullen Jennings and posted to the IETF  
>>> repository.
>>>
>>> Filename:     draft-bryan-p2psip-reload
>>> Revision:     02
>>> Title:         REsource LOcation And Discovery (RELOAD)
>>> Creation_date:     2007-11-18
>>> WG ID:         Independent Submission
>>> Number_of_pages: 96
>>>
>>> Abstract:
>>> This document defines REsource LOcation And Discovery (RELOAD), a
>>> peer-to-peer (P2P) binary signaling protocol for usage on the
>>> Internet.  A P2P signaling protocol provides its clients with an
>>> abstract hash table service between a set of cooperating peers that
>>> form the overlay network.  RELOAD is designed to support a P2P
>>> Session Initiation Protocol (P2PSIP) network, but it can be utilized
>>> by other applications with similar requirements by defining new
>>> usages that specify the data types that must be stored for a
>>> particular application, such as location for SIP.  RELOAD defines a
>>> security model based on a certificate enrollment service that
>>> provides unique identities.  NAT traversal is a fundamental service
>>> of the protocol.
>>>
>>> This draft represents a concrete proposal for the P2PSIP Peer
>>> Protocol.  The protocol described here builds on the lessons and
>>> experiences from designing and implementing the dSIP, ASP, and  
>>> RELOAD
>>> protocols and is a merge of features from RELOAD-01 and ASP.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/p2psip
>>
>>

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