1. Touring ICEBERG -- An Overview and Tutorial
Helen J. Wang
January 10, 2000
For the next hour, I will give you a tour on the ICEBERG project.
Logging,
what state should be persistent, what state is soft,
data path must be soft state as well.
data path table as a separate service.
call processing model --> interoperability is also an issue in the Internet, not
specific to IN.

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
So, why?
Nowaways, many people own many communication devices like cell phone,
pager, connected pdas, laptops. All these devices access heterogeneous networks.
Integrated use of these devices in a meanful way is very appealing, for example,
access your through your cell phone; or when you are on your cell phone,
and walking into your office, you may want to continue the conversation on
your office phone. We see Internet as a good rendevous point for heterogeneous
networks to be integrated because the Internet was designed to handle heterogeneity.
Also, what is lacking in today’s communication network, is easy, low cost,
service creation, customization and configuration. (Based on the evidence
of explosive web services and e-commerce) we believe the Internet can enable
a service infrastructure that can create, customize and configure communication
services easily
In Iceberg project, we are building a communication network and service
infrastructure that integrates telephony and data services from diverse networks.

4. ICEBERG Architecture: An Overview
Access Network
Plane
GSM
PSTN
Pager
IAP
IAP
IAP A
SF iPOP
NY iPOP
ICEBERG
Network
Plane B PR CA
PAC
APC
NMS
First, we begin with a 10, 000 feet view of the ICEBERG network
We envision a number of ICEBERG Service Provider, they provide integrated
communication services
For each ICEBERG Service Provider, there are Point of Presences at different
geographical locations.
SF iPOP
NY iPOP
Clearing House
ISP Plane
ISP1
ISP2
ISP3

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

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
Preference registry: takes the input of caller callee id, time of the day,
and the current callee behavior, and returns the desired communication endpoint.
And PAT is the entity that keeps tracks of someone’s dynamic information:
current location, current status, or more semantic behavior information like
“Alice is talking with Bob who is a VIP”.

8. An Illustration Bob Alice 3 5 4 2 7 10 6 11 8 9 12 PR NMS PR NMS IAP
iPOP
iPOP
Bob
Alice
Call
Agent 3
Call
Agent 5
1. Call Bob 4 2 7 10 6 11 8 9 12 PR
NMS PR
NMS
IAP
iPOP
Here only shows the sequence of events and interaction with various components,
precise protocol will be clarified later,
interaction with APC not shown
Carol
Call
Agent 13 16 14 15
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
must cope with component failure
Key to a robust wide-area system

12. Our Approach Call session: Call state as Soft State
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

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

15. Call Session Mtce/Ctl, Cont.
iPOP
Call
Agent
APC
Call state
iPOP
Call
Agent
Call state
Announce
Announce
Listen
Call Session
Listen
APC
Announce
Listen
Stateful
call request
iPOP
Call
Agent
APC
Call state
Each call agent periodically announces the call state they are in charge of:
the communication device of the call party it is serving, the device status,
and data path information.
Who owns a path: two call agents own a path, only one of them will create the
path; the one that leaves the call session is the one that destroys the path.
Path creation is pairwise
Later, paths may be able to be coalased.
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 -> 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 APC’s 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, , 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 -> only reply needs authentication

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

28. Related Work Intelligent Network: IETF PINT, WebIN:
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