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
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

4
ICEBERG Unique-ID
Universal Names Globally unique IDs
Anthony_at_Berkeley
OfficePSTN 510-644-4545 FaxPSTN
510-644-5454 DeskIP rover.cs.berkeley.edu555 Lap
topIP fido.cs.berkeley.edu555 PCS
510-555-6677 E-mail adj_at_cs.berkeley.edu Home
510-555-1212
An Entity has an ICEBERG unique-id Entities are
people or processes
Entitys set of domain-specific names
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_at_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 users
  unique-id
• Allows use of any number or device identity of
  callee by caller when calling

7
Name Lookup

• Naming service also is used to lookup information
  based on the unique-id
• Given a users unique-id, the Naming Service can
  give the location of the users 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 Bobs unique-id, and gives the location of
his iPOP
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