1 / 11

Design Decisions / Lessons Learned

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

riordan-nyhan
Download Presentation

Design Decisions / Lessons Learned

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 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. Communication devices Communication services Users 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@Berkeley” 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 An Entity has an ICEBERG unique-id; Entities are people or processes Entity’s 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@cs.berkeley.edu

  6. <Ofc Phone No> +1-510-642-8284 <Pager No> 1234321 <Unique ID> bhaskar@cs.berkeley.edu <Preferred End-Point> Desktop: 128.32.33.78 <Desktop IP Addr> 128.32.33.78 Preference Registry Lookup Name Mapping 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

  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. Naming Service Bob’s Preference Registry PSTN Network GSM Network 2 2 4 3 CA1 1 5 IAP2 IAP1 CA2 7 9 6 8 Internet-Core Cell-Phone (Alice) Telephone (Bob) APC Service 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

  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

More Related