MPLS-based QoS Interworking among Autonomous Systems

MPLS-based QoS Interworking among Autonomous Systems

° Alessandro Garibbo, * Mario Marchese, * Maurizio Mongelli

° Marconi Selenia Communications S.p.a., a Finmeccanica Company, Genova, Via di Francia, 3, 16149, Genova (Italy) Email: [email protected]

* CNIT - Italian National Consortium for Telecommunications University of Genoa, Via Opera Pia 13, 16145 Genova, (Italy)

Email: mario.marchese, [email protected]

Abstract- This paper deals with a protocol architecture to interconnect Autonomous Systems (ASes),

together with guaranteeing the QoS provision. The adoption of the MPLS protocol allows defining an effective way to face the heterogeneity due to the interconnection of ASes implementing different QoS technologies. In this perspective, the problem regarding the management of the traffic flows that cross the boundaries of the ASes reveals to be a hot topic of research and will be deeply investigated in the paper.

I. INTRODUCTION

Modern telecommunication networks are characterized by a great heterogeneity of services. Each application deserves a specific Quality of Service (QoS). Together with the need of quality, there is also a great heterogeneity concerning technologies. The ATM technology and the so-called QoS IP technologies (the Integrated and the Differentiated Services techniques) adopt different approaches to support QoS. Another technology, the Multi Protocol Label Switching (MPLS), has been recently developed from the convergence between the IP world and the ATM.

The two mentioned issues (quality versus heterogeneity) open the problem of defining a QoS-based interface among network portions implementing different QoS technologies as well as establishing a correct QoS mapping among different protocols, without penalising the QoS provision.

This problem is enforced by the fact that the Internet traffic flows that interconnect users located in different localities of the world are routed throughout different proprietary networks, called Autonomous Systems (ASes), managed by different Internet Service Providers (ISPs). The Internet is composed by up to 10,000 ASes and their number is rapidly growing ([1]). The same technology heterogeneity holds in current military telecommunication environments, too (see, e.g., [20]).

The study of the possible interactions between them is currently an open area of research (see, e.g., [1, 2]) and the availability of mechanisms able to control the network elements that interconnect different ASes constitutes an attractive network management issue for both the ISPs and the Authorities of the Internet Market. The connection point among different ASes is defined as Relay Point.

In this perspective, the paper proposes a QoS-based interworking at the Relay Points, so that quality requirements can be transmitted among different ASes. The idea is to use the features of MPLS to provide an interface independent of the technology used within each AS and oriented to QoS.

Moreover, since QoS needs to be provided along the end-to-end path, potentially established along several ASes, it is important to investigate which are the bandwidth requirements at the Relay Points when the support technology changes (e.g., between ATM to IP and viceversa) so to keep the same performance level. Such issue is deeply investigated in this paper, too.

II. THE INTERWORKING PROBLEM

A possible composition of Internet ASes connecting single LANs (Local Area Networks) and WANs (Wide Area Networks) is shown in Fig. 1. Technology chosen to guarantee services in AS 1 may be ATM, while AS 2 may be IP-based. AS 3 may implement an ISDN based plain telephony backbone and AS 4 may have chosen MPLS.

2

A utonom ous System 2


W A N W A N

L A N

L A NL A N

W A N

L A N

L A N



R elay P oin t

Fig. 1. Interworking scenario among ASes.

The problems, essentially, are:

1) establish a proper interface; 2) transfer the QoS needs for each end-to-end connection across the heterogeneous network; 3) once transferred the QoS requests among the ASes, it is topical to map the performance requests over the peculiar

technology implemented within each AS. Fig. 2 contains an example of the protocol architecture dedicated to the Relay Points. In the case reported, an ATM-

based AS and an IP-based AS are interconnected.

RELAY LAYER (Encapsulation, QoS Mapping,Tunneling …)

Physical (SDH Frame)

Physical

High Speed Link High Speed Link

Physical (SDH Frame))

Physical

High Speed Link

ATM ATM Layer to be defined Ethernet

ATM node RELAY LAYER (Encapsulation, QoS Mapping,Tunneling …)

Physical

Physical

Layer to be defined IP (IntServ, DiffServ)Ethernet

IP (IntServ, DiffServ)

IP router

Relay Point

Fig. 2. Relay Point: the protocol stack.

The Relay Point has the role of encapsulating information, establishing a common format and language to exchange

information about QoS requirements, establishing tunneling and implementing the other required functionalities (detailed in the following).

Often two different ASes do not work with the same “quantities” and a “mapping service” is required to guarantee the QoS. In general, the QoS mapping is strictly related to encapsulation. Actually, “Relay Layer” packets (Protocol Data Units, PDUs, if the ISO OSI terminology is used) needs to be encapsulated, on one hand, within the protocol acting over the Relay Point, and, on the other hand, over the protocol that operates over the AS. If an AS is implemented in IP and “Relay Layer” information has to be encapsulated in it, topical work is developed by the Pseudo Wire Emulation Edge-to-Edge (PWE3) working group of IETF that is working on protocols for transporting layer 2 services (which, in PWE3 view, includes also ATM) over IP-based network, supposing, as done also in this work, that IP backbone can support the transfer of other technologies. In this context, the mentioned environment includes also Frame Relay, circuit emulation, Synchronous Optical Network (SONET), and Ethernet over IP based backbones. On the other hand, if an AS is implemented in ATM (or DVB), “Relay Layer” packets may be transported over ATM (DVB) using proper adaptation layers; e.g., Relay Layer packets may be encapsulated in AAL 5 frames ([3, 27, 28]). Both the ATM Forum, the ETSI standardization body and the Internet Engineering Task Force (IETF) are currently facing interworking issues, too (see [4, 27, 28] and references therein). If ASes are implemented over TDM (e.g., ISDN) technologies, mapping is quite simple because only peak rate can be allocated for each connection.

The lower interface layers in Fig. 2 have been intentionally left without identification. Some possible alternative solutions, acting also on the physical layer, may be: SDH/ATM and Ethernet/IP. The solution proposed in this work is MPLS, which, used in all its functionalities, may provide also the functions of the Relay layer. The reasons for such a choice are explained in the following.

https://www.researchgate.net/publication/220548268_Translation_of_specification_units_between_IP_and_ATM_quality_of_service_declarations?el=1_x_8&enrichId=rgreq-46d0ff18-3ebe-4f2d-a84c-d105876cc88a&enrichSource=Y292ZXJQYWdlOzI3MTE5MDM3ODtBUzoxODc5ODkyMjUzODU5ODRAMTQyMTgzMTUzMjI5Mw==

https://www.researchgate.net/publication/3198864_ATM_in_MPLS-based_converged_core_data_networks?el=1_x_8&enrichId=rgreq-46d0ff18-3ebe-4f2d-a84c-d105876cc88a&enrichSource=Y292ZXJQYWdlOzI3MTE5MDM3ODtBUzoxODc5ODkyMjUzODU5ODRAMTQyMTgzMTUzMjI5Mw==

3

Host Protocol

Traditionally, communication networks are divided into circuit-switched (e.g., plain telephony, ISDN, xDSL) and packet-switched networks (e.g., ATM, DVB and IP). Circuit-switched technology was originally dedicated to voice and packet-switched technology to data. The future evolution is oriented to have one single network [13], but for now the two approaches still coexist, in particular at the host level. To match this issue, two types of hosts will be considered in this work: IP and ISDN (Fig. 3).

IP A u d io a n d V id e o

R T P R T C P

IP

U D P T C P

H .2 2 5 .0 R A S , H .2 2 5 .0 se s s io n c o n tro l a n d H .2 4 5

O th e r IP A p p lic a t io n s

E th e rn e t

A u d io /v id e o /d a ta

c o d e cIS D N

Q .9 3 1

Q .9 2 1

P h y s ic a l la y e r

IP A u d io a n d V id e o

R T P R T C P

IP

U D P T C P

H .2 2 5 .0 R A S , H .2 2 5 .0 se s s io n c o n tro l a n d H .2 4 5

O th e r IP A p p lic a t io n s

E th e rn e t

A u d io /v id e o /d a ta

c o d e cIS D N

Q .9 3 1

Q .9 2 1

P h y s ic a l la y e r

Fig. 3. Host protocol stack definition.

Service Level Specification

QoS is the ability of a network element (e.g., host or router) to have some level of assurance for traffic flows. QoS provision is offered using a Service Level Specification (SLS), which is “a set of parameters and their values which together define the service offered to a traffic” [22]. An example of SLS is represented by the ATM Traffic Contract [23], that is composed of traffic descriptors, along with a set of QoS parameters.

III. STATE OF THE ART

Interworking among ASes is an issue faced by the telecommunication community for both concern standards and research papers. The current trend is trying to employ an IP centric solution in order to face this issue. Architectures

The European Union has founded projects in the area of QoS IP. In particular, three of them have the aim of generating proposals to provide IP premium services (IP QoS within the DiffServ environment): AQUILA, TEQUILA and CADENUS (see, e.g., [10] and references therein). In particular, resource control for QoS over IP is managed by AQUILA, which assumes the presence of Admission Control Agents (ACAs) managing the QoS requests and operating within the Edge Routers of a DiffServ domain. ACAs communicate with Resource Control Agents (acting intra domain) to get information about available resources. Similarly, [11] uses QoS Network Server (QNS) to manage QoS information and to check resource status over an IP WAN and introduces the use of MPLS signalling and RSVP-TE to transport QoS requirements, again within the IP DiffServ world.

The expressed ideas are also applied to military communications: reference [12] focuses on providing end-to-end QoS over DiffServ networks by using Bandwidth Brokers (BB) communicating each other for interdomain information and managing intradomain resources. A specific signalling is forecast for end-to-end communication. Also in this case BBs act in strict connection with ingress/egress routers of the different IP domains. Routing and signaling: the Border Gateway Protocol

The IETF protocol aimed at the interworking among IP-based ASes is the Border Gateway Protocol (BGP). BGP [5] provides a mechanism independent of the routing protocol used within each AS and is used to exchange routing information among multiple ASes. Based on the information exchanged, BGP constructs a graph of ASes connectivity.

BGP offers no standardized way of transporting information about resources, as it only distributes information about ASes that may be reached without any QoS guarantee. Hence, two Internet drafts [6] and [7] have been proposed describing QoS extensions to BGP by defining a new Network Layer Reachability Information (NLRI) attribute. The main idea is to exchange QoS-related information as well as reachability information in a BGP UPDATE message. Both drafts specify a new BGP4 attribute, which conveys QoS-related information associated to the routes described in the corresponding NLRI field of the attribute.

BGRP and BGRPP [8], [9] are Internet drafts describing a signalling, resource reservation and control architecture for interdomain QoS control. It is independent but cooperates with the resource control mechanisms within each AS and, used with BGP, it offers a complete solution for resource reservation and control across interdomain boundaries

https://www.researchgate.net/publication/3198875_Advanced_QoS_Provisioning_in_IP_Networks_the_European_Premium_IP_Projects?el=1_x_8&enrichId=rgreq-46d0ff18-3ebe-4f2d-a84c-d105876cc88a&enrichSource=Y292ZXJQYWdlOzI3MTE5MDM3ODtBUzoxODc5ODkyMjUzODU5ODRAMTQyMTgzMTUzMjI5Mw==

https://www.researchgate.net/publication/3196620_A_practical_architecture_for_implementing_end-to-end_QoS_in_an_IPnetwork?el=1_x_8&enrichId=rgreq-46d0ff18-3ebe-4f2d-a84c-d105876cc88a&enrichSource=Y292ZXJQYWdlOzI3MTE5MDM3ODtBUzoxODc5ODkyMjUzODU5ODRAMTQyMTgzMTUzMjI5Mw==

https://www.researchgate.net/publication/3937800_A_new_architecture_of_providing_end-to-end_quality-of-service_for_Differentiated_Services_network?el=1_x_8&enrichId=rgreq-46d0ff18-3ebe-4f2d-a84c-d105876cc88a&enrichSource=Y292ZXJQYWdlOzI3MTE5MDM3ODtBUzoxODc5ODkyMjUzODU5ODRAMTQyMTgzMTUzMjI5Mw==

https://www.researchgate.net/publication/3888369_Quality_of_service_and_new_architectures_for_future_telecommunications_networks?el=1_x_8&enrichId=rgreq-46d0ff18-3ebe-4f2d-a84c-d105876cc88a&enrichSource=Y292ZXJQYWdlOzI3MTE5MDM3ODtBUzoxODc5ODkyMjUzODU5ODRAMTQyMTgzMTUzMjI5Mw==

4

based on aggregation of reservations on the basis of destination AS. BGRP stresses the need to ensure that the signalling, resource reservation and routing should be aligned.

It is worth noting that the BGP with QoS extensions drafts both lack further research and implementation experience showing the impact of adding QoS related NLRI attributes. Moreover, even though the BGRP and BGRPP approaches require no changes to the BGP protocol, they assume the implementation of a novel signalling protocol. The need of a novel architecture

The scope of all the aforementioned works is IP. However, it is a widespread perspective that “[…] capital expenditure constraints in both service providers and enterprises will mean that MPLS will evolve in the carrier core network first, with ATM remaining for some time to come as the primary technology for multiservice delivery in bandwidth-limited edge and access networks” [4]. “Today the ATM network are located in the heart of the network and IP in the periphery, but in the future only one network will be used. The best of IP and ATM will provide to develop Computer Telephony Integration applications, which take into account the convergence of data and telephony networks” [13]. Such consideration lead to the need of providing a global network integrating the best of packet and circuit switched networks (which was exactly the aim and motivation of standardizing ATM) but considering the IP importance and diffusion. It implies that IP should be the recognized technology to identify a host (without forgetting ISDN) but it does not imply the use of IP currently implemented everywhere, also concerning QoS managing. For this reason, the main objectives of this work are: 1) design a QoS-based interworking among ASes providing each traffic flow with the required QoS; 2) avoid the problem of lack of scalability; 3) allow the definition of a large number of traffic classes, taking into account Multi Level Priority Preemption

(MLPP) capabilities; 4) providing interworking of network portions implementing different technologies, independently of the technology

deployed within each AS. The reason for requirements 1) and 2) comes from the need to avoid the drawbacks of QoS IP technology for both

concern the IntServ and the DiffServ paradigms. The former does not scale in a large network and the latter is not able to guarantee QoS requirements because “Two conditions are necessary for QoS: guaranteed bandwidth, class-related scheduling and packet discarding treatment; the DiffServ architecture satisfies the second condition, but not the first” [14].

The importance of having MLPP capabilities included in civil networks is based on the fact that “[...] in talking with customers on both sides of the Atlantic, IP and voice communications will remain separated until MLPP capabilities are incorporated into an IP-manageable infrastructure in a Standards accepted way where multiple companies can provide products for bid” ([15]). Hence, retaining many important details of the IP-centric mentioned solutions (as, for example, the functionalities of bandwidth brokers within each specific AS), the solution proposed in this work tries solving the mentioned problems without penalizing the QoS provision.

The concept of “Autonomous System” is usually related to the Internet routing issue: “in technical terms, an AS number is a 16-bit integer assigned by Internet organization and used by BGP to implement policy routing and avoid top-level routing loops” [21]. In this work, we look at the interworking scenario of Fig. 1 in a more general fashion, having in mind not only the separation of different routing domains, but also emphasizing the ASes’ diversity in terms of the technology employed to meet the users’ QoS requirements.

IV. ARCHITECTURE AT THE RELAY POINTS Protocol Architecture for Data Traffic Communication

The solution proposed for interconnection at the Relay Points is MPLS-oriented. The protocol architecture for data traffic is reported in Fig. 4, where the concepts expressed in Fig. 2 are detailed. MPLS acts both as Relay Layer and as Layer 2. The Relay Point architecture works as a MPLS LER (Label Edge Router). LER functionalities include assignation/dropping and forwarding to next Relay Layer LER.

The overall network of Fig. 1 is seen as a full MPLS network (actually the network from first Relay Point to the last Relay Point through the end-to-end path is full MPLS). The interconnecting ASes are seen by the Relay Point as “abstract nodes” (Fig. 5) that are defined as a group of nodes whose internal topology is opaque to the ingress node of the MPLS Label Switch Path (LSP) ([16]). An abstract node is said to be simple if it contains only one physical node. In the case presented, the “opacity” is complete, not only concerning QoS routing (as outlined in [16]), but also regarding ASes’ technologies that can be different from MPLS.

Fig. 6 shows the overall information that flows through the Relay Points. The traffic flows of the ASes come from the host protocol stack plus the MPLS shim header (the MPLS label) added at the Relay Points and tunnelled along the ASes (not necessarily MPLS capable). Pure host packet is passed to the MPLS layer that adds the label and forwards it

https://www.researchgate.net/publication/3198864_ATM_in_MPLS-based_converged_core_data_networks?el=1_x_8&enrichId=rgreq-46d0ff18-3ebe-4f2d-a84c-d105876cc88a&enrichSource=Y292ZXJQYWdlOzI3MTE5MDM3ODtBUzoxODc5ODkyMjUzODU5ODRAMTQyMTgzMTUzMjI5Mw==

https://www.researchgate.net/publication/3888369_Quality_of_service_and_new_architectures_for_future_telecommunications_networks?el=1_x_8&enrichId=rgreq-46d0ff18-3ebe-4f2d-a84c-d105876cc88a&enrichSource=Y292ZXJQYWdlOzI3MTE5MDM3ODtBUzoxODc5ODkyMjUzODU5ODRAMTQyMTgzMTUzMjI5Mw==

5

to the next Relay Point. MPLS packets are transported over both the Relay Points and the ASes. A traffic flow composed by IP packets plus the MPLS label can be tunnelled along both an ATM-based and an ISDN-based AS backbone. Concerning the encapsulation of MPLS in IP: “it is possible to replace the top label of the MPLS stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers” [17].

EthEthAS 1AS 1 PhPh EthEth AS 2AS 2 PhPh

Autonomous Autonomous System 1System 1

Relay PointRelay Point

Technology Technology dependentdependent

InterworkingInterworking

TechnologyTechnology independentindependentinterworkinginterworking

AS 1AS 1 ProtocolProtocol

MPLS MPLS ((LayerLayer 3 and 3 and LayerLayer 2)2)



















Fig. 4. Relay Points: the MPLS solution.













AbstractAbstract NodeNode AbstractAbstract NodeNode














AbstractAbstract NodeNode AbstractAbstract NodeNode


Fig. 5. Abstract Nodes at Relay Point.

P h yP h yA S 1A S 1 P hP h P h yP h y

R e l a y P o i n tR e l a y P o i n t

T e c h n o l o g y T e c h n o l o g y d e p e n d e n td e p e n d e n t

I n t e r w o r k i n gI n t e r w o r k i n g

T e c h n o l o g yT e c h n o l o g y i n d e p e n d e n ti n d e p e n d e n ti n t e r w o r k i n gi n t e r w o r k i n g

A S 1A S 1 P r o t o c o lP r o t o c o l

M P L S M P L S M P L S M P L S



A S 2A S 2 P hP h


I P A u d io a n dV id e o

R T P R T C P

I P

U D P T C P

H .2 2 5 . 0 R A S , H . 2 2 5 . 0 s e s s io nc o n t r o l a n d H . 2 4 5

O t h e rI P A p p l ic a tio n s

A u d io / v id e o / d a t a

c o d e cI S D N

Q .9 3 1

Q .9 2 1

M P L SM P L S

P h yP h yA S 1A S 1 P hP h P h yP h y

R e l a y P o i n tR e l a y P o i n t



T e c h n o l o g yT e c h n o l o g y i n d e p e n d e n ti n d e p e n d e n ti n t e r w o r k i n gi n t e r w o r k i n g


M P L S M P L S M P L S M P L S



A S 2A S 2 P hP h



R T P R T C P

I P

U D P T C P

H .2 2 5 . 0 R A S , H . 2 2 5 . 0 s e s s io nc o n t r o l a n d H . 2 4 5

O t h e rI P A p p l ic a tio n s

A u d io / v id e o / d a t a

c o d e cI S D N

Q .9 3 1

Q .9 2 1

M P L SM P L S

Fig. 6. Relay Point Interworking.

The most important novelty of this architecture is related to the inference of the offered QoS as function of the MPLS

label. In general, the information of the QoS assigned to an IP packet is contained in the DiffServ Code Point (DSCP) field and the MPLS shim header is used for QoS routing purposes. Here, we propose to use MPLS at the Relay Points to classify packets for the QoS provisioning of each traffic class, thus inferring the guaranteed bandwidth, the class-related scheduling and the packet discarding treatment within the AS through the MPLS label.

Sketches of the data flow through the Relay Points are reported in the following to better investigate the architecture proposal from the operative viewpoint. The examples reported cover most of the QoS technologies mentioned in the previous sections.

The IP host carries (in the example reported in Figs. 7) a voice and video application and implements the necessary IP stack. The first QoS-PRN met along the end-to-end path acts as a LER by identifying the flow and applying the MPLS label. The same operation will be implemented at the last QoS-PRN before the destination. Intermediate QoS-PRNs act as conventional MPLS Label Switch Routers (LSRs). At the Relay Point, the IP host packet is encapsulated within the MPLS information and transported over the ATM backbone. This operation is described in detail in Fig. 7 where the black arrow identifies the direction of information. At the exit of the ATM backbone that, for the QoS-PRNs, is only an

6

opaque portion of the MPLS end-to-end path, ATM information is dropped and the IP host packet is passed through the AS Protocols / MPLS interface (identified and evidenced in Fig. 6). In this peculiar ATM case, the mentioned interface is AAL / MPLS. The encapsulation of IP packets over DVB is also similar to the IP over ATM case.

Similarly to the previous case, if an AS is implemented in IP and it does not include the IP host as destination, it is seen as an opaque portion and its implementation is transparent to the host. An IP tunnel (properly dimensioned to guarantee required QoS) is used to transport information. Fig. 8 reports in detail this situation. Also in this case, the voice and video application is just an example.

P h y


R T P

I P

U D P

E t h e r n e t

P h y s i c a l l a y e r

E t h e r n e t

P h y s i c a l l a y e r P h y P h y

A A L 1 / A A L 5


A T M

I P A u d io a n d V id e oU D P R T PI P

I P A u d io a n d V id e oU D P R T PI PM P L S H e a d e r


I P A u d io a n d V id e oU D P R T PI PA A L H e a d e r A A L t r a i l e r

A T M C e l l A T M C e l l A T M C e l l A T M C e l l

M P L SM P L S M P L SM P L S

M P L S H e a d e r

L E R / L S R L E R / L S R f u n c t i o n a l i t i e sf u n c t i o n a l i t i e s L S R L S R f u n c t io n a l i t i e sf u n c t io n a l i t i e s

P h y


R T P

I P

U D P

E t h e r n e t


E t h e r n e t

P h y s i c a l l a y e r P h y P h y

A A L 1 / A A L 5


A T M

I P A u d io a n d V id e oU D P R T PI P



I P A u d io a n d V id e oU D P R T PI PA A L H e a d e r A A L t r a i l e r

A T M C e l l A T M C e l l A T M C e l l A T M C e l l

M P L SM P L S M P L SM P L S

M P L S H e a d e r

L E R / L S R L E R / L S R f u n c t i o n a l i t i e sf u n c t i o n a l i t i e s L S R L S R f u n c t io n a l i t i e sf u n c t io n a l i t i e s

Fig. 7. Data traffic flow: IP host over ATM AS backbone.

E th

P hy

IP A ud io and V ideoU D P R TPIP

IP A ud io and V ideoU D P R TPIPM P LS H eade r

IP A ud io a nd V id eoU D P R TPIPM PLS H eade r

IP A ud io andV ideo

R TP

IP

UD P

E the rne t

Phys ica l la ye r

E the rne t

Phys ica l la ye r Phy Phy

IP

P hys ica l la ye r

E the rne t

M PLSM PLS M PLSM PLS

LER /LSR LER /LSR fun ctio na lit ie sfun ctio na lit ie s LSR LSR fun ctio na lit ie sfun ctio na lit ie s

IP A ud io and V ideoU D P R TPIPM P LS H eade rIP

IP A ud io and V ideoU D P R TPIPM PLS H eade rIPE th

P hy

IP A ud io and V ideoU D P R TPIP

IP A ud io and V ideoU D P R TPIPM P LS H eade r

IP A ud io a nd V id eoU D P R TPIPM PLS H eade r

IP A ud io andV ideo

R TP

IP

UD P

E the rne t

Phys ica l la ye r

E the rne t

Phys ica l la ye r Phy Phy

IP

P hys ica l la ye r

E the rne t

M PLSM PLS M PLSM PLS

LER /LSR LER /LSR fun ctio na lit ie sfun ctio na lit ie s LSR LSR fun ctio na lit ie sfun ctio na lit ie s

IP A ud io and V ideoU D P R TPIPM P LS H eade rIP

IP A ud io and V ideoU D P R TPIPM PLS H eade rIP Fig. 8. Data traffic flow: IP host over IP AS backbone.

The data traffic flow in case of an ISDN host is quite similar to the ones depicted in Figs. 7 and 8. The only difference

stems from the ISDN codec embedded within IP or ATM packets. Concerning the QoS provision, Relay Points act as conventional MPLS LERs. They implement traffic classification

(at the ASes’ boundaries) and deploy a set of MPLS Forwarding Equivalent Classes (FECs) to satisfy the SLSs defined in common among the ASes. Details about the mapping of such FECs to the QoS technology deployed within each AS are reported in the following. The idea is to establish QoS bandwidth pipes among the ASes by means of the MPLS-based traffic classification (and corresponding resource assignment along the end-to-end path) acting at the Relay Points. Even though MPLS is usually employed to enforce the QoS provision in a DiffServ environment [14], it reveals, in this work, the role of convergence QoS technology since it admits a large number of traffic classes (thus taking into account MLPP capabilities, too) by defining of a proper set of FECs. Protocol Architecture for Signalling

The proposed signalling architecture is based on RSVP-TE [16]. Each Relay Point can be identified (concerning signalling information) by an IP address. RSVP-TE is used to set the MPLS labels over the path and to signal QoS requirements. It is assumed that an IP address plane is available in each Relay Point for signalling, thus allowing any Relay Point to manage a proper routing scheme (e.g., by means of MPLS traffic engineering functionalities [18]) among the ASes.

7

End-to-end QoS The overall structure is got from the studies in [11] and [12], briefly described in the state-of-the-art section where

also the differences contained in this work are underlined. The overall structure is contained in Fig. 9. RSVP-TE transports QoS requirements up to the Relay Point by using the protocol architecture presented above and off-band channels. The QoS is then guaranteed along the end-to-end path, since resource allocation for each incoming connection is inferred, at the Relay Points, from the MPLS shim header. Each Relay Point maps the QoS requirements over a bandwidth request for the ASes, so getting a “bandwidth pipe” of proper dimension to guarantee the QoS up to the next Relay Point.

SourceSourceWANWAN

DestinationDestinationWANWAN

BBBB

BBBB

BBBB

TransitTransitWANWAN

Off bandOff band tunnelstunnels RSVPRSVP--TETE

EthEthAS 1AS 1PhPh EthEth AS 2AS 2PhPh

AS 1AS 1ProtocolsProtocols

MPLSMPLS


RSVPRSVP--TETE RSVPRSVP--TETE

MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS

SourceSourceWANWAN

DestinationDestinationWANWAN

BBBBBBBB

BBBBBBBB

BBBBBBBB

TransitTransitWANWAN

Off bandOff band tunnelstunnels RSVPRSVP--TETE



MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS



MPLSMPLS

Fig. 9. End-to-end management architecture.

Within this operation, the bandwidth pipe could be not available. The check is performed locally, within each single

AS querying a database constantly updated about the AS resource status (actually, a Bandwidth Broker (BB), as in [12], or a Quality Network Server, as in [11]). If no resource is available the connection is rejected. QoS requirements need to be careful mapped from Relay Points to the ASes and this is the object of next sections and of the following performance evaluation.

In the approach presented, BBs do not communicate each other and are AS locally implemented. Also the communication protocol between Relay Points and proprietary BBs may be implemented by using a private protocol as well as the format of each single BB. The advantage is that ASes need to have in common only the definition of the QoS requirements and its comprehension. QoS routing

An important problem concerns QoS routing because the tunnels connecting the ASes are crossed along opaque network portions. In this case, it is difficult to assure an end-to-end delay (which strongly depends on the number of nodes of the chosen routing path) if no a priori knowledge is available about the entire network topology. Such a drawback can be solved by configuring a priori, in each transit AS that could carry traffic destined to other ASes (as in Fig. 9), proper static tunnels ([19, 26]) aimed at carrying (with low delay and no losses) the traffic flow dedicated to one (or more) destination hosts placed in a different AS. In practice, each AS “sees” at its boundaries a “virtual” backbone, able to guarantee QoS bandwidth pipes with the other ASes.

The difference between the architecture proposed here and the other typical MPLS-based ones comes from the fact that the latter assume that the overall network infrastructure is build with MPLS routers, while, in our case, only the Relay Points interconnecting the ASes strictly need to deploy a MPLS interface. This should allow gradually migrating toward a global MPLS network infrastructure according to the evolution of the Internet market (see, e.g., [4]). Scalability

Traffic flows at the Relay Points must be managed through Call Admission Control as mentioned above. Recent results of the MPLS & Frame Relay Alliance follow this approach, details can be found in [24, 25]. In brief, some portion of the capacity on the tunnels in the transit WANs are statically configured according to the traffic variability forecast. The bandwidth provisioning is optimized on demand as function of the current level of congestion of each traffic class [26]. In this way, flows are aggregated with respect to the chosen traffic class and no “per connection” state is maintained within each tunnel [24, 25]. Thus, no scalability problem arises as the number of connections increases together with the network size. Note that the bandwidth provisioning for a heterogeneous tunnel composed by connections related to different traffic classes is still an unexplored area of research. For this reason, this is the subject of the following performance evaluation.

8

V. THE TRAFFIC AGGREGATION PROBLEM

The major concern, as regards the interworking scenario addressed in this paper, is the QoS maintenance among the ASes. The Service Provider of each AS should use the most convenient methodology after making proper modelling tests and simulations (as the ones proposed in the following) aimed at properly configuring the QoS-bandwidth pipes that cross its AS. However, a proper QoS mapping has to be found out among the ASes. An open problem, coming from the need of interconnecting portions of networks that use different QoS-based technologies, is the effect on performance of traffic aggregation. If traffic requiring different performance is joined in one flow, it is necessary to investigate the additional bandwidth required to keep the same performance level. An example may be represented by DiffServ environments that use a limited number of classes in IPv4 with respect to the ATM or MPLS technologies, in which a very large number of traffic classes could be available. In practice, due to the limited number of traffic classes, non-homogeneous traffic flows (i.e., flows with different SLSes, requiring diverse QoS) need to be aggregated and conveyed together. The following simulation results regard the effect on performance of traffic aggregation for traffic requiring different SLSes, in terms of packet loss, packet delay and delay jitter and highlight indication about flow bandwidth dimension at the Relay Points to guarantee the performance.

VI. SIMULATION RESULTS

The users’ application levels generate on-off sources whose traffic descriptors are: Peak bandwidth (Mbps or Kbps), Mean Burst Duration (s), Mean Silence Duration (s). The burst and silence durations are both Pareto distributed. An ad-hoc simulator in C++ has been used to compute the following results. The width of the confidence interval over the performance measures is less than 1% for the 95% of the cases.

If traffic needs to be aggregated, the choice of the bandwidth to be assigned to guarantee the fixed SLS is topical. The relevant metric, in this case, is the measure of the addition (or reduction) of bandwidth necessary to keep the same level of service when SLSes are aggregated with reference to a complete separation. The parameter used in this work is the gain, defined as the percentage difference between the overall bandwidth necessary to satisfy the requirements if the SLSes are kept separated and the bandwidth needed by the SLSes’ aggregation. For example, if a SLS1 needs 1.0 Mbps to satisfy the requirements and SLS2 2.0 Mbps, when kept separated, if the aggregation of the two SLSes requires 4.0

Mbps, the defined gain is: (1 2) 4100 33.33%(1 2)+ −

⋅ = −+

. It means that, in this example, aggregation is not convenient and

that 33% of more bandwidth is necessary to guarantee the fixed requirements. Investigations are reported in the following.

For each flow is specified: the number of connections within it, the performance requirement and the buffer dimension available for it at the Relay Point. Many studies confirm the efficiency of aggregating homogeneous traffic but the performance of non-homogeneous (from the QoS requirement viewpoint) trunks is still an open issue.

Buffer at the QoS-PRN has been dimensioned to 5.3 Kbytes (i.e., 100 ATM cells) for all the tests. The first part of the tests have been performed with the SLSes appearing in Table I and supposing that the two SLSes need to be aggregate because there are not enough classes to be assigned. They differ only for the Packet Loss Rate parameter.

The result heavily depends on the composition of the aggregate trunk.


Range

Premium VBR Variable Bit Rate (VBR)

Traffic description and conformance testing

Packet dimension: 424 bit; Peak Rate: 1.0 Mbps; Average Rate: 500 Kbps;

Performance guarantees Packet Loss Rate: 10-4-10-2; Packet Transfer Delay: not specified; Packet Delay Jitter: not specified

Table I. Two SLSes based on Packet Loss Rate: 10-4-10-2.

Figs. 10 and 11 contain the aforementioned bandwidth gain by varying: 1) the number of connections within the aggregate trunk; 2) the percentage of connections belonging to the two SLSes requiring, respectively, a Packet Loss Rate of 10-2

and 10-4. For instance, the percentage 33% and 66% stand for 1/3 and 2/3, respectively, so to get 100% of traffic and so on;

9

3) the performance value of the Packet Loss Rate for the aggregate trunk (set to 10-4, so to be sure that all the trunk is guaranteed, 10-2, the minimum request and an average value of 10-3). Packets of the two SLSes are no longer distinguished within the trunk.

The constraint imposed for the aggregate trunk is highlighted in the little square of each figure. Non-homogeneous aggregation is often convenient but, if traffic is unbalanced towards the less restrictive traffic, it is

needed either to relax the performance constraint or wasting a bandwidth portion. Results reported below (Figs. 10 and 11) give an operative solution to operate bandwidth dimensioning.

The trend is even clearer if the QoS differentiation stands in the Packet Delay Transfer constraint (Table II).


Range

Premium VBR Variable Bit Rate (VBR)

Traffic description and conformance testing

Packet dimension: 424 bit; Peak Rate: 16.0 Kbps; Average Rate: 8.0 Kbps;

Performance guarantees Packet Loss Rate: 10-2; Packet Transfer Delay: 50ms-10ms; Packet Delay Jitter: not specified

Table II. Packet Loss Rate: 10-2 and Packet Transfer Delay: 50ms and 10ms.

In this case, if the more restrictive constraint is chosen for the overall trunk, a bandwidth addition is needed to assure performance (Figs 12 and 13).

c

Aggregate flow composition: 66% requiring Ploss 1e-2; 33% 1e-4

-5.00%

0.00%

5.00%

10.00%

15.00%

100 200 300 400 500 600

Overall number of connections in the aggregate flow

1.00E-02

1.00E-03

1.00E-04

Aggregate flow; Ploss: 80% 1e-2; 20% 1e-4

-10.00%

-5.00%

0.00%

5.00%

10.00%

100 150 200 250 300


1.00E-021.00E-031.00E-04

Fig. 10, 11. Bandwidth percentage gain in traffic aggregation: the Packet Loss Rate case.

10

Aggregate flows Delay: 50% 50 ms; 50% 10 ms

-20.00%

-10.00%

0.00%

10.00%

20.00%

30.00%

40.00%

0 20 40 60 80 100 120


50 ms20 ms10 ms

Aggregate flow; Delay: 80% 50 ms; 20% 10 ms

-30.00%

-20.00%

-10.00%

0.00%

10.00%

20.00%

30.00%

0 50 100 150 200 250


50 ms

20 ms

10 ms

Fig. 12, 13. Bandwidth percentage gain in traffic aggregation: the Packet Delay Transfer case.

The last case presented concerning traffic aggregation tests refers to the jitter constraint (Table III).

Service Level Specification Range Premium VBR Variable Bit Rate (VBR)

Traffic description and conformance testing Packet dimension: 424 bit;

Peak Rate: 16.0 Kbps; Average Rate: 8.0 Kbps;

Performance guarantees Packet Loss Rate: 10-2; Packet Transfer Delay: 50ms; Packet Delay Jitter: 9ms – 5 ms

Table III. Packet Loss Rate: 10-2 , Packet Transfer Delay 50 ms, jitter 9 ms and 5 ms.

Being the two jitter values close, no intermediate solution is reported. The behaviour is similar to the transfer delay case but it is worth noting that the quality differentiation (5 and 9 ms) is really minimum. It means that jitter is a very sensible parameter for bandwidth reservation and a very critical issue for aggregation (Figs. 14 and 15).

11

Aggregate flows Jitter: 66% 9 ms; 33% 5 ms

-20.00%-15.00%-10.00%

-5.00%0.00%5.00%

10.00%15.00%20.00%

0 20 40 60 80 100 120 140


Gai

n in

per

cent

age

with

ag

greg

atio

n

9 ms5 ms

Aggregate flows Jitter: 80% 9 ms; 20% 5 ms

-25.00%-20.00%-15.00%-10.00%

-5.00%0.00%5.00%

10.00%15.00%20.00%

0 50 100 150 200 250


Gai

n in

per

cent

age

with

ag

greg

atio

n

9 ms5 ms

Fig. 14, 15. Bandwidth percentage gain in traffic aggregation: the jitter case.

VII. CONCLUSIONS

The paper has presented a MPLS-based protocol stack to connect network portions implementing different QoS technologies. Two topical problems have been solved at the Relay Points: QoS-based interworking and mapping.

QoS mapping regards the effect of traffic aggregation on the overall performance when the traffic flows are managed by Autonomous Systems that employ different QoS technologies (for example IP DiffServ vs. ATM or MPLS). The results reported investigate in detail this topic and allow providing operative solutions really applicable in the field.

REFERENCES [1] L. Gao, “On inferring autonomous system relationship in the internet,” IEEE/ACM Trans. Net., vol. 9,

no. 6, pp. 733-745, Dec. 2001. [2] L. Subramanian, S. Agarwal, J. Rexford, R. H. Katz, “Characterizing the Internet Hierarchy from

Multiple Vantage Points,” in Proc. of IEEE Infocom, June 2002. [3] J. Schmitt, Translation of specification units between IP and ATM quality of service declarations,

Internat. J. Comm. Sys., Vol. 16, Issue 4, pp. 291-310, 2003. [4] M. Bocci, J. Guillet, “ATM in MPLS-based Converged Core Data Networks”, IEEE Comm. Mag.,

Jan. 2003. [5] Y. Rekhter, T. Li, A Border Gateway Protocol 4 (BGP-4), IETF RFC 1771, March 1995. [6] O. Bonaventure, Using BGP to distribute flexible QoS information, IETF Internet draft: <draft-

bonaventure-bgp-qos-00.txt>, Exp: Aug. 2001. [7] G. Christallo, C. Jacquenet, Providing Quality of Service Indication by the BGP-4 Protocol: the

QoS_NLRI attribute, IETF Internet draft: <draft-jaquenet-qos-nlri-04.txt>, Exp: Sept. 2002. [8] P. Pan, E. Hahne, H. Schulzrinne, BGRP: A Framework for Scalable Resource Reservation, IETF

Internet draft: <draft-pan-bgrp-framework-00.txt>, Exp: July, 2000. [9] S. Salsano (ed.), Inter-domain QoS Signaling: the BGRP Plus Architecture, IETF Internet draft:

<draft-salsano-bgrpp-arch-00.txt>, Exp: Nov. 2002. [10] S. Giordano, S. Salsano, S. Van den Berghe, G. Ventre, D. Giannakopoulos, “Advanced QoS

Provisioning in IP Networks: The European Premium IP Projects”, IEEE Comm. Mag., no. 1, Jan. 2003.

[11] V. Fineberg, “A practical architecture for implementing end-to-end QoS in an IP network,” IEEE Comm. Mag., Jan. 2002.

12

[12] Y. Jia, M. Chen, "A new architecture of providing end-to-end quality-of-service for differentiated services network", in Proc. of MILCOM 2001 - IEEE Military Communications Conference, no. 1, Oct. 2001 pp. 1451-1456

[13] P. Lorenz, "Quality of service and new architectures for future telecommunications networks", in Proc. of MILCOM 2000, IEEE Military Communications Conference, no. 1, Oct. 2000, pp. 695- 698.

[14] V. Fineberg, “QoS Support in MPLS networks,” White Paper, MPLS/Frame Relay Alliance, May 2003.

[15] J. M. Polk, “Multi-Level Precedence and Preemption over IP,” IETF Internet Draft, Feb. 2001. [16] D. Awduche, L. Berger, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP

Tunnels" IETF RFC2309, Dec. 2001. [17] T. Worster, Y. Rekhter, E. C. Rosen, “Encapsulating MPLS in IP or Generic Routing Encapsulation

(GRE)”, IETF Internet Draft (draft-ietf-mpls-in-ip-or-gre-03.txt), Sept. 2003. [18] R. Zhang, J. Vasseu, MPLS Inter-AS Traffic Engineering requirements, IETF Internet Draft, draft-ietf-

tewg-interas-mpls-te-req-03.txt, Dec. 2003. [19] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP Operation Over IP Tunnels", IEFT RFC

2746, Jan. 2000. [20] Tacoms Post 2000, a NATO Steering Committee Project, 1999-2004, http://www.tacomspost2000.org. [21] Autonomous System definition: http://www.freesoft.org/CIE/Topics/4.htm. [22] R. Gellens, The SYS and AUTH POP Response Codes, IETF RFC 3206, Feb. 2002. [23] ATM Forum, Traffic Management Specification, Version 4.0, AF-TM-0056.000, Apr. 1996. [24] T. Phelan, MPLS PVC User to Network Interface Annex B: MPLS Proxy Admission Control Protocol

Implementation Agreement, MPLS & Frame Relay Alliance Technical Committee, Oct. 2004. [25] A. Bhargava, T. Phelan, MPLS Proxy Admission Control Definition Implementation Agreement,

MPLS & Frame Relay Alliance Technical Committee Oct. 2004. [26] Z. Duan, Z. Zhang, Y. T. Hou, “Service overlay networks: SLAs, QoS, and bandwidth provisioning,”

IEEE/ACM Transactions on Networking, vol. 11, no. 6, Dec 2003, pp. 870-883. [27] ETSI. Satellite Earth Stations and Systems (SES). Broadband Satellite Multimedia. Service and

Architectures; functional architecture for IP interworking with BSM networks. ETSI Technical Specification, TS 102 292 V1.1.1, Feb. 2004.

[28] ETSI. Satellite Earth Stations and Systems (SES). Broadband Satellite Multimedia. Services and Architectures; BSM Traffic Classes. ETSI Technical Specification, TS 102 295 V1.1.1, Feb. 2004.

Documents

MPLS-based QoS Interworking among Autonomous Systems