[P2PSIP] HIP-P2P-SIP message flow examples

["Henry Sinnreich" <[e-mail]>]

(I have changed the Subject name)

> I am sorry, but I am really  
> new to what is going on at P2PSIP.

Welcome to the crowd! 
Many of us are just as new to what is going on in HIP.

At this point time it seems we must bridge some interdisciplinary
divides alluded to in these postings.

Someone or a group that understands all three: HIP, DHT and SIP would be
very helpful with some message flows (call flows in SIP parlance). 

Using the example message flows, the debated points on the merits of HIP
and also possible duplication with TLS, DTL and SRTP could be
illustrated. Pushing the envelope; the associated protocol layer
diagrams would also help.

Diagrams and message flows are worth 1,000s of email words :-)

I am embarrassed to admit not knowing enough to volunteer to contribute.

Henry

-----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.

> Similarly, in section 3.3, you suggest that a HIP message could be
> tunneled through the overlay rather than establishing a new connection
> for a simple query.

My perhaps faulty understanding is that such "tunnelling" would be  
structurally similar to the case in 3.2.  The only difference would  
be than in 3.2 we discussed forwarding I1 packets (and presumably the  
rest of the packets in the HIP base exchange), while in 3.3 we  
basically state that any HIP packets could be forwarded over the HIP  
BONE, similar to the I1s, without creating any new HIP association.   
In general, the proposed forwarding function is pretty similar to the  
IP overlay forward in Berkeley i3.

> So I'm unclear on when the mechanism in 3.3 would be invoked.

One situation where it would be needed is when the peers lose  
connectivity, e.g., due to both moving at the same time and no more  
knowing each other's locators.  In HIP as defined today, the peers  
would use a HIP rendezvous server to pass HIP mobility update packets  
to pass the new locators.  In the HIP BONE case, the idea is that the  
HIP rendezvous functionality is replaced by the HIP BONE, i.e., the  
overlay would be used to pass the mobility update packets.

Other than that I cannot answer your question about 3.3., since I  
didn't understand that much about it.  I am sorry, but I am really  
new to what is going on at P2PSIP.

I hope that my answers above clarify our thinking.

--Pekka Nikander


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

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