The Location Layer

Over the past quarter century, stack-based layered architectures have become ubiquitous in networking, most notably the seven-layer OSI model. OSI seperates a Network Layer (responsible primarily for routing) from the Transport Layer and other layers above it. In recent years the Internet’s difficulty in handling mobile devices had suggested flaws in this original design. I propose that a new layer, the “Location Layer”, is needed between the Transport and Network Layers, whose function is to locate network resources, including mobile devices.

INTRODUCTION

Layered architectures generally promote improved protocol design by cleanly seperating disparate functions and focusing protocol design on clearly defined goals. [more on why they are good] [talk about building blocks – I use the work ‘export’ a lot]

While the TCP/IP architecture, structured around a four-layer model, became the dominate networking technology, OSI’s seven layer model has come to dominate network engineers’ conceptional view. [more about practical consequences of this]

The OSI model is not, however, a holy grail, and continues to evolve along with our understanding of data networking. The best example of the architecture’s continuing evolution is the fragmentation of the Data Link Layer into two sub-layers. This was motivated by the increased recognition that bridging required its own addressing structure, independent of both the Network Layer and any particular Link Layer technology.

Of the new networking technologies that have appeared since the development of TCP/IP and the OSI model, mobile devices, especially wireless, present perhaps the greatest challenge to the underlying architecture. Gigabit fiber optics, a million-fold increase in the number of connected devices, video and voice have all been fit remarkably well into the original design, but the simple ability to track a device moving through the network challenges some basic assumptions. [what are they?]

Another major open problem is caching. Notwithstanding the major obstacles to caching in the current web design (dynamic content chief among them), a central problem of caching, perhaps _the_ central problem is locating a suitable cache that contains the data you want. Paul Francis and others have talked about Content Addressable Networking – a network driven by the need to address the DATA and not the DEVICES, and thus fundamentally different from our current designs.

The problems with caching and mobility are both symptoms of the same problem. Both deal with situations where there is no longer a simple, static, one-to-one mapping between “it” and “it’s location”. In the case of mobility, you have a device on the move, with its location constantly changing. In the case of caching, you have possibly millions of copies of the data you’re looking for, spread out over millions of locations. Both present a non-trivial “location problem”.

THE LOCATION LAYER

As Paul Francis and others have argued, the very concept of a ”destination” is poorly defined. Francis identifies three different types of ”addresses”: identifiers, locators, and routes. Of these three, ”routes” seem to be largely an internal tool of the Network Layer, exported only when other layers require more detailed information of the path data takes through the network. The other two types of addresses (”identifiers” and ”locators”) seem more directly applicable to the problem of mobility and by distinguishing between them we can refine our networking model.

I propose refining the basic operation exported by the Network Layer, ”deliver packet to destination,” into two operations performed by two different layers – ”deliver packet to identifier” (identifier can be either a named device or named data) and ”deliver packet to location”. Of the two, “deliver packet to location” seems to match most cleanly with what our current Network Layer does, by using routing tables to find a path through the network to the destination location. The other function, “deliver packet to identifier”, must therefore be the function of a new layer, which I call the Location Layer, and must be between the Transport Layer and the Network Layer. The primary goal of Location Layer protocols would be to convert an identifier into a network location that could be used by the Network Layer to find a path to a particular location in a network topology.

Another way of looking at this is to see the Network Layer fragmenting into two sub-layers, just as the Data Link Layer has at least partially fragmented into a MAC sublayer and an LLC sublayer. Perhaps they would be called the “Location Sublayer” and the “Routing Sublayer”. Yet since the function of the new “Routing Sublayer” would be basically the same as the existing Network Layer, I’ll try to stick to the terminology of adding a new Location Layer to the model.

It is the Location Layer that is relatively novel, since we have been accustomed in the past to devices tied to a single location, requiring a near-nil Location Layer. For a new Location Layer, it would seem we need a new type of address – or do we?

DNS – A LOCATION LAYER PROTOCOL?

A troublesome aspect of the existing OSI model is our inability to neatly classify DNS. Often it is allowed to float to the top and designated an Application Layer protocol, but it is hard to accept that such as fundamental protocol essential to so many applications could actually be an Application Layer protocol. I suggest that our difficulty classifying DNS is because it is essentially a Location Layer protocol.

Consider how much cleaner our protocol operations would be if TCP, sitting in the Session/Transport Layers above a Location Layer DNS, would take advantage of a Location Layer primitive “send-to-DNS-name”. Then a mobile device, using dynamic DNS, could constantly modify its DNS-name-to-IP-address mapping to reflect its changing position. A TCP connection would continue unbroken, because the name being using by TCP (the DNS name) would remain unchanged. From this perspective, the clear protocol layering violation of TCP in including the IP address in its header checksum seems an increasingly suspect design choice.

Clearly, if DNS is a Location Layer protocol, then it is a fledgling one. For starters, there is no clearly defined mechanism by which Internet devices are assigned unique DNS names. But the real question here is, ”could it work?”. Would we lose anything by requiring every Internet device to have one or more unique DNS names? Clearly changes would be required. TCP endpoints would have to be bound to DNS names, not IP addresses. The TCP protocol itself would require changes, since the IP address is used implicitly in the TCP header checksum – a dubious protocol layer violation that may now be coming back to haunt us [CA]. Yet in the final analysis, I can’t see how anything would be fundamentally lost in tieing DNS names to our devices and regarding the IP address as something behind the scenes[CA], something more ephemeral that, like a network route, could morph during routine operation and should not be expected to remain constant.

For the above model to work, the TCP endpoints could not simply look up a DNS name once and use the resulting IP address blindly. In fact, applying the protocol layering concept, we can conclude that the _TCP_ endpoints should not look up the DNS name at all – they should pass it to a DNS resolver which is now seen as the end system component in a Location Layer protocol suite. An end system component which may need serious improvement, possibly modifying the DNS timeout model to include update notification from a DNS server when a record changes. Such modification strikes me as non-trivial and is beyond the scope of this paper. Suffice it to say that the TCP primitive ‘connect(IP-addr,port)’ now seems very suspect; I suggest that ‘connect(DNS-name,port)’ fits much more neatly into this model.

Could there exist another layer of name resolution? Should DNS properly be regarded as a higher-level protocol that produces a new type of address to identify the end system, which would then be converted to an IP address by the Location Layer?

DEPLOYMENT

Clearly, DNS is presently inadequate for full mobility support, but even more problematic is the dependance of higher level protocols (TCP) on the IP address. The first major steps toward deploying a DNS-based Location Layer would be to cleanly seperate the IP address in existing APIs – ‘connect(DNS-name,port)’ become the new primitive.

Clearly this requires rewriting a lot of code.

Could it be done differently? Could existing code be used with a Location Layer architecture? This would seem to require treating at least some IP addresses as fixed, like the present model, while treating others as mobile. Since IP addresses have to be used as upper-layer identifier addresses (to maintain backwards compatibility), while at the same time they possess all the semantics needed for a lower-layer locator address [which are?], this seems a workable model.

Should a new protocol be developed to translate fixed IP addresses into mobile IP addresses? Possibly, but since my analysis above suggests that DNS fits naturally into this role, augmenting DNS seems a better choice. Yet even using an augmented DNS with backwards-compatible IP addresses still requires widespread changes.

What could the “new” DNS look like? First of all is the question of identifying fixed IP addresses and translating them into mobile addresses. This can be done by placing A records in the in.arpa domain (presently only used for CNAME records) to point fixed addresses [new better terminology here] to mobile addresses. Furthermore, to support backwards compatibility with hosts using the older architecture, the fixed addresses should themselves be present and routable in the network. The destination of a fixed address should be a mobile-capable device that then translates the fixed address into a mobile address and forwards the packet across the network. This is exactly the world of Mobile IP.

The presence of IP addresses in the TCP protocol complicates things enormously. What source address does a mobile device use when replying to packets?

Yet this analysis suggests that any device on the network should be capable of performing the role of a Mobile IP gateway so long as a clearly defined protocol allows translation of fixed addresses into mobile ones. Inspired by NAT, let’s call these devices MAT (Mobile Address Translation) gateways. Internet providers could place MAT gateways at their low speed edge connections in order to intercept packets destined for mobile devices and improve overall network performance.

Thus, my analysis suggests that Mobile IP can remain a key component in a backwards compatible network moving towards mobility support. The key requirements to move forward are a clear architectural model (that I have tried to present in this paper), Location Layer protocols (DNS) capable of mobility support (beyond the scope of this paper), modified APIs that hide IP addresses and work solely with DNS names, and MAT gateways.

EXISTING WORK

Paul Francis, in his Ph.D. thesis, clearly distinguishes between ‘locator’ and ‘identifier’ addresses.

Clark, et. al, are very conscious of the overloaded dual role of IP addresses and propose a model (FARA) that cleanly seperates them. I haven’t read enough of this to know, but it looks like (M-)FARA doesn’t nearly slot into the OSI model as a new layer, rather it’s a whole new layered architecture (I think).

SUMMARY

The prospect of fragmenting now a second layer in the OSI model calls the entire architecture into question. A recent major study, [Clark03] suggested that the layered stack might be too restrictive, and proposed a broad model that retains the concept of modularized functionality while allowing the various protocol modules to be interconnected in a general mesh than a stack. While this proposal seems plausible, it seems that the layered architecture can still be expanded – so long as we do not remain wedded to OSI.

An entire layer appears to be missing from the OSI model. While backwards compatible solutions can be comtemplated, ultimately major architectural changes are required to support mobility. Given the apparent inability of the contemporary Internet to successfully deploy even technologies that fit neatly into the existing model, such as multicast, caching, dynamic DNS, and hard cryptographic security, the possibility for major architectural changes seems bleak. Probably, the best we can realistically hope for is an enhanced DNS specification and MAT gateways for those who wish to avoid the inefficiencies of Mobile IP.

Leave a Reply

Your email address will not be published. Required fields are marked *