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
