Architectural concept in communications protocol design.


The Hourglass model (1) is essentially the idea of funnelling all communications through some common, ubiquitous communications protocol. Prominent examples of this common protocol are Internet Protocol ("IP") and Asynchronous Transfer Mode ("ATM").

Applications adapt the information they need to convey into this common protocol. In the case of IP, for example, email traffic might get bundled into TCP and this into IP; a telephone call might get encoded in UDP, and this into IP; streaming video goal highlights might get sent via DCCP, which in turn would also be carried on IP. All applications that can find a way to get their message across using IP can then give the rest of the task to an IP stack and not worry too much about how their message gets delivered to the other side of the IP network.

The common narrow layer then gets transmitted across one of many divergent lower layer technologies. In the IP example again, IP might get sent via Ethernet, ATM, FDDI, carrier pigeons, take your pick.

You end up with a world with multiple applications and adaption or transport protocols (wide top) sitting on a single common protocol (narrow waist), which in turn sits on multiple link and physical technologies (wide bottom). Hence the hourglass analogy - wide top supported on wide bottom via a narrow waist. This is far more succinctly expressed in a diagram (such as (2)).


The principle benefit to developers of an hourglass architecture is essentially re-use. Application developers design their stuff once to work on the common narrow waist protocol. Physical and data-link layer equipment and protocol designers could in theory design their stuff once to just carry the common protocol. A clean separation could be made between the physical implementation and the ends for which it is used.

For service operators, a perfect hourglass architecture could ideally mean worrying only about buying, deploying and managing one type of technology and selling only one type of service.

For users the benefit is the Internet effect - suddenly no matter what equipment you've got, or what technology links you to the next guy, you have the potential to talk to more or less everyone - it's that clean separation thing again.


According to (3),

...the "hourglass" metaphor was first used by John Aschenbrenner in 1979, with reference to the ISO Open Systems Interconnection model.
Clearly the idea itself goes back much further than that, for example in Internet Protocol. The hourglass model and associated diagram (2) are now widely used in teaching and in promoting IP-related technologies, in addition to in protocol design and standardisation discussions.


I don't really know whether the analogy was originally drawn with an hourglass or with an hourglass figure. I like to think that each has it's merits.

People involved in IP tend to think of IP as the waist of the hourglass and ATM, for example, as part of the wide bottom. People involved in ATM, of course, think ATM is the waist of the hourglass and IP is part of the wide top. It's one of those "the north is anywhere north of my home town" things. There are probably many other good examples of waist-of-the-hourglass protocols. These days HTTP exhibits hourglass tendencies with all kinds of application exploiting it as a path of least resistance (4).


1. "Realizing the Information Future: The Internet and Beyond", Computer Science and Telecommunications Board, National Research Council, Washington, D.C., National Academy Press, 1994.

2. Hourglass diagram,, "The Internet's Coming of Age", National Academy of Sciences, based on a diagram by Steve Deering.

3. RFC 3234, "Middleboxes: Taxonomy and Issues", Carpenter, Brim, February 2002.

4. RFC 3093, "Firewall Enhancement Protocol (FEP)", Gaynor, Bradner, 1 April 2001.