QOS IP Networks

Quality of Service in IP Networks

Kobodi Coffart Mogale African Institute for Mathematical Sciences 6-8 Melrose Road, Muizenburg, 7945 coff[email protected]

Supervisor: Prof Anthony E. Krzesinski Department of Mathematical Sciences University of Stellenbosch Stellenbosch, 7600, South Africa [email protected] June 22, 2006

Contents

List of Figures Abstract 1 Introduction 1.1 Approaches to QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ii iii 1 1 3 3 4 5 6 6 6 7 7 8 12

2 IntServ / RSVP 2.1 2.2 2.3 Implementation framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traffic characterisation and specifications . . . . . . . . . . . . . . . . . . . . . . . . Service classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 2.4 Guaranteed service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlled load service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 2.4.2 2.4.3 Data flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RSVP reservation styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RSVP protocol mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Differentiated Services (DiffServ) 3.1 3.2 DiffServ domain

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Per-Hop behaviours

CONTENTS 3.3

ii

Traffic conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16

4 Multiprotocol Label Switching (MPLS) 4.1 4.2 4.3 4.4 4.5

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 MPLS components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Label switching architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 MPLS applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Survivability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 22

5 BGP/MPLS VPN fundamentals 5.1 5.2 5.3

MPLS VPN components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 VPN route distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Forwarding across the backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 28 29 31 33 34

Conclusion A Glossary B Acronyms Acknowledgements Bibliography

List of Figures
2.1 2.2 2.3 2.4 2.5 3.1 3.2 4.1 5.1 5.2 Router support for IntServ (adapted from RFC 1633). . . . . . . . . . . . . . . . . . Audio application example for real-time applications. . . . . . . . . . . . . . . . . . . RSVP architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RSVP PATH and RESV messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 7 9

Merging reservations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 DSCP redefine the IPV4 TOS byte. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Functional diagram of a traffic conditioner. . . . . . . . . . . . . . . . . . . . . . . . 15 MPLS shim header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Simple BGP/MPLS VPN Network topology. . . . . . . . . . . . . . . . . . . . . . . 23

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 applications, such as video-on-demand, video-conferencing, etc. Integrated Services (IntServ), Differentiated 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 networks. 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), Differentiated 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 requests 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 characterisation 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 differentiation 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), define 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 Network (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 applications 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 reservations 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.
Routing Agent Reservation Agent Management Agent

Admission Control Routing database Traffic control database

Input Driver

Classifier Internet Forwarder

Packet scheduler

Output Driver

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.

Microphone

Sampler A B Converter

Buffer B A Speaker

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
HOST
Application RSVP process
RSVP

7
ROUTER RSVP process
RSVP

Policy Control

Routing Process

Policy Control

Admission Control Packet Classifier Packet Scheduler
Data

Packet Classifier

Packet Scheduler

Admission Control
Data

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 Explicit Wildcard Distinct among senders Fixed-Filter (FF) style Not defined Shared by senders Wildcard-Filter (WF) style Shared-Explicit (SE) style

Table 2.1: Reservation attributes and styles.

2.4 RSVP Wildcard-Filter style.

8 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

R2
                      © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨ © ¨ ¨

Path = Resv =

Receiver

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 properties. 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).











£ ¢









£ ¢

Sender

£ ¢

£ ¢

£ ¢

£ ¢

£ ¢

£ ¢

£ ¢

R3

£ ¢

£ ¢

£ ¢

£ ¢

£ ¢





©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

©

¨

¦

¦

¦

§

§

§

¦

¦

¦

§

§

§

¦

¦

¦

¡   ¡   ¡  

§

§

§

¦

¦

¦

§

§

§

¦

¦

¦

¡   ¡   ¡   § § § ¦ ¦ ¥ ¦ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤ ¥ ¥ ¤ ¤

R1

2.4 RSVP
3Mbps 2Mbps 2Mbps
§ ¦ § ¦

10
3Mbps
§ ¦ " " " # # # " " " # # # " " " § ¦ § ¦ § ¦ § ¦ § ¦ § ¦ ¡   ¡   ¡   ¡   ¡   ¡  

Rt1
                      © © ¨ ¨   © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨ © © ¨ ¨

Rt2

Rt3
# # " " # # " " # # " " ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

3Mbps

1Mbps

R1

R2

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 ,

§ ¦

#

"

#

"

§ ¦

#

"

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!































¥ ¤

¥ ¤

¥ ¤

¥ ¤

¥ ¤

¥ ¤

¥ ¤

























¥ ¤

¥ ¤

¥ ¤

¥ ¤

¥ ¤

¥ ¤

¥ ¤











































































































































































£ ¢

£ ¢

£ ¢

£ ¢

£ ¢

£ ¢

£ ¢

























£ ¢

£ ¢

£ ¢

£ ¢

£ ¢

£ ¢

£ ¢





















































































































































¡  









¡  

S1

§ ¦ § ¦ § ¦

¡   ¡   ¡  

¡   ¡   ¡     © ¨  © ¨ © ¨ © ¨ © ¨ © ¨ © ¨ © ¨ © ¨ © ¨ © ¨ © ¨ © ¨ © ¨ © ¨

R3

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.

0

1

2

3

4

5 6 7 CU
Currently Unused

0 1 2 3 4 5 6 7 Precedence
RFC 1812

DSCP
Class Selector codepoints

TOS
RFC 1349

0
Must Be Zero

Differentiated Services Codepoint (DSCP) RFC 2474

IP Type of Service (TOS) RFC 791

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-toend 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-toend 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
1

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

3.2 Per-Hop behaviours domain.

14

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 001010 001100 001110 Class 2 001100 010100 010110 Class 3 001110 011100 011110 Class 4 100010 100100 100110

Low drop precedence Medium drop precedence High drop precedence

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
Meter

15

Marker Classified packets

Slapper/ droper Conditioned packets

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 routing protocols, such as Open Shortest Path First (OSPF).

17

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 contained 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 ProtocolTraffic 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
Datalink Layer Layer 2 Header MPLS Shim Header IP Header Layer 3 Packet Data

19

0 1 2 3 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 Label Label : Label Value, 20 bits Exp : Experimental Use, 3 bits Exp S TTL Label Stack Entry

S : Bottom of Stack, 1 bit TTL : Timeto Live, 8 bits

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 a group of inter connected label switches (LSRs).

20

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 control 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.
CE P CE

PE P P

PE

CE

Provider Network

CE

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.
8−Byte Route Distinguisher Type Field 2−Byte Type Field Administrator Subfield Assigned Number Subfield 6−Byte Value Field 4−Byte IPV4 Address IPV4 Address Prefix

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, DiffServ, 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) over the Internet. Classifier 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 provisioning policies and PHB definitions. DS region A set of contiguous DiffServ domains which can offer differentiated services over paths A group of IP packets which are forwarded in the across those DiffServ domains. Forwarding Equivalence Class (FEC) Jitter Label same manner (e.g., over the same path, with the same forwarding treatment). Introduced within routers by unrelated packets passing through shared resources at conA short fixed length physically contiguous identifier which is used to identify a FEC, This is a general technology that combines layer 2 and layer 3 routing techgestion points (queueing delays). usually of local significance. Label Switching nologies. Layer 2 The protocol layer under layer 3 (which therefore offers the services used by layer 3). An MPLS node which is in the interior of the network, capaLabel Switching Router (LSR) Latency link. Marker Marking Meter A device that performs marking. The process of setting the DS codepoint in a packet based on defined rules; preAn entity which selects packets based on the content of packet headers according to The exterior gateway protocol used for distributing routes

ble of forwarding datagrams based upon a label. Processing delays experienced within each router or transmission delays across each

marking, re-marking. A device that performs metering.

30 Metering 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 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 Shaping Site A device that performs shaping. The process of delaying packets within a traffic stream to cause it to conform to some To change the DC codepoint, usually performed by a marker in accordance with a The process of measuring the temporal properties of a traffic stream selected by clas-

defined traffic profile. The customer network attached to a VPN. A site contains one or more CE routers. An algorithm or a mechanism that is used to control traffic that is injected into Token bucket

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 ASN ATM BE BGP BGP-MP CE CLS CoS CR-LDP DestAddress DstPort DSCP DiffServ EBGP EF FEC FF GS IANA IETF IGP IGMP ILM IntServ IP Assured Forwarding Autonomous System Number Asynchronous Transfer Mode Best-Effort Broad Gateway Protocol BGP Multiprotocol Extensions Customer Edge Router Controlled Labelled Services Class of Service Constraint-Based Routing–Label Distribution Protocol Destination IP Address Destination Port Number Differentiated Services codepoint Differentiated Services Exterior BGP Expedited Forwarding Forward Equivalence Classes Fixed-Filter Style Guaranteed Services Internet Assigned Number Authority Internet Engineering Task Force Internal Gateway Protocol Internet Group Management Protocol Incoming Label Map Integrated Services Internet Protocol

32 IPV4 IPV6 LDP LER LIB LSP LSR MPLS NHLFE OSPF P PE PHB ProtoId PSC PQ QoS RD RIP RSVP RSVP-TE SLA SE TCA TCP TOS UDP VoD VPN VRF WF WFQ Internet Protocol version 4 Internet Protocol version 6 Label Distribution Protocol Label Edge Router Label Information Base Label Switched Path label Switching Router Multiprotocol Label Switching Next Hop Label Forwarding Entry Open Shortest Path First Provider Router Provider Edge Router Per-Hob Behaviour IP Protocol Number PHB Scheduling Class Priority Queueing Quality of Service Route Distinguisher Routing Information Protocol Resource Reservation Protocol Resource Reservation Protocol-Traffic Engineering Service Level Agreement Shared Explicit Style Traffic Conditioning Agreement Transmission Control Protocol Type of Service User Datagram Protocol Video-on Demand Virtual Private Networks VPN Routing Forwarding Wildcard-Filter Style 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 Differentiated 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-recoveryfrmwrk-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.