Policy-based QoS Network Management

Yi Pan & Ariffin Datuk YahayaProfessor Tatsuya Suda’s NetGroup

University of California, Irvine

ypan@uci.edu, ariffin@uci.edu

Outline

• Existing QoS frameworks

• Policy-based Network Management (PBNM)– Basic Concept– Components and Architecture

• Deploying PBNM in the Internet– Flat vs hierarchical Architecture

Existing QoS Frameworks

• Proposed frameworks to provide QoS services in the literatures– IntServ and RSVP

• A per-flow resource reservation based approach to enable end-to-end QoS guarantee

– DiffServ• A scalable provision scheme to provide hop-by-hop differentiated

service for aggregated flows

– IntServ over DiffServ• A hybrid framework to provide IntServ-like QoS service to users on top

of the underlying DiffServ core network

– Policy-based Network Management (PBNM)• Using policies and policy servers to provide QoS services based on the

contract between the service provider and the users

Outline

• Existing QoS frameworks

• Policy-based Network Management (PBNM)– Basic Concept– Components and Architecture

• Deploying PBNM in the Internet– Flat vs hierarchical Architecture

Policy-based Network Management (PBNM)

• Policy-based network management (PBNM) - Basic Concept– QoS service is provided through policy server

• The edge routers consult the policy server to perform admission control

• The core routers accept resource configurations from policy server to implement certain QoS service requirements

Policy-based Network Management (PBNM)

• Components and ArchitecturePolicyInput

Policy Server

User UserRouter

Router

Router

PolicyRepository

Policy Management ToolWeb

PDPPolicy

DecisionPoints Router: PEP (Policy

Enforcement Point)PIB/MIB

Policy-based Network Management (PBNM)

• Functions of Components:– Policy Repository

• A database storing all policy rules

• Describing the agreed level of QoS services to the users

– Policy Management Tools• An administrative tool to monitor, edit, and debug

the policies in the Policy Repository

Policy-based Network Management (PBNM)

– PDP (Policy Decision Point)• Performs the admission and configuration decisions

– Decisions are made by consulting the policies in the Policy Repository

– Configurations are deployed to PEPs

• PIB (Policy Information Base) and device MIB– Keep records of all instances of enforced policy rules on the

network devices

– PEP (Policy Enforcement Point)• Intelligent network device such as routers• Forward user request• Execute configuration defined by the policy rules• Control the resource for each user flow

Policy-based Network Management (PBNM)

• Summary:– Advantages of deploying PBNM

• Provides a flexible interface to define and deploy QoS services without depending on the hardware

• Can be applied together with IntServ, DiffServ, or IntServ over DiffServ frameworks, providing a flexible granularity of QoS services guarantee to the users

• Automate network resource management by dynamically reconfigure the network devices based on the policies

Outline

• Existing QoS frameworks

• Policy-based Network Management (PBNM)– Basic Concept– Components and Architecture

• Deploying PBNM in the Internet– Flat vs hierarchical Architecture

Deploying PBNM in the Internet

• Providing QoS in the Internet requires multi-domain operations

• A multi-domain PBNM system can have– Flat architecture

• All policy servers are peers to each other• Only one type of relationship between policy servers: neighboring

– Hierarchical architecture• Policy servers are grouped together in hierarchies• Two different types of relationship between the policy servers:

– Siblings: policy servers who are subordinates of the same master-server

– Master: policy servers that dominates several other sub-servers

Flat Architecture

Ha1 wants to send Data to Hd1 and sends a Request to the RouterThis Request is sent to the Policy Server for ProcessingPSa Decides to Allow the Flow and Chooses an Intradomain PathPSa Sends an Interdomain Request to Next Hop DomainBorder Router Forwards Interdomain Request to it’s Policy ServerPSc Decides to allow the flow and chooses a pathPSc Sends an Interdomain Request to Next Hop DomainBorder Router Forwards Request to it’s Policy ServerPSd Decides to allow the Flow and Chooses a PathSince this is the Destination, PSd Configures all the ComponentsComponents Acknowledges to Policy ServerPSd sends an Interdomain Reservation to the Return RouteBorder Router Forwards Reservation to it’s Policy ServerPSc Configures all the ComponentsComponents Acknowledges to Policy ServerPSc send an Interdomain Reservation to the Return RouteBorder Router Forwards Reservation to it’s Policy ServerPSa Configures all the ComponentsComponents Acknowledges to Policy ServerPSa sends a Reservation to the Requesting UserRequesting User uses the Reservation to Send Data (Ha1 to Hd1)

Hierarchical Architecture

Ha1 wants to send Data to Hd1 and sends Request to the RouterThis Request is sent to the Policy Server for ProcessingPSa Decides to allow the flow and chooses an Intradomain PathPSa Forwards the Request to it’s ParentSMPS1 Forwards the Request to it’s Parent

?

SMPS1’s Extended Domain

MPS Decides to allow the flow and chooses Inter Domain Path

MPS’s Extended Domain

MPS Sends Request to Destination Domain through SMPS2SMPS2 Forwards Request to Destination Domain

SMPS2’s Extended Domain

PSd Chooses an Intradomain PathPSd Configures All ComponentsComponents Acknowledge ConfigurationPSd Informs Parent that the Domain is ConfiguredSMPS2 Informs Parent that the Domain is ConfiguredMPS Configures All Other Components (Abbreviated)Components Acknowledge the Configuration (Abbreviated)MPS Sends Reservation to the Source (Abbreviated)Requesting User uses the Reservation to Send data out to Hd1

Deploying PBNM in Internet

• Conclusion:– For a small topology (that we simulated), flat is better

– Hierarchical architecture is better with large topology