Bandwidth Broker Project

1
Bandwidth Broker Project

• Andy Simmonds
• Priyadarsi Nanda
• Kamran Rajput
• Ming Li
• Faculty of Information Technology,
• University of Technology, Sydney

2
Overview

• The problem of QoS over IP
• Bandwidth Broker
• DiffServ traffic classes
• SIBBS signaling
• BB conclusions
• Resource allocation
• Fair Intelligent Admission Control over Enhanced
  DiffServ
• Policy
• Policy models
• 3 tier Policy Based Architecture
• Signaling
• Policy conclusions

3
1. The problem of QoS over IP

• QoS depends on per flow state
• Layer 3 IP
• provides only a datagram service (no native
  concept of a flow must be constructed by higher
  level protocols such as TCP)
• used as a common access protocol since ubiquitous
• Layer 2 Virtual Circuit e.g. ATM, MPLS
• can support per flow QoS, but insulated from user
  by IP

4
Internet QoS

• Past classic Best Effort IP
• relied on over-provisioning
• Present IntServ, DiffServ
• IntServ end-to-end QoS but does not scale
• DiffServ scales well, but coarse grained
• Future IPv6, all optical core (WDM, fibre
  optical packet switching), IntServ over DiffServ,
  

5
Wavelength Division Multiplexing

• Connelly M Optical Fibre Communications
  Highway for the 21st Century, Elements, Issue 4,
  http//www.ul.ie/childsp/Elements/HomePage.html/

6
IntServ

• Resource Reservation Setup Protocol (RSVP)
  signaling mechanism for QoS control information
• Robustness achieved by periodic refreshing of
  soft state in the routers

SENDER
RECEIVER
7
IntServ

• Resource Reservation Setup Protocol (RSVP)
  signaling mechanism for QoS control information
• Robustness achieved by periodic refreshing of
  soft state in the routers
• Reservation setup from destination

8
Goal scalable, end-to-end Internet QoS

• Core routers must have as little as possible to
  do besides packet forwarding
• gt Aggregated flows
• But DiffServ alone is not sufficient
• Call Admission Control (CAC) of all traffic
  (except BE traffic)
• Manage aggregated flows across the Internet gt BB
  broker

9
2. Bandwidth Broker
CAC
Edge Router Ingress Egress
10
DiffServ traffic classes
EF Expedited Forward AF Assured Forward
Gold Silver Bronze BE Best Effort
11
DiffServ Code Point (DSCP)
Use of ToS field of IPv4,Traffic class field of
IPv6 0 1 2 3 4 5
6 7
DSCP CU
EF 1011 10XX shift r 2 gt 0010 1110 0x2E BE
0x00 XXXX X0XX Standard activity XXXX
X1XX Experiment/local action CU
Currently Unused
12
AF traffic class

• Assured Forward (AF)
• Current specification defines the AF structure
  with 4 classes (AF4, 3, 2, or 1), each having 3
  different drop Precedences (dP x 1,2, or 3). We
  name the three classes
• Gold AF4x (eg 50 BW)
• Silver AF3x (eg 30 BW)
• Bronze AF2x (eg 10 BW)
• During congestion a router may discard packets
  based on their drop Precedences (3 first, then 2,
  finally 1). Therefore highest priority is AF41
• N.B. corrected 1/4/06

13
Structure of AF-PHB Group

• dP Priority (High to Low) dP1 gt dP2 gt dP3
• AF-PHB class priority (High to Low) AF4 gt AF3
  gt AF2 gt AF1
• AF1 AF2
  AF3 AF4
• AF11
  AF21
  AF31 AF41
• Lower
• Drop
• Preference AF12
  AF22 AG32
  AF42
• AF13
  AF23
  AF33 AF43
• 
  PHB Class (higher priority)
• N.B. corrected 1/4/06

14
QoS guarantees

• The reason we have QoS issues is because
  resources are limited
• Cannot afford to forego the statistical gain
  from multiplexing different streams
• Therefore we provision on average rates, not
  maximum (burst) rates
• Therefore there are no absolute guarantees, only
  statistical guarantees
• Only with a relatively small amount of EF traffic
  (say 10 of maximum capacity) can we have a
  statistical guarantee that is nearly an
  absolute guarantee (say 99.9)

15
Resource allocation examplesC 100 Mbps link

• Only BE traffic can be dropped if new traffic
  arrives (e.g. cant drop AF-S if accepted, and
  then AF-G wants bandwidth)
• therefore only BE can take unused BW
• Min allocation to ensure connections survive
• e.g.10 Mbps AF (G/S/B), 20 Mbps (BE)
• flows are restricted if necessary, but not shut
  off hence TCP congestion control can operate
  correctly
• Reserve e.g. 10 Mbps EF (10), to carry new EF
  traffic if fully loaded with AF traffic
• other traffic cannot steal min allocation of any
  class

16
Resource allocation examplesC 100 Mbps link
Fully loaded max all classes
Only 30 Mbps AF Gold 70 Mbps available BE
17
Resource allocation issues

• Differentiation in service done by managing queue
  lengths in routers
• QBE QAF-B QAF-S QAF-G QEF
• alternative differential loading using fixed
  buffers makes inefficient use of buffers. But
  needed if different networks are used for
  different classes (optical WDM?)
• With resource allocation CAC can ensure
• QEF Q0 for EF 10 max capacity C
• But cannot ensure
• QAF-G Q1, etc

18
End-to-end signaling
RAR
RAR Resource Allocation Request
RAR
RAA
RAA Resource Allocation Answer
RAA
19
QBone SIBBS

• End-to-end signaling is slow
• SIBBS (Simple Inter-domain BB Signaling protocol)
• bilateral agreements
• Immediate Response signaling

20
Immediate Response signaling
RAR
RAR
RAR Resource Allocation Request
RAA
RAA
RAA Resource Allocation Answer
data
gt edge router
21
Issues with QBone SIBBS

• Immediate Response signaling?
• accepts flow even if flow is later rejected. This
  is antithesis of QoS!
• But end-to-end is slow
• hence pre-allocate BW
• hierarchical BB (as DNS) especially as not all
  domains will have a BB!

22
BB conclusions

• Minimum BW allocated each QoS class
• Only BE traffic can take advantage of unused BW
• BB needs to be hierarchical
• but still bilateral agreements between domains
• Need to pre-allocate resources to minimize setup
  time
• For robustness needs to be soft-state
• Ingress router must do CAC
• Egress router may do traffic conditioning and
  must police traffic on streams originating in
  that domain

23
3. Resource allocation

• Constraint based
• reactive
• depends on resource availability
• makes best use of resources
• Policy based
• pre-emptive (fast)
• depends on whether request is within policy
  guidelines
• but pointless if policy database is out of step
  with the network state
• Both need accurate, up-to-date info on the state
  of the network gt Enhanced DiffServ

24
Fair Intelligent Admission Controlover Enhanced
DiffServ

• Idea of Enhanced DiffServ
• to calculate class-based network resource
  capability via closed-loop feedback (gt
  Resource Discovery)
• The role of admission control
• to check whether there is enough network
  resource to accommodate class-based requirement
  of Service Level Agreement (SLA), not just check
  traffic is within SLA.

25
Previous attempts to provide strong QoS with
scalability

• QoS support for UDP/TCP based networks (Jeong,
  et al 2001)
• simple buffer partitions for allocating
  bandwidth. Low level solution, OK but wasteful of
  resources
• Bandwidth feedback control of TCP and real time
  sources in the Internet (Gerla, et al 2000)
• needs to modify TCP protocol and hence wont
  work with UDP
• Using edge-to-edge feedback control to make
  assured service more assured in DiffServ networks
  (Kumar, et al 2001)
• relies on Explicit Congestion Notification
  mechanism. Only on/off congestion status
• we propose an acceptance region to avoid
  thrashing

26
Structure of Fair Intelligent Admission Control
Ingress router
Egress router
Admission control Module
Core router
Data Plane
Control Plane
Control Plane Module
Capability
SLS
Besides normal functions of DiffServ,
FIRD-DiffServ can provide network resource state
27
Resource Discovery

• Algorithm
• Ingress router resets RD packet and sends it over
  path
• Core routers update queue length if theirs is
  longer than entry in RD packet
• Egress router returns packet to ingress router
  (control plane - no more updates)
• Ingress router now aware of worst case queue in
  path
• Overhead 2
• 20 kbps/1 Mbps adequate. RD packet is 50 Bytes.

28
Acceptance region
Probability ß
1
Reject
Acceptance
Acceptance with prob
0
Traffic rate
min_th
max_th

• max_th maximum threshold is the explicit rate
• min_th 90 of max_th

29
4. Policy

• Policy Decision Point (PDP), part of BB function
• Policy Enforcement Point (PEP), part of Edge
  Router function
• Responsible for executing the policies defined
  and distributed to it by the PDP
• Policy models
• Outsourcing model flow request arrives at PEP
  which forwards request to PDP for decision
• Provisioning model PDP proactively configures
  the resource handling mechanisms in the PEP prior
  to user request.

30
a new proposed policy model
Egress router

• Direct-request model User makes a direct request
  to the PDP and if successful, the egress router
  is configured for CAC (but really Call Exit
  Control)

User
BB
31
a new proposed policy model
Egress router

• Direct-request model User makes a direct request
  to the PDP and if successful, the egress router
  is configured for CAC (but really Call Exit
  Control)

permit
User
BB
32
a new proposed policy model
Egress router

• Direct-request model User makes a direct request
  to the PDP and if successful, the egress router
  is configured for CAC (but really Call Exit
  Control)
• For end domains (rather than outsourcing model)

CAC
User
BB
33
Policy Based Architecture

• We propose a 3 tier structure
• Internetwork/ Service Provider/ Customer
• Eventually support for all three models of Policy
  Architecture
• initially Provisioning and Direct-request
• Service Level Agreement (SLA) between different
  domains established
• generate Service Level Specification (SLS) for
  each direction of each link between domains

34
Policy Based Architecture

Internetwork Policy Database
Neighbor Domain
Intra
Inter
Service Provider Database
Customer Policy Database
35
Administrative Control

• Service Provider Administrative Control (SAC)
• Intra-Domain
• Inter-Domain

• User Administrative Control (UAC)
• Management of traffic classes
• Keeping databases for each user
• Obtaining permission for aggregated flow through
  SLS

36
Signaling

• Signaling protocols
• COPS Common Open Policy Server (client/server)
  (and COPS-SLS)
• SIBBS Simple Inter-domain Bandwidth Broker
  Specification (P2P)
• RSVP Resource Reservation Setup Protocol
• BGRP Border Gateway Reservation Protocol (not
  BGP!)

37
Signaling

• Between UAC and SAC (User/Service Agent Clients)
• COPS-SLS RSVP
• To support both Outsourcing and Direct-request
  Models
• COPS-SLS for Direct-request Model
• RSVP for Outsourcing
• Within a SAC (Service Agent Client)
• COPS between PDP and PEP
• Supports Outsourcing and Provisioning Models
• Between BB (need P2P)
• SIBBS (but not Immediate Response!)

38
Traffic Engineering goals for end-to-end QoS

• Improve utilization of resources amongst all
  links
• Allow more users with existing resources
• Minimize packet loss and congestion

39
Policy Based Architectureconclusions and future
work

• Proposed a three-tier architecture
• Policy based, hence greater control of the
  networks
• Aimed for end-to-end QoS control
• Based on
• Administrative control
• Signaling
• Traffic Engineering
• Future work
• Implementation of our proposed architecture
  through Linux based routers
• Fine tuning of traffic Engineering and signaling
  methods
• Inter domain resource management and achievement
  of scalability

40
ARN Advanced Research in Networking Faculty of
IT, UTS http//research.it.uts.edu.au/arn/