von developers conference -- july 2000 introduction to impp jonathan rosenberg chief scientist

www.dynamicsoft.comVoN Developers Conference -- July 2000Introduction to IMPP

Introduction to IMPP

Jonathan Rosenberg

Chief Scientist


Presence Today Also Known as Buddy Lists

Indicates Online/Offline Status

Largely to Enable IM

Users Subscribe to “Friends” List

When User is Online Click to send instant message Initiate voice chat (newer)

When Friends Log On/Off, Notifications are Sent

Sometimes User Status Can Be Indicated Busy, not at my desk

Subscriber

Subscriber

Subscriber

Publisher

Notify

Subscribe

Publish

Presence Server


Presence Today cont. No Standard for IM or Presence

Many Players (i.e., AOL, Yahoo and Tribal Voice) Each with Different, Non-interoperable Systems

User Experience is Reduced Metcalfe’s Law Running many different applications

IETF IMPP Group to Develop a Standard Solution

Proposals Solicited for a Complete Solution at April 2000 Meeting

A SIP Solution was Submitted Co-authors from dynamicsoft, Microsoft, Cisco and Columbia University


Role of a Presence Service Users Ask Service to Subscribe

to Some Other User - Presentity

PresenceService

Service Asks Presentity to Authorize Subscription

Subscription Acceptance Passed to Subscriber

Service Remembers Other Subscriptions

Presentity Tells Service of Change in Communications State

Service Delivers Notifications to Subscribers


Architectural Components User Agent

Represents people Sends subscriptions Receives Notifications

SUBSCRIBE

Presence Server Repository of subscriptions Repository of presence state

Proxy Servers Forwards subscription and

notification messages Authorization Namespace division Load balancing


Protocol Components Subscription

Notification

Publication

Presence Data Format

Watcher Data Format

Subscription Data Format


SUBSCRIBE Mechanism Naming and Routing

Authentication of Subscriber

Authorization from Presentity

Acceptance/Rejection/Redirection to Subscription

Opaque Subscription Document Details on filtering of notifications Description of precise event

Soft State - Periodic Refresh

Notification Address


NOTIFY Mechanism Routing

Transport of Opaque Presence Document Describes the presence state of presentity

Correlation to Subscription

Authentication of Presentity or its Server

Encryption


Publication Mechanism Want Many Possible Ways

Distributed Publishers For One Presentity Wireless Phone PDA Laptop Desktop

Authentication

Naming

Soft State

Presentity

Publisher

Publisher

Publisher


Presence Data Format Describes State of Presentity

Extensible

Nested Data

Baseline Information Set of communications means

Voice, video, IM, email

Address for each mean URL

Status for each mean Available, busy

Capabilities

<presence> <means type=“voice”> <address> sip:[email protected] </address> <status> busy </status> </means></presence>


Watcher Data Format Who is Subscribed to Someone

Functions Status of my own subscription Who is subscribed to me? Administrator maintenance

Extensible

Baseline Information Subscriber Presentity Status of subscription Notification address

<watcher> <subscriber> sip:[email protected] </subscriber> <presentity> sip:[email protected] </presentity> <status status=''active''/> <first-subscribed> Wed, 17 May 2000 01:01:52 GMT </first-subscribed> </watcher> </watcherinfo>


Subscription Data Format Purpose

Define types of events Define type of presence

information to get

Carried in SUBSCRIBE

Extensible

Baseline Information Type of status changes Type of communications means

<subscriber-info> <event-filter type=“allow” priority=“1”> <on-status status=“online”/> <on-status status=“offline”/> </event-filter> <presence-filter type=“allow” priority=“1”> <on-means means=“sip”/> </presence-filter></subscriber-info>


Session Initiation and Presence/IM Share Requirements Network Awareness of Presence State

SIP for call routing Presence for distribution to subscribers

Real Time Delivery

Forwarding to Server Responsible for a User

Scalability


Session Initiation and Presence/IM Share Requirements cont.

Security Privacy Access controls Authentication

Carriage of MIME Data

Extensibility


SIP Already Provides Publication Capability REGISTER is a Publication Message

for Locations

Allows for SIP and Other URL Types

Multiple Entities Can Publish for the Same Address

SIP Caller Preferences Extension Allows for Attributes for Locations Mobile, landline Home, business Preferences Audio,video - MIME capability

Registrar

Client

Client

Client

Registrar


SIP Extension for Presence New Entity: Presence Agent

Purely logical entity Knows presence state of user Receives SUBSCRIBE requests Generates NOTIFY requests Co-located with proxy/registrar or User Agent

Basic Operation Subscriber send SUBSCRIBE Routed to PA using normal SIP PA authorizes subscriber Acceptance contains presence state NOTIFY sent when state changes

Routed using SIP Record-Route

REGISTER

SUBSCRIBE

NOTIFY

Presence Agent +Proxy/Registrar = Presence Server

Proxy

Subscriber

Presentity


Transitioning PA from Server to Client User Agent Can Perform

Notifications UA + PA = PUA

Scalability Benefits

Subscriptions Gradually Migrate to PUA As They Are Refreshed PA role is on a subscription by

subscription basis Both presence server and PUA

can be generating notifications for same PUA, but for different subscribers

Rapid Migration Back to Presence Server If PUA Crashes

SUBSCRIBE

200 OKREGISTER

200 OKNOTIFY

200 OK

login

SUBSCRIBE SUBSCRIBE

200 OK200 OK

PA migratedfor this subscriber


Features of SIP For Presence Extension

End Users Can Perform Notifications Scalability

Presence Agent Function Can Migrate Network provides service when user is offline When user is online, subscriptions migrate to user

Offline Subscriptions Handled

Authorization from User Can Be Obtained by Presence Server


Features of SIP For Presence Extension cont.

Multiple Entities Can Generate Presence Information for One Presentity Mobile phone, PDA, laptop and desktop PC

Multiple Presence Clients Can Be Online at Once

Traditional SIP Proxies Route SUBSCRIBE and NOTIFY

Presence Data is Orthogonal


How to Achieve Scale System Load Equation

LOAD = PRESENTITIES X SUBSCRIBERS X NOTIFICATION RATE

Three Primary Mechanisms Reduce Presentity Load

Distribute namespace

Reduce Subscriber Load Distribute state

Reduce Notification Rate Push notifications to edges


Distribute Namespace Break Large Domain Into

Hierarchy of Subdomains Through Proxies

Leaf Subdomains Handle Actual Presence Service for a Small Set of Users

Minimal Involvement and Operation by Proxies Results in scale

Mimics Email

ibm.com

a.ibm.com b.ibm.com

Proxy Server

Presence Server Presence Server Presence Server Presence Server


Distribute State Subscription State Can Be

Distributed Presence server does not hold

all subscriptions

Each Domain Holds Subscriptions for All Users in Its Domain

Single Subscription from Each Domain to Presentity’s Domain

Authorization an Issue

Presence Server

Presence Server

Presence Server


Push Notification to the Edges Internet Scalability Principle

Smart end systems Stupid network

Trying to Scale Any Other Way Does Not Work RSVP Diffserv

Push Notifications to Clients Clients directly notify other clients Requires subscriptions to be known

to clients Requires failover to network if client

not available

Presence Server

Proxy Server


SIP Extension for Instant Messaging Operation of Extension

Messages carried in SIP messages New method - MESSAGE Routed to recipient using normal SIP techniques Simple extension

Features Associates an IM with an existing call Any MIME data can be sent TCP for large messages Routed by existing proxies and registrars Possible to have a different client for IM and communications


Advantages of Using SIP for Presence and IM Unifies Major Communications Services

Voice/video IM Presence

Shared Databases

Shared Proxies

Shared Servers


Advantages of Using SIP For Presence and IM Reduces Management Costs

One infrastructure instead of two One NOC instead of two One set of managers instead of two

Enables New Combined Services Combined services integrate voice, video, IM, presence, web amd email These new services will be a “killer app” for communications on

the Internet Delivery of combined services is greatly facilitated by alignment of

presence and communication signaling protocols


IMPP Proposals

Nine Separate Proposals Submitted for June 15th Deadline SIP (J. Rosenberg et. Al.), dynamicsoft, Cisco, Microsoft, Columbia U. IMXP (M. Rose, G. Klyne, D. Crocker) based on BXXP Privacy Enhanced Presence Protocol (PePP) - Fujitsu MIT Proposal (G. Hudson), MIT RSVP-PP - Real-Time Messaging Transport Protocol (A. Fanti) IMX - Architecture (not a protocol), AOL Jabber - (J. Miller), Jabber.org OneIM - (F. Mazzoldi, A. Diacakis), Network Projects, Inc. RVP - (R. Osborne et. Al.), Microsoft


IMPP Proposals cont.

IESG Completed Review of Proposals July 15

Summary of Recommendations Protocol should be compatible with SIP, allow SIP servers to be

presence servers Protocol should be able to run ontop of a BXXP Mesh Protocol should not itself be based on SIP or RVP Protocol should be based on one of the other 7 proposals

Proposal Being Debated (Heatedly) on List

Hope is to Reach Consensus by Pittsburgh IETF


Information Resource Jonathan Rosenberg

[email protected] +1 973.952.5000

von developers conference -- july 2000 introduction to impp jonathan rosenberg chief scientist

Documents

developers conference

presence server slide

impp sip

impp presence data format

busy slide

routing presence

gmt slide

impp role