Prototype Overview
The XIA prototype is based on the Click modular router. The current incarnation supports five XIA principal types: AD (Administrative Domain), HID (Host IDentifier), SID (Service IDentifier), CID (Content IDentifier), and FID (Flood IDentifier). The prototype includes the Click implementation of the XIP network stack, socket API for XIA (Xsocket API), and network bootstrap/support services (e.g., routing, initial host configuration, name service).
XIA allows for hosts to be mobile while keeping mobility transparent to applications. We support migration of existing stream sessions and discovery of mobile services via a Rendezvous Service. We also support down-time when moving between networks.
Active XSP stream sessions are migrated automatically if the underlying network interface associates with another network. This is accomplished by sending a signed MIGRATE request with the new address to the corresponding remote endpoint.
When a mobile service is not in its home network, some or all packets destined to it can be sent to a Rendezvous Service. The rendezvous service then forwards the packets to the mobile host at its current address.
For implementation details, please refer to the Mobility page.
XIA uses various mechanisms to provide intrinsic security. Most of the identifiers used in XIA are hashes of their public keys and are backed by a key-pair only known to the owner of the identifier. We use these identifiers to provide intrinsic security among Hosts and Sessions at different levels.
At the host level, if a router receives packets from an unknown host, it sends a challenge back to the host. The host must respond to the challenge with a response that requires it to use its private key which matches its HID.
At the socket level, we migrate existing streaming sessions or forward packets to a mobile service with signatures based on public-private key pairs that match the SID of the endpoint sockets.
Even before XIA starts, we use a network joining protocol that allows us to securely establish L2, L3 and higher, connectivity.
For implementation details, please refer to the Intrinsic Security page.
Multi-homing is supported in XIA through the Network Joining Protocol. It allows XIA devices to join any available network on one or more of the interfaces on the device.
A DAG is assigned to each active interface. The user applications can query for these DAGs via the Xgetifaddrs() API calls and build application or service DAGs for a specific interface. This allows the application to choose the incoming interface for its corresponding application on a remote host.
As of this writing (Feb 2017) we don't support source routing that allows an application choose an interface for outgoing packets.
Content delivery under XIA is:
- Chunk-based – The content request and delivery from/to the requesting application is chuck-based. (The actual underlying transmission in the network is packet-based, i.e., chunk packetization).
- Reliable – Content chunks are delivered via the Xstream protocol.
- Correct - The integrity of the delivered content is checked by applying a cryptographic hash (e.g., SHA-1) on the delivered content and comparing to the requested CID. This ensures that the data has not been modified in transit. If the hash and CID do not agree the chunk is discarded and the application can choose how to proceed.
XIA facilitates content retrieval by allowing the content requests to be served by any intermediate routers (or the original publisher) that holds a copy of the content. In the XIA prototype, the xcache daemon is responsible for such in-network caching at routers and also used for publishing and serving contents at end-hosts.
Applications use the Xcache API to transfer data to and from the Xcache daemon.
End Host:
- Publisher
- Sends data (video, audio, images, etc) to the cache daemon
- daemon breaks the content into chunks and returns a list of CIDs to the publisher
- publisher creates a manifest file or some other method of advertising the chunk addresses
- publishing app does no more work unless designed to provide CIDs to the client directly
- xcache waits for CID requests and serves he chunks vis the Streaming protocol
- Client:
- obtains a list of CID DAGs via an application specific method
- instructs the xcache daemon to fetch the chunks
- xcache requests each chunk in turn
- one an entire chunk is received, it is sent up to the application
- if configured to do so, xcache also puts a copy of the chunk into it's own cache so it can serve it if requested
- Caching
- If configured to do so, runs an instance of the xcache daemon
- sends a copy of any data coming from a CID to xcache
- xcache watches the data stream for SYN-ACK packets
- when a SYN-ACK is seen, the xcache daemon looks to see if it already has a copy of the chunk, and potentially starts to cache the content depending on policy.
- once it sees the FIN, it validates the content it receives and if correct, saves the chunk and adds the CID to its routing table
- Publishing
- CID requests with no associated local route pass through untouched
- if the CID is found locally and if policy dictates it, the router will pass the request on to it's copy of xcache
- xcache will then serve the content rather than letting the request travel all the way back to the origin server
- daemons/xcache/* (caching daemon)
- api/xcache/* (caching API)
- click/elements/xia/xiacidfilter.cc (click - daemon interface)
Content IDs are used to identify chunks of data. The value of the CID is a cryptographic hash of the associated data. As such, the receiver of the chunk is able to verify that it has not been changed in transit.
See Content Delivery for more details.
The Flood IDentifier is new principal type that adds floodable packets to XIA. FIDs were initially implemented for use in our routing protocol. In addition the using the FID XID type in the DAG, each packet includes a FID header containing information to prevent reflooding packets already seen by the host.
FID packets are reflooded by all hosts in the network using the following rules.
- Initiate a FID packet
- pick random initial sequence #
- Send packet out on all internal facing interfaces
- Receive a FID Packet
- check the sequence # in the header and discard the packet if it is not newer than the previously seen value.
- if the host/router has a route registered for the HID, advance the next pointer in the DAG and route the packet normally
- otherwise, send the packet back out on all internal interfaces except for the one it arrived on
The DAG pictured about provides some unique functionality. If a route exists to the HID, the packet will be routed to the destination host normally. Once there the FID is checked to see if it's a new packet and then processed normally. Including the FID in this path is necessary so that sequence numbers can be checked to see if the packet can be discarded if it is stale or has previously arrived via flooding.
If a route to the HID does not exist, the packet will be flooded to the destination.
By arranging fallbacks in this manner, we can send routing messages from the SDN controller to routers before all routes have been set up. Once routes are in place, packets can be sent directly and avoid the overhead of flooding.
Source Code:
- click/elements/xia/fidrouteengine.cc
- click/include/click/xiafidheader.hh
XIP is XIA's common network layer for all principal types. It handles per-hop packet forwarding and routing in routers as well as at end-hosts. In the XIA prototype, XIP is implemented as several Click elements. The Click configuration files provided in our source use these elements to implement an XIA router and host. See our NSDI paper for a more detailed explanation of XIP.
Primary Source Code:
- click/elements/xia/xiacheckdest.cc
- click/elements/xia/xiadechlim.cc
- click/elements/xia/xianexthop.cc
- click/elements/xia/xiaselectpath.cc
- click/elements/xia/xiatypeclassifier.cc
- click/lib/xiapath.cc
- click/include/click/xiaheader.hh
- click/include/clicknet/xia.h
Source Code:
- click/elements/xia/xstream.cc
- click/include/click/xiastreamheader.hh
XDP is a simple message-based connectionless protocol. XDP does not set up a dedicated end-to-end connection, thus no handshaking establishment process for providing reliability, ordering, or data integrity. Communication is achieved by transmitting data in one direction from source to destination without verifying the readiness of the receiver.
- Unreliable – There is no concept of acknowledgment, retransmission or timeout.
- Not ordered – If two messages are sent to the same destination, the order in which they arrive cannot be predicted.
- Lightweight – There is no ordering of messages, no tracking connections.
- No congestion/flow control – XDP does not support any congestion or flow control.
- click/elements/xia/xdatagram.cc
- click/include/click/xiadatagramheader.hh
XCMP is XIA's version of ICMP. It is very similar to vanilla ICMP, however, XCMP only implements a subset of ICMP's features. The packet format is the same except that XCMP includes an XIP header as opposed to an IP header.
XCMP currently supports the following message types:
- Echo / Echo Reply
- Hop-Limit Expiry
- Unreachable
- Network Unreachable
- Host Unreachable
- XID Unreachable
- click/elements/xia/xcmp.cc
xping and xtraceroute applications use the XCMP protocol.
X-Address Resolution Protocol (XARP) is the XIA version of ARP and is used to resolve XIDs into MAC addresses. Similar to ARP, XARP is a request and reply protocol that runs at level 2 with an Ethernet Type of 0x9990.
The XARP operation and its message format are quite similar to ARP:
- XARP query – a broadcast XARP message (destination mac address FF:FF:FF:FF:FF:FF) requesting an answer for target XID
- XARP response – a unicast XARP message (to the source of XARP query) resolving the target XID to a MAC address
- Hardware Type
- Protocol Type (XIP is 0xc0de)
- Hardware Address Size
- Protocol Address Size
- Operation Type (Request|Reply)
- Source MAC
- Source XID
- Destination MAC
- Destination XID
- click/elements/xia/xarpquerier.cc
- click/elements/xia/xarpresponder.cc
- click/elements/xia/xarptable.cc
We provide a secure network joining protocol for devices to join a network quickly and safely. The protocol is comprised of two parts - the Network Discovery and Advertisement Protocol (NDAP) and Joining and Authentication Protocol (JACP). These protocols allow devices to establish all necessary Layer-2, Layer-3 connectivity and authentication by exchanging just four messages.
Please visit NetJoin for a detailed discussion and implementation details.
XIA sockets extend the standard BSD sockets, and allow developers to write applications that work over XIA.
Because click runs at userlevel, we have chosen to use a standard UDP socket on localhost to communicate between the API library and click. Google protobufs are used to encapsulated information exchanged between the layers. This UDP socket should be considered to be an API call within the Xsocket library rather than an actual socket from the applications perspective.
See the application developer's page for more detail.
Source Code:
- api/xsocket/* (API source code)
- click/elements/xia/xtransport.cc (click API interface)