In TRIAD, the transport layer checksum covers the name of the source and the name of the destination and does not include the addressing in the packet. In the case of multicast, the pseudo-header is based on the name of the channel. The addressing allows efficient forwarding of the packet to a destination; the name-based pseudo-header ensures it arrived at the correct destination (even though the names are not present in the header). Thus, a transport connection is between two endpoints identified by name, not address. To support these semantics, TRIAD-TCP operates as described below.
TRIAD-TCP takes a name parameter as part of connection setup to designate the destination, rather than an address. On connection setup, the local endpoint computes and saves a precomputed pseudo-header checksum value (PHCV) based on the name of the source and the destination, similarly at the remote endpoint. The source and destination names are also stored in the connection state record with the PHCV. When a packet is transmitted, the checksum is computed starting with the PHCV, effectively incorporating this name-based pseudo-header into the packet checksum. On reception, the packet is demultiplexed to the TCP connection state based on the packet addresses and port numbers. This receiving connection state contains the same PHCV, allowing the receiver to (re)compute the packet checksum efficiently. If the computed checksum fails to match that in the packet, the packet is considered corrupted in transmission.
If the packet does not map to a valid connection state, the receiver does a reverse name lookup to determine the source name and looks up the connection by name, creating it if this is a connection setup packet, e.g. a SYN packet in the case of TCP. If the name lookup fails, the packet is discarded as a corrupted packet. An endpoint may receive a packet for an existing connection that does not match based on addressing if the destination name has been rebound to a new IRT (perhaps because of a rerouting or relay agent reboot). The name-based mapping allows the connection state to be located and the address mapping to be corrected.
A transport-level checksum based on this pseudo-header provides end-to-end reliability because it detects corruption of the packet addresses in transit yet does not need to be modified in transit as part of relaying (or forwarding) the packet even though the packet addresses are modified.
This name-based pseudo-header checksum also allows end-to-end security because, with the relay agents not modifying the packet data or checksum, there is no conflict between an encrypted packet and network address translation. WRAP includes a security mechanism similar to IPsec, WRAPsec, which uses names for identification and the same pseudo-header for integrity check verification (ICV), and provides end-to-end security. Note that dispatch to connection state before validating the checksum is required both for secure and insecure connections, unifying the processing in both cases. With conventional TCP implementations, the checksum is often checked before mapping to the associated TCP connection state.
The endpoint name, stored with the connection state, is used to re-establish the connection if the connection fails. This re-establishment works because the name stored by the connection is the proper name for the other end. That is, the rebinding, if successful, maps to the endpoint that is storing the transport-level state of the connection, allowing the transport-level connection to continue with the new address binding, similar to an ARP-level rebinding. The only issue is identifying the state, and that relies on the name, which does not change.
Using this mechanism, TCP can transparently recover from changes in the relay path, whether caused by relay agent reboots or link failures (assuming an alternate path is available). This rebinding makes the translation in the network effectively soft state, preserving one of the key properties of the Internet. UDP-based services are expected to similarly rebind from the name, either periodically or on timeout, in the case of a reliable protocol built on UDP.
Hosts such as public web servers may want to respond to a connection request without (synchronously) looking up the client's name. To support this behavior, TRIAD-TCP includes a (new) option that can carry the PHCV, allowing the server to use this value as the base for the packet checksum calculation. Otherwise, a host receiving a connection setup request does a reverse name lookup on the RA and IRT in the packet to determine the source name. For backward compatibility, TRIAD-TCP uses the current TCP checksum algorithm for a connection where the source and destination are in the same realm, i.e. the IRT is null. However, this option can also be used to negotiate the use of the name-based pseudo-header checksum in general even without use of WRAP.
TRIAD-TCP provides an negotiated ``unreliable'' mode which simply disables retransmissions. This minor extension to TCP as a negotiated option allows applications such as real-time VoIP and video to use TCP and automatically get the rebinding behavior described above (as well as the TCP congestion avoidance mechanisms). With this provision, TCP can replace the wide-area use of UDP in all cases that we are aware of. Then, UDP is only used local to a realm, if at all.
TRIAD routers include support for WRAMP
, an ICMP-like protocol
for sending ``destination unreachable'' messages, similar
to ICMP, thus informing hosts (on a best efforts basis)
when an (RA,IRT) pair is no longer valid.
The behavior in TCP of allowing infinite timeouts when the connection
is idle is supported in TRIAD by a timestamp on the name stored in the
connection record, and rebinding when a connection becomes non-idle
if the connection has been idle with no relookup
for some excessive period of time.
In TRIAD, name mapping is made as reliable as packet forwarding, so applications can use names without loss of reliability. Also, name mapping is as secure as packet forwarding so there is no more risk of the name mapping providing the wrong host than relying on its IP address. This secure, reliable integrated directory service is needed so applications and systems can trust both forward and reverse name lookup. Of course, higher-level checksumming, encryption, and authentication can provide additional security and reliability when needed.
With these techniques, applications on WRAP-aware hosts using TCP have end-to-end semantics and are oblivious to loss of relaying and translating state because of relay agent reboot, except possibly for the performance impact. These changes to TCP do not change the packet format, are local to the implementation, and allow unmodified hosts to communicate within a realm.
Let's now consider WRAP in more detail.