P2PSIP Concepts & Terminology draft-willis-p2psip-concepts-03

1. P2PSIP Concepts & Terminologydraft-willis-p2psip-concepts-03 • David Bryan • Philip Matthews • Eunsoo Shim • Dean WillisIETF 67

2. Outline of Presentation • 1) Tutorial review of basic concepts • 2) Review of recent changes • 3) Review of open issues • Note: The names associated with many of the concepts are still under discussion, so for now, please concentrate on the concepts and don’t worry too much about the names

3. Document Goal • Define concepts and a framework within which we can discuss the design. • Mention major design choices, but be neutral on how they will be resolved. • For now, be general enough to reflect different views of what P2PSIP might be.

4. P2PSIP • A suite of communication protocols that extend SIP to use peer-to-peer techniques for looking up and reaching users and resources. vs.

5. P2PSIP Overlay • An association of P2PSIP nodes that provides: 1. User and resource registration (e.g., SIP registration) 2. Lookup of registration information 3. SIP request routing . . . and perhaps other functions using a peer-to-peer organization. • For example, if Skype used P2PSIP, then ‘skype.com’ would be a P2PSIP Overlay.

6. Two types of Overlay nodes

7. Peer/Clients + SIP entity • Both Peers and Clients may be coupled with a SIP entity. Examples: • Peer + SIP UA (= “Phone”) • Peer + SIP Proxy Server • Peer + SIP Registrar • Client + SIP UA (= another “Phone”) • Client + SIP Redirect Server • Client + Gateway

8. P2PSIP Resource (User) • An addressable user endpoint, entity, service, or function within a P2PSIP Overlay. • Examples include but are not limited to: • Humans, automata, bridges, mixers, media relays, gateways, and media storage • Has a unique identifier within the P2PSIP overlay that is presumably equivalent to an Address of Record. • Still under discussion: What, if anything, is the difference between a resource and a user? And are there multiple types of resources or users?

9. Enrollment vs Insertion • Enrollment: Gaining a user or peer ID and credentials needed to access the overlay. One-time operation • Insertion/Admission: Connecting to an overlay and adding routing information to that overlay so that the inserting node can be found. Multiple times.Equivalent to SIP “Registration” process. 1) Enroll. 2) Insert. 3) Make or take a call.

10. Peer vs. Client Protocol • Peer Protocol: Spoken between peers • Client Protocol: Spoken between a Client and a Peer • Client Protocol functionality is a subset of the Peer Protocol functionality. • > Anything a Client can do, a Peer can also do. • Client Protocol and Peer Protocol may be syntactically different. • E.g., one might be SIP-based, the other XML-based.

11. Protocol Comparison There may be additional operations not shown here.

12. Gateway Peer G UA Peer E UA Peer F P2PSIPClient Protocol UA Client C NAT Peer Q P2PSIP Overlay with peers speaking Peer protocol NAT UA Peer D Redir Peer R Proxy Peer P Reference Model SIP UA A

13. Gateway Peer G UA Peer E UA Peer F P2PSIP Client Protocol UA Client C NAT Peer Q P2PSIP Overlay with peers speaking Peer protocol NAT UA Peer D Redir Peer R Proxy Peer P Sample Message Flow SIP Invite Client calling a Peer: Client C sends a query to Peer Q for the location of User U. Messages are exchanged between peers, and User U is determined to reside on Peer F Peer Q sends response back to Client C. Client C sends SIP Invite message to Peer F.

14. Open Issues vs. Design Questions • Document contains both Open Issues and Design Questions. • Open Issues represent problems with the document that we hope to fix soon. These are internal inconsistencies. • Design Questions (section 4 of the document) represent major design choices that the WG will have to resolve.

15. Some Design Questions • Peer vs Client Protocol: Are these the same things, or not? Do we really need a Client protocol? Are either SIP? • How to find a media relay? Does it have to be network-path optimal? • How best to arrange NAT traversal? • Security: If peers are untrusted, how do we protect sensitive messages flowing through them? • Credentials. Certs from a CA? Self-signed? • Bootstrapping. How to start from zero?

16. Major changes since -00 (-00 was presented at ad-hoc in Montreal) • Removed most short-forms and alternative names. Most remaining ones changed to comparisons with concepts from general P2P literature. (-03) • Split concept of “P2PSIP Resource Identifier” into “P2PSIP Resource Name” (human-readable) and “P2PSIP Resource Identifier” (not human-readable and likely a hash value). (-02) • Added concept of P2PSIP Bootstrap Peer and reworked the text is a number of places to make the distinction clear (-03) • Noted the design possibility that the Client Protocol might be just SIP and discussed some ramifications of this choice (-02) • Added a discussion of the operations supported by the Peer protocol and the Client protocol (-03)

17. Major changes (continued) • Removed mention of "Send" operation in Client Protocol (-03), but added related Open Issue. • New reference model diagram (based on suggestion by Spencer Dawkins) which labels every node and clarifies usage of Peer protocol vs Client protocol (-02) • Added three message flow examples to illustrate expected operation (-02) • Added four new questions (-01) Credential Recovery Overlapping Domains Hybrid Domains Admissions Control

18. Major Open Issues • What, if any, is the difference between a User and a Resource? • Names for various concepts (!!) • EKR has proposed a third design model (Clients are aware of the Overlay structure). How can we accommodate this in our framework? • Need to rewrite certain sections with NATs in mind. • Does every peer support all services? If not, then need the concept of searching for a peer (or client?) that offers the service.