SEQUIN Premium IP

Nicolas Simar – DANTE - Sequin: Premium IP

SEQUIN Premium IP


Project info• SEQUIN - SErvice QUality across Independently

managed Networks (IST-1999-20841)

• Duration 18 months (Nov 2000...Apr 2002)

• Partners:

• Project Web site: http://www.dante.net/sequin

• Technical Web site: http://www.switch.ch/lan/sequin

DANTE, DFN, GARR, GRNET, PSNC, RENATER, SWITCH, UKERNA


Overview

• SEQUIN has defined and implemented an end-to-end approach to Quality of Service (QoS), operating across multiple management domains and exploiting a combination of IP and ATM technology

• The project has specified the implementation architecture for the Premium IP service, which aims at offering the equivalent of an end-to-end virtual leased line service at the IP layer across multiple domains.

• The architecture is targeted at the GÉANT (The pan-European Gigabit Research Network) and is applicable to each connected National Research and Education Network (NREN) across Europe and local DiffServ domains


Definition of QoS

• Work of WP2 ->D2.1• Top-down approach

– Interview with international user groups on their requirements

• Bottom-up – Network performance parameters that may be

influenced by configuration of equipment


QoS parameters

• From users’ requirements and technical considerations :– One-way delay (OWD)

– IP packet delay variation (IPDV)

– Available bandwidth

– One-way packet loss (OWPL)

• The set is common to IETF and ITU-T

• Naming and definitions are chosen to be comply to RFC 2330 (Framework for IP Performance metrics) and follow the ongoing IPPM IETF working group work.


QoS user requirementsQoS service One-way-delay ipdv packet loss bandwidth

Best effort wide wide medium wideVery good( Premium IP ) medium very small very small

according toSLA

PrioritisedBandwidth (IP+) medium medium medium

according toSLA

Guaranteedbandwidth

medium medium very small single value

One-way-delay IPDV Packet loss bandwidthBest effort Unspecified Unspecified < 5% Unspecified

Premium IPdistance delay

+ 50 ms< 25 ms negligible

according toSLA

IP+distance delay

+100 ms <25-50 ms < 2%

according toSLA

(from user’s questionnaire)


Premium IP Specification

• Differentiated Services Architecture and use the expedited forwarding per hop behavior (EF PHB) • Interface definition between domains that behaves as an EF PHB• Do not starve best effort traffic (limited percentage of link capacity devoted to Premium IP)• Initial provisioning structure: static, no dynamic signaling• IETF IPPM QoS parameters measurement framework• QoS parameters monitoring system is a key element


Premium IP Service

ImplementationBasic principles

minimize number of actions per node do not use a signaling protocol modular approach that allows different

implementation schemes at every hop or domain and allows domains to join the service when ready

Do not try to solve the most general problem, but rather develop a model that can be implemented in short time using available tools

Keep it simple


Simplifying the actions for each node

- monitoring and accounting- QoS rules propagation

- congestion control

- admission control and classification

- scheduling

In principle, each node might perform an awful lot of tasks:

- marking - policing

- shaping


Use the information in the IP header:

- IP source and destination (prefixes) as near to the source as possible

- the DSCP (or IP precedence equivalent value) along the path

- perform an optional, suggested, admission control based on AS source and destination at inter-domain links (safety measure)

- rules might be based on additional parameters, such as time-of-day

Admission control


The consequences are:- allowing the computation of total requested Premium IP capacity at each network node in the default case (and for main backup cases too)

- short access list near users’ premise (few users)

- simple control at backbones (IP addresses are not propagated)

- choosing destination aware service (next slide)

Admission control (continued)


AB

C

D

E

F

Guser 1 user 2

user 5

user 4

user 3

user IN (SLS) OUT (SLS) IN (real) OUT (real)1 10 10 40 02 10 10 0 103 10 10 0 104 10 10 0 105 10 10 0 10

Destination AwareVs destination Unaware

Admission control (continued)


Examining the tasks for each node




- scheduling

In principle, each node might perform an awful lot of tasks:

- marking - policing

- shaping

always


- Mark each “EF” legal packet at first classification point- Use the same DSCP value on all domains (decimal 46 [RFC 2474] to have interoperability with ToS only capable hardware) - strongly suggested -- valid DSCP coupled to invalid IP addresses may imply discard to allow easy debugging- packets with other DSCP values are left untouched

Marking is mandatory at the first classification point, remarking is optional.

Marking






- scheduling - marking - policing

- shaping

always

Selectedlocations


• Microflow policing should be done as close as possible to the source according to agreed (through SLA) Premium IP capacity. This step is mandatory

• Policing will be done using a token bucket. The depth of the token bucket will be two MTU close to the source and increase to 5 or more along the path if additional policing is required

• It is suggested to perform only one additional policing stage at the ingress to GÉANT from an NREN, with a larger aggregated capacity value than the sum of the agreements.

“Avoid unwanted packet loss” is the motto.

Policing


• The additional policing stage at the ingress to GÉANT from an NREN serves the purpose of protecting Premium IP traffic from misconfiguration/DoS coming from a single source.

• It creates virtual “pipes” for the aggregated Premium flows from each NREN to each other (when needed). The failure of one “pipe” does not influence the others.

Policing (continued)


L1 L2

N1

N2

N3

CORE

L1, L2 : end user domain (for example LANs)N1, N2, N3 : intermediate transport domains (for example NRENs backbones)CORE : interconnection domain (for example GÉANT) : router/switch

Sample multidomain network

Classification on IP addressesStrict policing

Policing can be avoidedat ingress when receivingfrom a trusted backbone

Classify by DSCPPolice by (AS source,dest)aggregate capacityon all border nodes

Policing not needed







- shaping

always

Selectedlocations

Selectedlocations

always


Shaping

The sending source is required to shape the traffic it produces.

Shaping can be done by the network close to the user

Shaping inside the sending host itself is the preferred way, shaping by the network will in most case lead to packet losses

TCP

Application

Scheduling

IP

Network Interface

No Packet/Data losses

host


AB

C

D

E

F

Guser 1 user 2

user 5

user 3

Shaping

Multiple aggregation-separationpoints and link speed changes.







- shaping

always

Selectedlocations

Selectedlocations

always

NODone bysource

notneeded

Selectedlocations

Selectedlocations


Shape ONLY here Classify (IP pair prefixes)Police - Strict, CapacityMark

Classify (DSCP) High priority queueingon all nodes

Do not police on egressDo not shape

Policing can be avoidedat ingress when receivingfrom a trusted backbone

Police by (AS source,dest)aggregate capacity on all border nodes

Summary


Grey Areas

Exact configuration of buffering and token bucket depth in routers. As a rule of thumb the token bucket depth can be assumed to be 1.2 * (Diffserv active interfaces on router)

Scalability - the maximum amount of aggregated Premium IP capacity the network can offer- hardware capabilities

Fast provisioning of the service

Widespread availability and tuning of “last mile” (LANs)


Example (one direction)

Domain 1802.1p VLANOr dedicated wire

Domain 5802.1p VLANOr dedicated wire

Domain 2ATM

Domain 3Backbone

Classification (DSCP)Policing (AS aggregate)

Classification (DSCP)Policing (AS aggregate)

Domain 4

Classification (IP)Policing (strict 2 MTU)Marking - scheduling

Classification (IP)Policing (strict 2 MTU)Marking - scheduling

Classification (DSCP)Scheduling

Classification (DSCP)Scheduling

Dedicated PVCDedicated PVC


“Proof of Concept”• Initial implementation of the testing methodology by

implementing a “Proof of Concept” test-bed involving user groups

• Goals:– access to a controlled environment composed of a variety of

hardware and underlying technology– functionality verification of each component required to implement

Premium IP

• The set of tests performed included:– laboratory tests for basic router functionality– wide area tests for network calibration (understand the performance

users can expect & the interaction between different network technologies)

– tests involving users to verify the QoS provisioning processes


H.323 users tests• H.323 users from TF-STREAM Task Force

– TF-STREAM, http://www.terena.info/task-forces/tf-stream/

• Tests– Core network (GÉANT): 10Gbit/s & 2.5 Gbit/s POS and Juniper routers.

– 4 high (2.5 Gbit/s POS) and lower (2x155Mbit/s ATM access) speed national networks connecting six testing locations

– Traffic tests with measurement tools with/without Premium IP enabled– Objective and subjective quality assessments of H.323 videoconferencing


H.323 tests topology


Test scenarios• End-to-end setup, between each pair of the participants

• Videoconference initiated – users assessment of audio and video quality

• ICMP Ping tool was used to measure end-to-end RTT

• The videoconference session was terminated

• Use of RUDE/CRUDE tool with traffic pattern imitating videoconference stream in both directions for recording jitter and packet loss

• NETPERF throughput test was used to assess the bandwidth available for Premium IP service


Test results IIP Premium

Audio SWITCH FOKUS RUS GRNET CINECASWITCH x 3(MCU) 4-5 6 6FOKUS 3.6 x 6 3 6

RUS 3.6 6 x 6 6GRNET 5.4 3(MCU) 5 x 6CINECA 6 6 5 6 x

FROM

IP Premium

Video SWITCH FOKUS RUS GRNET CINECASWITCH x 6(MCU) 5 6 6FOKUS 4.8 x 6 5 6

RUS 4.8 6 x 4 6GRNET 5.4 5(MCU) 5 x 5CINECA 5.4 6 5 5 x

FROM


Test results IIIP Premium

Bandwidth [10^3 bit/s] SWITCH FOKUS RUS GRNET CINECASWITCH x 3307.87 1909.83 870.00 1816.73FOKUS 1910.00 x 8725.30 910.00 1825.09

RUS 1910.00 8895.45 x 830.00 1835.18GRNET 1910.00 853.41* 1909.02 x 1839.94CINECA 1751.46 1944.39 1844.84 910.00 x

FROM

IP Premium

Loss[%] SWITCH FOKUS RUS GRNET CINECASWITCH x 0.00 0.00 0.02 0.00FOKUS 0.00 x 0.00 0.01 0.00

RUS 0.00 0.00 x 0.02 0.00GRNET 0.00 0.00 0.00 x 0.00CINECA 0.00 3.07 2.70 0.25 x

FROM

IP Premium

MIN AVG MAX MIN AVG MAX MIN AVG MAX MIN AVG MAX MIN AVG MAXSWITCH 37.00 37.00 41.00 50.68 51.31 55.43 112.22 114.29 124.14 17.04 19.91 19.97FOKUS 30.0 38.00 60.00 14.66 17.30 414.66 109.67 110.49 167.59 17.80 20.50 40.00

RUS 50.0 50.00 61.00 10.00 13.00 480.00 186.94 229.82 313.69 29.95 39.62 49.96GRNET 110.0 114.00 190.00 117.00 119.00 141.00 186.90 230.20 254.80 119.80 120.04 127.82CINECA 25.1 27.67 48.41 27.00 30.00 82.00 39.93 42.01 81.85 119.82 120.05 127.82

FROMCINECA

RTT[ms]SWITCH FOKUS RUS GRNET


Test results IIIJitter distribution in VBR traffic - BE & Premium IP

0%

10%

20%

30%

40%

50%

60%

70%

0.0

0

0.1

9

0.3

8

0.5

6

0.7

5

0.9

4

1.1

3

1.3

1

1.5

0

1.6

9

1.8

8

2.0

7

2.2

5

2.4

4

2.6

3

2.8

2

3.0

1

3.1

9

3.3

8

3.5

7

3.7

6

Premium IP BE jitter[ms]

pe

rce

nta

ge

of

pa

ck

ets

Avg. jitter vs. packet size - BE & Premium IP

0

2

4

6

8

10

12

14

Premium IP BE

avg

. jit

ter

[ms]

packet size [bytes]


Testing with IST projects

• AQUILA (IST 1999-10077)– Enhanced architecture for QoS in

Internet– PL (Warsaw) - AT (Vienna), 2.5 Mb/s– activated on 15 April 2002

• MOICANE (IST 2000-26137)– QoS support in access technologies– IT, GR, PT, RO– target time April/May 2002


Monitoring

Inter-domainmeasurements


backbonenetwork

Customer B

backbonenetwork

Customer A PoP a PoP bPoP n2PoP n1

Customer-to-customer Measurements


End-to-end intra-domainmeasurements Customer BCustomer A

PoP a PoP bPoP n2PoP n1


connection path

Customer BCustomer A

PoP a PoP bPoP n2PoP n1

Intra-domainmeasurements

Intra-domainmeasurements

PoP n3

end-userA

end-userB

end-to-end connection path

PoP am PoP bm

connection path

(a)

(b)

(c)


Conclusions

• SEQUIN has shown HOW to deploy Premium IP

• NRENs are invited to implement it as a replacement of ATM-based MBS

• The service provisioning model and debugging procedures need to be further elaborated

• Support sought for development of monitoring tools, which is fundamental for the provisioning of the service

SEQUIN Premium IP

Documents

Transcript of SEQUIN Premium IP