-
Notifications
You must be signed in to change notification settings - Fork 42
FAQ
XIA is a (meta) network architecture whose the central goal is an evolvable and secure Internet architecture. By evolvable, XIA means having an explicit, well defined, incremental path to introduce changes to its network protocol, which is called the eXpressive Internet Protocol (XIP). These changes are introduced and removed in units; each of these units is a principal. By secure, XIA means providing the capabilities to deliver security guarantees to applications. XIA's main vehicles to carry evolution and enable security guarantees are, its expressive network addresses and the intrinsic security found at its network identifiers, respectively. A short presentation of XIA is available on XIA 101 page.
What do you really mean by enabling a crowdsourced future Internet? Doesn't Linux XIA only target network researchers?
The efforts to explore what the future Internet will look like is mostly restricted to the research community nowadays. Thus, one may perceive Linux XIA as just helping the research community, but the truth is that if a broad community of kernel developers, researchers, application developers, users, entrepreneurs, and who else is interested get together on a single platform to explore new network architectures, implement code to address applications' needs, report bugs and suggestions, and make a business over this exploratory network, we believe that we all will make progress faster, and current siloed knowledge will circulate openly.
It is worth pointing that while some members of the "crowd" will be very informed, none of them may know what the future Internet will look like. Still, they, as a group, may figure this out thanks to the principal interoperability built into Linux XIA. In fact, "magic" combinations of principals may come from people that did not conceived or implemented the combined principals.
This community would be an alternative to the slow, open cycle: the researcher community comes up with an idea that get everyone excited, a few more years are spent drafting standards, and even more years afterwards to persuade everyone else that implementing the new standards is worth their time. Applications developers, users, and entrepreneurs will only join the effort way later, if at all.
Finally, if all that Linux XIA ever accomplishes is to bring the community together to explore the future Internet that we all want, it would easily be our most important contribution.
The string format used to print out DAGs is documented at Human readable XIP address format. From that page, one reads the following: The prefix "!" indicates that the address is invalid. Any index greater than 35 (i.e. 'z') is represented by '+', and an empty edge by '*'.
The function that tests if an address is valid or not checks many things as one can verify in the source code, for example, that the DAG is a single component, that there is no edge after an empty edge, the DAG is in topological order, etc.
This function assumes that addresses come from userland, so they cannot have chosen edges, and that is the reason most destination addresses in packets on a wire will be invalid. One may want to have a special version of this function for Wireshark, but nobody has worked on it yet.
Once an address is deemed invalid, all edges are printed out, including empty edges, in order to help with debugging cases like "-2**9", that is, an edge after an empty edge.
This question can arise when considering addresses like the following:
u4id-0a024702c3d70000000000000000000000000000-21: zf-0110000000000000000000000000000000000000-2: xdp-007f4e38904e83634acc7e1340ef7665e3f1f57b-210
It appears as if the edges coming out of the last node of the DAG (the XDP) are directed toward the previous nodes, such as 0 (the U4ID), 1 (the zF), or 2 (the XDP itself). However, the last node of a DAG is always a sink, so the last node does not have any outgoing edges. The edges of the last node represent the edges of the entry node.
This example can be found on the page An exemplifying demo, which includes an image of the DAG that may help you to understand what the textual representation above is trying to show. More information about the address grammar can be found on the page Human readable XIP address format.
In some cases, the source address DAG is the inverse of the destination address DAG, but this is not necessarily true. To new users of XIA, it is perhaps tempting to think of the DAGs as path specifications through the network, so it would only be natural to follow the reverse path back to the source. However, the DAG does not specify a path. The DAG is used to express an intent to the network, and typically the destination intent cannot be expressed in the same way as the source intent.
Consider this simple example, a client wants to send a request to a server, and uses the destination DAG <math>\bullet\rightarrow AD_1\rightarrow HID_1\rightarrow XDP_1</math> to do so. <math>AD_1</math> identifies the server's administrative domain, <math>HID_1</math> identifies the server, and <math>XDP_1</math> identifies a socket listening on the server. When the server receives the request and goes to respond to it, notice that it would not make sense to send data back to the client through the reverse DAG <math>\bullet\rightarrow XDP_1\rightarrow HID_1\rightarrow AD_1</math>, since none of this information is related to the client. Of course, the client could be located in the same administrative domain <math>AD_1</math> and be on the same machine <math>HID_1</math> that the server is, but even in this case, server and client could not share the same XDP XID, and the address would still not be in reverse order: <math>\bullet\rightarrow AD_1\rightarrow HID_1\rightarrow XDP_2</math>.
The original reasoning behind having such a large identifier space was two-fold. First, having a large address space would reduce the possibility of address space depletion. Since XIA must be able to address very large sets of entities, such as identifying globally-unique pieces of content, the address space must be quite large. Second, XIDs typically are cryptographically secure identifiers, and a longer identifier is more secure than a shorter identifier.
It has also been discovered that XIDs can serve as data structures. For example, the zFilter principal uses the XID field as a Bloom filter. It has proven beneficial to have ample space to store information for these kinds of principals.
Currently, XIP addresses must be manually generated by the user using the Human readable XIP address format. There is a project on our Roadmap that will create functionality that simplifies the construction of DAGs, but that project has not yet been claimed.
It is important to keep the DST table up-to-date amid updates to the routing table. Otherwise, stale cache entries may be used and incorrect routing behavior will result. Naive solutions to this problem include flushing the entire DST table every time the routing table is updated, or walking down the DST table to find which entries need to be updated. Both of these solutions are very expensive.
Instead, Linux XIA uses a dependency forest to anchor DST table entries on routing table entries, so that when a routing table entry is updated the cache remains valid. The low-level details of this data structure are outside the scope of this FAQ, but more information can be found in section 3.3 of the PhD thesis Linux XIA: An Interoperable Meta Network Architecture.
These wiki provides information about the high-level concepts of Linux XIA. For more information about the low-level details of the implementation, such as descriptions of functions, see the XIA header files in the kernel source tree, which all match the regular expression include/net/xia_*.h.
The Home page of this wiki provides a thorough overview of the project and how to get involved. We suggest starting there.
All grants that have generously supported the development of Linux XIA are listed on our Funding page.