Touring ICEBERG An Overview and Tutorial

1
Touring ICEBERG-- An Overview and Tutorial

• Helen J. Wang
• http//iceberg.cs.berkeley.edu/
• January 10, 2000

2
Outline

• Design goals
• ICEBERG Architecture
• ICEBERG Signaling System
• Fault Tolerance in ICEBERG
• ICEBERG perspectives on data path creation
• Service Creation
• Security
• Our testbed
• Related Work
• Conclusions and Future Work

3
Design Goals

• Potentially Any Network Services (PANS) beyond
  just the two party telephone call service
  requires a network/device independent system
• Personal Mobility person as communication
  endpoint requires a single identity for an
  individual - iUID
• Service Mobility seamless mobility across
  different devices in the middle of a service
  session
• Easy Service Creation and Customization
• Scalability, Availability and Fault Tolerance
• Operation in the Wide Area
• Security, Authentication and Privacy

4
ICEBERG Architecture An Overview
Access Network Plane
ICEBERG Network Plane
Clearing House
ISP Plane
ISP1
ISP2
ISP3
5
iPOP on Ninja Base

• Scalability, 24x7 availability, fault tolerance,
  cost effective -gt NOW
• NOW computing platforms mask away cluster
  management problems Ninja, AS1
• Ninja highly available service initiation
• Redirector stub
• Good for long running services such as web
  servers
• AS1 fault tolerant service session
• Client heartbeat with session state
• Good for session-based services such as video
  conferencing

6
iPOP on Ninja Base, Cont.

• Long running services of ICEBERG
• Name Mapping Service, Preference Registry,
  Personal Activity Coordinator, Automatic Path
  Creation Service
• Session-based service of ICEBERG -- calls
• iPOP on Ninja Base augmented with client stateful
  heartbeat support from AS1
• iPOP ICEBERG-capable Ninja Base

7
ICEBERG Components

• ICEBERG Access Point (IAP) a gateway that
  interconnects an access network with the ICEBERG
  network, outside iPOP, has call state machine
• Call Agent (CA) call setup and control
• Name Mapping Service mapping between
  communication endpoint and the iUID
• Preference Registry stores user profile
  including service subscription, configuration,
  and customization.
• Personal Activity Coordinator (PAC) tracks
  dynamic info of a person that is of her interest
• Automatic Path Creation Service (APC)
  establishes and manipulates data flow

8
An Illustration
iPOP
iPOP
Bob
Alice
1. Call Bob
PR
NMS
PR
NMS
IAP
iPOP
Carol
IAP
9
Outline

• Design goals
• ICEBERG Architecture
• ICEBERG Signaling System
• Fault Tolerance in ICEBERG
• ICEBERG perspective on data path creation
• Service Creation
• Security
• Our testbed
• Related Work
• Conclusions and Future Work

10
ICEBERG Signaling System

• A signaling system is a collection of network
  elements (CAs) that speak a signaling protocol to
  effect call setup, routing, and control.
• Signaling protocol designed to support a basic
  call service -- primitives for additional
  services
• Traditional Basic Call Service two-party call
  with homogeneous devices
• ICEBERG Basic Call Service multi-device call,
  anyone can invite new member, invitation-based
  instead of subscription-based call participation

11
Challenges for Signaling

• Maintain accurate call membership in a highly
  dynamic call session
• centralized approach not scalable and robust
• member list in invitation approach not accurate
• Capture the complete call state
• centralized approach not scalable and robust
• must cope with component failure
• Key to a robust wide-area system

12
Our Approach

• Call session
• group communication over a shared channel among
  Call Agents rather than pair-wise communication
  between CA pairs.
• The channel offers a level of indirection hiding
  CA identity and location -gt tackles dynamic
  membership
• Call state as Soft State
• Shared group channel soft state
• Light Weight Sessions
• Signaling protocol call session establishment
  call session maintenance and control

13
Call Session Establishment

• Instantiating Call Agents to form call session.
  Pairwise communication at this stage
• Key techniques
• Idempotent, stateful, keep-alive call request
  from IAP to iPOP (AS1 style)
• State machine-aware, but soft state Call Agents
• Call Agents advance call state machines on IAPs
  through periodic install-state message until
  receiving new call request with the new state
• Idempotent and soft state inter-iPOP
  communication

14
Call Session Maintenance/ Control

• What can happen in an established call session
• user interaction with the device (e.g., hangup,
  new invitation, service handoff, put on hold )
• components may fail
• Involves altering/propagating call state (call
  party identities, devices/status, data path
  endpoint info, time)
• CAs announce and listen call state to the the
  shared group channel (group communication in this
  phase). Receiving new/modified call state at a
  Call Agent triggers data path creation/modificatio
  n

15
Call Session Mtce/Ctl, Cont.
iPOP
Call Agent
Announce
Announce
Call Session
Listen
Listen
APC
Announce
Listen
Stateful call request
IAP
IAP
IAP
16
Fault Tolerance in ICEBERG

• An iPOP detects IAP faults periodic call
  requests from the IAP. Cannot recover IAP
  faults.
• An IAP detects network partition from an iPOP
  iPOP heartbeats to the IAP
• Call Agents are kept alive by periodic IAP call
  requests
• Transient component failures or network outage
  are masked away by soft state refreshes
  prolonged failures lead to call drops and cleanup
  actions
• Ninja Base provides fault detection and recovery
  for the PR, NMS, PAC, and the APC

17
Outline

• Design goals
• ICEBERG Architecture
• ICEBERG Signaling System
• Fault Tolerance in ICEBERG
• ICEBERG perspectives on data path creation
• Service Creation
• Security
• Our testbed
• Related Work
• Conclusions and Future Work

18
A Glimpse of Data Path Creation from the ICEBERG
Perspective

• Treating the APC as a black box creates mystery
• What are the appropriate interactions with the
  path creation service?
• How are the data path maintained robustly
  throughout the call session? and how should
  clients assist this?
• Who owns a path, who gets to create a path, and
  who gets to destroy? How should this be
  synchronized

19
A Glimpse of Data Path Creation from the ICEBERG
perspective, Cont.

• The key challenge fault tolerant wide area path
• Centralized APC service, even on a Base, not fit
• cannot stand network partition from that Base
• not practical for a world of multiple ISPs
• Distributed APC service pose difficult questions
  of ownership and access control
• From ICEBERG perspective, synchronized path
  creation/manipulation not compatible with the
  ICEBERG signaling protocol

20
An Idea on Wide-area Path with the ICEBERG
Perspective

• Reduce the difficulty of wide area path by
• one owner per path -gt no synchronization
• two communicators two paths output format of
  caller path input format of callee path
• need negotiation of caller and callee on the
  intermediate data format -- a separate problem
  from the APC
• iPOP level negotiation sufficient as an iPOP can
  keep track of the data formats it can support

21
Outline

• Design goals
• ICEBERG Architecture
• ICEBERG Signaling System
• Fault Tolerance in ICEBERG
• ICEBERG perspective on data path creation
• Service Creation
• Security
• Our testbed
• Related Work
• Conclusions and Future Work

22
Service Creation in ICEBERG

• Facilitators for service creation in ICEBERG
• ICEBERG signaling protocol primitives
• ICEBERG components such as PR, PAC
• The APCs flexible composition of computation
  units.

23
Signaling Primitives Facilitate Service Creation

• Multi-device call operations are building blocks
  for services
• add a communication endpoint in the middle of a
  call
• remove a communication endpoint in the mid of a
  call
• Simplify implementation of services that require
  communication endpoint changes
• change an endpoint remove add
• Service handoff generalized call transfer,
  switch device in a call, achieved by the user
  inviting another device, then hanging up the
  first device.

24
Service Creation, Cont.

• Universal In-box (more later)
• enables the user to receive or retrieve voice
  mail, e-mail, phone-calls, fax, instant-messages,
  etc. in a unified fashion
• Ninja Jukebox service on ICEBERG endpoints
• Room Control Service
• multi-modal control of smart spaces from various
  devices.

25
Outline

• Design goals
• ICEBERG Architecture
• ICEBERG Signaling System
• Fault Tolerance in ICEBERG
• ICEBERG perspective on data path creation
• Service Creation
• Security
• Our testbed
• Related Work
• Conclusions and Future Work

26
Security, Authentication and Privacy

• Assume the existence of PKI
• asymmetric crypto to establish shared session key
• symmetric crypto for session security and privacy
• Name Mapping Service
• public info -gt only reply needs authentication

27
The ICEBERG Testbed
In/outdoor Coverage
Indoor Coverage
Controller
IAP
1900 MHz GSM Cellular Base Station
Paging BS
IAP
Data Converter
1800 MHz GSM Cellular Base Station
IAP
H.323 Gateway
Outdoor Coverage
PSTN
28
Related Work

• Intelligent Network
• separate service logic from call processing
• standardize basic call model (failed)
• Problems inter-operability among switches
  integration with mobile networks, service
  creation by network operators only
• IETF PINT, WebIN
• IN service logic in the Internet with
  non-proprietary languages
• service implementation easier, but other problems
  remain

29
Related Work, Cont.

• Hybrid Services
• Internet-core approach
• Clouds interconnected by edge routers
• TOPS directory service for name mapping,
  preference, and location tracking
• Mobile People Architecture person layer,
  personal proxy as person level router
• H.323 complex, hard to extend, non-scalable,
  limited in perference support
• SIP does not address fault tolerance, dynamic
  call session membership

30
Conclusion

• ICEBERG an Internet-core network architecture
  for integrated communications
• Islands of Ninja Bases that offer scalable,
  available, and robust services on the Bases
• Signaling protocol lightweight sessions and soft
  state approach for scalable and robust wide area
  call services
• Easy service creation through powerful
  multi-device call primitives, ICEBERG components,
  and the APC service
• The Clearing House approach for wide area QoS,
  scalable resource reservation and integrated
  billing

31
Future Work

• Operations, Administrations, and Maintenance
• Experiment with more services and generalize a
  service creation model
• Metrics for a more quantitative evaluation of
  ICEBERG architecture
• Plan to address the incremental wide area
  deployment of ICEBERG architecture