Quality of Service in IP Networks

Kobodi Coffart Mogale

African Institute for Mathematical Sciences

6-8 Melrose Road, Muizenburg, 7945

coffart@aims.ac.za

Supervisor: Prof Anthony E. Krzesinski

Department of Mathematical Sciences

University of Stellenbosch

Stellenbosch, 7600, South Africa

aek1@cs.sun.ac.za

June 22, 2006

Contents

List of Figures ii

Abstract iii

1 Introduction 1

1.1 Approaches to QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 IntServ / RSVP 3

2.1 Implementation framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Traffic characterisation and specifications . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Service classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 Guaranteed service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.2 Controlled load service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.1 Data flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.2 RSVP reservation styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.3 RSVP protocol mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Differentiated Services (DiffServ) 12

3.1 DiffServ domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Per-Hop behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

CONTENTS ii

3.3 Traffic conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Multiprotocol Label Switching (MPLS) 16

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 MPLS components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Label switching architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 MPLS applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5 Survivability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 BGP/MPLS VPN fundamentals 22

5.1 MPLS VPN components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 VPN route distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3 Forwarding across the backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Conclusion 28

A Glossary 29

B Acronyms 31

Acknowledgements 33

Bibliography 34

List of Figures

2.1 Router support for IntServ (adapted from RFC 1633). . . . . . . . . . . . . . . . . . 4

2.2 Audio application example for real-time applications. . . . . . . . . . . . . . . . . . . 5

2.3 RSVP architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 RSVP PATH and RESV messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Merging reservations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 DSCP redefine the IPV4 TOS byte. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Functional diagram of a traffic conditioner. . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 MPLS shim header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.1 Simple BGP/MPLS VPN Network topology. . . . . . . . . . . . . . . . . . . . . . . 23

5.2 Encoding a Route Distinguisher and IPV4 Addresses. . . . . . . . . . . . . . . . . . 24

Abstract

Quality of service has become a major issue in the Internet due to the growth of real-time applica-

tions, such as video-on-demand, video-conferencing, etc. Integrated Services (IntServ), Differenti-

ated Services (DiffServ), and Multiprotocol Label Switching (MPLS) are technologies widely used

to provide a means for delivery of end-to-end QoS to applications over heterogeneous networks.

After reviewing different technical papers, we present a comprehensive summary of QoS in IP net-

works. Additionally, to support outsourcing of IP backbone services for enterprise networks, we

analyse the RFC2547bis specification that describes how to use an IP backbone to provide scalable

Virtual Private Networks (VPN).

Keywords: IntServ, DiffServ, MPLS, Quality of service, BGP, and VPN

Chapter 1

Introduction

The Internet was designed to offer a best-effort (BE) service, which means that the network does

not offer any assurance of the quality of service (QoS). As more users are connected to the network,

they are using new applications which require better service from the Internet. Thus, the Internet

service needs to be modified to deliver satisfactory service to the users. QoS is typically measured

in terms of reliability, delay, jitter and bandwidth [1] allocated to the service.

In the past few years, new types of applications that require performance guarantees beyond the

BE service have emerged. The Internet Engineering Task Force (IETF) proposed and developed

Internet Protocol (IP) QoS protocols for quality of service provisioning on the Internet. These

include Integrated Services and the Resource Reservation Protocol (IntServ/RSVP), Differenti-

ated Services (DiffServ), and Multiprotocol Label Switching (MPLS), which emerged to realize

QoS in the Internet.

1.1 Approaches to QoS

The first approach, IntServ [2] was designed to provide QoS on a per-flow basis according to re-

quests from the end application. The IntServ application first signals its resource requirements to

the network in the form of a reservation, and the network responds to this request. Requests are

then passed to the routers along the path using the Resource Reservation Protocol [3]. Once the

appropriate reservation is installed, the reservation remains in force until the application requests

termination, or the network signals that it is unable to continue the reservation. Traffic characteri-

sation and service-specific steps are employed to ensure that non-complying flows do not affect the

QoS commitments for well-behaving data-flows.

IntServ has defined two standardised services: Controlled-Load Service (CLS) and Guaranteed

Service (GS). However, this architecture is not appropriate to the Internet because of drawbacks

1.1 Approaches to QoS 2

in its design. It is not scalable since it requires per-flow state to be maintained at each network

node. Also, every packet has to be classified into the different service classes. In order to solve

the scalability and flexibility related problems of the IntServ architecture, the IETF defined the

DiffServ protocol [4].

Differentiated Services has the main objective of realizing a scalable architecture for the differen-

tiation of services in IP networks. This architecture does not support the concept of a per-flow

application path state across the network. DiffServ aggregates the entire resource requirement and

drops the concept of a per-application path state across the network, using instead the concept

of aggregated service mechanisms. DiffServ defines a small number of forwarding modes called

per-hop behaviours (PHB) [4], and classifies the IP packet header, using 6 bits in the IPV4 header

type-of-service (TOS) field. The first 6 bits, the Differentiated Service code-point (DSCP), de-

fine the PHB. Currently, two PHBs have been defined: Expedited Forwarding (EF) and Assured

Forwarding (AF).

The IETF has also proposed to use label switching technology [11]. Multiprotocol Label Switching

(MPLS) is an advanced forwarding scheme that works between Layer 2 (data link layer) and Layer

3 (network layer). In MPLS networks, ingress routers label traffic based on Forward Equivalence

Classes (FEC) and core routers use the label to forward the traffic to next node. MPLS routers,

called label-switching routers (LSRs), use the labels along the forwarding tables, to map the packet

to a specific path called the label-switched path (LSP).

MPLS defines a Label Distribution Protocol (LDP) to allow LSRs to inform one another of the

label and FEC bindings it has made. When more packets enter an LSR, MPLS label stacking allows

the aggregation of their FEC Label Switched Path (LSP) into a single route. Label Stacking is

a powerful feature of MPLS, which allows labelled packets to carry labels that are organised in a

last-in-first-out manner.

The border gateway protocol/multiprotocol label switching (BGP/MPLS) Virtual Private Net-

work (VPN) standards, defined by IETF, provide Layer 3 VPN solutions using BGP to carry route

information over a MPLS core. The BGP/MPLS VPN is the choice of service providers due to its

scalability, which is comparable to that of traditional VPN technologies such as ATM and Frame

Relay. The service provider backbone comprises of the Customer Edge (CE) routers, Provider

edge (PE) routers, which are situated at the edge of the service provider (SP) core and connect

directly to the CE, and the Provider (P) routers situated inside the PE routers.

Chapter 2

IntServ / RSVP

The legacy Internet provides a BE service to every user regardless of their requirements. Because

each user receives the same service, congestion in the network degrades the performance of applica-

tions that require a minimum amount of bandwidth to function properly. As the Internet becomes

universally available, there is a marked increase in the number of real-time bandwidth intensive

applications over the Internet, like video-conferencing.

IntServ [2] and RSVP [3] are strongly connected, thus we describe these two technologies together.

While IntServ handles the classification and working of packets, RSVP is used to signal the reser-

vations in the routers. There are two key features that IntServ defined: reserved resources and call

setup.

. Reserved resources. A router must keep track of how much of a resource is currently free to

be allocated.

. Call setup. A flow requiring QoS guarantees must be able to reserve sufficient resources at

each router on a path to ensure that QoS requirements are met. The call setup (also known

the call admission) process requires the participation of each router on the path. All routers

participate in call admission to accept or reject a call based on available resources.

2.1 Implementation framework

The IntServ model implements a framework to provide QoS to IP traffic. In the IntServ framework,

each QoS-enabled node forwards all incoming packets to the packet classifier. The packet classifier

decides to which route and QoS class each packet belongs. As shown in Figure 2.1, the packet

classifier maps incoming packets into classes that will be handled by the packet scheduler. The

packet scheduler queues and forwards the packets according to the contracted QoS. A generic

2.2 Traffic characterisation and specifications 4

description would be that the function of the packet scheduler is to re-order the output queue. There

is another component that could be related to packet scheduler, an estimator. This component is

used to measure properties of the outgoing traffic scheduler.

ReservationAgent

RoutingAgent

ManagementAgent

AdmissionControl

Traffic control databaseRouting database

DriverInput Classifier

InternetForwarder

OutputDriver

Packet scheduler

Figure 2.1: Router support for IntServ (adapted from RFC 1633).

2.2 Traffic characterisation and specifications

The flow descriptor, which describes the traffic and QoS requirements of a flow, consists of two

parts: a filter specification (filterspec) and a flow specification (flowspec). The flowspec consists

of a traffic specification (Tspec) and a service request specification (Rspec). An Rspec defines the

desired QoS, while a Tspec characterises the traffic that the client either sends to, or receives from

the network or the traffic that the receiver will obtain from the network. The filterspec provides

the information required by the packet classifier to identify the packets that belong to the flow.

The service model is primarily concerned with the time-of-delivery of packets [2]. Thus per-packet

delay is the primary metric which the network will use when making QoS guarantees. Applications

are categorised in terms of their behaviour and resource reservation requirements; that is the

real-time applications such as remote video, visualisation, multimedia conferencing and elastic

applications, that are are not time-sensitive such as email, fax, etc.

Real-time applications

An important class of real-time applications are playback applications. In a playback application,

the source takes some signal, packetizes it, and then transmits packets over the network. Figure 2.2

shows an example of a audio real-time application; other examples are Internet radio/TV broadcast,

IP-telephony, and video-conferencing. The network introduces some variation in the delay of the

delivered packets. In order to set up the playback time, an a priori characterisation of a maximum

delay is needed for the application. The receiver de-packetizes the data and then attempts to

faithfully play back the signal. This is done by buffering the incoming data and then replaying

2.3 Service classes 5

the signal at some fixed offset delay from original departure time. The real-time applications are

classified as either tolerant or intolerant.

Speaker

BufferSampler

Microphone ConverterA AB B

Figure 2.2: Audio application example for real-time applications.

Intolerant vs tolerant applications

Tolerant applications impose QoS requirements but with ranges or levels that allow the application

to run even if the optimal QoS levels are not provided. Some applications can afford occasional loss

of data. Tolerant applications are usually inelastic with ranges of QoS requirements, but if their

QoS bounds are violated, they cannot run correctly. An example of these is IP telephony.

On the other hand, hard real-time applications are examples of intolerant applications. For example,

a engine control management system is a hard real-time system because a delayed signal may cause

engine failure or damage. Any application that specifies fixed values for its QoS requirements, and

cannot run if these values are not met is an intolerant application

Elastic applications

While real-time applications do not wait for late data to arrive, an elastic application will always

wait for data to arrive. They use the arriving data immediately, rather than buffering it for

some later time, and will always wait for incoming data. Because arriving data can be used

immediately, these applications do not require any a priori characterisation of the service in order

for the application to function. Generally, elastic applications depend on the average delay and

they work well with best effort service. Examples of these include mail, news delivery, etc.

2.3 Service classes

The IntServ model introduces two additional service classes in addition to the BE service of the

Internet: Guaranteed Service (GS) [5] and Controlled-Load Service (CLS) [6].

2.4 RSVP 6

2.3.1 Guaranteed service

The guaranteed service specification guarantees an assured provision of bandwidth and a strict

bound on the queueing delays for each packet in a session. That is, it does not attempt to minimise

the jitter (the difference between the minimal and maximal datagram delays), but it controls the

maximum queueing delay. The GS guarantees that datagrams will arrive within the guaranteed

delivery time and will not be discarded due to overflows. This service is intended for applications

that need a firm guarantee that a datagram will arrive no later than a certain time after it was

transmitted by its source. For example, video “playback” applications.

2.3.2 Controlled load service

The controlled load service is intended for adaptive applications that can tolerate some delay but

are sensitive to an overloaded network and to the danger of losing packets. Adaptive applications

try to maintain the perceived quality at an acceptable level even under poor network conditions.

Examples are file transfer, email and Internet access. It is a qualitative guarantee in that the

application requests the possibility of low-loss or no-loss packets. CLS is used in both real-time

and elastic applications.

2.4 RSVP

RSVP [3] is a protocol that was designed as an IP signalling protocol for the IntServ model. To

enable resource reservations, an RSVP process in each node has to interact with other modules,

as shown in Figure 2.3. There are differences between the RSVP process in a host and a router.

RSVP is used by a host to request a specific amount of bandwidth from the network. It also receives

and sends RSVP messages, and authenticates requests with the policy control module. In the a

router, the RSVP process relays the appropriate objects to the traffic control. It also stores these

objects in the flow state. The RSVP process uses the routing databases to route RSVP messages

to appropriate destinations.

RSVP is not a routing protocol; it is designed to operate with current unicast and multicast routing

protocols. For example, in the multicast case, a host sends Internet Group Management Protocol

(IGMP) messages to join a multicast group and then sends RSVP messages to resources along

delivery path(s) of that group.

In all nodes, two modules, the admission control module and policy control module, handle resource

reservation requests. The admission control module determines whether the node has sufficient

available resources to supply the requested QoS. The policy control module determines who can

and who cannot reserve network resources on the node. If both tests succeed, parameters are set

2.4 RSVP 7

PacketScheduler

RSVPprocess

Application

PacketClassifier

PacketScheduler

PacketClassifier

processRSVP

AdmissionControl

Process

PolicyControl

HOST ROUTER

RSVP RSVP

DataData

ControlRoutingPolicy

AdmissionControl

Figure 2.3: RSVP architecture.

in the packet classifier and the packet scheduler to exercise the reservation. However, if either test

fails, an error notification is returned to the originating application by the RSVP program.

2.4.1 Data flows

In RSVP, a data flow is a sequence of datagrams that have the same source, destination, and quality

of service. RSVP defines a session to be a data flow with a particular destination and transport-layer

protocol. An RSVP session is defined by its destination IP address (DestAddress), IP protocol

number (ProtoId), and optionally, destination port (DstPort). The DestAddress may be a

unicast or multicast address. The optional DstPort maybe be specified by a Transmission Control

Protocol (TCP)/User Datagram Protocol (UDP). In the session definition where DestAddress is

multicast, it is not necessary to include DstPort since different sessions can always have different

multicast session addresses. However, DstPort is necessary; it allows more than one unicast session

to be addressed to the same receiver host.

2.4.2 RSVP reservation styles

Reservation styles refer to a set of control options that specify a number of supported parameters.

When there is more than one flow, then the router needs to make a reservation to accommodate all

of them. RSVP supports two major classes of reservation: a distinct reservation for each upstream

sender and a shared reservation for sets of senders that are known to not interfere with each other.

Table 2.1 illustrates these two reservation-style types. The three reservation styles defined in RSVP

are Wildcard-Filter (WF), Fixed-Filter (FF), and Shared Explicit (SE).

Selection selection Distinct among senders Shared by senders

Explicit Fixed-Filter (FF) style Wildcard-Filter (WF) style

Wildcard Not defined Shared-Explicit (SE) style

Table 2.1: Reservation attributes and styles.

2.4 RSVP 8

Wildcard-Filter style. The router creates a single reservation that is shared by all senders in

the session. The WF-style of style is used when the flows from different senders do not occur at the

same time; it can be thought of as a shared pipe whose reservation is based on the largest request.

An example of WF is an audio-conferencing meeting in which only one participant is allowed to

speak by an automated moderator. In this case, enough bandwidth to support one voice signal is

required at every link that connects senders to receivers; that is, the reserved bandwidth is shared

by all senders. WF style is symbolically represented by

WF( ∗Q )

where the asterisk represent wildcard sender selection and Q represents the flowspec.

Fixed-Filter style. The FF-style creates a distinct reservation for data packets from a particular

sender, not sharing them with other sender’s packets for the same session. This means that if there

are N flows, N different reservations are made. An example of FF is a video-conferencing meeting

in which each of the N participants receives a video image of the other N − 1 participants. In this

case, bandwidth is not shared; that is, each sender must have reserved bandwidth on every link

that connects it to every receiver. Symbolically, FF-style is represented by

FF ( S1{Q1},S2 {Q2}, . . . )

where the total reservation on a link for a given session is the sum of Q1, Q2, etc. . . for all requested

senders.

Shared Explicit style. The SE-style creates a single reservation which can be shared by a set

of flows. An example of SE is video-streaming in which different receivers can receive and display

video images at different qualities. The amount of bandwidth that needs to be reserved on a given

link is the amount required by the highest quality level that traverse the link. An SE reservation

request containing a flowspec Q and a list of senders S1, S2, . . . can be represented by

SE ( (S1, S2, . . .) )

2.4.3 RSVP protocol mechanisms

RSVP messages

RSVP is a receiver-oriented reservation protocol that is used in an IntServ network to signal the

QoS requirement of an application session along the path from source to destination. There are

two fundamental message types: PATH and RESV. As described in [7] and illustrated in Figure 2.4,

2.4 RSVP 9

Sender

Receiver

Path =Resv =

R2

R3

R1� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� �� �� �� �� �� �� �� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � � �� � � � � �� � � � � �

� � � � �� � � � �� � � � �

� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � �� � � � �� � � � �

Figure 2.4: RSVP PATH and RESV messages.

any applications supporting IntServ use RSVP to inform the receiving application about its coming

flow, and the receiving application makes the reservation.

An application wishing to make reservations in the data transmission path sends a PATH message

along the route provided by routing protocol. These path messages store path state in each node

along the route and information regarding the sender’s traffic characteristics and end-to-end prop-

erties. The path state includes at least the unicast IP address of the previous RSVP-hop node,

which is used to route the RESV message hop-by-hop in the reverse direction. The PATH message

contains the following information:

• Phop: The address of the previous-hop RSVP-capable node that forwards the PATH message.

• Sender Template: Describes the format of data packets that the sender will originate from.

These include the sender IP address and optionally the sender port.

• Sender Tspec: This defines the sender’s traffic characteristics.

• Adspec: A PATH message may carry an advertising information package known as the Adspec.

The contents of the Adspec may be updated by each router along the path.

When the message reaches the receiver, the application will read the contents of the message. Then

the reservation needed for the flow is calculated. The receiver generates a RESV message and replies

upstream towards the sender. The RESV messages follow the reverse of the path the packets will use,

and they create and maintain a reservation state in each router along the path. If the reservation

cannot be made, the router will replace the RESV message with an error message and send it up

the reservation tree.

Routers have no ability to negotiate the demands in the RESV, so if the reservation fails the sender

has to try again with reduced demands. The RESV message contains the following: TIME-VALUE

(refresh period), FLOWSPEC (desired QoS), FILTERSPEC (defines the subset of data packets that

should receive the desired QoS).

2.4 RSVP 10

3Mbps3Mbps 2Mbps 2Mbps

S1

3Mbps 1Mbps

R1 R2

Rt3Rt1 Rt2

R3� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� �� �� �� �� �� �� �

� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � �� � � � �� � � � �

� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � � � �� � � � � � �� � � � � � �

� � � � �� � � � �� � � � �

� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � � � �� � � � � � �� � � � � � �

� � � � � �� � � � � �� � � � � �

� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �� � � � � � � � � � � � � � �

� � � � � �� � � � � �� � � � � �

� � � � �� � � � �� � � � �

Figure 2.5: Merging reservations.

Soft state

The reservation states that are maintained by RSVP at each node are refreshed periodically by

PATH and RESV messages. The state is deleted if no matching refresh messages arrive before the

expiration of a cleanup timeout interval. This type of state managed by a timer is called soft state.

RSVP sends its messages as IP datagrams with no reliability enhancement, occasional losses can

be tolerated as long as at least one of the k refresh messages gets through.

The state can also be deleted by an RSVP teardown message. The teardown message may be

initiated either by an application in a system (sender/receiver) or by a router as the result of state

timeout. There are two types of teardown messages: PathTear and ResvTear. A PathTear travels

towards all receivers downstream from its points of initiation and deletes the path states, as well as

all dependent reservation states, along the way. A ResvTear deletes reservation state and travels

towards all sender upstream from its point of initiation.

If an error occurs or there are not enough resources to be allocated, then either a PATHerr or a

RESVerr message is generated by the corresponding router. This message is returned to the sender

and any reservations already made in the intermediate routers are cancelled along the way.

Reservation merging

When there are multiple receivers, the resource is not reserved for each receiver but is shared up to

the point where paths to different receivers diverge. From the receiver’s point of view, RSVP merges

the reservation requests from different receivers at the point where multiple requests converge. A

Resv message forwarded to a previous hop carries a flowspec that is the largest of the flowspecs

requested by the next hops to which the data flow will be sent. We say the flowspec have been

“merged”.

In Figure 2.5, R3 requests a 2 Mbps bandwidth while R2 requests a 1 Mbps bandwidth. Router Rt3,

2.4 RSVP 11

which needs to make a bandwidth reservation, merges the two requests. The reservation is made

for 2 Mbps, the larger of the two, because a 2 Mbps input reservation can handle both requests.

Chapter 3

Differentiated Services (DiffServ)

Differentiated Services [8] is a model which provides QoS through a relative priority scheme, with

network devices handling traffic aggregates rather than the IntServ model approach of handling

individual flows. The DiffServ Working Group standardised a set of router behaviours to be applied

to marked packets. These are called per-hop behaviours (PHB), indicating that they define the

behaviour of individual routers rather than end-to-end services. The IETF has redefined the old

TOS field from the IP header. As illustrated in Figure 3.1, six bits of this field have been allocated

for Differentiated Services Code Point (DSCP), where each DSCP identifies a particular PHB to

be applied to a packet. The other two bits in the octet are currently unused and are ignored by

the router.

In the DiffServ architecture, services are defined in the form of a Service Level Agreement (SLA)

between a customer and the service provider. The SLA specifies the forwarding service that the

customer will receive. One element in an SLA is the traffic conditioning agreement (TCA), which

details service parameters for traffic profiles and policy actions.

DSCP Precedence TOS 0

Differentiated Services Codepoint (DSCP) RFC 2474

IP Type of Service (TOS) RFC 791

CU

MustBe Zero

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

CurrentlyClass Selectorcodepoints Unused

RFC 1812 RFC 1349

Figure 3.1: DSCP redefine the IPV4 TOS byte.

3.1 DiffServ domain 13

3.1 DiffServ domain

A DiffServ domain is a contiguous set of DiffServ nodes which operate with a common service policy

and PHB conditions. A DiffServ domain normally consists of one or more networks under the

same administration, e.g. an organisation’s intranet or an ISP. The administration of the domain

is responsible for ensuring that adequate resources are provisioned to support the differentiated

services offered by the domain. Nodes within the DiffServ domain select the forwarding behaviour

for packets based on their DSCP, mapping that value to one of the supported PHBs using either

the recommended codepoint or the PHB mapping.

Where an end-to-end path involves the connection of DS domains, called the DiffServ region, it is

up to the network operator to ensure that each DS domain acts in a way that supports the end-to-

end QoS goals. Edge routers surrounding DiffServ domain are known as DS boundary nodes with

traffic entering a DiffServ domain at a DS ingress node and leaving a DS domain at a DS egress

node. The interior nodes, as part of the DS domain, only connect to other DS interior or boundary

nodes within the same DiffServ domain. Interior nodes may also be able to perform limited traffic

conditioning functions such as DS codepoint re-marking1.

3.2 Per-Hop behaviours

The PHB is the policy applied to a packet when passing through a hop. There have been several

PHBs proposed, but only two have gained much attention: expedited forwarding (EF) [9] and

assured forwarding (AF) [10].

Expedited Forwarding

The EF (also known as premium service) PHB provides low-loss, low-latency, low-jitter, end-to-

end bandwidth through the DiffServ domain. This service appears to the users as a point-to-point

connection or “virtual leased line”.

To ensure low-loss, low-latency, and jitter for some traffic aggregate, the aggregate arrival of EF

packets at every router should be less than the aggregate minimum allowed departure rate. For

example a router with 100Mbps interface needs to be assured that the arrival rate of EF packets

destined for that interface never exceeds 100Mbps. The rate limiting of EF packets is achieved by

configuring the routers at the edge of an administrative domain to allow a certain maximum rate

of EF packet arrivals into the domain. A simple approach will be to ensure that the sum of the

rates of all EF packets entering the domain is less than the bandwidth of the slowest link in the

1re-marking: to change the DS codepoint of a packet in accordance with a Traffic Conditioning Agreement (TCA)

3.2 Per-Hop behaviours 14

domain.

There are several queueing scheduling mechanisms to implement EF behaviour. The simplest of

these is a priority queue (PQ), where the arrival rate of the queue is strictly less than its service rate.

This algorithm has the following drawback: when packets from the highest priority are present,

the packets in lower priorities are probably starving. It is possible that when a source sends too

much traffic and has the highest priority, it may occupy up to 100% bandwidth. Therefore, the

SLA must be used to manage the bandwidth.

Another mechanism is to perform weighted fair queueing (WFQ) between EF packets and other

packets. A packet from the queue with the biggest weight is dequeued; the queue with the next

bigger weight is dequeued, and so on. The WFQ compares the weight for each sub-queue with the

bandwidth share. This algorithm assures that no service occupies more bandwidth on the average

than it should accept.

Assured Forwarding

The AF PHB group is a means for a provider DiffServ domain to offer different levels of forwarding

assurances for IP packets received from a customer DiffServ domain. The AF PHB divides the traffic

into four classes, where each AF class is guaranteed to be provided with some minimum amount

of forwarding resources (bandwidth and buffering). Within each AF class IP packets are marked

with one of three possible drop precedence values. In the case of congestion, the drop precedence of

a packet determines the relative importance of the packet within the AF class. An AF-compliant

DiffServ node drops low precedence packets in preference to higher precedence packets.

An IP packet that belongs to an AF class number i and has drop precedence value j is marked

with the AF codepoint AFij where 1 ≤ i ≤ 4 and 1 ≤ j ≤ 3.

The recommended values of the AFij codepoint are shown in Table 3.1.

Class 1 Class 2 Class 3 Class 4

Low drop precedence 001010 001100 001110 100010

Medium drop precedence 001100 010100 011100 100100

High drop precedence 001110 010110 011110 100110

Table 3.1: Four drop classes and three drop precedences.

The drop precedence level of a packet could be assigned, for example, by using a leaky bucket traffic

policer, which has as parameters a flow rate and the number of tokens and is the sum of two burst

values: committed burst size and an excess burst size. A packet is assigned low drop precedence if

the number of tokens in the bucket is greater than the excess burst size, medium drop precedence

if the number of tokens in the bucket is greater than zero, and higher drop precedence if the bucket

is empty.

3.3 Traffic conditioning 15

Meter

Slapper/droper

ConditionedClassifiedpackets packets

Marker

Figure 3.2: Functional diagram of a traffic conditioner.

3.3 Traffic conditioning

In order to deliver a service agreement, each DiffServ-enabled edge router implements a traffic

conditioning function that performs metering, shaping, policy, and marking of packets. This ensures

that the traffic entering a DiffServ network conforms to the Traffic Conditioning Agreement. Figure

3.2 shows the block diagram of a traffic conditioner.

Meter. A meter is used to measure the bandwidth of the incoming traffic aggregates and provides

this information to the marker or a shaper/dropper. That is, it passes state information to other

conditioning functions to initiate a particular action for each packet.

Marker. Packet markers are the DiffServ field of a packet to a particular codepoint, adding the

marked packet to a particular DiffServ behaviour aggregate. They may be configured to mark all

unmarked packets or may re-mark previously marked packets.

Shaper. This component stores and forwards the incoming traffic. Shapers delay some or all of

the packets in a traffic stream in order to bring the stream into compliance with a traffic profile.

Packets may be discarded if there is not sufficient buffer space to hold the delayed packets.

Dropper. Droppers discard some or all of the packets in a traffic stream in order to bring the

stream into compliance with a traffic profile.

Chapter 4

Multiprotocol Label Switching

(MPLS)

4.1 Overview

The IETF’s MPLS [11] architecture describes the mechanisms to perform label switching, which

combines the benefits of packet forwarding based on Layer 2 switching with benefits of Layer 3

switching. The main goal of this standard is to create a new platform that provides increased

performance and scalability.

Choosing the next hop for the IP packet is a combination of two functions. The first function

partitions the entire set of packets into a set of Forward Equivalence Classes (FECs). The second

function maps each FEC to an IP next hop. A FEC is a set of flows that can be handled equivalently

for the purpose of forwarding their packets and thus is suitable for binding the packets belonging

to a single label. A label edge router (LER) is responsible for classifying incoming packets and

relating them to FECs. In MPLS, the assignment of a particular FEC is done once, when a packet

enters the network. When packets leave the label edge router (LER) and enter the MPLS domain,

each LSR examines labels in the MPLS packet and matches it with labels within its forwarding

table. This forwarding table is called the label information base (LIB).

In MPLS, data transmission occurs on label-switched paths (LSPs). LSPs are sequence of labels

which identify each node along the path from source to the destination. Within an MPLS domain,

which is a collection of MPLS-enabled routers, a path is set up for a given packet to travel based

on a FEC. MPLS provides explicit routing and hop-by-hop routing options to set up an LSP. In

explicit routing the route taken by a packet is determined by a single node, usually the ingress LSR.

The ingress LSR specifies the list of nodes through which the ER-LSP traverses. In hop-by-hop

routing, each LSR independently selects the next hop for a given FEC. The LSR uses any available

4.2 MPLS components 17

routing protocols, such as Open Shortest Path First (OSPF).

4.2 MPLS components

A router that supports MPLS is called a label-switching router (LSR). The LSR separates the

control and forwarding components. There are two types of LSRs in an MPLS network:

• Edge LSRs make classification and forwarding decisions based on header information within

the IP packet. Edge LSRs can be further classified according to the specific function they

perform:

. Ingress LSRs apply labels to incoming IP traffic flows at the edge of the MPLS network.

The ingress LSR forwards traffic after establishing LSPs using a label signalling protocol.

. Egress LSRs remove labels from outgoing IP traffic flows at the edge of the MPLS

network.

• Core LSRs forward packets along the LSP through the network based on information con-

tained within the applied label.

Labels

A label is defined as a short fixed length physically contiguous identifier which is used to identify

a FEC. The label which is applied to a particular packet represents the FEC to which that packet

is assigned. A shim header label is carried in a Layer-2 header along with the packet. The label

identifies the path a packet should traverse. The label values are of local significance, meaning

they apply only to hops between LSRs. The receiving router examines the packet for its label to

determine the next hop.

Label distribution

A label distribution protocol (LDP) is a procedure by which one LSR informs another of the

label/FEC bindings it has made. It also allows LSRs to determine each others’ MPLS capabilities.

The FEC associated with an LSP specifies which packets are mapped to that LSP. Two LSRs

which use a label distribution protocol to exchange label/FEC bindings information are called label

distribution peers with respect to the binding information they exchange. Initially, an LSR sends

a “test” message over UDP periodically to its neighbours to discover potential LDP peers. When

LDP peer is discovered, the LSR attempts to establish a TCP connection to its peer.

4.2 MPLS components 18

The MPLS architecture allows a LSR to explicitly request, from its next hop for a particular FEC, a

label binding for that FEC. This is known as downstream-on-demand label distribution. The MPLS

architecture also allows an LSR to distribute bindings to LSRs that have not explicitly requested

them. This is known as unsolicited downstream label distribution. It is expected that some MPLS

implementations will provide only downstream-on-demand label distribution, and some will provide

only unsolicited downstream label distribution, and some will provide both.

The label distribution protocol also encompasses any negotiations in which two label distribution

peers need to engage in order to learn of each other’s MPLS capabilities. Extensions to the base LDP

have been defined for the explicit purpose of routing based on QoS and CoS requirement. Among

these are an extension to establish traffic-engineered LSPs called the Resource Reservation Protocol-

Traffic Engineering (RSVP-TE) [12] and constraint-based routing (CR-LDP) [13] protocol.

RSVP-TE and CR-LDP are signalling mechanisms used to support Traffic Engineering (TE) across

an MPLS backbone. RSVP is a QoS signalling protocol that is an IETF standard.

• RSVP-TE is a signalling protocol based on the RSVP originally used for signalling IP QoS

connections. RSVP-TE supports label distribution and explicit routing between each LSR

pair. The RSVP protocol defines a session as a data flow with a particular destination and

transport-layer protocol. However, when RSVP and MPLS are combined, a flow or session

can be defined with greater flexibility and generality. The ingress node of an LSP uses a

number of methods to determine which packets are assigned a particular label. Once a label

is assigned to a set of packets, the label effectively defines the flow through the LSP. We refer

to such an LSP as an LSP tunnel because the traffic through it is opaque to intermediate

nodes along the label switched path.

• CR-LDP contains extensions for LDP to extend its capabilities (designed for hop-by-hop

label distribution to support QoS signalling and explicit routing). This allows extending the

information used to set up paths beyond what is available for the routing protocol.

Label stack

MPLS requires a set of procedures for augmenting network layer packets with “label stacks”, thereby

turning them into “labelled packets”. The label stack mechanism allows for hierarchical operation

in the MPLS domain. The label stack [14] is represented as a sequence of label stack entries. Each

label stack entry is represented by 4 octets. The position and the format of label is shown in Figure

4.1.

• Label Value

This 20-bit field carries the value of the label. If the label entry is at the top of the label

stack, the LSR refers to the value of this field to infer the following:

4.3 Label switching architecture 19

0

0

1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

1 2 3

Label Exp S TTL

Label

Exp

: Label Value, 20 bits

: Experimental Use, 3 bits

S :

TTL : Timeto Live, 8 bits

Bottom of Stack, 1 bit

LabelStackEntry

Packet DataLayer 2 HeaderDatalink Layer IP Header

Layer 3Header MPLS Shim

Figure 4.1: MPLS shim header.

(a) the next hop to which the packet is to be forwarded;

(b) the operation to be performed on the label stack before forwarding; this operation may

be to replace the top label stack entry with another, or to pop an entry off the label

stack, or to replace the top label stack entry and then to push one or more additional

entries on the label stack.

• Experimental Use (Exp)

This three-bit field is reserved for experimental use.

• Bottom of Stack (S)

One of Bottom-of-stack bit identifies the last entry in the label stack and zero for all other

label stack entries.

• Time to Live (TTL)

Eight Time to Live (TTL) bits prevent packets from looping in the network. The value

assigned to the original label by the Ingress LSR is based on the known number of hops in

the defined path.

4.3 Label switching architecture

MPLS label switching relies on two distinct functional components: the forwarding component

and the control component. The forwarding component uses labels carried by packets and the

label-forwarding information maintained by an LSR to perform packet forwarding. The Next Hop

Label Forwarding Entry (NHLFE) is used when forwarding a labelled packet. When forwarding

packets arrive as labelled packets, the Incoming Label Map (ILM) maps each incoming label to a

set of NHLFEs. And, also the FEC-to-NHLFE maps each FEC to a set of NHLFEs for forwarding

packets that arrive unlabelled and which are labelled before being forwarded.

The control component is responsible for maintaining correct label-forwarding information among

4.4 MPLS applications 20

a group of inter connected label switches (LSRs).

Control component

Information has to be stored about the manner in which packets will be routed. The control

component includes label binding between MPLS nodes and uses standard routing protocols to

exchange information with other routers to build and maintain a forwarding table.

Forwarding component

When packets arrive, the forwarding component searches the forwarding table maintained by con-

trol component to make a routing decision for each packet. It does this by examining the table

information when a packet arrives. The forwarding component maps the information in the packet

header with the lookup table to determine the next hop and then directs it to the destination.

4.4 MPLS applications

Currently there are three applications for MPLS in large ISP networks:

• Traffic Engineering

• Class of Service (CoS)

• Virtual Private Networks (VPN).

Traffic engineering

Internet traffic engineering [15] is defined as an aspect of network engineering dealing with the

issue of performance evaluation and performance optimisation of operational IP networks. Traffic

engineering allows ISP’s to move traffic flows away from the shortest paths and onto less congested

paths across the network. Traffic engineering is currently the primary application of MPLS because

of the unpredictable growth in demand for network resources. Successful traffic engineering can

balance a network’s aggregate traffic load on the various links, routers, and switches in the network

so that none of its individual components is overutilized or underutilised.

4.5 Survivability 21

Class of service

Some routers analyse a packet’s network layer header not only to choose the packet’s next hop, but

also to determine a packet’s precedence or class of service. They may then apply different discard

thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the

precedence or class of service to be fully or partially inferred from the label. In this case, one may

say that the label represents the combination of a FEC and a precedence or class of service.

Virtual private networks

A VPN is a private data network that makes use of the public telecommunication infrastructure,

maintaining privacy through the use of a tunnelling protocol and security. A VPN can be set up

by connecting a set of LPSs among VPN sites through LSPs that are dedicated to the VPN. Each

VPN site then tells the ISP about a set of reachable prefixes within the local site. VPN identifiers

allow a single routing system to support multiple VPNs whose internal address overlap with each

other. Each ingress LSR then places traffic into LSPs based on packet’s destination address.

4.5 Survivability

Network survivability refers to the capacity of a network to maintain existing services in the event of

network equipment failures. Since MPLS is on the technology of choice in future IP-based transport

networks, it is necessary that MPLS be able to provide restoration and protection mechanisms of

traffic [16].

With restoration, new paths are established after a failure occurs and the affected traffic is then

routed through the new paths. With a protection mechanism (or protection switching), protection

paths are used as backups for the working paths and are pre-established. When failure occurs,

the affected traffic is switched to the protection paths. These two paths are usually disjoint to

ensure that a failure will not simultaneously affect both paths. Since restoration requires a path to

be established after a failure is detected, restoration take longer to restore traffic than protection.

On the other hand, restoration requires less resources (e.g. bandwidth) than protection since the

resources are only activated after failure occurs.

Chapter 5

BGP/MPLS VPN fundamentals

To achieve the security that is required for corporate users, Virtual Private Networks (VPN) can

be used to guarantee that traffic is securely tunnelled over the Internet. Most VPNs have been

provisioned using Layer 2 technologies, such as Frame Relay, and Asynchronous Transfer Mode

(ATM). The problem with Layer 2 is that it does not scale well and it is difficult to provide traffic

engineering using a Layer 2 VPN approach, i.e. it does not provide a complete separation between

the provider’s network and the customer’s network.

To solve these scaling problems, the Border Gateway Protocol/Multiprotocol Label Switching

(BGP/MPLS) VPN has been adopted to allow service providers (SPs) to use their IP backbone to

deliver VPN solutions to their customers. MPLS is used for forwarding packets over the backbone,

and BGP is used for distributing routes over the backbone.

The primary objectives of this approach is to enable SPs:

• to make the IP backbone service simple for diverse customer population.

• to make service scalable and flexible to large customers.

• to allow SP to deliver a value added service

• to allow separate route forwarding information to be maintained for each VPN client.

5.1 MPLS VPN components

In the context of [17], a VPN is a set of sites which are allowed to communicate with each other.

The VPN is defined by set of administrative policies that determine both connectivity and QoS

service among sites attached to the network which is referred to as the backbone. Policies are

5.1 MPLS VPN components 23

established by customers and can be implemented by the VPN SPs using BGP/MPLS VPN [17].

A customer is connected to the SP network by one or more ports, where the SPs associate each

port with a VPN routing table called VPN routing forwarding (VRF) table. The BGP/MPLS

VPN standard has three key components: Customer Edge (CE) routers, Provider (P) routers, and

Provider Edge (PE) routers. Figure 5.1 illustrates the fundamental building blocks of BGP/MPLS

VPN.

Provider Network

P

P

P

CECE

PE PE

CECE

Figure 5.1: Simple BGP/MPLS VPN Network topology.

Customer Edge routers

Customer Edge router provides access to the SP network over a data link to one or more P routers.

The CE router has an access connection to a PE device, and are customer owned routers. The CE

routers run the routing protocol(s) of the customer’s choice, and they support the IP addressing

scheme implemented by the customer.

Provider routers

P routers within a provider network interconnects PE (or other P) devices but do not have any

direct attachment to CE devices. P routers are the core of the provider network and are concerned

with forwarding VPN traffic that is placed by CE and PE.

Provider Edge routers

PE routers serve as the customer’s entry and exit points for the VPN and are managed by the

SP. All functions associated with maintaining, establishing, and operating MPLS VPN take place

in the PE routers. Typically, a PE router will be connected to multiple CE routers supporting

different customers. A PE router is directly connected to the CE router and exchanges information

5.2 VPN route distribution 24

using static routing, Open Shortest Path First (OSPF), Routing Information Protocol (RIP) or

Exterior BGP (EBGP).

5.2 VPN route distribution

Each VPN is allowed to name its own address space, which means that a given address may denote

different systems in different VPNs. This can result in routing difficulties because BGP assumes

that each Internet Protocol version 4 IPV4 address it carries is globally unique. To solve this

problem, BGP/MPLS VPNs support a mechanism that converts a non-unique IP address into a

globally unique address by combining the use of VPN-IPV4 family [18] with the deployment of

Multiprotocol Extensions BGP (BGP-MP).

VPN-IPV4 address family

If two routes, to the same IP denote address prefix, are actually routes to different systems, it is

important to ensure that BGP not treat them as comparable. Since BGP treats the prefixes as

if they are equivalent, BGP might choose to install only one of them, making the other system

unreachable.

To provide for more than one route to a given IPV4 address, BGP/MPLS VPNs use a 12-byte

quantity that begins with an 8-byte Route Distinguisher (RD) followed by a 4-byte IPV-4 address

to create unique VPN-IPV4 addressing. If several VPNs use the same IPV4 address prefixes, the

PEs translate these into unique VPN-IPV4 address prefixes. The purpose of the RD is to create

distinct routes to a common IPV4 address prefix and also the RD can be used to create multiple

routes to the same system. Figure 5.2 shows the structure of a VPN-IPV4 address family.

Administrator

4−Byte IPV4 Address8−Byte Route Distinguisher

6−Byte2−ByteType Field Value Field

Subfield Subfield

Assigned Number IPV4 Address

Prefix

Type

Field

Figure 5.2: Encoding a Route Distinguisher and IPV4 Addresses.

The RDs are structured so that every SP can administer its own numbering (can make its own

assignments of RDs), without conflicting with the RD assignments made by other SP. An RD can

be specified in either of the following ways:

5.2 VPN route distribution 25

• An autonomous system number (ASN) followed by a 32-bit assigned number (AS). If the

AS is from the public address space, it must have been assigned to the SP by the Internet

Assigned Number Authority (IANA). The AS may be chosen by the SP.

• An IP address followed by a 16-bit AS. If the IP address is from the public address space, it

must have been assigned to the SP by the IANA.

An RD consists of 3 fields: a 2-byte type field, an administrator field, and an assigned number

field. The type fields determines the lengths of the other two fields, as well as the semantics of

the administrator field. The administrator field identifies an assigned numbering authority, and an

assigned number field contains a number which has been assigned, by the identified authority, for

a particular purpose. Currently, there are two values defined for the Type field: 0 and 1.

• Type 0: The Administrator subfield contains 2 bytes and the Assigned number contains 4

bytes. The Administrator subfield holds an autonomous system number. (ASN). The use

of ASN values from the private ASN is strongly encouraged. The Assigned number subfield

contains a value from a numbering space which is administered by the SP that offers the VPN

and to which the ASN has been assigned.

• Type 1: The Value field consists of the Administrator subfield which contains 4 bytes and

the Assigned number field which contains 2 bytes. The Administrator subfield must contain

an IP address. The Assigned number field contains a number from a numbering space which

is administered by the enterprise to which the IP address has been assigned.

The purpose of BGP is to support BGP/MPLS VPN that was designed to carry routing information

only for the IPV4 family. As mentioned above, the IETF realized this limitation by standardising

BGP-MP. These extensions allow BGP to carry routing information for multiple network layer

protocols (e.g Internet Protocol version 6 (IPV6), IPV4, etc).

Route targets

We have talked about VPN and VRF, one might ask if there is no one-on-one mapping between

the two, how does the router know which routes need to be inserted into which VRF. This is solved

by the introduction of another concept in MPLS/VPN architecture: the route target (RT). Every

VPN route is tagged with one or more route targets when it is exported from a VRF. A set of route

targets can also be associated with a VRF, and all routes tagged with at least one of those route

targets will be inserted into the VRF.

Any route associated with RT τ must be distributed to every PE router that has a VRF associated

with RT τ . When such a route is received by a PE router, it is eligible to be installed in those of

the PE’s VRFs which are associated with RT τ .

5.3 Forwarding across the backbone 26

5.3 Forwarding across the backbone

Each PE router needs to maintain one or more separate forwarding tables known as the VRFs.

Every site to which the PE is attached must be mapped to a forwarding table. When a packet is

received from a particular site, each of its VRFs associated with that site is consulted in order to

determine how to route the packet.

Transmitting customer traffic from one VPN site to another VPN site involves a number of different

forwarding decisions.

PE router forwarding. When a PE router receives an IPV4 packet from a CE router, the PE

router performs a route look up in the VRF for the site based on the packet’s destination address.

If a match is found in the VRF, the route lookup returns a next hop.

If the packet’s next hop is reached over a VRF attachment circuit from this PE, then the packet is

sent on the egress attachment circuit.

If the ingress and egress attachment circuits are associated with two different VRFs, and if the

route which best matches the destination address in the ingress attachment circuit’s VRF is an

aggregate of several routes in the egress attachment circuit’s VRF, to forward packets, it might be

necessary to lookup the packet’s destination address in the egress VRF as well.

If the packet’s next hop is not reached over a VRF attachment circuit, the packet must travel at

least one hop through the backbone. The packet thus will have two next hops: a BGP next hop

and an Internal Gateway Protocol (IGP) next hop

• the BGP next hop is the ingress PE router that redistributes the VPN-IPV4 router. The BGP

next hop map assigns an MPLS label for the route that best matches the packet’s destination

address. The PE router pushes this label onto the packet’s label stack and becomes the

bottom label.

• the IGP next hop is the next hop along the IGP route to the BGP next hop. The IGP next

hop is assigned a label (via LDP or RSVP) for the LSP that leads to the BGP next hop

router. This label is pushed onto packet’s label stack and becomes the top label.

CE router to PE router forwarding. When a CE router receives an IPV4 packet from the

system in its site, the CE router performs a match route-lookup and forwards the IPV4 packet to

its directly attached PE router.

5.3 Forwarding across the backbone 27

PE router to CE router forwarding. When a PE router receives the packet, it looks for a

matching MPLS route for the label. When the PE processes a received packet that has this label

at the top of the stack, the PE will pop the stack, and send the packet directly to the site from to

which the route leads. This will usually mean that it just sends the packet to the CE router from

which it learned the route.

Conclusion

In this essay, we have defined current approaches used in Internet to provide QoS: IntServ, Diff-

Serv, and MPLS. Our studies have showed that IntServ and DiffServ are capable of offering QoS

guarantees for real-time traffic with certain limits. Together, IntServ and DiffServ, can facilitate

deployment of multicast applications such IP-telephony, VoD. IntServ and DiffServ deal with issues

relevant to resource reservation and traffic policing.

IntServ enable hosts to request per-flow along end-to-end data paths, and to obtain feedback

regarding admissibility of these requests. Scalability is critical and must be considered when QoS

is required for multicast applications. Per-aggregate based DiffServ is more scalable than per-flow

based IntServ. DiffServ and MPLS can be both employed in core networks because of fast handling

that results in more traffic being handled per time unit. By using MPLS, flows that have the same

demands for QoS and are heading in the same direction can be mapped in the same aggregate flow.

To deliver IP-based services, MPLS is used to map a customer’s private IP network to the provider’s

own IP network. These are commonly known as BGP/MPLS VPNs. BGP/MPLS VPNs offer

increased scalability and flexibility for the SP, and allow the SP to add value. BGP/MPLS VPNs

are well suited for customers that have relatively simple networks. The BGP/MPLS VPNs allow

customers to shift the complexities from the subscriber CE router to the PE router, and allows the

SP to use a shared MPLS infrastructure to transport both private and public data traffic. However,

the BGP/MPLS VPN does not provide a way for a SP to offer IP multicast, and might have

difficulties handling complex routing because it is based on simple routing relationships between

PE and CE router.

Appendix A

Glossary

Border Gateway Protocol (BGP) The exterior gateway protocol used for distributing routes

over the Internet.

Classifier An entity which selects packets based on the content of packet headers according to

defined rules.

Datagram Unit of information sent through a network.

DiffServ domain A contiguous set of nodes which operate with a common set of service provi-

sioning policies and PHB definitions.

DS region A set of contiguous DiffServ domains which can offer differentiated services over paths

across those DiffServ domains.

Forwarding Equivalence Class (FEC) A group of IP packets which are forwarded in the

same manner (e.g., over the same path, with the same forwarding treatment).

Jitter Introduced within routers by unrelated packets passing through shared resources at con-

gestion points (queueing delays).

Label A short fixed length physically contiguous identifier which is used to identify a FEC,

usually of local significance.

Label Switching This is a general technology that combines layer 2 and layer 3 routing tech-

nologies.

Layer 2 The protocol layer under layer 3 (which therefore offers the services used by layer 3).

Label Switching Router (LSR) An MPLS node which is in the interior of the network, capa-

ble of forwarding datagrams based upon a label.

Latency Processing delays experienced within each router or transmission delays across each

link.

Marker A device that performs marking.

Marking The process of setting the DS codepoint in a packet based on defined rules; pre-

marking, re-marking.

Meter A device that performs metering.

30

Metering The process of measuring the temporal properties of a traffic stream selected by clas-

sifier.

PHB group A set of one or more PHBs that can be meaningfully specified and implemented

simultaneously, due to a common constraint applying to all PHBs in the set such as queue servicing

or queue management policy.

Re-mark To change the DC codepoint, usually performed by a marker in accordance with a

TCA.

Traffic conditioner An entity which performs traffic conditioning functions and which may

contain meters, markers, droppers, and shapers.

Traffic Conditioning Agreement (TCA) An agreement specifying classifier rules and any

corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to

apply to the traffic streams selected by the classifier.

Shaper A device that performs shaping.

Shaping The process of delaying packets within a traffic stream to cause it to conform to some

defined traffic profile.

Site The customer network attached to a VPN. A site contains one or more CE routers.

Token bucket An algorithm or a mechanism that is used to control traffic that is injected into

the network, based on the presence of tokens in the bucket. It contains tokens, each of which

represent a unit bytes that travels around a token-ring .

QoS A set of metrics including, service availability, delay, latency, delay-variation, throughput

and packet loss rate (jitter).

Appendix B

Acronyms

AF Assured Forwarding

ASN Autonomous System Number

ATM Asynchronous Transfer Mode

BE Best-Effort

BGP Broad Gateway Protocol

BGP-MP BGP Multiprotocol Extensions

CE Customer Edge Router

CLS Controlled Labelled Services

CoS Class of Service

CR-LDP Constraint-Based Routing–Label Distribution Protocol

DestAddress Destination IP Address

DstPort Destination Port Number

DSCP Differentiated Services codepoint

DiffServ Differentiated Services

EBGP Exterior BGP

EF Expedited Forwarding

FEC Forward Equivalence Classes

FF Fixed-Filter Style

GS Guaranteed Services

IANA Internet Assigned Number Authority

IETF Internet Engineering Task Force

IGP Internal Gateway Protocol

IGMP Internet Group Management Protocol

ILM Incoming Label Map

IntServ Integrated Services

IP Internet Protocol

32

IPV4 Internet Protocol version 4

IPV6 Internet Protocol version 6

LDP Label Distribution Protocol

LER Label Edge Router

LIB Label Information Base

LSP Label Switched Path

LSR label Switching Router

MPLS Multiprotocol Label Switching

NHLFE Next Hop Label Forwarding Entry

OSPF Open Shortest Path First

P Provider Router

PE Provider Edge Router

PHB Per-Hob Behaviour

ProtoId IP Protocol Number

PSC PHB Scheduling Class

PQ Priority Queueing

QoS Quality of Service

RD Route Distinguisher

RIP Routing Information Protocol

RSVP Resource Reservation Protocol

RSVP-TE Resource Reservation Protocol-Traffic Engineering

SLA Service Level Agreement

SE Shared Explicit Style

TCA Traffic Conditioning Agreement

TCP Transmission Control Protocol

TOS Type of Service

UDP User Datagram Protocol

VoD Video-on Demand

VPN Virtual Private Networks

VRF VPN Routing Forwarding

WF Wildcard-Filter Style

WFQ Weighted Fair Queueing

Acknowledgements

The completion of this essay would not have been possible without the encouragement, guidance

and friendship of many individuals. It is an honour to deeply thank the people who have supported

me throughout my pursuit of higher diploma. I would like to thank my supervisor, Prof Anthony

E. Krzesinski for been available during the whole period of my essay. Through his guidance, I have

learnt to identify, develop and present the material in a comprehensive manner.

To Prof. Neil Turok and Prof. Fritz Hahne, many thanks to you for initiating the great idea

of AIMS. Special thanks go to the tutors, especially Mike who has been very supportive to me

throughout my stay at AIMS, Mr Igsaan Kamalie, the kitchen staff, and to all my classmates.

Finally, I would like to thank my family for their support, encouragement and an eternal love.

Many thanks to my mother Idah Mogale, who provided me with an environment that supported

my academic dreams. Lastly, I would like to thank Almighty God for giving me the strength to

pursue my studies up to this level.

Bibliography

[1] B. A. Forouzan, and S. C. Fegan. Data Communications and Networking, McGraw Hill, 2006.

[2] R. Braden, D. Clark, and S. Shenker. Integrated Services in the Internet Architecture: an

Overview, IETF RFC 1633, June 1999.

[3] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource ReSerVation Protocol

(RSVP), IETF RFC 2205, September 1997.

[4] A. Leon-Garcia and I. Widjaja. Communication Networks: Fundamental Concepts and Key

Architectures, 2nd edition, McGraw Hill, 2004.

[5] S. Shenker, C. Partridge, and R. Guerin. Specification of Guaranteed Quality of Service, IETF

RFC 2212, September 1997.

[6] J. Wroclawski. Specification of the Controlled-Load Network Element Service, IETF RFC 2211,

September 1997.

[7] J. Wroclawski. The Use of RSVP with IETF Integrated Services, IETF RFC 2210, September

1997.

[8] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for Differ-

entiated Services, IETF RFC 2475, December 1998.

[9] V. Jacobson, K. Nichols, and K. Poduri An Expedited Forwarding PHB, IETF RFC 2598, June

1999.

[10] J. Heinanen, W. Weiss, J. Wroclawski, and F. Baker, Assured Forwarding PHB Group, IETF

RFC 2597, June 1999.

[11] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol Label Switching Architecture, IETF

RFC 3031, January 2001.

[12] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow. RSVP-TE: Extensions

to RSVP for LSP Tunnels, RFC 3209, December 2001.

BIBLIOGRAPHY 35

[13] B. Jamoussi, L. Andersson, R. Callon, R. Dantu, N. Feldman, and L. Wu. Constraint-Based

LSP Setup using LDP, RFC 3212, January 2002.

[14] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, and A. Conta. MPLS

Label Stack Encoding, RFC 3032, January 2001.

[15] D. O. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and X. Xiao. draft-ietf-tewg-framework-02.txt,

July 2000.

[16] V. Sharma, B-M Crane, S. Makam, K Owens, and L. Andersson. draft-ietf-mpls-recovery-

frmwrk-01.txt, November 2000.

[17] E. Rosen and Y. Rekhter. BGP/MPLS VPNs, RFC 2547, March 1999.

[18] E. Rosen and Y. Rekhter. draft-ietf-l3vpn-rfc2547bis-02.txt, September 2004.