RE: [P2PSIP] New draft: HIP BONE

Bruce,

>In the RELOAD-02 architecture, what you would presumably do would be
>to replace the bottom two layers (Forwarding Layer and Transport
>Layer) with HIP.  The routing queries are merely an upcall between
>layers.

What you describe seems very solid and may be applicable to other P2PSIP
proposals as well.

Would you have time to elaborate in a little write-up and add a diagram
for the RELOAD case?
It could but need not be an I-D at this point.

Henry

-----Original Message-----
From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] 
Sent: Wednesday, January 09, 2008 3:28 PM
To: Henderson, Thomas R
Cc: Pekka Nikander; P2PSIP Mailing List
Subject: Re: [P2PSIP] New draft: HIP BONE

On 1/9/08, Henderson, Thomas R <thomas.r.henderson@boeing.com> wrote:
>
>
> > -----Original Message-----
> > From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com]
> > Sent: Tuesday, January 08, 2008 2:16 PM
> > To: Gonzalo Camarillo
> > Cc: Pekka Nikander; P2PSIP Mailing List
> > Subject: Re: [P2PSIP] New draft: HIP BONE
> >
>
> >
> > Going with the HIP-BONE, approach, as I understand the "HIP is IP
and
> > the peer protocol is OSPF" idea...
>
> I think this analogy has some weaknesses, as you have pointed out, in
> the "peer protocol is OSPF" part.  My reading of HIP BONE is that the
> overall goal is to allow the peer protocol and other applications to
> deal with HIP identifiers instead of IP addresses.  That is a worthy
> goal IMO which might free RELOAD and other applications from having to
> do ICE and handle recursive routing issues or host mobility and
> multihoming.
>
> However, the problem with this approach is that HIP needs a naming
> service or routing service to resolve identifiers to either locators
or
> route lists.  This does not exist yet in HIP.  There have been
proposals
> to use DHTs to provide this service, but they do not presently
> accommodate the possibility of multiple DHTs, which is pretty much a
> requirement to handle, from my perspective.  HIP BONE seems to be
> suggesting that the peer protocol can fill this gap but there appear
to
> be some issues that need to be worked out, or maybe HIP BONE needs its
> own resolution/routing service separate from the application overlay.
>

I think this is hitting on the key issue.  A p2p overlay is
fundamentally about routing.  It already has its own ID/locator
mechanism.  Trying to separate the routing and resource querying
aspects is going to be difficult.  Rather than try, I think it's best
to take advantage of the connections.  The peer protocol provides a
component that can answer routing questions for the HIP layer.  The
HIP layer provides the traversal/connection opening functionality, a
link layer capability, and delivers to applications the ability to
transparently use end-to-end connections while being unaware of the
details.

I don't think that having HIP BONE have a separate resolution/routing
service from the application overlay would help.  I'm not even sure
what that would mean, given the relationship between overlay routing
and resource storage.

> Question:  How would RELOAD or other proposals change if that were the
> case?  Would the benefits greatly outweigh any drawbacks to this
> abstraction?

In the RELOAD-02 architecture, what you would presumably do would be
to replace the bottom two layers (Forwarding Layer and Transport
Layer) with HIP.  The routing queries are merely an upcall between
layers.

This is just one possibility, but it is reasonably clean, and it
should be easy to clarify what functions the HIP layers are providing
when they're used, compared to when non-HIP forwarding and transport
layers are used.

Bruce

_______________________________________________
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