Introduction to IMPP - PowerPoint PPT Presentation

Loading...

PPT – Introduction to IMPP PowerPoint presentation | free to view - id: 1b0b0-YmI4M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Introduction to IMPP

Description:

Many Players (i.e., AOL, Yahoo and Tribal Voice) Each with. Different, Non-interoperable Systems ... integrate voice, video, IM, presence, web amd email ... – PowerPoint PPT presentation

Number of Views:93
Avg rating:3.0/5.0
Slides: 31
Provided by: JonathanR161
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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

Presence Service
  • 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
About PowerShow.com