peer to peer sip n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Peer-to-Peer SIP PowerPoint Presentation
Download Presentation
Peer-to-Peer SIP

Loading in 2 Seconds...

play fullscreen
1 / 45

Peer-to-Peer SIP - PowerPoint PPT Presentation


  • 463 Views
  • Uploaded on

Peer-to-Peer SIP. David Bryan July 27, 2005. p2psip.org. Affiliation(s). Overview. Motivation What is Peer-to-Peer? Why P2P SIP? P2P basics Approaches to P2P SIP P2P SIP/SOSIMPLE Problems, barriers, and future work. What is Peer-to-Peer?. Peer-to-Peer (P2P) technology

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Peer-to-Peer SIP


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
peer to peer sip

Peer-to-Peer SIP

David Bryan

July 27, 2005

overview
Overview
  • Motivation
  • What is Peer-to-Peer?
  • Why P2P SIP?
  • P2P basics
  • Approaches to P2P SIP
  • P2P SIP/SOSIMPLE
  • Problems, barriers, and future work
what is peer to peer
What is Peer-to-Peer?
  • Peer-to-Peer (P2P) technology
    • Fundamentally different than client server
    • Nodes cooperate to provide (collectively) the functionality a central server would provide
    • Not all nodes provide all services/know everything, but as a group they do
what is peer to peer1
What is Peer-to-Peer?

Client Server:









what is peer to peer2
What is Peer-to-Peer?

Peer-to-Peer









motivating cases
Motivating Cases
  • Small deployments
    • Security
    • Lack of resource
  • Limited/No Internet connectivity
  • Ad-Hoc and ephemeral groups
  • Censorship or impeded access
  • Large scale decentralized communications
    • Skype (sort of)
why p2p
Why P2P?
  • Infrastructure independence
    • No central servers
    • Don’t need connectivity
  • Simple discovery and setup
  • Privacy
  • Highly scalable
  • Lack of central control
  • Dynamic DNS doesn’t offer all of this
why sip
Why SIP?
  • Widely established protocol
    • Standards based
    • Compatibility with existing equipment
    • Reuse existing software components
    • Many problems already solved
  • SIP is already “mostly” P2P
    • SIP vs. H.323
  • Support for both IM and VoIP
    • SIP/SIMPLE vs. XMPP
related work
Related Work
  • Skype
    • Not as P2P as they imply, non-standard
  • EarthLink’s SIP Share
    • Use SIP messages to encode filesharing DHT
  • Others in this area
    • Kundan Singh/Henning Schulzrinne at Columbia University
p2p basics
P2P Basics
  • Most famous use of P2P is file sharing
  • Most famous infamous use of P2P is file sharing
    • Each user stores some number of files on the network, ask peers for the file
  • Can also share other resources or services, no need to be files
  • Connected to each other in a logical network called an overlay
overlay network
Overlay Network
  • Collection of nodes, connected logically in some way
  • The connections in the overlay are frequently not related to those in the physical network
flooding w ttl
Flooding w/TTL

Node broadcasts to neighbors

Node(s) respond directly

TTL = 1

TTL = 2

TTL = 3

problems w flood
Problems w/Flood
  • Inefficient!
    • Lots of network traffic
    • Multiple nodes respond (can be good or bad)
  • No guarantee of completion – some outside of TTL “horizon”
  • Nodes working on behalf of others
    • DOS risk, but doubles traffic otherwise
  • Gnutella was a flood based design
structured p2p
Structured P2P
  • Basic idea is that what you are looking for has an identifier
    • Locate items in the overlay based on the identifier
    • Distributed Hash Table (DHT), Content Addressable Networks (CAN)
    • Since “everything has its place”, eliminate false negatives
    • Since you can go (close to) directly to the item you want, more efficient
distributed hash tables
Distributed Hash Tables
  • Every resource has a keyword, hashed to produce a Resource ID, or key
  • Every node participating hashes a unique property (IP address) to produce a Node ID
  • The resource itself, or information about how to find it, for a particular Resource ID is stored at a node with a similar Node ID
chord
Chord
  • Algorithm/Implementation for a DHT in a circular namespace
    • 0 and max ID are neighbors
  • A resource w/key k is stored by the first node with Node ID ≥ k
    • This node is called the successor node of key k
example chord ring
Example namespace is 0-31

Wraps at 0/31

Values increase clockwise

Sometimes called an identifier circle

Example Chord Ring

0

31

1

2

3

4

5

6

7

15

example chord ring1
Example Chord Ring

Node A

Node-ID 2

Item A, key = 5

Stores:

Item C,

key = 30

Node D

Node-ID 29

Item B, key = 18

Item C, key = 30

Node C

Node-ID 18

Stores:

Item B, key = 18

Node B

Node-ID 13

Stores:

Item A, key = 5

IDs/key namespace is 0-31

finger tables
Finger Tables
  • Each node keeps n “fingers” spaced around the ring to route messages (where address space is 2n)
    • Fingers point 1, 2, 4, …2n-1 away from the node the ring, so nodes know more about neighbors than distant nodes
  • Most distant finger is ½ the distance across the identifier ring, so all fingers are in the node’s “half”
  • If no node at the exact value the finger should point to, points to the next actual node
example finger table
Example Finger Table
  • Namespace 0-31 is size 25, so 5 fingers
  • Node is 3, so fingers are:

0

31

1

2

3

4

5

6

7

15

example finger table1
Example Finger Table
  • Namespace 0-31 is size 25, so 5 fingers
  • Node is 3, so fingers are:

3

4

5

7

19

11

example finger table2
Example Finger Table
  • If only nodes 3, 6, 11 are in the overlay:

3

6

11

routing in chord
Routing in Chord
  • Chord routes by sending messages to some node nearer the desired resource
  • The nearer node sends to an even closer node on behalf of sender
  • Process repeats until a node receiving the message knows its successor controls that space
    • Returns address of successor, sender and responsible node then exchange data
applying this to sip
Applying this to SIP
  • Use pure DHT to find the other UAs
    • Could leverage standards for DHT, but there aren’t any
    • Some firewalls block DHT traffic as “file sharing”
  • Use DHT for location, but implemented as SIP messages
    • Essentially, use DHT as another registration/location mechanism
    • Requires some “tweaks” to Chord
  • Use standard SIP to signal once resources are located
sosimple
SOSIMPLE
  • Protocol suggested by myself and Cullen Jennings of Cisco
    • Available as IETF Internet-Draft
  • Implemented and being studied at William & Mary
  • Implements a Chord-like DHT using SIP
    • All traffic is SIP messages
    • Very similar to Chord, only slight changes
node vs user operations
Node vs. User Operations
  • Operations can be either Node operations, or User operations
    • Node operations are DHT related – a node joining, a node leaving, a node updating its finger table
    • Use REGISTER for much of this
  • User operations are completely separate
    • More traditional SIP registration here
    • Registration is stored by Resource ID of hashed username
  • A user’s node has a Node ID, but their User ID, and thus registration, will be stored at a different node
  • Once a user’s node joins, only means the node is in the DHT. Still need to do a user registration to make calls
node joining
Node Joining

Joining Node

Node-ID 503

1. REGISTER

Bootstrap Node

Node-ID 023

302 Node B

2. REGISTER

Node B

Node-ID 245

302 Node C

3. REGISTER

Differences from Chord: node answers for itself – doesn’t return successor that controls, iterative vs. recursive

200 OK

Node C

Node-ID 520

4. Joining node after join

Node-ID 503

user registration

302 Node B

  • REGISTER
  • Alice

Alice (User ID 234)

2. REGISTER

Alice

200 OK

User Registration

Node A

Node-ID 023

Node B

Node-ID 245

Stores:

Alice’s Registration

Node C

Node-ID 520

Alice’s Node

Node-ID 503

session establishment
Session Establishment

Alice hashes Bob and gets 011

Alice searches for a registration

with User ID 011, sends invite

to Node A (023)

Node A

Node-ID 023

Bob-> Bob’s Node

Bob’s Node

Node-ID 683

  • INVITE
  • Bob

Alice (User ID 234)

Node B

Node-ID 245

Bob (User ID 011)

Node C

Node-ID 520

Alice-> Alice’s Node

Alice’s Node

Node-ID 503

session establishment1
Session Establishment

Node A stores a registration for

Bob (User ID 011) and returns

Bob’s Node as a contact in a 302

Node A

Node-ID 023

Bob-> Bob’s Node

Bob’s Node

Node-ID 683

  • INVITE
  • Bob

Alice (User ID 234)

302

Contact:

Bob’s Node

Node B

Node-ID 245

Bob (User ID 011)

Node C

Node-ID 520

Alice-> Alice’s Node

Alice’s Node

Node-ID 503

session establishment2
Session Establishment

Alice’s UA now invites Bob’s UA

Call set up proceeds as normal

Node A

Node-ID 023

Bob-> Bob’s Node

Bob’s Node

Node-ID 683

Alice (User ID 234)

2. INVITE

Bob

Node B

Node-ID 245

Bob (User ID 011)

100, 180, 200

Node C

Node-ID 520

Alice-> Alice’s Node

Alice’s Node

Node-ID 503

session establishment3
Session Establishment

Node A

Node-ID 023

Bob-> Bob’s Node

Bob’s Node

Node-ID 683

Media and further signaling flow directly between UAs

Alice (User ID 234)

Node B

Node-ID 245

Bob (User ID 011)

Node C

Node-ID 520

Alice-> Alice’s Node

Alice’s Node

Node-ID 503

presence buddies
Presence/Buddies
  • Subscribe/Notify used for presence
  • Subscribe to all available buddies at startup and periodically
  • Serve as additional finger table entries
encoding p2p in sip
Encoding P2P in SIP
  • SIP URI parameters
    • alg : (defined in draft-ietf-sip-identity) to convey hash algorithm used
    • user=node : used when messages are about node operations, rather than user
    • resourceID : used on user messages to indicate what a resource hashes to
    • overlay-name : indicates name of the particular overlay (can be more than 1)
encoding p2p in sip1
Encoding P2P in SIP
  • New headers
    • DHT-NodeID : defines sending node’s node ID
    • DHT-Link : used by nodes to exchange information about fingers, successors, predecessors
encoding p2p in sip2
Encoding P2P in SIP

Register for a node first joining the overlay:

REGISTER sip:10.7.7.1 SIP/2.0

To: sip:4737a8fe3d@10.4.2.2;user=node;alg=rsa-sha1;overlay=chat

From: sip:4737a8fe3d@10.4.2.2;user=node;alg=rsa-sha1;overlay=chat

Contact: sip:4737a8fe3d@10.4.2.2;user=node;alg=rsa-sha1;overlay=chat

Expires: 600

DHT-NodeID: rsa-sha1 4737a8fe3d 10.4.2.2

Require: dht

Supported: dht

encoding p2p in sip3
Encoding P2P in SIP

Response from accepting node:

SIP/2.0 200 OK

To: sip:4737a8fe3d@10.4.2.2;user=node;alg=rsa-sha1;overlay=chat

From: sip:4737a8fe3d@10.4.2.2;user=node;alg=rsa-sha1;overlay=chat

Contact: sip:4737a8fe3d@10.4.2.2;user=node;alg=rsa-sha1;overlay=chat

Expires: 600

DHT-NodeID: rsa-sha1 34f2a82eee 10.7.7.1

DHT-Link: P 1 rsa-sha1 312a18dd12 10.8.7.5

DHT-Link: S 1 rsa-sha1 3863a23ad1 10.11.22.233

DHT-Link: F 2 rsa-sha1 459a1211df 10.101.0.45

DHT-Link: F 3 rsa-sha1 a61bd8c100 10.210.78.101

Supported: dht

Require: dht

encoding p2p in sip4
Encoding P2P in SIP

User Registration:

REGISTER sip:10.5.22.112 SIP/2.0

To: sip:alice@10.4.2.2; alg=rsa-sha1;overlay=chat;resource-ID=51a6f9098d

From: sip:alice@10.4.2.2;alg=rsa-sha1;overlay=chat;resource-ID=51a6f9098d

Contact: sip:alice@10.4.2.2;alg=rsa-sha1;overlay=chat;resource-ID=51a6f9098d

Expires: 600

DHT-NodeID: rsa-sha1 4737a8fe3d 10.4.2.2

Require: dht

Supported: dht

problems with p2p sip
Problems with P2P SIP
  • Like most things SIP, NATs
    • Same problems, plus some new ones
    • Super nodes?
  • Security
    • Sybil attacks
    • DOS (through traffic and true denial)
    • Encryption
    • Information “leakage”
    • Choosing node locations to divert/block
future work
Future Work
  • Improved Security
  • Adding features
    • Configuration information, VM storage
  • Using overlay for voice traffic as well
  • Alternate methods for routing
  • Comparing different P2P approaches
references
References
  • draft-bryan-sipping-p2p-01
  • D. A. Bryan, B. B. Lowekamp and C. Jennings, SOSIMPLE: Towards a Serverless, Standards-based, P2P Communication System, AAA-IDEA, June 2005
  • Stoica et al., Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications, IEEE/ACM Transactions on Networking (to appear)
    • (Don’t use the algorithms from SIGCOMM paper by same authors with same title – it contains some algorithmic errors)
  • I maintain a list of references at

http://www.p2psip.org

  • Contact me via email

bryan [at] ethernot [dot] org