Network Services Definition and Deployment in a Differentiated Services Architecture

Transcription

1 etwork Servces Defnton and Deployment n a Dfferentated Servces Archtecture E. kolouzou, S. Manats, P. Sampatakos,. Tsetsekas, I. S. Veners atonal Techncal Unversty of Athens, Department of Electrcal and Computer Engneerng, 9 eroon Polytechnou str, 57 73, Athens, Greece Telephone: , FAX: Abstract- ext generaton Internet archtectures wll consder the Dfferentated Servces paradgm for the provson of qualty of servce to ndvdual customers needs and applcatons. Ths paper addresses the defnton and deployment of specfc network servces n a DffServ envronment. The proposed network servces and the underlyng traffc engneerng methods are analyzed and smulated. Smulaton outcomes prove that the fundamental prncples of the network servces are fulflled. I. ITRODUCTIO The Internet s constantly evolvng from a network carryng manly data traffc nto a network that should handle a varety of traffc profles, rangng from real tme audo and vdeo to web traffc. owever, the best effort nature of the current Internet s not suffcent to cope wth the requrements of ths traffc, n terms of throughput, delay, jtter and packet loss. The Integrated Servces (IntServ) archtecture [] was the frst sgnfcant step for the ntroducton of QoS n the Internet. IntServ uses the Resource Reservaton Protocol (RSVP) [2] for the explct setup of reservaton state on each network node along the path from the sender to the recever. owever, the constant exchange of RSVP messages, as well as the need for separate reservaton establshment for each flow rased scalablty concerns. The Dfferentated Servces (DffServ) archtecture [3] emerged as a more scalable and manageable approach by provdng relatve prortzaton of IP traffc. In DffServ, IP flows wth smlar QoS requrements are grouped together under a common IP header feld, the DffServ Code Pont (DSCP), and treated n the same queue nsde the routers. DffServ was also enhanced by the ntroducton of the Bandwdth Broker concept [4], a central entty that manages the resources of a doman and allocates them to requestng users. The Dfferentated Servce archtecture provdes servce dfferentaton based on the DSCP feld n the IP header and the Per- op Behavor (PB), whch defnes the externally observable behavor at each node. Two PBs have been defned: the Expedted Forwardng (EF) [5] and the Assured Forwardng (AF) [6] PB. The EF PB provdes premum servce that can be vewed as a vrtual leased lne (VLL) servce and s sutable for real tme flows that requre low delay, low jtter and guaranteed throughput. On the contrary, AF does not provde strct bandwdth guarantees, but assures that packets wll be forwarded wth hgher prorty n relaton to best effort traffc. In the event of congeston, AF packets wll encounter less bandwdth decrease than best effort traffc. There are four AF classed defned wth three levels of drop precedence wthn each class, although t s not mandatory that all four classes have to be used n a doman. In ths paper we brefly present the Resource Control Layer (RCL), a dstrbuted archtecture for the effcent and manageable provson of QoS n DffServ-based networks. owever, we manly focus on the defnton of the etwork Servces that are offered to the users and ther deployment on the network. In order to accommodate traffc wth dfferent QoS requrements, a lmted set of etwork Servces has been defned. The proposed etwork Servces follow the concepts of the IETF EF and AF PBs, but they addtonally propose and explot a specfc mplementaton, whch allevates ther deployment n real networks. The paper s structured as follows. In Secton II, the most mportant concepts of our archtecture are descrbed: the Resource Control Layer and the etwork Servces. Then, n Secton III, the concept of Traffc Classes s ntroduced and descrbed n detal. Traffc Classes provde the traffc handlng mechansms for each etwork Servce. Secton IV presents the smulatons performed and the obtaned results that nvestgate the performance of the proposed etwork Servces n a realstc network topology. II. BASIC ARCITECTURAL MECAISMS A. The RCL Layer The am of ths secton s to gve a short ntroducton of the archtecture, n the context of whch the etwork Servces are defned. The archtecture conssts of two functonal areas: the data plane that s responsble for transmttng IP packets, and an overlay control plane, namely the Resource Control Layer (RCL) that s based on the Bandwdth Broker (BB) concept. Although the classcal BB archtecture proposes a concentrated approach where one BB s responsble for an admnstratve doman, RCL s desgned as a dstrbuted BB, to overcome scalablty problems. As depcted n Fg., the three key components of the RCL are: the Resource Control Agent (RCA), the Admsson Control Agent () and the End-User Applcaton Toolkt (EAT). EAT Access etwork Resource Control Layer (L) Edge Router DffServ Layer (L) ool ool 2 ISP root ool ool 2 RCA (L) (L) Edge Router Fg.: RCL Structure and man nteractons EAT Access etwork The Resource Control Agent s manly responsble for the management of network resources (bandwdth). In order to smplfy the task of the RCA to handle the resources effcently, two concepts are ntroduced: the Resource Pools () and the Resource Shares

2 (RS). The Resource Pool concept s based on the fact that n most networks the topology follows a tree lke structure and therefore an aggregaton of traffc on each subsequent level. Accordng to the composte pattern [7], the s form a tree herarchy as t s shown n Fg. 2. Each, whch s a logcal entty, s assocated wth a real sub-area of the network and manages the resources of the sub-area. The root of the tree s n charge of the avalable resources n the whole network, whle each leaf of the tree structure (Resource Pool Leaf, L) s assocated to one Admsson Control Agent, whch s n turn assocated to one edge router (ER) of the network. In the provsonng phase, by takng nto account the traffc forecasts, the complete network topology and the resource sharng polces between the network servces, the ntal values for the resource dstrbuton are calculated. After the phase of provsonng each /L s ntalzed wth a specfc amount of resources that wll allow makng admsson control decson locally. Wthn each /L, the total resources assgned to t are dstrbuted among the avalable network servces, n the form of Resource Shares. owever, n many cases the ntal dstrbuton of resources dffers sgnfcantly from the actual traffc load, thus an ntellgent loadbalancng redstrbuton algorthm has been defned to redstrbute the avalable resources approprately [8]. L L2 L L Fg. 2: erarchy of the s In order to better understand the redstrbuton process and how t s related to the resource pool concept, consder the case where a L has already reserved all the resources that have been assgned to t ntally, whle L2 has reserved only a small amount. The father by dentfyng that stuaton wll dynamcally shft resources from L2 to L. In other words, even f the provsonng phase produces less accurate values for the resource dstrbuton, the proposed mechansm wll dentfy the actual needs (based on the resource reservaton requests) and adapt accordngly. The Admsson Control Agent s manly responsble for user authentcaton and authorzaton, reservaton handlng, and flow Admsson Control (AC). User authentcaton s ntally performed through an explct logn procedure, whle authorzaton refers to the permsson of a user to place a request for the selected network servce. Durng reservaton handlng, flow admsson control s performed. The admsson control decsons are made only at the edges of the network, therefore the correspondng ngress and egress ponts (ngress-egress s) of the flow are dentfed and the Resource Share, whch corresponds to the user selected network servce, n the L s checked to ensure that the flow can be accommodated. The core network s provsoned through the mechansm explaned above, n order to ensure that once the admsson control at the edges succeeds, no bottleneck wll be created n the core network. Upon a successful reservaton request, the correspondng s consequently confgure the edge routers approprately to accommodate the flow. Reservaton requests are forwarded to the s from the End- User Applcaton Toolkt, whch medates between end-users or applcatons and the network. The EAT nteracts wth the to be aware of the avalable network servces. A reservaton request specfes the flow dentfers, the selected network servce and the traffc profle for t. Specal support s foreseen for legacy applcatons as well as for end users that are not aware of traffc descrpton detals, through the use of Applcaton Profles. Profles are prepared through extensve testng of the applcaton behavor and stored n a repostory. The EAT nterprets the profles and prepares the reservaton on behalf of the user. B. etwork Servces In order to provde QoS guarantees n a DffServ network t s essental to assure QoS dfferentaton. Therefore, a set of fve etwork Servces (S) has been specfed and mplemented n our framework, whch comprses the servces sold by the provder to the potental customers, ether end-users or other provders. They descrbe the QoS treatment a user s traffc experence wthn a network. The specfed Ss are: Premum Constant Bt Rate (PCBR), Premum Varable Bt Rate (PVBR), Premum Multmeda (PMM), Premum Msson Crtcal (PMC) and Standard Best Effort (STD). Applcatons can be grouped nto ths relatvely small number of servces, wth the applcatons n each servce havng smlar requrements on the network n order to perform effectvely and flows n each servce havng smlar characterstcs. The PCBR network servce s ntended to support applcatons that requre VLL-lke servces. Therefore, t s approprate for voce flows, voce trunks or nteractve multmeda applcatons. That knd of flows usually s characterzed by low peak-to-mean rato (almost constant bt rate, CBR) and low bandwdth requrements, whle a great number of them are unresponsve (UDP). In addton, they should have small packets, so as not to provoke long transmsson delays. It requres and expects to receve low delay, very low jtter and very low packet loss. The targeted quanttatve value for end-toend delay s less than 50msec for 99.99% of the packets, whle packet loss s expected to be less than 0-6. The PVBR network servce manly copes wth unresponsve varable bt rate (VBR) sources wth medum to hgh bandwdth requrements. The ntenton s to separate those possbly hgh bandwdth VBR flows from the low bandwdth VBR and CBR flows n PCBR. Ths s caused by the fact that peak rate allocaton s neffcent for the hgh bandwdth VBR flows, contrary to the flows belongng to PCBR. Typcal canddate applcatons are real tme vdeo and teleconferencng. The requrements are smlar to the PCBR network servces but wth a less strct need concernng the jtter and packet loss. They are characterzed by large packet sze and hgh peak-to-mean rato. The targeted end-to-end delay s lmted to less than 250msec for 99.99% of the packets, whle packet loss should be less than 0-4. The PMM s expected to carry a mxture of TCP and non-tcp traffc. These flows requre a mnmum bandwdth, whch must be delvered at a hgh probablty. Independently of the transport protocol, flows are expected to mplement some knd of congeston control mechansm and ther aggressveness should be smlar to the one of TCP, assumng that they are roughly TCP-frendly [9]. Ths S s supposed to serve adaptve applcatons (TCP), lke lowqualty vdeo, streamng multmeda applcatons or fle transfer (FTP). By nature, these flows are usually responsve, greedy and reflected to long-lved connectons. They requre throughput guarantees, whch are translated nto low packet loss for n-profle packets (P loss 0-3 ), whle there are no QoS guarantees for out-ofprofle packets.

3 PMC s targetng to non-greedy adaptve applcatons that have great senstvty concernng packet loss. It s thus sutable for transacton-orented applcatons and nteractve applcatons such as onlne games and chat-lke applcatons. The man characterstcs are the non-greedness of the flow, the responsve nature (TCP), the low use of bandwdth and the short lfe of the connecton. As mentoned above, the most crtcal QoS parameter s the packet loss, so the most mportant requrement s very low packet loss for n-profle packets (P loss 0-6 ), whle no QoS guarantees are expected for outof-profle packets. evertheless, low queung delay s also desred, n order to retan the meanng of nteractveness. Fnally, packets belongng to the STD class receve no specal treatment n the network. III. TRAFFIC ADLIG The prevous secton ntroduced brefly the archtecture and the proposed network servces. Ths secton covers some detaled network servce aspects. A. TCLS Implementaton The mplementaton of the etwork Servces s realzed wth the use of some network s mechansms, whch are the Traffc Classes (TCLs). A TCL s defned as a composton of a set of admsson control rules, a set of traffc condtonng rules and a per-hop behavor (PB). In the proposed archtecture fve TCLs are ntroduced: TCL, TCL2, TCL3, TCL4 and TCL5 whch correspond to PCBR, PVBR, PMM, PMC and BE. Each TCL mantans a separate queue at the router output ports and allocates one or more DSCPs n order to enable dfferentaton of packets n the core network. A PB mplemented n the output port of a router s realzed n the network wth the use of schedulng and buffer management algorthms. The schedulng mechansm selected s a combnaton of the Prorty Queung () [0] and Weghted-Far Queung () [0], whch s called and s depcted n Fg. 3. A weght s assgned to each TCL, though a queue s dedcated for TCL-, whch has strct prorty over the other TCLs. The rest TCLs are scheduled wth the and each queue s managed by dfferent queung strategy (Drop-Tal, Random Early Detecton (RED), Weghted-RED (WRED) [, 2]). overcomes the lmtatons ntroduced by the, whch provdes absolute preferental treatment to hgh prorty traffc, whle the lowest prorty traffc (BE) s possble to experence starvaton. On the other hand, would not be able to guarantee the strct delay requrement for TCL and TCL2. Packet arrves Classfer TCL TCL 2 TCL 3 TCL 4 TCL 5 gh prorty Low prorty Packet departs Fg.3: Desgn of router output port The confguraton of the weghts determnes the sharng of each lnk resources among the dfferent traffc classes. In ths way the network operator expresses ts requrements on the network resources utlzaton and the maxmum amount of traffc for each TCL, whch s allowed to transt onto a lnk. The routers are confgured wth those weghts durng the start-up procedure. Those weghts are somehow statc, snce are not updated dynamcally. Accordng to the weghts, the AC rate lmts for all TCLs at the Ls are also set, whch wll be used by the AC algorthm. Moreover, specfc polcng actons are deployed to ensure that non-conformng data flows do not affect the QoS requrements for already actve data flows. Polcng at the network access pont s performed through a token bucket devce (r,b) [3]. A specfc traffc profle s determned for each S, whch best characterzes the data source. The traffc profle for TCL s descrbed n terms of a Sngle Token Bucket, whch polces the peak rate of the flows. Admsson control functons are also based on the peak rate of allocatons for TCL, snce those flows are usually of low bandwdth. The sngle token bucket (TB) operates as both meter and dropper. Snce TCL s characterzed wth strct QoS requrements, packet exceedng the declared profle should be dropped. The sngle token bucket s confgured wth token rate r equal to the Peak Rate (PR) of the flow, and bucket sze b equal to a multple x of the maxmum allowed packet sze (<256 Bytes), whch s called Bucket sze for PR, (BSP). The value of x les n the range of {,5}; a possble value could be x=, whle a larger value would allow a small amount of burstness. The traffc condtonng mechansm s realzed n the routers wth the use of the Commtted Access Rate (CAR) mechansm. Packets of TCL are enqueued n a sngle drop-tal queue. Peak rate allocaton s not approprate for TCL2, snce t s characterzed wth hgh bandwdth flows. Therefore, admsson control functon s based on both the peak and sustanable rate of the flows and a dual TB as meter and dropper s proposed. The frst token bucket s confgured wth r equal to the Sustaned Rate (SR) of the flow, and b equal to the Bucket Sze for SR n bytes (BSS). The second token bucket s confgured wth r equal to the PR of the flow and b equal to a multple x of the maxmum allowed packet sze (<500 Bytes), (BSP). The value of x s n the range of {,5}. The depth of the frst bucket defnes the burstness allowed for the sender s flow (BSS). A packet s marked as n-profle f there are enough tokens n the frst and second TB to accommodate t, otherwse t s dropped. The ntenton s to lmt the sender s traffc n order to be conformant to the profle of the frst TB (SR, BSS), whle the second TB (PR) allows an amount of burstness. Packets of TCL2 are also enqueued n a sngle drop-tal queue. A sngle TB as a meter and marker s proposed as the traffc condtonng mechansm for TCL3, whch polces the sustaned rate and s confgured wth r equal to the SR of the flow and b equal to BSS. Flows conformng to ths profle wll be marked as n-profle otherwse as out-of-profle. The bucket sze (BSS) should be very hgh to satsfy the bursty nature of TCP traffc and the maxmum allowed packet sze of flows could be set to 500bytes. Packets of TCL3 are enqueued n a sngle queue, whch s managed by WRED wth two sets of parameters (mnth, maxth, maxp). One set s for n-profle and the other for out-of-profle packets, as descrbed n [2]. Out-of profle packets are not dropped, but marked wth a dfferent DSCP. The traffc profle for TCL4 s specfed wth the use of a Dual Token Bucket, whch polces both the sustanable and peak rate of flows. The frst token bucket s confgured wth (SR of the flow, BSS), whle the second token bucket wth (PR of the flow, BSP). The parameter x for TCL4 has a fxed value n the range of {,5} and the maxmum allowed packet sze can be set to 500bytes. A packet

4 that requres fewer tokens than avalable n the frst and second TB s marked as n-profle, otherwse s marked as out-of-profle and forwarded nto the network. SR should be small n order to dsable greedy sources to transmt n-packets wth a hgh rate nto the network, whle BSS should be large enough to allow several backto-back packets to enter the network wthout beng marked as outof-profle. TCL4 occupes two DSCPs, one for n-profle and one for out-of-profle packets. WRED wth two sets of parameters s used n order to dscrmnate out-of-profle packets aganst n-profle packets. Fnally the TCL5 requres no qualty of servce guarantees and best effort packets are enqueued n a sngle queue. B. Admsson Control Functons Admsson Control (AC) plays a sgnfcant role n ensurng the requested qualty of servce to user traffc. It s manly responsble for lmtng the access to the network, so that the already admtted flows do not antcpate any deteroraton n ther qualty contract. Therefore, a bottleneck s prohbted to arse n the edge-lnk (.e. the lnk between a core network and the ngress or egress router) as well as n any of the nternal-lnks. The AC rate lmts may be changed dynamcally as a result of resource pool operatons. Settng the AC lmts s based on the target network utlzaton as well as the target performance of each etwork Servce. Although t s not the am of ths paper to analyze the AC procedures, the dfferentaton of AC functons among the proposed network servces s brefly dscussed. Admsson control s performed per flow and s based on the selected network servce and the traffc profle from the user n the reservaton request. Accordng to the network servce ndcated n the request, the (ngress or/and egress) module uses a specfc formula n each case, as shown below: PR Eff SR Eff + PR ρc for TCL TCL + Eff C for TCL2 TCL 2 + SR C for TCL3 TCL3 + Eff C for TCL4 TCL 4 TCL s descrbed n terms of a sngle TB, whch polces the peak rate. The AC functon therefore checks whether the PR of the flow (PR ) plus the sum of the PR of all admtted TCL flows do not overcome a threshold calculated by multplyng the capacty for TCL (C TCL ) by a parameter ρ, whch corresponds to the target utlzaton for TCL. The capacty of a TCL s the Resource Share for ths TCL n the L logcally assocated wth the. TCL2 s based on a dual TB, so the peak and sustanable rates, along wth the BSS are used for the calculaton of the effectve bandwdth for the flow and the already admtted TCL2 flows. The sum of these must be less than the capacty of TCL2 n the L (C TCL2 ), n order the flow to be accepted. The formula for the calculaton of the effectve bandwdth takes nto account the target packet loss rate and can be found n [4]. TCL3 s descrbed n terms of a sngle TB, whch polces the sustanable rate. The formula used n ths case s smlar to TCL, but the SR s used n the calculatons. Moreover, the parameter ρ s not used here. The fact that the AC algorthm s based on SR maxmzes the network utlzaton. Ths s adequate for TCL3 as t provdes only rough guarantees to the TCP-controlled flows that are supposed to be submtted n ths traffc class. A dual token bucket characterzes TCL4, so lke TCL2, the effectve bandwdth s calculated accordng to PR, SR and BSS, targetng at ths tme to a zero packet loss. The formula used for the calculaton of TCL4 s dfferent than that for TCL2 and can be found n [4]. IV. SIMULATIOS Ths secton presents some smulaton results llustratng the qualty of servce offered by TCL and TCL2. The test topology s conssted of 5 routers connected n a chan for achevng a relatvely large number of hops. The lnks are of hgh capacty (44Mbps), except from the access lnk, between the edge router, where the sources are connected, and the frst core router, whch compromses the bottleneck wth a low capacty of 2Mbps. The Opnet 7.0 smulaton tool s used for the smulatons. The topology s used for studyng the performance of the dfferent etwork Servces, under dfferent traffc loads and under dfferent schedulng algorthms;,, and. The performance s based on measurements such as the one-way average delay and the packet loss. A. Results for TCL TCL2 Each lnk capacty s dstrbuted among the traffc classes, whch s determned by the assgned weghts. For TCL a relatvely small share of each lnk s recommended, whch s restrcted to 3% of the bottleneck lnk, determnng that the maxmum allowed traffc for TCL s 260Kbps. TCL2 reserves the 20% of the lnk capacty, whle the rest (67%) s reserved by TCL5. In the smulatons, voce flows wth bandwdth of 64Kbps are used for TCL. Each packet sze s 28bytes, ncludng the relatve protocol headers. Furthermore, the buffers for TCL n the routers were set to 0 packets to guarantee low packet delay requrements. Vdeo flows for TCL2 use an exponental nterarrval dstrbuton wth mean tme 0.039sec, and constant packet sze of 52bytes determnng an average bandwdth of 05Kbps. Fnally best effort flows for TCL5 are modeled wth an exponental nterarrval model, wth mean tme of 0.07sec and constant packet szes of 500bytes, where the average bandwdth of each flow s 7Kbps. The traffc load of TCL5 vares from a number of 4 admtted flows to a number of admtted flows (684Kbps-88Kbps), therefore utlzng ts assgned bandwdth from 50% - 40%. When 8 BE flows are transmtted, then TCL5 s consdered to occupy all of ts reserved bandwdth, whle when more than 8 flows are transmtted, then the bottleneck lnk s consdered congested. When flows of BE are transmtted, then TCL5 s consdered to occupy 40% of ts assgned bandwdth, therefore transmttng 540 Kbps addtonally. We assume a 74% utlzaton of the reserved bandwdth for TCL, n order to guarantee ts strct delay and packet loss requrements. For TCL2, 80% of the reserved bandwdth s utlzed, provdng TCL2 wth ts QoS requrements. The CAR s confgured for both TCL and TCL2, as depcted n TABLE I, n order to polce the admtted traffc, and drop packets n case they exceed the predefned profle.

5 TABLE I CAR Profle Confguraton CAR profles TCL (Sngle Token Bucket) PR = 92Kbps, BSP = 28bytes PR=340Kbps, BSP=024bytes, TCL2 (Dual Token Bucket) SR=35Kbps, BSS=520bytes The characterstcs of the one-way average delay as a functon of the packet sze for TCL s gven n Fg.4. In ths case TCL2 s consdered to occupy 80% of ts reserved bandwdth, whle four flows of the best effort traffc are transmtted. The maxmum observed delay was 05msec, whch s acceptable for voce traffc. One-way average delay (msec) One-way average delay (msec) 05 04, , , Packet Sze (bytes) Fg. 4: One-way average delay of TCL vs. packet sze BE traffc load (number of flows) Fg.5: One-way average delay of TCL vs. dfferent TCL5 (BE) traffc load and dfferent schedulng algorthms One-way average delay (msec) BE traffc load (number of flows) Fg. 6: One-way average delay of TCL2 vs. dfferent TCL5 (BE) traffc load and dfferent schedulng algorthms The delay for TCL and TCL2 under dfferent traffc load of TCL5 and under dfferent schedulng algorthms s depcted n Fg. 5 and Fg. 6 respectvely. In these fgures, the delay usng the schedulng algorthm gets a hgh value (24.4 msec for TCL and 23.9 msec for TCL2) when havng BE flows, and therefore due to lack of space s omtted. guarantees for both voce and vdeo traffc an accepted delay, whch s qute lower than the maxmum delay determned for each S. Voce experences a maxmum delay of 08msec under a heavy load of TCL5, whle t can tolerate up to 50msec. Vdeo experences a maxmum delay of 09msec, whch s an acceptable value comparng to the maxmum value of 250msec. We have to stress here that also acheves a lower than the maxmum value of end-to-end delay for TCL2 (23.9 msec), but ths s accomplshed wth an unacceptable packet loss rate, as more than 20% of TCL2 packets are dropped under (Fg. 8). TCL and TCL2 experence under better performance than under. Ths can be justfed from the fact that n a queue s dedcated for TCL, whch has strct prorty over the rest TCLs, whle TCL2 acheves better utlzaton of ts assgned bandwdth. provdes the best delay guarantee to TCL, whle degrades the performance of TCL2 and may drve TCL5 to starvaton. The packet loss for TCL and TCL2 s depcted n Fg.7 and Fg.8 respectvely. The smulatons assume the maxmum allowed traffc for TCL and TCL2, and flows of BE traffc (congested network). Under, all TCLs experence packet loss only when flows of BE traffc are transmtted, whle under and only the best effort traffc experences packets drops. provdes the worst performance as depcted n Fg.7 and Fg.8. % packet loss % packet loss tme (sec) Fg. 7: Packet loss for TCL under flows of BE tme (sec) Fg. 8: Packet loss for TCL2 under flows of BE

6 As far as the BE traffc s concerned, t experences packet dscards under all schedulng algorthms, whle t receves the best performance under. Ths s caused by the fact that under all traffc flows experence the same behavor and no prortzaton to any TCL s gven. Therefore, the excess load of TCL5 traffc storms the bottleneck lnk, nducng greater packet dscards to both TCL and TCL2. B. Impact of TCL on TCL2 The mpact of TCL traffc on TCL2 s llustrated on Fg. 9, showng the end-to-end delay for both TCL and TCL2 usng the schedulng algorthm and havng 8 BE flows. End-to-end delay (msec) TCL load (kbps) TCL TCL2 Fg. 9: End-to-end delay for TCL&2 vs. dfferent TCL load It s observed that ncreasng the load of TCL above the admsson lmt (92Kbps) ncreases the end-to-end delay for TCL2, whch reaches a value of 3,88msec. Lkewse, the end-to-end delay of TCL s also ncreased, but n a small grade. Ths s due to the fact that for TCL a prorty queue s dedcated provdng to t strct prorty over the other TCLs. evertheless, the end-to-end delay of TCL2 does not ncrease dramatcally, snce t utlzes ts unused assgned bandwdth. V. COCLUSIOS The work presented n ths paper dealt wth the defnton and deployment of a set of etwork Servces wthn a DffServ-enabled core network archtecture. The etwork Servces, whch are mplemented n the network wth the traffc handlng mechansms offered by respectve Traffc Classes, target at dfferent knds of user traffc that exhbt smlar QoS requrements and characterstcs, and they therefore demand analogous treatment wthn the network. We propose fve etwork Servces that can accommodate most of the well-known applcaton traffc usually submtted n a network. We descrbed a specfc mplementaton for all etwork Servces n the context of the Resource Control Layer archtecture. Subsequently, smulaton results proved that the proposed traffc handlng mechansms are adequate for two of the etwork Servces, the PCBR and PVBR. Future work s ntended for the other two etwork Servces (PMM and PMC), n order to show that the man requrements for these servces are also fulflled. REFERECES [] R. Braden, D. Clark and S. Shenker, Integrated Servces n the Internet Archtecture: an Overvew, RFC 633 [2] R. Braden, L. Zhang, S. Berson, S. erzog and S. Jamn, Resource ReSerVaton Protocol (RSVP), RFC 2205 [3] S. Blake, D. Black, M. Carlson, E. Daves, Z. Wang and W. Wess, An Archtecture for Dfferentated Servces, RFC 2475 [4] K. chols, V. Jacobson and L. Zhang, A Two-bt Dfferentated Servces Archtecture for the Internet, RFC 2638 [5] V. Jacobson, K. chols and K.Podur, An Expedted Forwardng PB, RFC 2598 [6] J. enanen, F. Baker, W. Wess and J. Wroclawsk, Assured Forwardng PB Group, RFC 2597 [7] E. Gamma, R. elm, R. Johnson, J. Vlssds, Desgn Patterns Elements of Reusable Object-Orented Software, pp , Addson-Wesley, 995. [8] E. kolouzou, G. Polts, P. Sampatakos, I. Veners, An adaptve algorthm for resource management n a dfferentated servces network, ICC200, elsnk, Fnland, June 200. [9] M. Allman, V. Paxson, and W. Stevens, TCP Congeston Control, RFC 258 [0]M. Markak, E. kolouzou, I. Veners, "Performance Evaluaton of Schedulng Algorthms for the Internet", 8 th IFIP Conference on Performance Modelng and Evaluaton of ATM & IP etworks, Ilkley, June 2000 []V. Frou, M. Borden, A study of actve queue management congeston control, Infocom 2000, Tel- Avv, Israel, March [2]T. Zegler, C. Brandauer, S. Fdda, "A quanttatve model for parameter settng of RED wth TCP traffc", 9th Internatonal Workshop on Qualty of Servce, Karlsruhe, Germany, June 6-8, 200 [3]Y. Bernet, S. Blake, D. Grossman,A. Smth, An nformal management model for Dffserv routers, draftetf-dffserv-model-06.txt, February 200, exp. August 200 [4]Delverable D30, Specfcaton of traffc handlng for the frst tral, AQUILA project consortum, September 2000.