Multi Domain Policy Server V2 Scheme Overview

1
Multi Domain Policy ServerV2 Scheme Overview

• Ariffin Yahaya
• v2.0

2
General

• Concept
• Packet level simulation of Policy Server managed
  domains with dynamic routing. Paths for QoS flows
  are decided by the Policy Server(s).
• Why?
• Version One Routing was static, so the flows that
  are accepted will create the same hot spots in
  both architectures.
• V2 New Statistics
• Flow level
• Admission acceptance/blocking
• Packet Level
• Dropping
• Delay

3
Admission Control Criteria

• Specified by User in the RSVP Flowspec
• Bandwidth
• All routers involved in a QoS flow must have at
  minimum the requested bandwidth.
• EF/AF/BE traffic have their own respective pipes
  that do not interact.
• Latency
• Propagation Assumption 5 microseconds per
  kilometer
• We will standardize (average out) the distance
  between hops so that we can consider the latency
  factor to be in terms of hops

4
Routing

• Routing
• Both Inter and Intra domain routing for QoS flows
  will be dynamic
• BE Traffic will use static routes
• Route selection concept
• longest widest approach wherever possible
• Longest widest will give each request what it
  needs both in terms of bandwidth and latency
  without over provisioning.
• In theory, this will leave the shorter routes to
  flows that really request it.

5
V2 OPNET Routers

• Signaled Flow
• Each Signaled flow can be uniquely identified by
  the ltOriginating IP, Session gt tuple
• Provisioned Flow
• Each Provisioned flow is viewed as one big
  microflow, regardless of how many
  Ips/Users/Sessions use the Provisioned flow
• Rule names are unique among Provisioned Flows
• VFL
• We now no longer uses the VFL concept, choosing
  instead to be more specific to the microflow.
• Note
• we will need to fine tune the router queuing
  system when we have some working model.

6
Flat Architecture

• Concept
• A signaled Interdomain request creates a cascade
  of requests that propagate through all paths that
  are possible between the source to the
  destination. Because there is initially no
  information about the whole path, the destination
  domain PS will make the decision on the Longest
  Widest Path based on the probes that reaches
  it. The destination domain PS will then signal
  back its choices to the domains that it wants to
  use. So, the actual path of the microflow is
  determined by the destination domain PS.

7
Flat Architecture - cont

• Performance Steps
• Source Domain PS Probes for best path with RSVP
  Path Message
• This probe packet is sent out on all possible
  paths and will be propagated by subsequent domain
  policy servers (with poison reverse). Bandwidth
  is reserved on paths with timeout value set to
  latency2 microseconds.
• Destination Selects a Path
• When the destination receives the first probe
  packet, it will wait for latency microseconds and
  will then create a topology (graph) based on the
  incoming probes. It will then decide on a Longest
  Widest Path.
• Destination Sends RSVP Resv Message
• Resv is sent to the Domains that contain the
  desirable routes.
• Intermediate Domain PS receives RSVP Resv Message
• Policy Server will configure routers within its
  domain for the newly decided path.
• Source Domain PS receives RSVP Resv Message
• Policy Server forwards Resv to the Sending User
  and the Sending User starts to send data.

8
Hierarchical Architecture

• Concept
• Hints are advertised from the leaf domains up to
  the parent domains. Admission control is done by
  the Policy Server presiding over the whole path.
  Path selection is divided into three cases, the
  Source domain, the Destination domain and the
  Intermediate domain. The Source and Destination
  domain will give up to date state information
  while the advertised hints are used for the
  Intermediate domains. Path selection criteria in
  the Source and Destination domain are Shortest
  Widest, and Longest Widest in the Intermediate
  domains.

9
Hierarchical Architecture - cont

• Performance Steps
• Source Domain PS Receives Interdomain request
  from User
• Source Domain PS compiles Widest Shortest Path to
  all of its Border Routers and sends these up to
  its parent
• This RSVP Path is propagated until we reach the
  decision point
• Deciding PS asks for Interdomain Path from
  Destination Domain
• Destination Domain compiles Widest Shortest Path
  to all Border Routers and sends these up to the
  Deciding PS
• Deciding PS decides on Path
• PS creates a graph of the topology based on the
  Source and Destination Domain Paths, and the
  Advertising of the Interdomain Paths. A Longest
  Widest Path is chosen.
• Deciding PS Sends Configure Message to All
  Routers
• Source Domain PS receives RSVP Resv Message
• Policy Server forwards Resv to the Sending User
  and the Sending User starts to send data.

10
Observations

• General
• Both Architectures can make optimized decision on
  the path, but with different overhead costs and
  complexities.
• Flat Architecture
• Must (selectively probe) flood to achieve
  knowledge of the whole topology.
• Has high on-demand processing time at the
  destination domain.
• Hierarchical Architecture
• Must advertise topology information up the
  hierarchy.

11
Current Status

• Test out simple single domain scenario
• Scheduled for this weekend.
• Implement the multi domain scenario
• TBA

12
Problems

• What algorithms (and how) to use in V2 to avoid
  too major a change. Dijstra, Bellman Ford, Floyd
  Warshall, etc.
• Looking for ways to minimize broadcasted Path
  packets and unused reservations in the Flat
  architecture.
• What to send up as advertisements in the
  Hierarchical architecture.
• Looking for a good algorithm to do optimization
  for the Hierarchical architecture.
• Looking for a good way to do Longest Widest path
  selection based on exclusive paths.