RE: [P2PSIP] New draft: HIP BONE

["Henderson, Thomas R" <[e-mail]>]

 

> -----Original Message-----
> From: Pekka Nikander [mailto:[e-mail]] 
> Sent: Friday, December 21, 2007 12:16 PM
> To: Bruce Lowekamp
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] New draft: HIP BONE
> 
> Hi Bruce,
> 
> Let me try to clarify a few of your HIP-specific questions.  In  
> general, we tried to clarify the proposed relationship between HIP  
> and the peer protocols by the architectural analogy (in Section 6),  
> where we state that HIP acts in a role similar to IP 
> (forwarding that  
> results in connectivity) and the peer protocols in a role similar to  
> routing protocols such as OSPF, i.e., building the routing tables  
> needed to do forwarding.
> 
> > On a specific issue, I'm still a little confused about 
> where the line
> > is between what the overlay does with overlay routing and what
> > HIP-BONE should be responsible for.  Your section 3.2 
> proposes that I1
> > packets are sent across the Peer Protocol overlay.
> 
> Well, not quite.  We propose that "Nodes in the overlay forward I1  
> packets in a hop-by-hop fashion according to the overlay's routing  
> table towards its destination."  While that is true, it is 
> inaccurate  
> in the sense that it does not make the distinction between the  
> routing tables (as build by the peer protocols) and the forwarding  
> tables (as used by HIP) clear enough.
> 
> A better way to state what we propose might be "Nodes participating  
> into an overlay forward I1 packets in a hop-by-hop fashion over the  
> HIP BONE using the  forwarding tables, which in turn are built based  
> on the routing table constructed by the peer protocol for the  
> overlay."  But that would be quite a bunch to engulf at one time.
> 
> > Were I to
> > implement RELOAD on top of HIP-BONE, what exactly does this mean?
> 
> [Caveat: I don't know RELOAD nor other peer protocols in detail.]
> 
> > Does this mean that I send a RELOAD CONNECT message and the contents
> > of that message are now an I1 instead of ICE candidates?  Or would
> > RELOAD's CONNECT go away and RELOAD would simply try to 
> send a message
> > directly to a new PeerID via its ORCHID and the HIP-BONE layer would
> > then produce an upcall to RELOAD asking that an I1 be 
> tunneled across
> > the overlay?
> 
> I cannot say anything about RELOAD's CONNECT, but my 
> understanding is  
> that a forwarding node would look at the next hop ORCHID 
> based on the  
> forwarding table, and then pass the packet to the HIP  
> implementation.  The HIP implementation would then detect if 
> there is  
> an active HIP association towards that ORCHID.  If there is, the I1  
> packet is passed over that HIP association.  If there are not but  
> there is a valid locator associated with the next hop ORCHID, then  
> the I1 packet is passed over IP using the locator.  If 
> neither, there  
> the forwarding table is faulty, and the HIP layer needs to kick the  
> peer protocols to rebuild the forwarding table.  That is similar to  
> the case where the IP layer kicks the routing layer whenever 
> it drops  
> a packet due to missing route.  An open question here is whether and  
> how to report the error back, i.e., if there should be a function  
> similar to ICMP.  If yes, HIP NOTIFY packets could be used for that  
> purpose.
> 
> Further note that there are at least two choices of what to use as  
> index to the forwarding table look up.  Either one can use the Peer  
> ID, presumably carried in a new HIP parameter in the I1 packet, or  
> one can use the ORCHID, carried in the source HIT field in the I1  
> packet.   From the high level point of view, both would work equally  
> well, but as usual the devil may lie in the details.  The latter  
> would be structurally similar to the currently specified HIP  
> rendezvous service, and has been used in previous suggestions 
> for HIP- 
> based overlays.

Pekka,

If I understand correctly, you are suggesting that there would be HIP
forwarding table(s) with next hop ORCHIDs.  There may be next hop IP
addresses or active HIP tunnels corresponding to each next hop ORCHID.
There may be multiple peer protocols populating this HIP table.  

Then, it seems to be the case that there must be multiple HIP forwarding
tables, one for each overlay.  I think it has to be so because, unlike
routing, where different routing protocols will likely inject forwarding
table entries (prefixes) corresponding to separate regions of the IP
address space, each HIP-based overlay (and ORCHID space) overlaps the
ORCHID range completely.  Furthermore, nodes in a DHT will be
responsible for portions of the space and these portions will overlap
from overlay to overlay.

If so, then there is a requirement to be able to look up the right
forwarding table from an I1, which I think you are suggesting above in
the last paragraph.  So the I1 (and probably all HIP packets) needs to
carry some metadata about the ORCHID type in use, either in a new
parameter or embedded in a certificate.  Basically, there needs to be a
new namespace in use at the HIP forwarding layer-- the namespace
uniquely identifying overlays.  This could perhaps be the ORCHID Context
ID.  

Another related question I have is whether you think the legacy
application API (based on sockets) would work anymore with ORCHIDs,
because if you get a raw ORCHID across the sockets API, you can't tell
by inspecting the ORCHID which overlay it belongs to, because the
context ID is not visible.  It seems that you would need to pass
metadata about the ORCHID across the sockets API, so that the node knows
which ORCHID-based overlay that it belongs to, or else you need to use
LSIs even in the IPv6 case (as suggested by Philip Matthews at the
Vancouver meeting).

Tom


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