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
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
--
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [EMAIL PROTECTED]
Web: http://net.informatik.uni-tuebingen.de/~fessi/
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
