Re: [P2PSIP] New draft: HIP BONE

[Ali Fessi <[e-mail]>]

maybe the best way to understand the inter-working between HIP and P2P 
is to compare it with the inter-working between SIP and P2P.

HIP has the Identifier/Locator separation and SIP has also the 
SIP-URI/Contact-URI seperation.

In both cases, the P2P protocol is used for the overlay maintenance 
(e.g. join and leave).

and usually it is also the P2P protocol that will resolve lookups and be 
responsible for storing data, (i.e. get and put)

So you can use the P2P protocol to resolve a SIP-URI to a Contact-URI 
and perform B2B SIP signaling afterwards.

Simlarly, you can use the P2P protocol to resolve a HIP ORCHID to a 
Locator, and then when you get the Locator start the HIP handshake.

And in fact, this is maybe something confusing in the HIP BONE draft

(many thanks BTW to the authors here. IMHO, the draft clarified many 
things about HIP and its potential use for P2PSIP),

because HIP BONE says that a I1 message is transported hop-by-hop in the 
overlay. I would let the P2P protocol resolve the HIP Identifier to a 
Locator first, and then send the I1 message directly to the HIP Responder.

Cheers,
  Ali


Spencer Dawkins wrote:
> Hi, Thomas,
> 
> I'm not sure I'm entirely in sync with the conversation, but when I was
> speed-reading HIP BONE over the Christmas break, I saw the following 
> text, which seems to say that P2P comes first, because the overlay is 
> used to route I1 packets. ("HIP over P2P")
> 
> My understanding of HIPHOP was that HIP came first, because it was used 
> to forward P2P packets without "popping up" to a P2P protocol engine at 
> every hop. ("P2P over HIP")
> 
> If I am misrepresenting either of these proposals, I apologize.
> 
> If I am not, I am confused, and think that this is one of the key design 
> decisions we need to discuss before moving forward with a P2P/HIP 
> proposal, which I hope we do, by the way.
> 
> Thanks,
> 
> Spencer
> 
>> From draft-camarillo-hip-bone-00.txt:
> 
> 3.2.  Connection Establishment
> 
>   Nodes in an overlay need to establish connection with other nodes in
>   different cases.  For example, a node typically has connections to
>   the nodes in its finger table.  Nodes also need to establish
>   connections with other nodes in order to exchange application-layer
>   messages.
> 
>   As discussed earlier, HIP uses the base exchange to establish
>   connections.  Therefore, a node uses an I1 packet to establish a
>   connection with another node in the overlay.  Nodes in the overlay
>   forward I1 packets in a hop-by-hop fashion according to the overlay's
>   routing table towards its destination.  If the overlay nodes have
>   active connections with other nodes in their finger tables and if
>   those connections are protected (typically with IPsec ESP), I1
>   packets may be sent over protected connections between nodes.
>   Alternatively, if there no such an active connection but the sending
>   peer node has a valid locator for the next hop, the I1 packets may be
>   forwarded directly, in a similar fashion to how I1 packets are today
>   forwarded by the HIP RVS service.
> 
>   Since HIP supports NAT traversal, a HIP base exchange over the
>   overlay will perform an ICE offer/answer exchange between the nodes
>   that are establishing the connection.  In order to perform this
>   exchange, the nodes need to first gather candidate addresses.  Which
>   nodes can be used to obtain reflexive address candidates and which
>   ones can be used to obtain relayed candidates is defined by the peer
>   protocol.
> 
> 3.3.  Lightweight Message Exchanges
> 
>   In some cases, nodes need to perform a lightweight query to another
>   node.  In this situation, establishing a connection using the
>   mechanisms in Section 3.2 for a simple query would be an overkill.  A
>   better solution is to forward a HIP message through the overlay with
>   the query and another one with the response to the query.  The
>   payload of such HIP packet is integrity protected.  Nodes in the
>   overlay forward this HIP packet in a hop-by-hop fashion according to
>   the overlay's routing table towards its destination, typically
>   through the protected connections established between them.
> 
> 
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
> 


-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: [phone] / Fax: [phone]
EMail: [e-mail]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

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