1. Design Decisions / Lessons Learned Monday 21 August 2000 10:15 - 10:35 Top-level design decisions Rationale for IP-based approach Why an infrastructure based approach? Leveraging cluster-computing environments: Ninja vSpace 10:35 - 12:00 Design of the ICEBERG components and capabilities Signaling protocol for flexible multi-party communication Service creation model Clearing House for resource reservation 13:00 - 15:00 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. Naming Service: Outline Aug 21 2000, Monday –Naming service functionality Aug 22 2000, Tuesday –Details of implementation

3. Naming Service User has different identities associated with different devices and services Naming service helps map between these identities Unique-ID assigned for ICEBERG user Communication devicesCommunication services Users

4. OfficePSTN: 510-644-4545 FaxPSTN: 510-644-5454 DeskIP: rover.cs.berkeley.edu:555 LaptopIP: fido.cs.berkeley.edu:555 PCS: 510-555-6677 E-mail: adj@cs.berkeley.edu Home: 510-555-1212 OfficePSTN: 510-644-4545 FaxPSTN: 510-644-5454 DeskIP: rover.cs.berkeley.edu:555 LaptopIP: fido.cs.berkeley.edu:555 PCS: 510-555-6677 E-mail: adj@cs.berkeley.edu Home: 510-555-1212 “Anthony@Berkeley” An Entity has an ICEBERG unique-id; Entities are people or processes Universal Names: Globally unique IDs Entity’s set of domain-specific names ICEBERG Unique-ID

5. ICEBERG Unique-ID (Continued) Identifies a user in ICEBERG –To map between different device and service identities Chosen format: e-mail id –Example: bhaskar@cs.berkeley.edu

6. Name Mapping Domain/Service-specific Ids –Example: cell-phone number, pager number, ICQ number Name Mapping: –Given a service-specific-id, return the user’s unique-id Allows use of any number or device identity of callee by caller when calling +1-510-642-8284 1234321 128.32.33.78 bhaskar@cs.berkeley.edu Desktop: 128.32.33.78 Name Mapping Preference Registry Lookup

7. Name Lookup Naming service also is used to lookup information based on the unique-id Given a user’s unique-id, the Naming Service can give the location of the user’s iPOP (ICEBERG Point of Presence) Naming service acts as a level of indirection for getting at information about a user

8. Role in Call/Session Setup Alice calls Bob; In step 2, the Naming Service gives Bob’s unique-id, and gives the location of his iPOP GSM Network Cell-Phone (Alice) PSTN Network Telephone (Bob) Internet-Core APC Service Naming Service Bob’s Preference Registry IAP1 CA1 IAP2 CA2 1 2 3 4 5 6 7 8 9 2

9. Name Space Naming service needs to be distributed To scale, we use a hierarchical name-space Service-specific ids may already have a hierarchical structure –Example: cell-phone number, POTS number Unique-id also structured hierarchically Like with the Domain Name System, system can scale and parts of the name-space can be administered independently

10. Name Space (Continued) Name trees corresponding to service-specific-ids are combined in a single logical tree

11. Implementation In ICEBERG v0: –LDAP server with modified schema –No distribution mechanisms yet Tagged-tree schema of LDAP suited our requirements well