Peer to Peer SIP

Views:
 
Category: Education
     
 

Presentation Description

Peer to Peer SIP authored by David Bryan. This presentation contains information about Peer to Peer SIP

Comments

By: braca (42 month(s) ago)

Thanks :D

By: prashant.swarnkar (42 month(s) ago)

A culturally affirming relationship is central to engaging youth; A youth's cultural style, expressions and values should drive intervention process

By: alzol (44 month(s) ago)

this is a guud one

By: aiueohaha (50 month(s) ago)

thankyouuu :))

Presentation Transcript

Peer-to-Peer SIP: 

<![CDATA[ Peer-to-Peer SIP David Bryan July 27, 2005]]>

Affiliation(s): 

<![CDATA[ Affiliation(s)]]>

Overview: 

<![CDATA[ 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?: 

<![CDATA[ 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-Peer?: 

<![CDATA[ What is Peer-to-Peer? Client Server:    ]]>

What is Peer-to-Peer?: 

<![CDATA[ What is Peer-to-Peer? Peer-to-Peer    ]]>

Motivating Cases: 

<![CDATA[ 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)]]>

Client/Server Session: 

<![CDATA[ Client/Server Session ]]>

Problem w/Remote Server: 

<![CDATA[ Problem w/Remote Server]]>

Why P2P?: 

<![CDATA[ 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]]>

P2P Session: 

<![CDATA[ P2P Session ]]>

Why SIP?: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ Flooding w/TTL TTL = 1 TTL = 2 TTL = 3 Node broadcasts to neighbors Node(s) respond directly]]>

Problems w/Flood: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ Example Chord Ring Example namespace is 0-31 Wraps at 0/31 Values increase clockwise Sometimes called an identifier circle 0 15 31 7 1 2 3 4 5 6 ]]>

Example Chord Ring: 

<![CDATA[ Example Chord Ring IDs/key namespace is 0-31 Node D Node-ID 29 Node A Node-ID 2 Node C Node-ID 18 Node B Node-ID 13 Item A, key = 5 Item B, key = 18 Item C, key = 30 Stores: Item A, key = 5 Stores: Item B, key = 18 Stores: Item C, key = 30]]>

Finger Tables: 

<![CDATA[ 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: 

<![CDATA[ Example Finger Table Namespace 0-31 is size 25, so 5 fingers Node is 3, so fingers are: 0 15 31 7 1 2 3 4 5 6 ]]>

Example Finger Table: 

<![CDATA[ Example Finger Table Namespace 0-31 is size 25, so 5 fingers Node is 3, so fingers are: 3 4 5 7 11 19]]>

Example Finger Table: 

<![CDATA[ 11 Example Finger Table If only nodes 3, 6, 11 are in the overlay: 3 6]]>

Routing in Chord: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ Node Joining Bootstrap Node Node-ID 023 Node B Node-ID 245 Joining Node Node-ID 503 1. REGISTER 302 Node B 2. REGISTER 302 Node C 3. REGISTER 200 OK 4. Joining node after join Node-ID 503 Node C Node-ID 520 Differences from Chord: node answers for itself – doesn’t return successor that controls, iterative vs. recursive]]>

User Registration: 

<![CDATA[ User Registration Node A Node-ID 023 Node B Node-ID 245 Alice’s Node Node-ID 503 Node C Node-ID 520 Stores: Alice’s Registration]]>

Session Establishment: 

<![CDATA[ Session Establishment Node A Node-ID 023 Node B Node-ID 245 Node C Node-ID 520 Alice’s Node Node-ID 503 Alice-> Alice’s Node Bob-> Bob’s Node Bob’s Node Node-ID 683 INVITE Bob Alice (User ID 234) Bob (User ID 011) Alice hashes Bob and gets 011 Alice searches for a registration with User ID 011, sends invite to Node A (023)]]>

Session Establishment: 

<![CDATA[ Session Establishment Node A Node-ID 023 Node B Node-ID 245 Node C Node-ID 520 Alice’s Node Node-ID 503 Alice-> Alice’s Node Bob-> Bob’s Node Bob’s Node Node-ID 683 INVITE Bob 302 Contact: Bob’s Node Alice (User ID 234) Bob (User ID 011) Node A stores a registration for Bob (User ID 011) and returns Bob’s Node as a contact in a 302]]>

Session Establishment: 

<![CDATA[ Session Establishment Node A Node-ID 023 Node B Node-ID 245 Node C Node-ID 520 Alice’s Node Node-ID 503 Alice-> Alice’s Node Bob-> Bob’s Node Bob’s Node Node-ID 683 Alice (User ID 234) Bob (User ID 011) Alice’s UA now invites Bob’s UA Call set up proceeds as normal 100, 180, 200 2. INVITE Bob]]>

Session Establishment: 

<![CDATA[ Session Establishment Node A Node-ID 023 Node B Node-ID 245 Node C Node-ID 520 Alice’s Node Node-ID 503 Alice-> Alice’s Node Bob-> Bob’s Node Bob’s Node Node-ID 683 Alice (User ID 234) Bob (User ID 011) Media and further signaling flow directly between UAs]]>

Presence/Buddies: 

<![CDATA[ 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: 

<![CDATA[ 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 SIP: 

<![CDATA[ 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 SIP: 

<![CDATA[ Encoding P2P in SIP 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 Register for a node first joining the overlay:]]>

Encoding P2P in SIP: 

<![CDATA[ Encoding P2P in SIP 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 Response from accepting node:]]>

Encoding P2P in SIP: 

<![CDATA[ Encoding P2P in SIP 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 User Registration:]]>

Problems with P2P SIP: 

<![CDATA[ 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: 

<![CDATA[ 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: 

<![CDATA[ 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 ]]>