ICEBERG: From POTS to PANS

1. ICEBERG: From POTS to PANS Anthony D. Joseph B. R. Badrinath June 11, 1998 UCB BARWAN Retreat

2. Future networks: Satellite, UAVs, Military, InfoStations 2-way Paging PSTN GSM IAP IAP IAP • Iceberg Access Points (more than H.323 gateways) • Provide policy engine • Handle routing, security IP IAP WIP IAP Iceberg Architecture

3. Outline • Potentially Any Network Services (PANS) • Some areas to study • Service Mobility as a first-class object • Naming, Authentication, and Billing • Example service • Summary

4. Potentially Any Network Services (PANS) • Goal: Cross-network services • Same-service in different networks • Service handoff between networks • Related work focused on single networks • Only PSTN-IP link is being considered • Leverage NINJA infrastructure • Service location and composition • Persistent data storage

5. Cross-Network Services • Example: Follow-Me Service • Exists in PSTN/GSM: Static mappings & poor UI • Security and billing based upon “line” • How to implement this in Iceberg? • Example: Any-to-Any Access to Services • Access any service from any I/O device • E911: Where is the caller? • Voice over IP => jitter: Bad for IVR & tones

6. Classes of services • How to deploy/extend services? • Cross-implementation of services • E911, billing, MCIOne • Mapping of existing services • Directory services: 411, DNS, HLR, VLR, HA • Voice-mail, E-mail • Totally new services • Concierge, location-dependent, best-mode routing

7. Partial List of Areas to Study for PANS • Entities - What are the endpoints? • Naming - “What’s in a name?” • Authentication - Entity to Entity auth. • Billing - Charging entities not “lines” • Routing - QoS and cost issues • Source conversion - Text-to-Speech, etc. • Network mgmt - Monitoring, provisioning • Intelligent terminals - Svcs at the terminal

8. “Anthony@Berkeley” Universal names are globally unique IDs. DeskPhone: 510-555-1212 DeskIP: rover.cs.berkeley.edu:555 LaptopIP: intruder.cs.berkeley.edu:555 PCS: 510-555-1414 E-mail: adj@cs.berkeley.edu Home: 510-555-1313 An Entity has a universal name and a profile. Entities are people or processes. A profile is a set of domain-specific names. Service Mobility as a First-Class Object • Use indirection for One-to-Many mapping

9. Iceberg Inter-Domain Naming Protocol • Naming: • Reuse network’s local naming services • Single resolution point for universal names • Routing: • Handles inter-network signaling • Users provide policies • IDNP gatekeepers provide policy engine • IDNP provides replication and consistency control

10. Call(Randy@Berkeley, Caller’s network, Interactive, CallerID certificate) Profile Policy System State weeks/months • Replicated • Information: • Real-time? • Lazy? • Epidemic? days/weeks minutes/hours IDNP Overview IAP IDNP Server IDNP Server

11. Authentication and Billing • Each network uses a different mechanism • PSTN relies on “line” • GSM uses SIM card (Carrier-carrier agreement) • Original cellular networks used personal agreements • IP uses host address, X.509, etc. • Iceberg certificates - two versions • Online verification by home network (Carrier) • Offline verification by local network (Personal/Visa)

12. Call-Forwarding Example • Callee’s can change policy and profiles from any network • Secure identification of entities • IDNP handles propagation of changes • IDNP can expose domain-specific addresses or hide them for privacy • Domain-specific information exposed to apps • Interactive? • Billing policies

13. Summer Prototyping Effort • Integration work: • GSM basestation (GSM-IP) • H.323 gateway (PSTN-IP) • Service Discovery • Cellular data transport protocols • Information dissemination • Interactive Voice Response and Control

14. Summary • Services that span multiple networks • Lots of open problems! • Related work doesn’t address multiple networks • Iceberg testbed and Ninja infrastructure will provide a good proving ground

15. ICEBERG: From POTS to PANS Anthony D. Joseph B. R. Badrinath June 11, 1998 UCB BARWAN Retreat