A Layered Naming Architecture for the Internet
`
`∗
`Hari Balakrishnan
`hari@csail.mit.edu
`†§
`Scott Shenker
`shenker@icsi.berkeley.edu
`
`†
`Karthik Lakshminarayanan
`karthik@cs.berkeley.edu
`†
`Ion Stoica
`istoica@cs.berkeley.edu
`
`‡
`Sylvia Ratnasamy
`sylvia@intel-research.net
`∗
`Michael Walfish
`mwalfish@csail.mit.edu
`
`ABSTRACT
`Currently the Internet has only one level of name resolution, DNS,
`which converts user-level domain names into IP addresses. In this
`paper we borrow liberally from the literature to argue that there
`should be three levels of name resolution: from user-level descrip-
`tors to service identifiers; from service identifiers to endpoint iden-
`tifiers; and from endpoint identifiers to IP addresses. These addi-
`tional levels of naming and resolution (1) allow services and data
`to be first class Internet objects (in that they can be directly and per-
`sistently named), (2) seamlessly accommodate mobility and multi-
`homing and (3) integrate middleboxes (such as NATs and firewalls)
`into the Internet architecture. We further argue that flat names are a
`natural choice for the service and endpoint identifiers. Hence, this
`architecture requires scalable resolution of flat names, a capability
`that distributed hash tables (DHTs) can provide.
`
`Categories and Subject Descriptors
`C.2.5 [Computer-Communication Networks]: Local and Wide-
`Area Networks—Internet; C.2.1 [Computer-Communication
`Networks]: Network Architecture and Design; C.2.4 [Computer-
`Communication Networks]: Distributed Systems—Distributed
`databases
`
`General Terms
`Design
`
`Keywords
`Naming, Internet architecture, name resolution, distributed hash ta-
`bles, middleboxes, global identifiers
`∗
`MIT Computer Science and Artificial Intelligence Lab
`†
`UC Berkeley, Computer Science Division
`‡
`Intel Research, Berkeley
`§
`International Computer Science Institute (ICSI)
`
`Permission to make digital or hard copies of all or part of this work for
`personal or classroom use is granted without fee provided that copies are
`not made or distributed for profit or commercial advantage and that copies
`bear this notice and the full citation on the first page. To copy otherwise, to
`republish, to post on servers or to redistribute to lists, requires prior specific
`permission and/or a fee.
`SIGCOMM’04, Aug. 30–Sept. 3, 2004, Portland, Oregon, USA.
`Copyright 2004 ACM 1-58113-862-8/04/0008 ...$5.00.
`
`1.
`
`INTRODUCTION
`the Internet architecture is
`Despite its tremendous success,
`widely acknowledged to be far from ideal, and the Internet’s in-
`creasing ubiquity and importance have made its flaws all the more
`evident and urgent. The case for architectural change has never
`been stronger, as witnessed by the burgeoning set of architectural
`critiques and counter-proposals emerging from the research com-
`munity (e.g., [2,5–8,41,45,55,56]). Ironically, the growth that mo-
`tivated these proposals now makes their success unlikely: the sheer
`size of the Internet’s installed router infrastructure renders signifi-
`cant changes to IP almost impossible. The decade-long struggle to
`deploy IPv6 should give any aspiring network architect pause.
`Rather than attempt the Sisyphean task of modifying routers,
`we focus on improving a more malleable facet of the architecture:
`naming.1 Although this restriction in focus prevents us from ad-
`dressing issues that inherently involve routers (such as complete
`denial-of-service protection, fine-grained host-control over routing,
`and quality-of-service) there are many issues for which changes to
`IP would be irrelevant—and for which changes to the naming ar-
`chitecture would be crucial.
`The current Internet has only two global namespaces, DNS
`names and IP addresses, both of which are tied to pre-existing struc-
`tures (administrative domains and network topology, respectively).
`The rigidity and paucity of these namespaces are responsible for
`a variety of architectural ills. For instance, the Internet is now
`widely used by applications to gain access to services (processes
`that are remotely invoked by clients, such as Web servers) and data
`(files, streams, etc.), yet the Internet does not have a mechanism
`for directly and persistently naming data and services.
`Instead,
`both are named relative to the hosts on which they reside. Us-
`ing DNS to name data overloads the names and rigidly associates
`them with specific domains or network locations, making it incon-
`venient to move service instances and data, as well as to replicate
`them [23, 36, 50, 51, 59]. In this sense, the Internet’s current host-
`centric naming treats data and services as second-class network cit-
`izens.
`In addition, users and system administrators often resort to ar-
`chitecturally suspect middleboxes—such as NATs/NAPTs [52],
`firewalls and transparent caches—because they cannot get sim-
`ilar functionality within the architecture. The well-known ar-
`chitectural problems posed by today’s middleboxes include vio-
`lating IP semantics and making the Internet application-specific;
`
`1Of course, our naming proposal requires alterations to host soft-
`ware and, as we discuss later, a new name resolution infrastructure.
`These alterations are a significant deployment barrier but not one
`as unyielding as changing the router infrastructure. We will return
`to this issue in Section 6.
`
`343
`
`Session 9: DNS and Naming
`
`Page 1 of 10
`
`Netskope Exhibit 1023
`
`

`

`see [15, 31, 60] for details.
`To remedy these and other architectural problems, in this paper
`we revisit the issue of naming. We begin by describing four general
`design principles about the nature and use of names. While these
`principles are seemingly innocuous, they are routinely violated in
`today’s Internet. We claim that adherence to these principles re-
`quires a naming framework with four layers: user-level descriptors
`such as search keywords, e-mail addresses, etc.; service identifiers
`(SIDs); endpoint identifiers (EIDs); and IP addresses or other for-
`warding directives.2 We then propose an architecture that makes
`essential use of these namespaces. This architecture has the fol-
`lowing benefits: (1) services and data become “first-class” Internet
`objects, in that they are named independent of network location or
`DNS domain and thus can freely migrate or be replicated across
`host and administrative boundaries, (2) mobility and multi-homing
`of hosts can be gracefully accommodated, and (3) network-layer
`and application-layer middleboxes (which we rechristen “interme-
`diaries”) can be interposed on the data path between two commu-
`nicating endpoints.
`Our principles, naming framework, and architecture rely heav-
`ily on existing proposals. From Nimrod [7] and the Host Identi-
`fication Protocol (HIP) proposal [32, 33, 35], we borrow the idea
`of decoupling the transport and networking layers to address mo-
`bility and multi-homing. From the Unmanaged Internet Protocol
`(UIP) proposal [14], we borrow the idea of using this same de-
`coupling to address problems that result from private addressing
`realms, such as those created by NATs. From the Internet Indirec-
`tion Infrastructure (i3) [53], we borrow the idea of source-directed
`indirection. From Semantic-Free Referencing (SFR) [59], we bor-
`row the idea that the service identifier namespace be flat (meaning
`that the identifiers are unstructured and not overloaded with any se-
`mantics about the object being named, e.g., a flat identifier might be
`a number chosen uniformly at random from [0, 2128−1]), and from
`HIP and UIP again, we borrow the idea that the endpoint identifiers
`be flat. Our proposal thus requires a name resolution infrastruc-
`ture that can scalably resolve flat names. Distributed hash tables
`(DHTs) represent one possible solution to this resolution problem
`(see [3, 40, 42, 54, 61] for background on DHTs), and so we borrow
`from that literature as well.
`Thus, this work is a pastiche of borrowed elements; our con-
`tribution is both the distillation of some basic principles and their
`synthesis into a coherent architecture. We present our four basic
`design principles in Section 2, followed by a description of the ar-
`chitecture and its benefits in Section 3. A key aspect of the proposal
`is flat names, and we discuss the issues associated with them in Sec-
`tion 4. We survey related work in Section 5, and in Section 6 we
`conclude with a brief discussion.
`
`2. DESIGN PRINCIPLES
`
`Those are my principles, and if you don’t like them...
`well, I have others.
`
`Groucho Marx
`
`We now present four basic design principles that we feel are es-
`sential to the nature and use of Internet names.
`
`2This naming hierarchy is nothing more than a particular realiza-
`tion of Saltzer’s taxonomy of network elements [44], in which he
`identified users/services (our SIDs), hosts (our EIDs), network at-
`tachment points (IP addresses), and paths. Since we don’t consider
`aspects of the architecture that require router involvement, we don’t
`address the issue of naming paths.
`
`2.1 Names and Protocols
`Our first design principle addresses the role of names in proto-
`cols.
`
`Principle #1: Names should bind protocols only to the
`relevant aspects of the underlying structure; binding
`protocols to irrelevant details unnecessarily limits flex-
`ibility and functionality.
`
`This seemingly innocuous principle is routinely violated in to-
`day’s architecture. When applications request a service or data,
`they care only about the identity (for service) or content (for data)
`of the object they requested; the particular end-host servicing a re-
`quest is immaterial. However, today’s DNS-based names for ser-
`vices and data (e.g., URLs like http ://abc.org/dog.jpg) force
`applications to resolve service and data names down to an IP ad-
`dress (e.g., to fetch the data named by the URL above, the Web
`browser itself, rather than a lower level software module, has to
`learn the IP address represented by abc.org), thereby binding the
`application request to a particular network location, as expressed
`by an IP address. This resolution violates Principle #1 twice over:
`it binds data and services to particular end-hosts—and, even worse,
`to the network locations of those end-hosts. (In the rest of this pa-
`per, for brevity, we mostly use the term “service” to mean “service
`and data.”)
`Rectifying this double violation requires the introduction of two
`(and only two) new naming layers. First, Principle #1 implies that
`applications be able to refer to services with persistent names that
`aren’t tied to the endpoint hosting the service. We therefore claim
`that a class of names called service identifiers (SIDs) should exist
`that give applications exactly this ability. We think that humans and
`the software they use should get these SIDs as the output of various
`mapping services that take as input user-level descriptors. By user-
`level descriptors, we mean handles in various formats that humans
`can exchange (e.g., search queries, e-mail addresses). See [37, 58,
`59] for discussion about such mapping services.
`Second, transport protocols exchange data between two end-
`points, and the network locations of the endpoints are irrelevant
`to the basic semantics of transport. Only at the IP layer is the
`IP address naturally part of the protocol semantics of best-effort
`packet delivery between network-layer addresses. Today, however,
`the semantics of IP are wound into the transport layers. For ex-
`ample, hosts name TCP connections by a quadruple that includes
`two IP addresses. As a result, a TCP connection fails when the IP
`address of an endpoint changes,3 and a TCP connection on a multi-
`homed endpoint cannot use more than one of the IP addresses at
`a time. Principle #1 suggests that transport protocols should be
`able to refer to endpoints in a manner independent of their IP ad-
`dress or network topology. We thus adopt—from previous work,
`as mentioned in Section 1—the idea of a topologically independent
`endpoint identifier (EID) that uniquely identifies a host.
`These two new naming layers that have been motivated by Prin-
`ciple #1 require two additional layers of name resolution: from
`SIDs to EIDs and from EIDs to IP addresses. To interact with a
`
`3One solution to this problem, Mobile IP [34], treats the mobile
`host’s “home” IP address as a permanent identifier and relies on
`IP-layer packet interception and redirection. Another solution is
`migrating TCP connections “in-band” [48]. A third is allowing
`connections to break but using a session layer to re-initiate broken
`connections [47, 49], giving applications the abstraction of an un-
`interrupted connection. These three solutions work around the fun-
`damental issue: endpoints are named by topological identifiers (IP
`addresses). None directly addresses the architectural shortcoming.
`
`344
`
`Page 2 of 10
`
`Netskope Exhibit 1023
`
`

`

`service (e.g., a Web server), the application initiates a communi-
`cation session whose destination is named by the service’s SID.
`When an application resolves that SID, it gets one or more EIDs
`that identify the end-hosts that run the service. The session will
`typically involve one or more transport-layer (e.g., TCP) connec-
`tions between the client and service EIDs. Before invoking IP, the
`transport layer resolves the EID to the current set of IP addresses to
`which the EID is attached.
`A crucial property of this layering is that the resolution of a SID
`to the eventual set of IP addresses for the communication session
`does not happen prematurely. More concretely, applications gener-
`ally deal with SIDs (after perhaps resolving user-level descriptors),
`transport protocols generally deal with (or bind to) EIDs, and only
`IP itself deals with IP addresses. The resulting bindings are thus ac-
`curate and appropriate even in the face of host mobility and service
`migration. For instance, if the EID-to-IP mapping changes, then
`the transport layer can re-initiate an EID lookup to rebind [35, 48].
`If a service moves, or is copied, to another location, a new SID
`lookup provides the current SID-to-EID bindings; if a service were
`to move while a session were in progress, the application might
`initiate such a lookup to continue the session.
`2.2 Namespaces and Network Elements
`Principle #1 concerned how names should relate to protocols.
`Our second design principle discusses how names should relate to
`their referents. When users care about the identity of an object
`rather than its location, the object’s name should be persistent in
`that it remains unchanged even when the object’s location changes.
`
`Principle #2: Names,
`if they are to be persistent,
`should not impose arbitrary restrictions on the ele-
`ments to which they refer.
`
`The two current global namespaces, IP addresses and DNS
`names, are each closely tied to an underlying structure. Achieving
`scalable routing requires that IP addresses reflect network topology.
`DNS names, though more flexible, nonetheless reflect administra-
`tive structure.
`As has been noted in the URN literature [23, 50, 51] and by oth-
`ers [4,37,59], DNS-based names for data are inherently ephemeral.
`Data does not naturally conform to domain boundaries, so data is
`likely to be replicated on, or moved to, hosts outside the originat-
`ing domain. When this replication or movement happens, exist-
`ing references to the data become invalid; e.g., if the file dog.jpg
`moves to def.org from abc.org, existing Web links that reference
`abc.org are now useless. (For a more complete discussion of the
`problems of hostname/pathname URLs, see [50, 51, 59] and cita-
`tions therein.) The same difficulty arises when services move and
`there are pre-existing pointers to those services (e.g., when a pop-
`ular FTP server encodes a DNS name that is no longer correct),
`though one might argue that services are less peripatetic than data.
`Thus, no namespace currently exists that can persistently name
`data and services. Some of the URN literature proposes a new
`namespace and resolution mechanism [11] for each genre (e.g.,
`ISBN numbers would have their own canonical resolver). Parti-
`tioning allows resolution to scale since different resolver types can
`incorporate genre-specific knowledge, but then adherence to Prin-
`ciple #2 depends on an accurate mapping of elements to genres
`and on an element’s never changing genres. In contrast, the Globe
`project [4], Semantic-Free Referencing [59], and Open Network
`Handles [37] take an entirely different approach: they advocate a
`single new flat namespace that can serve all present and future net-
`work elements. A flat namespace has no inherent structure and so
`does not impose any restrictions on referenced elements, ensuring
`
`EID Resolution
`Service
`
`E I D e , I P = ?
`E I D e , I P = y
`
`Intent:
`“send to EID e’’
`
`Source
`(Querier)
`
`EID: e
`IP: x
`
`Dest
`(Target)
`
`IP: y
`
`Delegate
`
`Figure 1: EID-level delegation. A source queries on a given EID
`and is given the IP address of a delegate. The source could also
`be given the delegate’s EID or multiple EIDs (not shown).
`
`universal compliance with Principle #2. In this paper, we adopt this
`second approach, using a flat namespace for SIDs and EIDs.
`2.3 Resolution and Delegation
`Our first two design principles concerned the role of names. Our
`third addresses how these names are resolved. The typical defi-
`nition of “resolving a name” is mapping a name to its underlying
`“location”. In our case, an SID’s “location” would usually be an
`(EID, transport, port) triple4 and an EID’s location would be an IP
`address. However, we think this typical definition is too restrictive
`and instead adopt the following more general notion of resolution.
`
`Principle #3: A network entity should be able to direct
`resolutions of its name not only to its own location, but
`also to the locations or names of chosen delegates.
`
`In any logical network connection, the initiator at any level (e.g.,
`a human requesting a Web page or an endpoint initiating a trans-
`port connection) intends to connect to a destination entity. In our
`case, for example, transport protocol entities connect to destination
`EIDs. However, the destination entity may not want to handle the
`connection directly, preferring instead to direct the connection to
`a chosen delegate, as shown in Figure 1. This kind of delegation
`neither alters essential trust relationships (if you trust an entity, you
`trust its delegates), nor interferes with established protocol seman-
`tics, as will be seen when we describe the details of such delegation
`in Section 3.2.5
`While the recipient-controlled delegation in Principle #3 might
`seem esoteric at first, it is crucial to the overall architecture. As we
`describe in Section 3, delegation allows the architecture to grace-
`fully incorporate intermediaries, which we define as cleaner and
`more flexible versions of middleboxes. Delegation also yields some
`
`4Resolving an SID can also return meta-data (such as a pathname
`on a Web server) in addition to the “location”, thereby allowing
`data (in this case a Web page) to be named by an SID.
`5Recipient-controlled delegation could accommodate the kind of
`distributed network element envisioned in [9]; that is, the destina-
`tion and its delegate could be part of the same logical element even
`if they are physically distinct.
`
`345
`
`Page 3 of 10
`
`Netskope Exhibit 1023
`
`

`

`protection against denial-of-service attacks, as discussed in Sec-
`tion 3.2.
`
`2.4 Sequences of Destinations
`In traditional IP routing, the routing protocol is responsible for
`choosing the packet’s path through the network. However, there
`have been many source routing proposals in which sources are
`given the power to specify the path or, in the case of loose source
`routing, a few points along the path. We believe that this ability
`should be available not just at the routing layer (which is not our
`concern here) but also at the endpoint and service layers.
`More specifically, the abstraction of sending to a destination
`should be generalized to allow sources to indicate that their pack-
`ets should traverse a series of endpoints (specified by a sequence
`of EIDs) or that their communications, the granularity of which we
`address later, traverse a series of services (specified by a sequence
`of SIDs). Such abstractions would generalize the notion of a desti-
`nation to a sequence of destinations. Note that since these various
`destinations are not specified at the IP layer, but rather at the end-
`point and service layers, these intermediate points do not merely
`forward the packets but may act on them in non-trivial ways.
`Combining this sentiment with Principle #3 suggests that end-
`points and services should be able to have their names resolve not
`just to a single location but more generally to a sequence of iden-
`tifiers (either IP addresses or EIDs). In this way, both senders and
`receivers could loosely dictate the paths of packets sent from them
`or destined for them. This idea is captured in our fourth, and final,
`design principle.
`
`Principle #4: Destinations, as specified by sources and
`also by the resolution of SIDs and EIDs, should be
`generalizable to sequences of destinations.
`
`3. ARCHITECTURE
`We should first note that our belief in the general principles
`above is deeper than our conviction about any of the architectural
`details that follow. The description below is intended to illustrate
`how to achieve the benefits that flow from these principles, but one
`should view this architecture merely as an existence proof that the
`general principles can be realized, not as their definitive embodi-
`ment. In fact, many of the details here arose during an implemen-
`tation effort, described in [60].
`The four general principles led us to claim that (1) two additional
`sets of names (SIDs and EIDs) should exist, (2) these names should
`be flat, (3) the architecture should support delegation as a basic
`primitive, and (4) destinations, whether specified by the source or
`receiver, can, in fact, be sequences of destinations. In this section,
`we present an architecture that results from these claims, first fo-
`cusing on the consequences of SIDs and EIDs (Section 3.1), then on
`delegation (Section 3.2). We defer discussing the consequences of
`flat names to Section 4, and we incorporate the notion of sequences
`in our description of delegation. In the process of describing the
`architecture, we note how it yields the three benefits stated in Sec-
`tion 1, namely making services and data first-class objects, support
`for mobility, and graceful incorporation of intermediaries.
`
`3.1 EIDs and SIDs
`We start by describing how this architecture works in the basic
`case. The discussion of intermediaries in Section 3.2 will compli-
`cate the story. Although we will refer to SIDs and EIDs throughout
`Section 3, not every application will require both SIDs and EIDs.
`The two mechanisms are logically distinct and need not be coupled.
`
`user-level descriptor (ULD) lookup
`(e.g., e-mail address, search string, etc.)
`App obtains SIDs corresponding to ULD
`using a lookup or search service
`SID resolution
`App’s session protocol (e.g., HTTP) resolves
`SID to EIDs using SID resolution service
`
`EID resolution
`Transport protocol resolves EID to
`IP addresses using EID resolution service
`IP address “resolution” (routing)
`
`Figure 2: The naming layers.
`
`Principle #1 led us to claim that applications should bind to SIDs
`and transport protocols should bind to EIDs. Thus, applications
`must use a layer between them and transport that resolves SIDs to
`EIDs, and similarly, transport protocols must use a layer between
`them and IP that translates between EIDs and IP addresses. We will
`call the layers resolution layers, though they do more than simply
`resolve identifiers. These layers could be separate libraries or soft-
`ware that is part of the application or transport protocol. The reso-
`lution layers result in the naming architecture depicted in Figure 2.
`We now give more details on how these resolution layers are used,
`focusing on how they fit into the overall architecture. We defer the
`mechanics of resolution to Section 4.
`In what follows, we assume that humans and the applications
`under their control have already used an auxiliary mapping service
`(e.g., a search engine) to map a user-level descriptor (e.g., a search
`query) to an SID. As a result, we will not discuss user-level
`descriptors and will instead assume that applications have in hand
`an SID representing a service or data.
`
`SID resolution: Consider an SID-aware application, a, run-
`ning on a given host, h, and say that a wishes to gain access
`to a service or data represented by an SID s. The application
`hands s to the SID resolution layer, which contacts the resolution
`infrastructure (one realization of which is described in Section 4)
`and is handed back one or more (EID,transport,port)6 triples,
`where each triple represents an instance of the desired service.
`Following the approach in [59], if the SID abstracts a data item, not
`just a service, then the SID resolution layer would also receive, for
`each triple, an application directive. For example, if s represented
`a Web server, then the triple returned might be (EID of the Web
`server, TCP, port 80). If s represented a Web page, not just a Web
`server, then a pathname on the Web server might also be returned.
`The functions we next describe might be abstracted by an
`application-independent library. However, since the library would
`be under a’s control, and since some applications might want
`different behavior and thus elect not to use the library, we will
`describe the actions as performed by a, not by the library. Given
`
`6Since EIDs are not required, the triple could be (id,transport,port),
`where id is another host identifier, such as a DNS name or an IP
`address. However, as we have noted, such usage would not cope
`with host mobility.
`
`346
`
`Page 4 of 10
`
`Netskope Exhibit 1023
`
`

`

`a triple of the kind mentioned above, a would communicate with
`the specified EID using the specified transport protocol and port
`number (or other transport-specific information). The transport
`protocols, now bound to EIDs (instead of IP addresses), would
`use h’s EID as the source EID and the one from the triple as the
`destination EID. Depending on the application semantics, a might
`use multiple triples for simultaneous connections, or it might use
`multiple triples as backups in case the current connection failed. If
`all of the triples failed, a could re-invoke the SID resolution layer
`to re-resolve s to check for new triples.
`
`EID resolution: The transport protocol prepares one or more
`packets to send, which it passes down to the EID resolution layer.
`The EID resolution layer resolves the destination EID into one
`or more IP addresses.
`(Multiple IP addresses could arise for
`multi-homed hosts and also when a logical endpoint represented
`a collection of physical machines, each with its own IP address.)
`When handing control to the IP layer, the EID resolution layer uses
`one of the returned IP addresses as the destination IP address, and
`the source IP address is that of the sending host. If the destination
`host is unreachable, the EID layer can use another IP address if
`it received more than one from the resolution step.7
`If none of
`the previously returned IP addresses works, the EID resolution
`layer re-resolves the EID in case the corresponding destination IP
`addresses have changed.
`
`Where do these identifiers go?
`Packets are logically des-
`tined for endpoints, which are identified by EIDs. Hence, we
`imagine that EIDs would be carried in packets to identify the
`packet’s logical endpoint. In Section 3.2, we say why the sender
`must put the destination EID in the packet. See [60] for a more
`complete description of one instantiation of this architecture at the
`EID level.
`The case of SIDs is conceptually identical. SIDs name services
`or data, and so the SID must often be carried in band, like the EID.
`However, the SID is not required to be in every packet but rather
`in each logical piece of data being communicated between sender
`and recipient. The actual location of SIDs in data streams would
`vary by application and by what the SID is being used for. For
`example, the SID corresponding to a given SMTP server might be
`carried in an e-mail header. Similarly, the SID corresponding to an
`HTTP Web proxy might be in the HTTP header. If an SID named
`a Web page, the SID might again be somewhere in the HTTP
`header. We will use the term application data unit [10] to mean
`“a coherent unit of data transmitted between applications.”
`In
`the examples above, the e-mail and HTTP requests were the ADUs.
`
`Benefits: As explained in Sections 2.1 and 2.2, naming data
`and services with SIDs overcomes the problems of using DNS-
`based URLs for that purpose. Naming endpoints with EIDs
`provides natural solutions to mobility and multi-homing:
`if an
`endpoint identified by EID e changes its IP address,
`then the
`EID resolution layer on a peer of the endpoint will re-resolve e
`to find the new IP address.8 As explained in [32, 33, 35], this
`rebinding enables continuous operation in the presence of mobile
`or renumbered hosts and provides smooth failover for multi-homed
`hosts; we direct the reader to these references for more details.
`
`7We envision, as in HIP, using explicit end-to-end signaling for ex-
`pected address changes and using EID resolution layer keepalives
`to detect unexpected address changes or other failures.
`8This re-resolution could conceivably occur on each packet but
`more likely will be invoked only when the EID layer on the peer
`detects failure.
`
`3.2 Delegated Bindings and Intermediaries
`is
`The other major aspect of our architecture, delegation,
`dictated by principle #3. In this section we explain the mechanics
`of delegation, and then describe how delegation provides support
`for intermediaries.
`
`Delegation: At the EID layer, a host with EID e can insert
`the IP address or EID of a different host in the resolution infras-
`tructure. As a result, when a third host establishes a transport
`connection to e, its packets actually go to the delegated host. The
`host identified by e must establish state at the delegated host—
`through some protocol outside the scope of our discussion—so that
`when packets arrive at the delegated host they can be forwarded.
`The intermediary uses the destination EID, which is carried in
`every packet, to determine the intended ultimate recipient of the
`packet. This type of intermediary is network-level, in that it is a
`delegate for an endpoint, not a service.
`At the SID layer, the mechanism is similar: a service s, running
`on a host h, rather than listing the EID of h in the resolution in-
`frastructure, instead lists the EID of some other endpoint, o.
`(s
`could also list an SID instead of an EID, and this SID would map
`to an EID.) s would have to establish state at o so that o would
`know how to handle ADUs destined for s. o could be, for example,
`an application-level gateway: hosts trying to contact s would have
`their connections terminated at endpoint o, and the gateway would
`inspect the ADUs, and then make a decision about whether to for-
`ward them. The reason that s’s SID must be in the data stream near
`or in the ADU is to let o know which service is the logical desti-
`nation of the ADU: o might be a gateway for other services s(cid:1)
`, s(cid:1)(cid:1)
`,
`etc. We will call endpoints such as o application-level intermedi-
`aries and give examples of such intermediaries below.
`In accordance with Principle #4, at the SID (resp., EID) level, re-
`ceiving entities could express the fact that more than one intermedi-
`ary should be involved: services (resp., endpoints) could list in the
`resolution infrastructure a sequence of SIDs (resp., EIDs). Each of
`these identifiers represents an intermediary that the receiver wants
`the ADU (resp., packet) to visit on the way to the final destination.
`However, Principle #4 also applies to the source, so our architec-
`ture allows sources to specify a sequence of EIDs or SIDs to be tra-
`versed, via the well-known mechanism of stacked identifiers (used
`by i3 [53] and others). One can think of these waypoints as source-
`controlled (as opposed to receiver-controlled) intermediaries; the
`source can express that it wants one or more intermediaries to send
`on its behalf, just as the destination can express through the resolu-
`tion of its EID that it wants one or more intermediaries to receive on
`its behalf. An intermediary, which is assumed to be a chosen dele-
`gate of either sender or receiver, can also make decisions on behalf
`of the delegator (which might include pushing additional identifiers
`onto the destination stack). These two mechanisms, sender- and
`receiver-controlled indirection, are not exclusive: when both enti-
`ties specify intermediaries, the source creates the actual sequence
`of intermediaries by concatenating its desired sequence to the se-
`quence specified by the receiver (which is returned in the resolution
`step).
`When the receiver and sender switch roles, the origi