Post on 19-Dec-2015
Touring ICEBERG-- An Overview and Tutorial
Helen J. Wang
http://iceberg.cs.berkeley.edu/
January 10, 2000
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
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
PSTN GSM PagerAccess Network
Plane
ICEBERG Network
Plane
ISP Plane
A
B
IAP IAP
ISP1 ISP2 ISP3
IAP
SF iPOP
NY iPOP
NY iPOP
SF iPOP PRCA
PACAPCNMSClearing House
ICEBERG Architecture: An Overview
IAP IAP IAP
iPOP on Ninja Base
• Scalability, 24x7 availability, fault tolerance, cost effective -> 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
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
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
An Illustration
Alice Bob
Carol
IAP
8 9
IAP 1516
iPOP
Call Agent
3
PR NMS
iPOP
Call Agent
5
PR NMS
iPOP
Call Agent
13
1. Call Bob
24
67
10
11
12
14
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
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
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
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 -> 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
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
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/modification
Call Session Mtce/Ctl, Cont.iPOP
Call Agent
APC
Call state
iPOP
APC
Call state
iPOP
Call Agent
APC
Call state
Call Session
Call AgentAnnounce
Listen
Announce
Announce
Listen
Listen
IAP
IAP
IAP
Stateful call request
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
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
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
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
An Idea on Wide-area Path with the ICEBERG Perspective
• Reduce the difficulty of wide area path by:– one owner per path -> 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
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
Service Creation in ICEBERG
• Facilitators for service creation in ICEBERG:– ICEBERG signaling protocol primitives– ICEBERG components such as PR, PAC – The APC’s flexible composition of
computation units.
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.
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.
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
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 -> only reply needs authentication
In/outdoorCoverage
In/outdoorCoverageIndoor Coverage
The ICEBERG Testbed
ICEBERG
IAPIAP
IAP
H.323 Gateway
PSTNPSTN
1900 MHz GSM Cellular Base Station
Outdoor Coverage
1800 MHz GSM Cellular Base Station
Data Converter
ControllerPaging BS
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
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
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
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