Introduction to IMPP

1
(No Transcript)
2
Introduction to IMPP

• Jonathan Rosenberg
• Chief Scientist

3
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

4
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
• Metcalfes 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

5
Role of a Presence Service

• Users Ask Service to Subscribe to Some Other User
  - Presentity

• Service Asks Presentity to Authorize Subscription

PresenceService

• Subscription Acceptance Passed to Subscriber

• Service Remembers Other Subscriptions

• Presentity Tells Service of Change in
  Communications State

• Service Delivers Notifications to Subscribers

6
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

7
Protocol Components

• Subscription
• Notification
• Publication
• Presence Data Format
• Watcher Data Format
• Subscription Data Format

8
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

9
NOTIFY Mechanism

• Routing
• Transport of Opaque Presence Document
• Describes the presence state of presentity
• Correlation to Subscription
• Authentication of Presentity or its Server
• Encryption

10
Publication Mechanism

• Want Many Possible Ways
• Distributed Publishers For One Presentity
• Wireless Phone
• PDA
• Laptop
• Desktop
• Authentication
• Naming
• Soft State

Presentity
Publisher
Publisher
Publisher
11
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

ltpresencegt ltmeans typevoicegt ltaddressgt
sipjdrosen_at_dynamicsoft.com lt/addressgt
ltstatusgt busy lt/statusgt
lt/meansgt lt/presencegt
12
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

ltwatchergt ltsubscribergt
sipjoe_at_company.com lt/subscribergt
ltpresentitygt sipprofessor_at_university.edu
lt/presentitygt ltstatus
status''active''/gt ltfirst-subscribedgt
Wed, 17 May 2000 010152 GMT
lt/first-subscribedgt lt/watchergt
lt/watcherinfogt
13
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

ltsubscriber-infogt ltevent-filter typeallow
priority1gt lton-status statusonline/gt
lton-status statusoffline/gt
lt/event-filtergt ltpresence-filter typeallow
priority1gt lton-means meanssip/gt
lt/presence-filtergt lt/subscriber-infogt
14
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

15
Session Initiation and Presence/IM Share
Requirements cont.

• Security
• Privacy
• Access controls
• Authentication
• Carriage of MIME Data
• Extensibility

16
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

17
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

18
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 OK
REGISTER
login
NOTIFY
200 OK
200 OK
SUBSCRIBE
SUBSCRIBE
200 OK
200 OK
PA migrated for this subscriber
19
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

20
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

21
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

22
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

23
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
  Presentitys Domain
• Authorization an Issue

24
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
25
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

26
Advantages of Using SIP for Presence and IM

• Unifies Major Communications Services
• Voice/video
• IM
• Presence
• Shared Databases
• Shared Proxies
• Shared Servers

27
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

28
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

29
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

30
Information Resource

• Jonathan Rosenberg
• jdrosen_at_dynamicsoft.com
• 1 973.952.5000