Traffic Engineering for Quality of Service in the Internet

1
Traffic Engineering for Quality of Service in
the Internet
David Griffin University College London
2
Presentation outline

• Intra-domain QoS solutions in TEQUILA
• Holistic approach to IP QoS delivery
• From service subscription to dynamic resource
  allocation
• Resource Provisioning Cycle linking SLSs and TE
• Inter-domain QoS solutions in MESCAL
• Extending QoS capabilities across multiple
  domains

3
The IST TEQUILA project (Traffic Engineering for
Quality of Service in the Internet at
Large) January 2000 to October 2002
4
Tequila Consortium

• Industrial Partners
• Alcatel, Belgium
• Algosystems S.A., Greece
• France Telecom-RD, France
• Global Crossing, UK
• Universities
• NTUA - National Technical University Athens,
  Greece
• UCL - University College London, UK
• UniS - The University of Surrey, UK
• Research Institutes
• IMEC, Belgium
• TERENA, Netherlands

5
Introduction

• The Internet evolves towards the global
  multi-service network of the future
• Need for scalable solutions for end-to-end QoS
  guarantees
• DiffServ tackles scalability by per-class
  processing
• But only per-hop guarantees for aggregate packet
  streams...
• no hard per-flow guarantees
• traffic engineering is needed to configure the
  network to meet QoS objectives
• missing standards
• Traffic Contracts - Service Level Specifications
• co-ordination required between SLSs and TE
• TEQUILA main objective to address these
  limitations by
• developing a model of co-operating components,
  algorithms and protocols offering a holistic
  solution for fulfilling contracted SLSs, while
  continuously optimising use of network resources

6
From SLAs to Packets
- Non-technical terms conditions - technical
parameters SLS-set
Service Level Agreement (SLA)
IP Transport Service (VPN, VLL)
- IP service traffic characteristics - offered
network QoS guarantees
Service Level Specification (SLS)
- Network QoS capabilities - DiffServ
edge-to-edge aggregates
QoS class
Per Domain Behaviour (PDB)
- Generic Router QoS capabilities - DiffServ
core edge routers
Per Hop Behaviour (PHB)
Traffic Conditioning Block
- vendor product specific implementation
Scheduler (e.g. WFQ)
Algorithmic Dropper (e.g. RED)
7
TEQUILA SLSs
8
Service Level Specification - topological
scope - QoS characteristics - schedule - etc.
9
- How to configure the network to accommodate all
demands and... - Meet SLS requirements - Meet
operational objectives of provider
10
- How to configure the network to accommodate all
demands and... - Meet SLS requirements - Meet
operational objectives of provider - With a
given physical infrastructure
11
to allow SLSs to be realised
Configure PHBs
Configure PHBs
Configure PHBs
Configure Traffic Conditioning
Configure LSPs
Map addresses to LSPs
12
(No Transcript)
13
SLS
14
(No Transcript)
15
(No Transcript)
16
Resource Provisioning Cycle (RPC) - background
operational cycle to pre-configure network - map
traffic predictions to network configuration -
based on aggregate repository of subscribed SLSs
and predictions for next cycle - order of
days/weeks/months
Traffic Forecast
Resource Availability Matrix
Network Configuration
17
Dynamic Traffic Engineering - tune network
configuration according to monitored operational
conditions - between RPC cycles - according to
constraints set by network dimensioning - order
of minutes/hours
18
SLS Subscription Epoch - SLS negotiation with
customer - accepts/rejects SLS based on Resource
Availability Matrix - configures mapping to
(pre-existing) LSPs - does not require new RPC
19
SLS Invocation Epoch - dynamic admission
control based on network state - configures
traffic conditioning
20
(No Transcript)
21
Traffic Forecast
SLS Subscription
SLS Invocation
22
Traffic Forecast
SLS Subscription
SLS Invocation
23
Traffic Forecast
SLS Subscription
SLS Invocation
24
Traffic Forecast
SLS Subscription
SLS Invocation
25
Traffic Forecast
SLS Subscription
SLS Invocation
Customer
26
The IST MESCAL project (Management of End-to-end
Quality of Service across the Internet At
Large) November 2002 to April 2005
27
From TEQUILA to MESCAL

• TEQUILA addressed intra-domain QoS
• SLSs for customer-ISP interactions
• service and resource (TE) aspects for
  edge-to-edge QoS across a single domain
• MESCAL addresses inter-domain QoS
• customer-ISP and ISP-ISP interactions
• service and resource (TE) aspects and
  interactions across multiple ISPs for
  inter-domain QoS delivery end-to-end across the
  Internet
• MESCAL builds on TEQUILA results
• SLS-based QoS definition
• service and TE architectures, logic, protocols

28
Project partners

• Industrial partners
• France Telecom RD (PM)
• Thales Research Ltd (P)
• Algonet SA (P)
• Academics
• UCL (P)
• UniS (P)
• Equipment vendors
• Cisco Systems (sponsorship)
• Alcatel Bell (standardisation)

29
Environment and assumptions

• No Internet God
• No global view of the Internet
• No ASs of the same (or affiliated) administration
  to offer global Internet coverage
• IP-based networking
• Diffserv-capable IP networks
• Different QoS policies per ISP
• Build-on existing, widely accepted/deployed
  inter- and intra-AS protocols (e.g. BGP, OSPF)
• Currently, SLAs between customers and ISPs are
  given ONLY within the geographical span of the
  ISPsthus

MESCAL
30
MESCAL principles

• Co-operation is required between ISPs
• Inter-domain QoS delivery is NOT a single
  optimization problem, but a set of them
• Clear distinction between services and resources
• ISP interactions based on widely accepted
  information templates and related exchange
  protocols (for services and resources)

31
MESCAL approach
Each ISP to
1. Engineer the QoS capabilities
2. Engineer the network
Extending QoS capabilities beyond domain, by
peering SLSs with neighboring ISPs QoS-bindings
of ISP QoS capabilities with QoS capabilities of
peer ISPs
Inter-domain To select the best neighbor to
route Internet traffic to Intra-domain To meet
the QoS of the established SLSs with customers
and peer ISPs
Driven by SLS requirements
Driven by market needs and business objectives
32
MESCAL vs. TEQUILA revisited
33
Inter-domain QoS example
Two ASs interconnected by direct link or
through Internet Exchange Point
A
B
C
D
ISP/AS1
ISP/AS2
Customer 2
Customer 1
Routers B and C are BGP peers. AS2 advertises
reachable destination prefixes, including
customer 2
34
Inter-domain QoS example
A
B
C
D
BGP
ISP/AS1
ISP/AS2
Customer 2
Customer 1
AS1 applies its preferred TE method to
engineer QoS class qc1
AS2 applies its own TE method to engineer QoS
class qc2
35
Inter-domain QoS example
A
B
C
D
BGP
SLAs are required between ISPs and customers (or
peer ISPs) to use other than Best Effort QoS
Classes qc1 or qc2 - quantity of traffic -
topological scope - quality parameters - a la
TEQUILA SLS template
ISP/AS1
ISP/AS2
Customer 2
Customer 1
36
Inter-domain QoS example
ISP1 is aware of ISP2s qc2 capability through,
e.g. InterQoS marketplace. According to its
business objectives, customer requirements, ISP1
defines an Inter-domain QoS Class, iqc1 iqc1
qc1 op qc2 (op e.g. addition for delay, minimum
for throughput) (QoS binding in MESCAL)
qc2
qc1
A
B
C
D
BGP
ISP/AS1
ISP/AS2
Customer 2
Customer 1
37
Inter-domain QoS example
ISP1 initiates SLS negotiation with
ISP2. Resulting in SLS between peering providers
pSLS
Routers in AS1 are updated with QoS based
reachability information Automatic, distributed
configuration to support business agreement (SLS)
qc2
qc1
A
B
C
D
BGP
ISP/AS1
ISP/AS2
Customer 2
Customer 1
ISP2 may reengineer its network (depending on
Resource Provisioning Cycle) Deploys diffserv
traffic conditioner at C
AS2 advertises QoS capabilities to destinations
defined in pSLS to AS1. QoS extensions to BGP4
(qBGP)
38
Inter-domain QoS example
qc2
qc1
pSLS
A
B
C
D
BGP
qBGP
ISP/AS1
ISP/AS2
Customer 2
Customer 1
ISP1 is now in a position to offer inter-domain
QoS Class iqc1 to its customers in addition to
intra-domain QoS Class qc1 and BE services
39
Inter-domain QoS example
iqc1
qc2
qc1
pSLS
A
B
C
D
BGP
qBGP
ISP/AS1
ISP/AS2
Customer 2
Customer 1
Customer 1 may now negotiate with ISP1 for a cSLS
based on QoS Class iqc1 to customer 2
40
Inter-domain QoS example
iqc1
qc2
qc1
pSLS
A
B
C
D
BGP
qBGP
ISP/AS1
ISP/AS2
Customer 2
Customer 1
ISP1 may reengineer its network to accommodate
the new cSLS (depending on its Resource
Provisioning Cycle) Deploys diffserv traffic
conditioner at A
41
Inter-domain QoS example
iqc1
qc2
qc1
pSLS
A
B
C
D
BGP
qBGP
ISP/AS1
ISP/AS2
Customer 2
Customer 1
AS1 may now forward packets from customer 1
towards customer 2 via AS2 meeting QoS
requirements of cSLS with customer 1 (must assume
AS2 fulfils its pSLS)
42
Example 2 gt2 ASs/ISPs
43
Example 3 alternative QoS bindings
iqc1
200ms
100ms
qc2a
qc1a
50ms
200ms
qc2
qc1
pSLS
cSLS
A
B
C
D
ISP/AS1
ISP/AS2
Customer 2
Customer 1

• Considering one way delay only

• Possible delay values from customer 1 to 2 of
• qc1 qc2 50 200 250ms
• qc1 qc2a 50 100 150ms
• qc1a qc2 200 200 400ms
• qc1a qc2a 200 100 300ms

44
Example 3 alternative QoS bindings
iqc1
200ms
100ms
qc2a
qc1a
50ms
200ms
qc2
qc1
pSLS
cSLS
A
B
C
D
ISP/AS1
ISP/AS2
Customer 2
Customer 1
QoS bindings of AS1qc1, AS2qc2 AS1qc1a,
AS2qc2a for iqc1 meet max. delay of
300ms AS1qc1, AS2qc2a may be too
expensive...

• Considering one way delay only

• Possible delay values from customer 1 to 2 of
• qc1 qc2 50 200 250ms
• qc1 qc2a 50 100 150ms
• qc1a qc2 200 200 400ms
• qc1a qc2a 200 100 300ms

45
Example 4 alternative AS paths
qc2
pSLS
qc1
C
D
cSLS
ISP/AS2
B
qc3
A
G
Customer 2
ISP/AS1
Customer 1
pSLS
E
F
ISP/AS3
46
MESCAL standardisation objectives

• MESCAL proposes to contribute to standardisation
  in the following areas
• SLS Management
• nsis (next steps in signalling)
• Traffic Engineering
• ptomaine (prefix taxonomy ongoing measurement
  inter network experiment)
• idr (inter-domain routing)
• tewg (internet traffic engineering
• Policy Management
• rap (resource allocation protocol)

47
Please visit http//www.ist-tequila.org

• for more information
• deliverables
• papers
• IETF contributions
• software