Through the Network
This article is the fifth and final article of a series focused
on the various pieces of communications technology that can be used
to obtain a Quality of Service (QoS) capability. The previous article
discussed the Type of Service (ToS) byte in the IP header and showed
how the ToS byte can be used to provide differentiated service (DiffServ)
information to routers. (See the sidebar "The Story thus Far"
for more background.) In this article, I will point out some of
the limitations of DiffServ and then examine an alternative approach
to QoS based on Integrated Services and the use of RSVP. I will
briefly describe and discuss a few techniques that can facilitate
obtaining a QoS capability under different networking environments.
There are many aspects associated with QoS that make network managers
and LAN administrators yearn for the good old days when the use
of 64-Kbps time slots was the only way to obtain a Quality of Service.
Fortunately, the ability to support a much higher level of traffic
through the use of packet networks compensates for the effort involved
in effecting a QoS capability.
Return to DiffServ
In the previous article, I noted that this traffic expediting
technique divides transmission into a small number of classes. Routers
then apply a standardized set of behaviors to each class of traffic,
which is referred to as a per hop behavior. Because DiffServ-aware
routers perform their operation without the need to know the path
of traffic or information about other routers in the network, the
technology avoids the need for conveying signaling information other
than the bit composition of the revised ToS byte. While this is
a key advantage of DiffServ, it also results in the need to carefully
consider, as well as control, the arrival rate of one or more types
of traffic classes. For example, consider the use of expedited forwarding
(EF), which represents a simple per hop behavior that informs routers
that packets marked for EF status should be forwarded with minimal
delay and loss. The only way that a network operator can guarantee
minimal delay and loss to all packets marked for expedited forwarding
is to limit the arrival rate of such packets to less than the rate
at which routers can forward them. Although this task may appear
simple, in actuality, this method of flow control can be quite complex
as shown in Figure 1.
In examining Figure 1, let's assume routers 1 and 2 are connected
via a T1 circuit in the middle of a network, while router 1 has
connections via circuits labeled A, B, and C to three other devices.
This means that the network operator must limit the aggregate arrival
rate of EF packets via circuits A, B, and C destined to router 2
via router 1 to less than 1.544 Mbps. In actuality, the network
operator must also consider other traffic classes and control the
aggregate arrival rate of EF-marked packets to a rate significantly
under 1.544 Mbps to enable router 1 to transfer other traffic to
router 2. Because routers connected to circuits A, B, and C may
have one or more inputs that will flow from router 1 to router 2,
EF-marked packets at another hierarchy in the network must also
be considered. As a network increases in complexity, it becomes
harder for the network operator to configure devices at the edge
of the network to mark packets that allow routers to guarantee a
consistent handling of the packets. For this reason, an alternate
approach to provide a QoS capability through a network may be desirable.
One such method is based upon what is referred to as Integrated
Integrated Services refer to a suite of evolving standards intended
to provide a QoS transport capability over IP-based networks. IntServ
dates to the work of the IEFT during the mid-1990s and is defined
in RFC 1633.
The basic design issue covered by IntServ concerns sharing available
bandwidth during times of congestion. Under IntServ, congestion
management consists of the following:
- Admission control, which is invoked by a reservation protocol
to determine whether resources are available for the flow at the
- A routing algorithm, which maintains a routing database that
provides next hop information for each destination address
- A queuing algorithm, which controls the flow of traffic through
- A discard policy, which provides a uniform mechanism that denotes
the conditions under which packets are sent to the great bit bucket
in the sky
Although IntServ includes an admission control function, it does
not define the method of control to be used. However, when discussing
admission control, many people incorrectly associate the ReSerVation
Protocol (RSVP) as part of IntServ. In actuality, RSVP can be used
under IntServ but is not a required member of the architecture.
Because RSVP is currently the only mechanism that can be employed
to deliver guaranteed bandwidth within an IP network, I will describe
the basics of this signaling protocol.
RSVP is a signaling protocol that enables applications to request
guaranteed bandwidth from a network. In doing so, RSVP provides
an admission control capability on an end-to-end basis, since the
availability of required bandwidth determines whether the application
gains access to the network.
Unlike most protocols that are sender driven, RSVP is receiver
driven. The rationale for this change is based upon the need to
accommodate different members of a multicast group that can have
different resource requirements. For example, one member of a multicast
group could be connected to an IP network via a 56-Kbps digital
circuit, while a second member is connected via a corporate LAN
using a T1 line operating at 1.544 Mbps. Under RSVP, a sender will
transmit a Path message downstream toward all receivers. The Path
message includes information on the traffic characteristics of the
data stream that will be generated. Each receiver requests a specific
QoS from the network by responding to the Path message with a reservation
(Resv) message. As a Resv message flows toward the originator, each
router in the path checks to determine whether sufficient resources
are available. If so, a reservation is established, and the Resv
message is forwarded to the next upstream router. Otherwise, the
reservation fails, and an error message is returned to the receiver.
To reduce signaling requirements, a sequence of packets from a
common address with a common destination are treated as a flow specification
(flowspec). The flowspec describes the service requirements in terms
of a desired QoS or reservation request and can include information
such as a service class defined by the application and a reservation
specification (Rspec) that defines the bandwidth required.
Each RSVP-compliant router includes a packet classifier and packet
scheduler. The classifier determines the route of the packet, while
the scheduler is responsible for servicing and forwarding decisions
required to achieve the requested QoS.
Another integral part of each RSVP-compliant router is a filter
specification (filterspec). The filterspec specifies the packets
that will be serviced and the manner in which they will be serviced
based upon the flowspec. An example of the relationship between
the filterspec and flowspec is shown in Figure 2. Note that the
packet classifier aggregates a series of packets that flow to a
common destination. The filterspec specifies packets that will be
serviced by the flowspec, while the flowspec parameters are used
by the router to place packets into applicable QoS-delivery queues.
Both Resv and Path messages have timeout values that are used
by routers and switches to set their internal timers. If those timers
expire, the reservation and routing information associated with
the reservation are turned down. This limits the seizure of resources
by the failure of a receiver to terminate an RSVP session.
Although RSVP is several years young, its implementation is commonly
restricted to small intranets. The reasons for its limited use are
primarily the signaling overhead associated with the protocol, the
need for all routers in a network to be RSVP compliant, and the
inability to negotiate the cost of bandwidth when a QoS traffic
flow crosses an ISP boundary. Concerning the latter, the simplicity
of allocating bandwidth to an application does not mean that it
is easy to bill for the bandwidth. This is because allocated bandwidth
can be temporarily deallocated when the application is quiescent,
permitting a router to use previously allocated bandwidth until
the application needs it. Thus, an interesting issue is how, for
example, would one ISP bill another for an application that required
8 Kbps of bandwidth that was available for use by the host ISP 60
percent of the time? While billing issues between ISPs may take
a while to resolve, many carriers are taking another look at RSVP
for internal use to include its proposed extension to support label
distribution and explicit routing. This issue requires knowledge
of label distribution, so I'll address this topic with the
help of Internet draft documents that describe multiprotocol label
switching (MPLS). (For further discussion of RSVP, see Ron McCarty's
article in this issue.)
Multiprotocol Label Switching (MPLS) represents a switching architecture
where packets entering a network are assigned a label. Then, instead
of forwarding packets based upon searching their routing table,
a router uses the label as a forwarding criteria. Because there
can be tens of thousands of entries in a routing table (while label
entries are associated with device interfaces), it is much faster
for the router to make forwarding decisions based upon the contents
of the label.
The original goal of MPLS was to provide the efficiency of Layer
2 switching to Layer 3 networking. Although the manufacture of application-specific,
integrated circuit (ASIC)-based routers permits relatively fast
router table lookup operations, that negates the original goal of
MPLS, there are other benefits associated with label switching.
Those benefits include the ability to define paths for different
types of traffic through a network (i.e., traffic engineering) and
the creation of IP tunnels through a network facilitating the creation
of virtual private networks (VPNs).
The MPLS Label
The MPLS label is 32 bits in length and consists of four fields
as indicated below:
|-20 bits Label-|-3 bits CoS-|-1 bit stack-|-8 bits TTL-|
The 20-bit label field contains the actual value of the MPLS label
and has local significance in the same manner as a Frame Relay Data
Link Control Identifier (DLCI) is used to convey path information.
The Class of Service (CoS) field permits packets to be placed into
one of eight classes than can affect queuing and discard algorithms
applied to the packet as it flows through each router in a network.
The third field in the label is the Stack (S) field. This one-bit
field is used to indicate a hierarchical label stack and is referred
to as a label stack. This means that it becomes possible for a packet
to have multiple paths with the value of the label stack identifying
a particular path to be taken.
The fourth field, time to live (TTL), consists of eight bits that
provide the functionality of the conventional IP TTL field in the
MPLS header. That is, it prevents a labeled packet from endlessly
wandering through a network. The MPLS label is inserted after the
Layer 2 header, preceding the IP header. The specific path through
an MPLS network is referred to as a label switch path (LSP). The
LSP is provisioned via the use of a label distribution protocol
(LDP), which both establishes a path through an MPLS network and
reserves resources to satisfy the predefined service requirements
for the data path. One pending LDP is the previously mentioned extension
to RSVP to support label distribution and explicit routing referred
to as RSVP-TE.
While one group of vendors (including Cisco and Juniper Networks)
supports the extension of RSVP, a second group of vendors (including
GDC and Nortel) are backing a second signaling mechanism referred
to as CR-LDP. Although both proposed signaling protocols have many
similarities, they are not interoperable, and the IETF's MPLS
working group has its work cut out in attempting to select one.
The MPLS Resource Center (www.mplsrc.com) functions as a
clearinghouse for information on the IETF's MPLS Standard.
There, you can determine whether a selection between the two signaling
protocols was made, as well as access a wealth of MPLS-related information.
Please refer to Ron McCarty's two-part series on MPLS (Sys
Admin Vol 9, Issue 5 and 6) and Randy Zhang's article in
Sys Admin Vol 9, Issue 12 for further discussion of MPLS.
Other QoS Techniques
Although DiffServ, MPLS, and other techniques represent traffic-expediting
methods, there are other techniques end users can employ that also
affect QoS. Those techniques are generally classified as efficiency
methods that facilitate data flow through a network. An example
of an efficiency method is the use of Real-Time Transport Protocol
(RTP) header compression.
RTP adds time stamping and data sequencing information to a packet.
In a voice over IP environment, an RTP header consisting of 12 bytes
is used behind an 8-byte UDP header. The RTP and UDP headers are
in turn prefixed with a 20-byte IP header. If RTP is employed with
an 8-Kbps voice digitization method that results in 20-ms portions
of speech being encoded, then the payload of the UDP segment will
be 160 bits or 20 bytes. This means that the total length of the
IP datagram conveying the digitized voice sample is 60 bytes, of
which only 20 bytes represent the actual payload. Through the use
of RTP header compression, it becomes possible to reduce the IP/RTP/UDP
header from 40 bytes to 2-5 bytes, with the actual reduction dependent
upon the susceptibility of the header's contents to compression.
RTP compression is currently defined in the IETF draft Compressed
Several vendors, including Cisco Systems, have implemented RTP
header compression to enhance communications on serial lines using
Frame Relay, HDLC, Point-to-Point Protocol (PPP) encapsulation,
or via an ISDN interface. Note that there is a relationship between
router processing time to perform header compression and the speed
at which compressed data is provided to a router's interface.
In general, the higher the data rate, the higher the processing
time. Thus, RTP header compression is commonly recommended for use
on slower links operating up to 512 Kbps where RTP header compression
can reduce overhead.
Another QoS technique that can be protocol independent is setting
router queues to prioritize traffic based on packet length. Because
digitized voice and interactive queries are typically transported
in relatively short packets, it becomes possible to favor such applications
over traffic transported in long frames, such as Web pages and graphics.
Focusing on a particular communications transport protocol may
provide control over one or more transmission parameters in conjunction
with a service level agreement (SLA) initiated with a carrier. For
example, in Frame Relay networking, you can use an SLA governing
the delivery rate of frames with or without their discard eligibility
(DE) bit set along with a maximum latency time to provide a QoS
capability to traffic.
As I've noted in this series, there are many parts of this
puzzle. Unlike when the telephone company provided QoS in the form
of reserved 64-Kbps time slots, the ability to provide QoS to packet
networks is significantly more complex. However, the fact that packet
networks dynamically allocate bandwidth makes their transport efficiency
much greater than the use of reserved time slots, resulting in an
economic reward for our efforts. Although it may be quite some time
until all the pieces of the QoS puzzle come together in an orderly
and manageable manner, it doesn't take an expert to note the
With communications carriers installing tens of thousands of fiber
miles each year, while the migration from single channel to wavelength
division multiplexing (WDM) and dense WDM (DWDM) continues to add
significant networking bandwidth, it is quite possible that another
approach to QoS will evolve. That approach is for carriers to provide
sufficient bandwidth to overcome any potential bottlenecks. As we
plan for the vast migration onto packet networks, we need to periodically
check the progress of standards, examine SLA offerings, and be aware
of the techniques used to expedite traffic through our networks.
Who said the life of a network manager or LAN administrator is boring?
Gilbert Held is an award-winning author and lecturer. Gil is
the author of over 40 books and 250 technical articles and has represented
the United States at technical conferences in Moscow and Jerusalem.
Some of Gil's recent titles include Voice and Data Internetworking,
Cisco Router Performance Field Guide, and Cisco Access
List Field Guide (co-authored with Kent Hundley), all published
by McGraw Hill Book Company. Gil can be reached via email at: email@example.com.