The Packet's in the Mail

But What Route Is It On?

Ten or 15 years ago it would have been much simpler and of interest to a much smaller number of people. Back then, before we all worried about Y2K and the web, a router was, well ... a router. There was a small community of vendors and a small number of products that all pretty much did the same things.

Over the past decade the space has changed dramatically. We now have an army of vendors with a galaxy of products targeted at market segments that are becoming more clearly defined week by week.

Routers have what is essentially a very simple job: they forward packets they receive toward the networks or hosts for which the packets are destined. Routers join different networks, and they have some way of determining the network or host to which a packet should be delivered.

The Internet protocol (IP) architecture allows computers, referred to somewhat arcanely as 'hosts' in the parlance of IP, to communicate. IP is an example of a datagram protocol. Datagrams consist of a data and a header portion and are injected into the network that attempts to deliver them to the address contained in the 'destination fields' in the header. An analogy familiar to all of us is that of the postal service. To communicate via 'snail' mail, we write the letter out on paper (the 'data'), we place it in an envelope (the 'header') and we fill in the address (the 'header fields'). Finally, we place the letter in a U.S. postal box (we inject it into the network) whereupon the U.S. Postal Service springs into action and delivers it to the person to whom it is addressed.

There are rules, the 'protocol' part of IP, associated with making both these systems work. For example, in the case of this analogy, the name and street address of the intended recipient are written on the outside of the envelope in English. Only the amount of data that will fit into the envelope is sent. Instinctively it is known that a banana in an open paper bag with "For Paul" written on it is not going to make it to my desk, even if deposited in the mail box outside my office. Completely analogous rules apply to our datagrams; they may only be so big, the address must be in a certain place and be of a certain form. We do not, for example, expect an IP network to deliver packets addressed to a DECNet or Appletalk address, although schemes do exist to 'encapsulate' such packets in IP packets and thereby deliver them over IP networks.

There are no temporal guarantees about when packets will be delivered and no guarantees about the interpacket arrival times.Overnight Delivery?

Contemporary IP networks offer, in the main, a single service class, the so-called "best effort." In this respect, the much-derided postal service is considerably more sophisticated. There are, for example, several classes of service: postcard, regular mail, priority mail, etc. The key notion is that by paying more you get a better quality of service (QoS) from the system. In the main this translates to a different delay--the system as a whole actually provides a pretty good bound on loss, the other metric that is of concern in packet networks. In the postal system, the priority of a piece of mail may be indicated in a number of different ways: air mail bears a blue "Par Avion" sticker, next day mail goes in special envelopes. In general terms, these classifications are performed by the users--someone applies the air mail sticker or selects a next day envelope and pays the appropriate fee.

What does all of this have to do with routers? The key notion is that the new generation of routers is going to be the service gateways. These will be the places where users select the service class for their packets--the analog of the postal clerk's window in the local post office.

The IP and the networks based on it have been enormously successful. In large part this is due to key architectural decisions made 30 years ago when it was designed. One of those was to keep the network itself simple, and embed such complexity as was needed in the hosts.

One of the drawbacks of this approach, however, is that systems based on it are constrained in the range of services they can deliver. For example, is it possible for the system, end-to-end, to support paradigms the core network cannot? What about reliable data transfer? What about guaranteed bounds on delay?

We have seen that IP networks offer only "best effort" service. There are no temporal guarantees about when packets will be delivered and no guarantees about the interpacket arrival times. In fact, IP provides no guarantee that it will even deliver packets at all. It does its best to do so, however. Adding capabilities to hosts can deal with the reliability issue.

Transmission control protocol, the TCP part of the familiar TCP/IP, is implemented in the hosts and provides a guaranteed byte-stream delivery on top of an IP service. It does this through a somewhat complicated process of acknowledgements and retransmissions. Two hosts communicating using TCP count the number of bytes they send to each other and expect acknowledgement of the receipt of that data.

Should a partner fail to do so or acknowledge only partial receipt of a message, it is resent. TCP is used by many other protocols and applications to provide increasingly more useful services. For example, the workhorse file transfer protocol (FTP) of the Internet is "built on top of" TCP to ensure reliability.

However, what if the application using the data requires reliable and timely delivery of data? Existing processes so far cannot provide guarantees.

Express Mail Options

The architectural principles are being employed to evolve IP and IP networks to a service class-aware system parallel to the host/network split in functionality already in place. The goal is to keep the core simple and move complexity to the edges, in this case to the edge routers (as opposed to the hosts). The key notion is to "classify" packets in the edge routers and mark them in such a way that the core will provide the correct "service" to them.

Most commonly, classification is associated with what are called "flows." A flow is a sequence of packets that has the same source address and port, the same destination address and port, and the same protocol ID in the header of the individual packets (see "QoS Marketing and Forwarding" chart, page 88). The significance is that these fields essentially identify an end-to-end application data flow that can be associated with specific QoS or class of service requirements. The oft-quoted example is voice over IP (VoIP). Identifying a flow as being one between two voice gateways (using maybe only source and destination addresses) allows it to be marked as requiring low-delay service.

Graph: QoS Marking and Forwarding

The differentiated services (DiffServ) scheme explicitly encodes the result of classification into the packet (in the DiffServ code point [DSCP] field), while multiprotocol label switching (MPLS) relies on using an encapsulating label, separate from the packet header, that can be used to encode service class (in addition to where to send the packet). The DSCP field is a reuse of an existing field in the IP header. MPLS is, in contrast, a completely new protocol.

The trick of making either scheme work end to end is to coordinate the classifi-cation, marking and treatment of packets. In MPLS, a label distribution protocol (LDP) communicates the semantics of the labels between adjacent label switching routers. An LDP message may say, "please send packets encapsulated with label "X" to such and such a network with low delay." In contrast, label "Y" may mean "send these packets the same way, but with best-effort (e.g., cheapest) service only. One might use label "X" for VoIP and label "Y" for e-mail, for example. In DiffServ, a network operator can specify that a particular DSCP indicates, for example, expedited forwarding, and configure the core routers to provide that particular behavior to the packets bearing it. In both schemes, of course, packets must be classified by the edge router before being marked.

While MPLS could theoretically offer more service granularity than the limited DiffServ codepoint space allows, most network operators seem to be aiming toward two or three classes of service, regardless of which technology they will use. This restrictive approach is a pragmatic response to thedifficulty in defining, charging for and even using a large number of service classes, as much as by the technical challenges. There's a parallel with TV here. Sure, cable and satellite can offer tens or hundreds of channels, but how many home-shopping experiences does anyone need?

Paul Doolan is vice president and chief technology officer at Ennovate Networks Inc., Chelmsford, Mass. He can be reached (978) 263-2002.

Share this article: Email, Slashdot, Digg, Del.icio.us, Yahoo!MyWeb, Windows Live Favorites, Furl
Add this article feed to: RSS, My Yahoo, Newsgator, Bloglines