1 / 40

Design of a Scalable Clearing House Architecture

Design of a Scalable Clearing House Architecture. Lakshminarayanan Subramanian Chen-Nee Chuah Ramakrishna Gummadi. ICEBERG Design Review Jan 12, 2000. Basic Questions in Mind!!!. What is a Clearing House? What are the basic requirements of the Clearing House?

wynter-michael
Download Presentation

Design of a Scalable Clearing House Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design of a Scalable Clearing House Architecture Lakshminarayanan Subramanian Chen-Nee Chuah Ramakrishna Gummadi ICEBERG Design Review Jan 12, 2000

  2. Basic Questions in Mind!!! • What is a Clearing House? • What are the basic requirements of the Clearing House? • What are the services it supports? • What are the goals of our design? • What are the assumptions we make in our design?

  3. Clearing House • Coordinates interactions between the various ISPs in the network. • What kind of interactions? • Performs path discovery and resource reservation. • Services wide-area call requests. • Provide QoS guarantees. • Secure billing services. • Support for multicast and mobility.

  4. Present Scenario ISP3 H3 ISP1 ISP2 H1 ISP4 H2

  5. Goals of our design • Scalability- throughput, state maintained • Optimize network utilization • Dynamic call-routing • Continuous path monitoring for QoS • Reduce response time for call requests • Support multicast, mobility and secure billing • Recovery from link,node and packet failures • Security and Privacy

  6. How do we achieve it!!! • Build a logical hierarchy in the network • Distribute state and resources among the nodes in the hierarchy and create a distributed database • Aggregate requests and bound queue size • Hierarchical and dynamic routing of call requests • Continuous monitoring of resources • Separate resource reservation and call-setup

  7. Assumptions • Edge routers can collect traffic statistics and estimate bandwidth requirements • Control and data paths are separated • Clearing House and ISP trust each other • Routers can measure queueing delay statistics • Possible to introduce a monitoring system into existing ISP architecture

  8. Clearing House Structure ISP3 ICH ECH ICH ISP1 ISP2 ICH ICH ISP4

  9. Clearing House Infrastructure • External Clearing House(ECH) as third party agent to coordinate inter-ISP traffic. • Internal Clearing House(ICH) services intra-ISP traffic and acts as a monitoring agent for external traffic. • ECH organized as a hierarchy of nodes. • ECH stores inter-ISP network state and ICH stores intra-ISP network state in a distributed manner.

  10. Hierarchical Structure • Divide network into non-intersecting basic domains(e.g.. Cluster area codes) • Recursively join physically adjacent domains to form larger logical domains. • Generate a hierarchical tree of domains in the network. • Associate a distributed ECH with every domain in the tree.

  11. Hierarchical Clearing House ISP3 ICH ECH Domain ICH ECH ECH ISP1 ICH ICH ISP4 ISP2

  12. External Clearing House • Performs hierarchical routing and computes near optimal path for call requests. • Aggregates call requests. • Collects statistics on resource reservations and delay statistics from ISPs. • Performs extra resource reservations for call requests if necessary. • Monitors performance of traffic. • Stores billing prices of ISPs within its domain

  13. Internal Clearing House • Every ISP has an ICH. • Routes intra-ISP calls. • Monitors and predicts incoming and outgoing traffic in edge routers • Performs advanced reservations for predicted traffic and updates ECH. • Determines link reservations in ISP and updates traffic routing table of routers.

  14. Hierarchical Routing Inter-domain and Intra-domain paths Domain 1 1c 1b 1a

  15. Clearing house state • Billing information is present in CH of basic domain. • Each CH maintains aggregated state of its domain. • Calls between two sub-domains of its domain. • Aggregated connectivity graph between domains. • Reservation and delay status along links and nodes in the graph. • Pricing information between domains.

  16. Other Enhancements • Caching • Cache computed inter-domain paths • RxW scheduling • Maximize throughput without affecting response time. • Measuring QoS parameters • Multicast support • Dynamic path routing to support mobility • Secure billing architecture • Fault tolerance

  17. Support for Multicast and Broadcast Trees Edge router • Nodes up in the hierarchy find inter-domain multicast tree. • Local nodes find intra-domain optimal tree.

  18. Scalable Infrastructure for supporting Mobility Moving Object L1 L1 Domain Structure Level 0

  19. Strengths • State of network distributed among various CH nodes. • Aggregation of call requests. • Response time depends on locality. • Bounded queue size. • Path discovery is distributed. • Localized billing – makes it real-time. • Core routers do not maintain much state info. • Caching, scheduling improve performance.

  20. Clearing House Design:Resource Reservation Strategies Chen-Nee Chuah ICEBERG Design Review Jan 12, 2000

  21. H1 H3 Resource Reservation H2 Example Scenario • Quality of Service? ISP 2 ISP 1 ISP 3

  22. H1 H3 SLA SLA H2 SLA: Agreements that describe the volume of traffic exchanged, bandwidth reserved and price Example Scenario ISP 2 ISP 1 ISP 3

  23. Challenges • How is the SLA between two ISPs established? • How do SLAs reflect dynamic traffic patterns? • What happens when it involves more than 2 ISPs? => Clearing House provides a scalable approach to address these questions

  24. destination Updates Adapt Reservation Updates Hierarchical Clearing House source Edge Router ISP n ISP2 ICH ICH ICH ISP1 CH1 CH1 CH2 • Distributed database & bandwidth brokering agent • reservation status, % link utilization, traffic predictor • establish advanced reservation (based on traffic predictor)

  25. Resource Reservation Infrastructure H1 H2 Assume the Edge Router • collects traffic statistics • e.g. average aggregate incoming and outgoing traffic volume • estimates dynamic change of bandwidth requirements • statistical techniques (Kalman filter) • sends regular updates to LCH • aggregates reservation requests Edge Router ICH ISP1 Edge Router ICH ISP2

  26. Static Reservation Dynamic Reservation Static & Dynamic Reservations H1 H2 Internal Clearing House • Maintain intra-ISP reservation status • Establish static reservations based on mean aggregate traffic for different time of the day. • Adapt reservations on a smaller time-scale based on existing reservation and bandwidth predictor. • Send regular update to GCH Edge Router ICH ISP1 CH Edge Router

  27. Properties • Aggregation of Signaling • Resource reservation requests are aggregated at various levels (ER -> ICH, ICH-> CH1 etc.) • De-couple notifications & reservation requests • notifications: updates on reservation status, % link utilization, traffic predictor • reservation requests: initiation of SLA renegotiations • Hierarchical Approach • Static and Dynamic Reservations • reduce reservation setup time • compensate for the coarse granularity of the notifications

  28. Clearing House Hierarchical Tree Adapt Reservations- Advance reservations - Process reservation requests CH2 Notifications (every Du s) - Reservation status - Link utilization - Bandwidth predictor CH1 CH1 ICH ICH ICH ICH LCH LCH Aggregate reservation requests (Ta)

  29. Int-Serv Approach destination source • End-to-end notifications & reservation requests • ISP 2 notifies next-hop ISPs and negotiate new SLA with them. When all downstream ISPs accept the SLAs, an ISP notifies upstream ISPs and set up new SLAs. • When original SLA is accepted, all SLAs from source to sink are updated. BB ISP n BB BB ISP1 ISP2

  30. destination Diff-Serv Approach source • Limited or no notifications • Trade-off end-to-end QoS for scalability Edge Router ISP n ISP1 ISP2 BB BB BB BB

  31. Evaluation • Overall Performance Metrics • Trade-offs between scalability, QoS and signaling complexity • Effect of aggregation on QoS • e.g. % blocking/dropping • Choice of signaling between CHs • Link efficiency • Bandwidth Estimator • How well do the predictors track the traffic fluctuation? • Window of measurement?

  32. Clearing House Design:Billing, Security and Privacy Ramakrishna Gummadi ICEBERG Design Review Jan 12, 2000

  33. Basic Goals • Support Scalable, Secure and Correct Billing • Support Trust Management for Traffic Monitoring • Support Privacy Management

  34. Tasks while supporting Secure and Scalable Billing • Must scale to millions of calls per day • Must perform authentication (in both directions), authorization, and correct billing

  35. Approaches to support Secure and Scalable Billing • Use a level of indirection through authorization and billing tickets • Generate these tickets offline • Perform offline settlements with the user and various ISPs • Use aggregation for storing and verifying tickets to reduce storage space • Use X.509 certificates, passwords or Public-key challenge/response for mutual authentication

  36. Notes on Authorization and Billing Tickets • Both used as level of indirection, for achieving scalability, while maintaining high security and requiring little trust • Both like Kerberos, a scalable security service, using tickets for authentication and secrecy • Both acquired by the user once at the beginning, and used as needed

  37. Notes on Authorization and Billing Tickets (contd..) • Authorization tickets used to establish that call corresponds to resources reserved • Billing tickets used to charge the user for time spent on the call • Billing tickets can be returned by the user at end of call, or more can be acquired during duration of call, as needed, to maintain correct billing records

  38. Performance Optimizations • Can use shared-key techniques in using authorization tickets • A lot depends on the degree of trust between the CH and the ISPs (though the ISPs themselves don’t need to trust each other) • If trust possible, we can use shared-key cryptography for billing (no non-repudiation support) • Lots of performance and storage improvement through aggregation

  39. Trust Management • CH can incorporate a Trust Management module to: • Provide a standard, general-purpose mechanism for specifying application security and credentials • Directly authorize security-critical actions, like network monitoring • Bind keys directly to authorization records to perform specific tasks • Describe delegation of trust and subsume the role of public key certificates

  40. Privacy Management • Privacy management very difficult in the current Internet, more so in ICEBERG (because of billing) • Privacy of users and participating ISPs needed • User privacy with respect to participating ISPs achieved by anonymization in the form of indirect authorization and billing tickets

More Related