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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] > > 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 [email protected] https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
