Design Decisions Lessons Learned

1
Design Decisions / Lessons Learned

• Monday 21 August 2000
• 1015 - 1035 Top-level design decisions
• Rationale for IP-based approach
• Why an infrastructure based approach?
• Leveraging cluster-computing
  environments Ninja vSpace
• 1035 - 1200 Design of the ICEBERG components
  and capabilities
• Signaling protocol for flexible
  multi-party communication
• Service creation model
• Clearing House for resource reservation
• 1300 - 1500 Design of the ICEBERG components
  and capabilities
• Automatic Path Creation service
• Naming service
• Preference Registry and Preference
  Manager
• Personal Activity Coordinator
• Universal Inbox for personal mobility
  and service mobility

2
Choices for Service Integration

• ICEBERGs goal Potentially Any Network Service
• It should be easy to introduce communication
  services
• Hybrid services spanning heterogeneous networks
  are crucial
• Introduction and integration of novel services
  should be possible in shorter time-scales
• What are the options?
• Integration based on IP-technology
• Use SS7 network and components for functionality
• IN-based approach

3
IN-based Integration Advantages

• Global network, scalable
• Engineered well for 2-way voice communication
• Highly robust
• Replication of components for fall-back
• Pervasive monitoring infrastructure
• Connection-oriented approach suited for
  applications requiring Quality of Service
• Trunk allocation part of call-setup

4
IN-based Integration Disadvantages

• Closed model of operation
• High cost of entry
• Little opportunity for innovation
• Intelligence in the network
• Inflexible for introducing new services
• Large, sophisticated components
• Incremental scaling is a problem
• Connection-oriented approach
• Not suited for packet-oriented applications

5
Internet-based Integration Advantages

• Open service model
• Intelligence at the edges, simple network
• Rapid development and deployment of services
• Example web-based services Napster, Gnutella
• Well-developed client-proxy-server model
• Good for addressing heterogeneity
• Components can be incrementally provisioned and
  scaled
• Computational resources are cheap
• General-purpose PCs can be used for implementing
  functionality
• Example IP-PAD in our GSM testbed replaces
  costly ZAK/TRAU

6
Internet-based Integration Challenges Addressed
by ICEBERG

• Scaling services to a large user-base and to the
  wide-area
• Leverage cluster-computing platforms Ninja
• Robustness and fault-tolerance issues
• Soft-state model
• Resource provisioning for Quality of Service
• Clearing House architecture