RE: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00
JiangXingFeng <jiang.x.f@huawei.com> Wed, 27 June 2007 02:04 UTC
Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Mt4-0006zh-HN; Tue, 26 Jun 2007 22:04:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Mt3-0006zZ-68 for p2psip@ietf.org; Tue, 26 Jun 2007 22:04:05 -0400
Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Msx-00013W-1Q for p2psip@ietf.org; Tue, 26 Jun 2007 22:04:05 -0400
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK900BPIV10TU@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:03:00 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK90080DV0ZI2@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:03:00 +0800 (CST)
Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK900H2PV0WLS@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:02:59 +0800 (CST)
Date: Wed, 27 Jun 2007 10:02:56 +0800
From: JiangXingFeng <jiang.x.f@huawei.com>
Subject: RE: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00
In-reply-to: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca>
To: 'Philip Matthews' <philip_matthews@magma.ca>
Message-id: <003a01c7b85f$47bd4a20$6905a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Thread-index: Acew4ZzpomBzIqHPRuWy47yMQWGj9QHfRjAQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: p2psip@ietf.org
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org
HI, Philip: In all, using HIP to deliver peer protocol message is an interesting topic. I give some comments below. Regards! 1. section 1.1 Note that SIP and other applications an access the Distributed Transport function directly without going through the other two functions. [JiangXingFeng]Do you want to make the distributed transported function so general that all application messages could be forwarded in the overlay? Let me show an example: Alice wants to call Bob? How does Alice send the Invite message? Send to Bob through the overlay or get the Bob's contact address first, later send to Bob directly? If Alice sends the invite message through the overlay, what does the admitting peer of Bob's key do? Forward the message to Bob's contact address? If it forwards the message, how does the admitting peer know the characteristic of the value under this key? 2. o Network layer: The ability to deliver a message to an arbitrary peer in the overlay. In our view, this involves adding a header to the message that specifies the destination peer ID and then routing that message along existing connections in the overlay to the destination peer. [JiangXingFeng] What does the network layer refer to? IP layer or overlay network layer? In my opinion, it refers to overlay network layer here. 3. Figure 2:Each peer in the network is behind its own NAT. What does this statement mean? 4. There are two ways to send a packet to another peer in the overlay: send it on a direct connection to the remote peer, or send it hop-by- hop through the overlay. A peer typically uses hop-by-hop routing when it has only a small amount of data to transfer to the remote peer (for example, a Distributed Database update or a SIP INVITE transaction), and sets up a direct connection when it has a larger amount of data to transfer (for example, an RTP session). In my opinion, only the peer protocol message should be routed hop-by-hop through the overlay? Like the comments in 1, how does the admitting peer process the application message? Maybe the peer does not recognize the specific application message? That Sending packets directly to destination peer, i think, is a problem arising from the usage of HIP, not in the scope of P2P, because in P2PSIP case, not all communications should be protected by IPSEC ESP. -- Jiang XingFeng > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Sunday, June 17, 2007 9:15 PM > To: P2PSIP Mailing List > Subject: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 > > Folks: > > Eric Cooper, Alan Johnston, and I have just written a draft that > suggests what we think > is an interesting direction for the P2PSIP working group. > > We argue that a P2PSIP overlay should use HIP (the Host Identity > Protocol) > to provide a number of the basic features in an overlay, namely: > o Peer IDs; > o Transporting messages around the overlay; > o Signaling new overlay connections; > o Supporting mobility and multi-homing of peers; > o Providing message security. > > One of the reasons we really like this idea is because, using the > approach > described in the draft, many existing applications don't require any > modifications > and "just work" in an overlay. > > We describe this idea in a draft that has just been submitted. > Until the draft appears in the archives, you can get a copy at > http://www.magma.ca/~philip_matthews/draft-willis-p2psip- > concepts-04.txt > or for the html version > http://www.magma.ca/~philip_matthews/draft-willis-p2psip- > concepts-04.htm > > Here is the abstract from the draft: > This document examines a P2PSIP architecture where the peer-to-peer > (P2P) layer is separate from and lies below the SIP layer. We > discuss the functions of the P2P layer in such an architecture, and > focus in on the Distributed Transport function - the function that > allows a peer to exchange messages with any other peer in the > overlay, even in the presence of NATs. We list the features that > the > Distributed Transport function needs to provide, and observe that > the > Host Identity Protocol (HIP) already provides a number of these > features. We then propose extensions to HIP that allow it to > provide > the missing features. We discuss how a complete P2PSIP architecture > can be built around HIP, and contrast this approach with other > approaches for implementing a P2P layer. Two of the advantages of > HIP approach are that (a) most existing applications can run in an > overlay without needing any changes and (b) peer mobility and NAT > traversal are handled in a way that is transparent to most > applications. > > - Philip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip
- Re: [P2PSIP] New draft: draft-matthews-p2psip-hip… Gonzalo Camarillo
- [P2PSIP] New draft: draft-matthews-p2psip-hip-hop… Philip Matthews
- Re: [P2PSIP] New draft: draft-matthews-p2psip-hip… Hannes Tschofenig
- Re: [P2PSIP] New draft: draft-matthews-p2psip-hip… Philip Matthews
- Re: [P2PSIP] New draft: draft-matthews-p2psip-hip… Philip Matthews
- Re: [P2PSIP] New draft: draft-matthews-p2psip-hip… Philip Matthews
- RE: [P2PSIP] New draft: draft-matthews-p2psip-hip… JiangXingFeng
- Re: [P2PSIP] New draft: draft-matthews-p2psip-hip… Philip Matthews