Bandwidth Broker for endtoend QoS

1
Bandwidth Broker for end-to-end QoS

• Andy Simmonds
• Advanced Research in Networking
• 14 Dec 2006

2
QoS mechanisms

• IntServ per flow, fine granularity, route
  pinned, does not scale
• DiffServ aggregated flows, coarse granularity,
  route not pinned, scales well
• MPLS layer 2, virtual circuit, intra-domain
• We assume DiffServ used. Since flows aggregated
  need Call Admission Control (CAC) at all ingress
  points.

3
Manage resources

• BW, low delay/jitter/loss/cost
• We choose to manage BW with 5 traffic classes
• Expedited Forward
• Assured Forward Gold/Silver/Bronze
• Best Effort
• Plus higher priority network traffic

4
Traffic classes 100 Mbps link
Fully loaded 50 Mbps EF min others
Only 30 Mbps AF Gold 70 Mbps available BE
5
Bandwidth Broker starting point

• R Nielson, J Wheeler, F Reichmeyer, S Hares A
  Discussion Of Bandwidth Broker Requirements for
  Internet2 Qbone Deployment, August 1999
• QBone Signaling Design Team Final Report,
  http//qos.internet2.edu/wg/documents-informationa
  l/20020709-chimento-etal-qbone-signaling
• Centralized
• One BB per domain, one DB per domain
• BB is Policy Decision Point (PDP)
• Ingress router is Policy Enforcement Point (PEP),
  i.e. CAC function
• Egress router may do traffic shaping
• SIBBS (Simple Inter Domain BB Signalling) from
  QBone BB architecture

6
BB domain
7
BB functions

• Billing is separate function (too hard basket)
• I started by assuming reserving resources in
  advance is a BB function
• BB/PDP is not really the policy validation point.
  I think there are two functions
• Are resources free? (BB function)
• Is request within policy? (higher layer)

8
Policy Based Internet architecture

• 3. End-to-end QoS inter domain
• BGP (Border Gateway Protocol) to provide policy
  based routing and traffic engineering
• 2. Network level QoS inter/intra domain
• BB to set up path from source to dest domain
• BB signals to devices (intra) and other BBs
  (inter)
• 1. Device level QoS intra domain
• device configuration

9
BB design

• Incremental design
• Self organizing
• Given available resources, BB will track resource
  allocation (open loop)
• No resource discovery mechanism
• Must be soft-state
• DB able to flush old entries and rebuild after
  restart

10
BB prototype

• Programmed in Java
• DB implemented as arrays
• Only deals with immediate requests
• Static routing between BBs

11
Test bed

• ---------------
• cabbage3927
• ---------------
• (50,10,10,10,20)
• v
• to Potato --------------- to Turnip6666
• 3927 (U) --gt kakadu2222 lt----
  (50,10,10,10,20)
• ---------------
• (50,10,10,10,20)
  (0.03,10,10,10,60.97)
• v
• ---------------
• beetroot3333
• ---------------
• (50,10,10,10,20) (U)
• v

12

• having implemented the prototype had some
  further thoughts about requirements
• Advanced reservations
• Centralized BB
• Signaling

13
1. Decided against advance reservations

• Difficult policy decisions a flow from domain A
  may be accepted at 7 pm, but not at 9 am
• I think advanced reservations needs to be an
  added function in layer 3, whilst the BB deals
  with immediate reservations at layer 2
• Incremental design get immediate reservations
  working, than add advanced reservations working
  later
• Serendipity - the BB can be used for billing (a
  successful reservation means the connection is
  made)

14
2. Decided against a centralized BB

• Decided on one BB per router (with incoming links
  to monitor), one DB per BB
• Not all links need to be monitored
• Normally monitor incoming links (CAC), but if
  necessary can use same functionality to monitor
  outgoing links
• BB will self organize to find route (as routers
  do)
• Static routes now, eventually routes to be
  determined by BGP at layer 3
• Each BB is logically associated with one router
  may be physically integrated, or may be
  centralized and all run on one box
• Scales well

15
3. Decided against SIBBS

• Designed new lightweight inter domain signalling
  protocol BBIDRA (Inter Domain Resource
  Allocation)
• multi-hop datagram service
• SIBBS assumes inter-BB signalling is done between
  two BBs as endpoints - no routing functionality
• SIBBS is connection oriented - not light weight

16
BBIDRA

• Like RSVP, it follows the signal path across the
  Internet.
• Unlike RSVP, it does not reserve resources in
  routers but in BBs.
• A PATH message is sent from sender to receiver
• A RESV reply threads its way back along the same
  path confirming the reservation.

17
BBIDRA

• msg1 - PATH ask for resources, goes downstream
• msg2 - QUIT message to shut this listener down
  (to close listening thread cleanly), goes only to
  local BB
• msg3 - RESV allow resources, goes upstream
• msg5 - RLSE release individual resource
  downstream.
• msg6 - RFRSH renew individual resource
  downstream.

18
End-to-end signaling
PATH
PATH
PATH
RESV
RESV
RESV
19
To Do

• Proper DB
• Routing from BGP at layer 3
• Policy at layer 3
• Advanced reservations at layer 3
• Resource Discovery

20
Prototype available from
ARN Advanced Research in Networking Faculty of
IT, UTS http//research.it.uts.edu.au/arn/
gt Products gt Software