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
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, http://www.nap.edu/html/coming_of_age/ch3_f2.html, "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.