Optimal Infrastructure for a Universal Electronic Enterprise

1
Optimal Infrastructure for a Universal Electronic
Enterprise
Fractal rendering by Ken Musgrave
Radhakrishnan Kadengal, Engineering
Doctorate Nortel Networks and UCL Main
Supervisor Prof. Jon Crowcroft
2
Optimal infrastructure for a Universal Electronic
Enterprise
3
Topic of Research Research, Design, development
and implementation of a system Architecture to
efficiently operate, control and manage a
Universal Electronic Enterprise based on computer
Communications control The project envisages to
make original contributions in inter-disciplinary
systems science, distributed engineering
technology and near-real time protocols for
distributed routing, rapid restoration and load
balancing. Such a system, operating with
appropriate pricing models might foster a
balanced network growth. The main thrust is to
find a confluence of Communications, Control,
Signal processing and economics/game theory/
management in the emerging internet.
4
(No Transcript)
5
Distributed and Dynamic Resource Control and
Management
The Problem of Control

• Congestion control for different classes/ type of
  service
• Isolation between classes of traffic
• Better resource utilisation
• More revenue for operators
• Better utility and fairness for users

Implementation must address

• Scaling and Distributed operation
• Incremental deployment
• Inter-domain operations
• Substrate independence

and Support

• Resilient routing and provisioning
• Authentication, Authorisation, Accounting
  Charging
• Decision support system for competitive management

6
General system To manage a resource, one need
to measure and control
Resource Broker
Policy Information Base
Benefit/ Revenue Meter
Policy Decision Point
Network Information Base
Control interface
Policy Enforcement
Network measurements
Ingress Router
C1, P1
C2, P2
F1, PP1
Core Router
Egress Router
Core Router
Traffic in
Traffic out
Ingress Router
F3, PP3
F2, PP2
Ingress Router
Example topology
Traffic in
F Flow P Resource Price PP Potential to Pay C
Set Capacity
Implementation of the DRCM System - COPS
compliant architecture
7
Schedulers as output policy enforcement points
Everything begins from Discrimination
A versatile scheduler is devised that can - be
made both work-conserving, non-work conserving -
prioritise traffic according to policies -
penalise flows for no-show - avoid undue delays
to expedited traffic
8
Approach to system design and fairness attribute
General Control System framework for the resource
allocation problem

• Control systems try to hold the output at a
  preset level
• This is achieved by manipulating an intermediate
  variable
• Multiple components sharing the output are
  treated evenly

• Set level optimisation for each class of traffic
• Resource price like variable
• Proportional fairness to user aggregates

9
Can this system be extended to Multi-Input
Multi-Output systems?
Ingress routers
Core routers
Bandwidth Broker
Distributed Digital Control Systems model of the
DRC implementation
10
Does this work? Screen capture from Research
Router Lab implementation
The system uses 2 core routers 4 edge routers 5
hosts as source/sink 1 host as broker
11
Results

• Resources are fully utilised to the set levels
• The sharing is proportionally fair
• Congestion performance
• Interaction performance

• When the core routers are congested, the edge
  routers actively throttle
  their output
• Congestion in one core router frees up bandwidth
  in the core router down stream. This
  reduces the resource price of the second core
  router

12
Integrity of the autonomous systems is maintained
IR Ingress Router NAP Network Access Point
13
Results
Autonomous Network A Price A
Autonomous Network B Price B
Flow c3 PP c3
Flow c1 PP c1
ResourceA2 Price A2
ResourceA1 Price A1
ResourceB1 Price B1
ResourceB2 Price B2
Flow a1 PP a1
Flow b1 PP b1
Flow b3 PP b3
Flow a3 PP a3
Flow b2 PP b2
Flow a2 PP a2
Disturbance a
Flow c2 PP c2
Flows c1, c2 c3 works with the resource price
information available at network access
points. This eliminates the need to poll
individual routers within an autonomous network.
System characteristics remain same across
multiple domains.
14
Unique and novel aspects of the work

• Demonstrated a dynamic resource management
  system in a real network
• The Operator-Network loop and Customer-Operator
  loop are separated. Thus operators are free to
  adopt independent policies to maximise the
  overall value of the service
• Distributed control eliminates the need for
  global knowledge of policies to assure fairness
• Works with path resource prices fed back from
  network access points, thus signalling
  requirements are affordable
• Uses a simple algorithm and hence computation
  complexity is negligible
• Operates in the middleware, providing network
  transparency and easier modification
• Ubiquitous deployment of the protocol is not
  required. Hence an incremental introduction
  strategy is viable

15
What are the architectural requirements for
deployment in real networks?

• As the network size is enlarged
• Individual telnet sessions for measurement and
  control becomes cumbersome
• Frequency of polling gets limited
• Usage of resource management cells
• Cells are interleaved with data packets
• Common data formatting is undefined
• Requires commonly agreed protocol
• Remote Procedure Calls
• Provides data marshalling
• No interference with network layer
• Other required features
• Work across the heterogeneous network that runs
  on variety hardware, software and OS
• Work with multiple autonomous components
• Multi-threading
• Desired features

• Not actively considered

16
Proposed way forward Dynamic Resource Control
Middleware for Carrier Networks
Benefit/ Revenue Meter Browser interface
Network Management System interface
Authentication Authorisation Accounting
Charging
Resilient/ routing and Provisioning interface
Policy Browser interface
Inter-domain interface
CORBA Software Bus
Network Information Base
Policy Information Base
Policy Decision Point
Policy Enforcement
Set levels Measurement
Core Network
Edge Network
Software engineered in UML
17
Different economies at each loop (charging might
be best as an overlay)
18
QoS and Traffic mix
A preliminary interpretation of the results of
diffserv simulation Inference The trend shown by
the graph is as expected (filler data used to fit
the surface)
19

• Applications in the Internet Traffic Control and
  Management business
• Different strands of these ideas can be
  effectively used in
• IP Routers
• MPLS switches
• Optical switches
• Photonic switches
• Wireless resource management
• Server farm load balancers
• Content provisioning

20
Example in IP router/switch architecture
In the basic simulation result shown on the left,
the marked area shows doubled network utilisation
compared to current figures (10-20 ) of
utilisation and maintains same QoS.
21
Example in multi-layer (IP/ Photonics) example
22
Back-up
23
Working model of the proposed distributed system
Component m
Component m
Component 1
Component 1
Middleware
Middleware
Network Operating System
Network Operating System
Hardware
Hardware
Network communication
Router 1
Router n

• DRC system designed as middleware provides
  appropriate development and run-time environment
  for distribution
• Layered between the application and the
  network/OS, this is a compact and fast layer4
  solution

24
Choice of distribution architecture, language and
engineering tool

• Common Object Request Broker Architecture
  (CORBA)
• Transactions between functional objects are by
  Object Requests
• Scaling is easy
• Versatile Coordination and policy enforcement
• Flexible and preferred over CMIP and SNMP
• Java programming language
• Easy Run time installation of new functionality
  in other network elements
• Browser (?SGML) interface is simple
• Multi-threading
• Unified Modeling Language (UML) for software
  engineering
• Modular design
• Hierarchical generalisation is easier
• Effective communication
• We are also exploring the use of the in-house
  Momentum tool

25
Link Bandwidth/ price Database
Path Advisor Alg (OSPF)
LID C Usage Cl Resource
PR AF Price (update)
S D Link IDs Path Label
Topology Database
Path price Virtual port Query
PDP Policy Decision Point PEP Policy
Enforcement Point S Source, D Destination LID
Link Identifier C Link capacity Cl set capacity
level PR Premium, AF Assured Forwarding
PDP
Network Information Base - approximate schematic
26
Traffic info to PDP
Policy Enforcement from PDP
PEP - Forwarding path
Scheduler per Virtual Port
PEP- Admission Control
PR
Meter, Policer, In/ out profile marker, Shaper
(aggregate/flow)
Classifier per Virtual Port
Traffic i/p
Authentication
AF
Output Link
BE
RC
PDP Policy Decision Point PEP Policy
Enforcement Point PR Premium, AF Assured
Forwarding BE Best Effort, RC Router Control
Ingress Router - approximate schematic
27
PIB NIB
PP, Price V.port Query
SResource Price Database
Flow database register lookup, Add/ delete
Virtual Port Number
SPP SPrice
If PP lt Path Price, drop OR mark drop prob.
PR AF BE RC PR AF BE RC
Add to/ delete from SPP-Price table Class, PP,
Price, V. Port
Traffic info from edge router ingress
Policy Enforcement to Admission Control and
Forwarding Path
Benefit/ Revenue Display
PIB Policy Information Base NIB Network
Information Base PR Premium, AF Assured
Forwarding BE Best Effort, RC Router
Control PP Potential to Pay
Policy Decision Point - approximate schematic
28
SLA Database
Subscription Contract Class, Payments
Utility Function Database
User Number
Usage
Potential to Pay
Policy
Resource supply
Value Proposition (Rule based priority,
charging, application../ Profile/
Heuristics)
Avg. Bandwidth Max. Burst Service classes
SLS
PP Query
PDP Policy Decision Point SLA Service Level
Agreement SLS Service Level Specification
PDP
Policy Information Base - approximate schematic
29
Can this be introduced in the Carrier Networks?

• The system doesnt require ubiquitous deployment
  of the scheme for a start
• The system can work across heterogeneous network
  and multiple domains
• Can co-work with the deployment of differentiated
  services
• Distributed control eliminates the need for
  information from other edge routers
• Signalling complexity is affordable and
  computational complexity is negligible
• Operators are free to adopt independent policies
  to maximise the overall value of the service
• An incremental introduction strategy is viable

Aspirations

• Detailed design of object models and product
  development strategy
• Standardisation initiatives incl. IRTF/IETF
• Further theoretical studies