Resilient Overlay Networks

1
Resilient Overlay Networks

• Arezu Moghadam
• 07/11/03

2
Background

• Internet as independently ASs
• Border Gateway Protocol (BGP-4)
• Running at the border routers
• Performing more aggregation and fewer updates
• Time consuming fault recovery
• Todays internet is vulnerable to router link
• faults.

3
Goals

• Failure detection and recovery in the short time
• Tighter integration of routing with the
  application
• Expressive policy routing

4
RON

• Virtual network created on top of an existing
  network
• The nodes use each other as routers

5
Characteristics

• RON nodes exchange quality of the paths
• Each RON is designed to be limited in size
• Integration of path selection with applications
• Implementation of expressive routing policies

6
Past Related Work

• Measurement and analysis to show time consuming
  procedure of achieving a consistent view of
  network topology for routers.
• Labovitz, Paxon, Chandra,
• Network-Layer Techniques
• ARPANET
• A delay congestion based distributed shortest
  path
• BGP-4
• Multi-home advertising a customer through
  multiple ISPs
• Overlay-Based Techniques
• MBone, 6-Bone, X-Bone,
• Designed for specific goals

7
Design Goals

• Fast failure detection and recovery
• Link failures Path failures result in outages
  performance failures
• Failures of BGP-4
• Tighter integration with application
• Failures faults from point of view of
  applications
• Priority of some metrics over others in the path
  selection
• Expressive policy routing
• It is impossible to announce a BGP route only to
  particular users (unable to keep private routes)

8
Design

• Enter via a conduit at entry node
• Consulting with router to select the best path
• Path selection is done at entry nodes
• Hands packet to the appropriate out put conduit
  at exit node

9
Design (Software architecture)

• Each program communicating with the RON software
  is a RON client
• A client interacts with RON across an API called
  conduit which access RON via two functions
  provided by forwarder
• Send(pkt, dst, via_ron)
• Recv(pkt, via_ron)
• RON router
• Implements a routing protocol
• RON membership manager
• A protocol to maintain the list of members

10
Design (Routing path selection)

• Tagging the packets RON header
• Speeding up the forwarding at intermediate nodes
• Default specific metrics
• Latency, packet loss, throughput
• Link-state dissemination
• Link-state routing protocol by which each node
  gets information about other N-1 virtual link
• Path evaluation selection
• Outage detection
• PROBE_TIMEOUT, OUTAGE_TRESH
• Latency loss-rate

11
Design(performance database)

• Good routing decisions need detailed performance
  info.
• Each RON node uses a seprate performance
  dadabaseto store samples.

12
Design (policy routing)

• Allows defining the type of traffic on particular
  link
• Classification
• A packet is classified given a tag when enters
  RON
• Routing table formation
• The tag is used to perform lookups in the routing
  tables
• Policy classifier component
• Produces permits function
• If a given policy is allowed to use a particular
  virtual link

13
Design (Data Forwarding)

• Forwarder passes an incoming packet to the
  routing table if it is not destined for a local
  client

• Policy tag to decide on routing policies
• Packet type to demux the packet to the RON
  client for the local node

14
Design(bootstrap membership management)

• Static membership management
• Load peers from a file
• Dynamic announcement-based
• Soft-state membership protocol
• Each node periodically floods to all other nodes
  its list of peer RON nodes

15
Implementing

• RON system is implemented at user-level as a
  flexible set of C libraries
• Resilient IP forwarder

16
Implementing (cont.)

• Routers
• Implement the router virtual interface with this
  function
• lookup(pkt mypkt)
• Static router
• Dynamic router
• Extensible by linking it with a different set of
  metric descriptions

17
Implementing (cont.)

• Monitoring virtual links
• Each RON node monitors other N-1 virtual links
  using randomized periodic probes
• The active prober component maintains a copy of
  peers table with a next_probe_time field per peer
• Both sides get reachability and RTT information
  from 3 packets

18
Evaluation

• Ability to detect outages recover quickly from
  them
• Performance failures
• Ability to improve loss rate, latency and
  throughput
• Effectiveness of one-intermediate-hop strategy

19
Overcoming path outages
20
Handling packet floods

• RON recovers quickly reroute through the third
  node
• NON-RON BGP would not have marked this link as
  down

21
Overcoming performance Failures

• Loss rate
• Effect of outage detection component of RON

22
Latency
23
throughput
24
RON Routing Behavior

• RONs single-hop indirection worked well for
  avoiding problematic paths
• Problematic path s?t
• Some link l(s,t) congested
• As long as there is even one node u and s?u or
  u?t dont go through l(s,t) ,

RONs single-hop indirection will suffice
The probability that a single-intermediate RON
path is optimal is 1
25
Conclusion

• Application specific routing
• Improve the reliability of internet packet
  delivery
• Overcome performance failures
• Improve loss rate, latency and TCP throughput
• Building Apnet on overlays