Allowing applications to evolve with the Internet: The case for Internet Resource Descriptors

Abstract

Today's socket API requires an application to bind a socket to a network address before it can use the socket to communicate. Early bindings of names to addresses create significant bottlenecks, reliability problems, and force applications to manage complex lower-layer issues. Many approaches have been introduced to address this problem; however, all prior proposals introduce additional identifiers, modify applications, or require additional protocols in the protocol stack. In contrast, we propose a generalized socket API based on Internet Resource Descriptors (IRDs), which are opaque identifiers used by applications to refer to network resources and are known only within the hosts in which the applications run. IRDs enable sockets to evolve with the Internet by hiding mobility, multihoming, and multiplexing issues from applications, do not induce significant overhead in the protocol stack, preserve backwards compatibility with today's networks and applications, and do not require additional identifiers or protocols to be used in the protocol stack.

Freeing the IP Internet Architecture from Fixed IP Addresses

“…We have provided simple proofs-of-concept implementations of the concept of hidden identifiers [1], [2]. This paper extends this prior work into a robust, three-part network architecture we call HIDRA (Hidden Identifiers for Demultiplexing and Resolution Architecture).…”

“…As a result, this requirement ensures that the identifiers used by the higher layer are scoped correctly, and can therefore be resolved unambiguously by the higher layer. 1 In this context, we use "name" and "address" interchangeably, since as [3] points out, an "address" is just the "name" of a lower-level entity.…”

“…Open identifiers are transparent values used by communicating parties to name or locate an entity or resource. In contrast to open identifiers, our own recent prior work [1], [2] introduced the architectural concept of a hidden identifier, which is an opaque, meaningless value to be used used internally by a communicating entity instead of an open identifier. Section II provides a discussion of how hidden identifiers differ from and relate to open identifiers.…”

A Simple Solution to Scale-Free Internet Host Mobility

“…Indeed, part of the justification of recent ICN architectures is the argument that using addresses is inherently limiting in supporting the mobility of services or content. However, as we have argued recently [45], [46], [47], the limitations of prior proposals stem from the assumption that the identifiers used in the communication protocols operating in the data plane must be the same as the identifiers used within the protocol stack of a host or a router to pass information across layers of the stack. We have demonstrated that this does not have to be the case and that indirection within the protocol stack can be done efficiently to allow names and addresses used in communication protocols to differ from the identifiers used inside hosts and router to refer to resources, connections, or remote processes.…”

“…First, our prior work on "hidden identifiers" in the protocol stack [45], [46], [47] demonstrates that hosts and routers can denote resources, connections and remote processes with identifiers that need not be the same as those used as part of communication protocols. Second, updating the mappings from names to addresses need not be done solely through a common directory service, and indeed communicating hosts or routers can update one another directly if done properly.…”