--- 1/draft-ietf-p2psip-concepts-05.txt 2014-06-13 14:14:24.463201015 -0700 +++ 2/draft-ietf-p2psip-concepts-06.txt 2014-06-13 14:14:24.503201993 -0700 @@ -1,59 +1,59 @@ P2PSIP Working Group D. Bryan -Internet-Draft St. Edwards University +Internet-Draft Cogent Force, LLC Intended status: Informational P. Matthews -Expires: January 13, 2014 Alcatel-Lucent +Expires: December 15, 2014 Alcatel-Lucent E. Shim Samsung Electronics Co., Ltd. D. Willis Softarmor Systems S. Dawkins Huawei (USA) - July 12, 2013 + June 13, 2014 Concepts and Terminology for Peer to Peer SIP - draft-ietf-p2psip-concepts-05 + draft-ietf-p2psip-concepts-06 Abstract This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group - and the RELOAD protocol ([I-D.ietf-p2psip-base], + and the RELOAD protocol and SIP usage ([RFC6940], [I-D.ietf-p2psip-sip]) defined by the working group. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 13, 2014. + This Internet-Draft will expire on December 15, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -91,30 +91,30 @@ 6.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Locating and Joining an Overlay . . . . . . . . . . . . . 15 6.5. Clients and Connecting Unmodified SIP Devices . . . . . . 16 6.6. Architecture . . . . . . . . . . . . . . . . . . . . . . . 17 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Informative References . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Editor's Notes and Changes To This Version - This version of the draft represents a minor revision of version -04 - and is intended to restart conversation on this draft in the group, - to identify open issues, address them, and complete work on the - document. + This version of the draft represents a very minor revision of version + -05 and is intended to restart conversation on this draft in the + group, to identify open issues, address them, and complete work on + the document in light of RELOAD being issued as an RFC. Version -03 represented a substantial revision from the previous version. Until -02, this work was tracking open questions and being used to help reach consensus on a draft. With the selection of RELOAD as the protocol for this WG, the focus of the group turned to - completing the RELOAD drafts, and the WG directed the editors to + completing the RELOAD draft, and the WG directed the editors to update the document to reflect the decisions made in RELOAD upon completion. Please see Section 7 for the list of major open issues. 2. Background One of the fundamental problems in multimedia communication between Internet nodes is discovering the host at which a given user can be reached. In the Session Initiation Protocol (SIP) [RFC3261] this @@ -135,32 +135,32 @@ This document gives a high-level description of an alternative solution to this problem. In this alternative solution, the relatively fixed hierarchy of Client/Server SIP is replaced by a peer-to-peer overlay network. In this peer-to-peer overlay network, the various AoR to Contact URI mappings are not centralized at proxy/ registrar nodes but are instead distributed amongst the peers in the overlay. The details of this alternative solution are specified by the RELOAD - protocol. The RELOAD base draft [I-D.ietf-p2psip-base] defines a - mechanism to distribute using a Distributed Hash Table (DHT) and - specifies the wire protocol, security, and authentication mechanisms - needed to convey this information. This DHT protocol was designed - specifically with the purpose of enabling a distributed SIP registrar - in mind. While designing the protocol other applications were - considered, and when possible design decisions were made that allow - RELOAD to be used in other instances where a DHT is desirable, but - only when making such decisions did not add undue complexity to the - RELOAD protocol. The RELOAD sip draft [I-D.ietf-p2psip-sip] - specifies how RELOAD is used with the SIP protocol to enable a - distributed, server-less SIP solution. + protocol. The RELOAD base draft [RFC6940] defines a mechanism to + distribute using a Distributed Hash Table (DHT) and specifies the + wire protocol, security, and authentication mechanisms needed to + convey this information. This DHT protocol was designed specifically + with the purpose of enabling a distributed SIP registrar in mind. + While designing the protocol other applications were considered, and + when possible design decisions were made that allow RELOAD to be used + in other instances where a DHT is desirable, but only when making + such decisions did not add undue complexity to the RELOAD protocol. + The RELOAD sip draft [I-D.ietf-p2psip-sip] specifies how RELOAD is + used with the SIP protocol to enable a distributed, server-less SIP + solution. 3. High-Level Description A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer fashion for the purpose of enabling real-time communication using the Session Initiation Protocol (SIP). Collectively, the nodes in the overlay provide a distributed mechanism for mapping names to overlay locations. This provides for the mapping of Addresses of Record (AoRs) to Contact URIs, thereby providing the "location server" function of [RFC3261]. An Overlay also provides a transport function @@ -202,21 +202,21 @@ 3.2. Clients An overlay may or may not also include one or more nodes called clients. Clients are supported in the RELOAD protocol as peers that have not joined the overlay, and therefore do not route messages or store information. Clients access the services of the RELOAD protocol by connecting to a peer which performs operations on the behalf of the client. Note that in RELOAD there is no distinct client protocol. Instead, a client connects using the same protocol, but never joins the overlay as a peer. For more information, see - [I-D.ietf-p2psip-base]. + [RFC6940]. Note that in the context of P2PSIP, there is an additional entity that is sometimes referred to as a client. A special peer may be a member of the in the P2PSIP overlay and may present the functionality of one or all of a SIP registrar, proxy or redirect server to conventional SIP devices (SIP clients). In this way, existing, non- modified SIP clients may connect to the network. These unmodified SIP devices do not speak the RELOAD protocol, and this is a distinct concept from the notion of client discussed in the previous paragraph. @@ -396,24 +396,24 @@ P2P technology. . A P2P Network may also be called a "P2P Overlay" or "P2P Overlay Network" or "P2P Network Overlay", since its organization is not at the physical layer, but is instead "on top of" an existing Internet Protocol network. P2PSIP: A suite of communications protocols related to the Session Initiation Protocol (SIP) [RFC3261] that enable SIP to use peer- to-peer techniques for resolving the targets of SIP requests, providing SIP message transport, and providing other SIP-related - functions. At present, these protocols include - [I-D.ietf-p2psip-base], [I-D.ietf-p2psip-sip], - [I-D.ietf-p2psip-diagnostics], [I-D.ietf-p2psip-service-discovery] - and [I-D.ietf-p2psip-self-tuning]. + functions. At present, these protocols include [RFC6940], + [I-D.ietf-p2psip-sip], [I-D.ietf-p2psip-diagnostics], + [I-D.ietf-p2psip-service-discovery] and + [I-D.ietf-p2psip-self-tuning]. User: A human that interacts with the overlay through SIP UAs located on peers and clients (and perhaps other ways). The following terms are defined here only within the scope of P2PSIP. These terms may have conflicting definitions in other bodies of literature. Some earlier versions of this document prefixed each term with "P2PSIP" to clarify the term's scope. This prefixing has been eliminated from the text; however the scoping still applies. @@ -473,22 +473,21 @@ hold data about Services, and the working group may define other types. The types, usages, and formats of the records are a question for future study. Responsible Peer The Peer that is responsible for storing the Resource Record for a Resource. In the literature, the term "Root Peer" is also used for this concept. Peer Protocol: The protocol spoken between P2PSIP Overlay peers to share information and organize the P2PSIP Overlay Network. In - P2PSIP, this is implemented using the RELOAD - [I-D.ietf-p2psip-base] protocol. + P2PSIP, this is implemented using the RELOAD [RFC6940] protocol. Client Protocol: The protocol spoken between Clients and Peers. In P2PSIP and RELOAD, this is the same protocol syntactically as the Peer Protocol. The only difference is that Clients are not routing messages or routing information, and have not (or can not) insert themselves into the overlay. Peer Protocol Connection / P2PSIP Client Protocol Connection: The TLS, DTLS, TCP, UDP or other transport layer protocol connection over which the RELOAD Peer Protocol messages are transported. @@ -554,21 +553,21 @@ user and the location of the UAs that the user is using (the users SIP AoR). Full details of how this is implemented using RELOAD are provided in [I-D.ietf-p2psip-sip] Before information about a user can be stored in the overlay, a user needs a User Name. The User Name is a human-friendly identifier that uniquely identifies the user within the overlay. In RELOAD, users are issued certificates, which in the case of centrally signed certificates, identify the User Name as well as a certain number of Resource-IDs where the user may store their information. For more - information, see [I-D.ietf-p2psip-base]. + information, see [RFC6940]. The P2PSIP suite of protocols also standardizes information about how to locate services. Services represent actions that a peer (and perhaps a client) can do to benefit other peers and clients in the overlay. Information that might be stored in the resource record associated with a service might include the peers (and perhaps clients) offering the service. Service discovery for P2PSIP is defined in [I-D.ietf-p2psip-service-discovery]. Each service has a human-friendly Service Name that uniquely @@ -732,27 +731,26 @@ | | RELOAD Layer | |______|___________________| | Transport Layer | |__________________________| 7. Open Issues MAJOR OPEN ISSUE: The initial wording in the high-level description about proving AoR to contact mapping reflects a very long and contentious debate about the role of the protocol, and reflected a - pretense that this was an overlay only for P2PSIP. That is - explicitly not true in base anymore (see last paragraph of - introduction) and the language has been very much genericized in - base. Should we make this text more abstract and then use - AoR->contact mapping as an example of the (original) use? On a - related note, see the last paragraph of the Background section -- do - we want to reword this? + pretense that this was an overlay only for P2PSIP. That is not + really true in base anymore (see last paragraph of introduction) and + the language has been very much genericized in base. Should we make + this text more abstract and then use AoR->contact mapping as an + example of the (original) use? On a related note, see the last + paragraph of the Background section -- do we want to reword this? OPEN ISSUE: Should we include a section that documents previous decisions made, to preserve the historical debate and prevent past issues from being raised in the future, or simply rely on the mailing list to address these concerns? OPEN ISSUE: Should we include the use cases from draft-bryan-p2psip-app-scenarios-00 (now long expired)? There was some interest in doing so in previous versions, but no conclusion was reached. @@ -761,48 +759,41 @@ [Chord] Singh, K., Stoica, I., Morris, R., Karger, D., Kaashock, M., Dabek, F., and H. Balakrishman, "Chord: A scalable peer-to-peer lookup protocol for internet applications", IEEE/ACM Transactions on Neworking Volume 11 Issue 1, pp. 17-32, Feb. 2003. Copy available at http://pdos.csail.mit.edu/chord/papers/paper-ton.pdf - [I-D.ietf-p2psip-base] - Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and - H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) - Base Protocol", draft-ietf-p2psip-base-26 (work in - progress), February 2013. - [I-D.ietf-p2psip-diagnostics] - Song, H., Jiang, X., Even, R., and D. Bryan, "P2P Overlay - Diagnostics", draft-ietf-p2psip-diagnostics-11 (work in - progress), March 2013. + Song, H., Jiang, X., Even, R., Bryan, D., and Y. Sun, "P2P + Overlay Diagnostics", draft-ietf-p2psip-diagnostics-14 + (work in progress), February 2014. [I-D.ietf-p2psip-self-tuning] - Maenpaa, J. and G. Camarillo, "A Self-tuning Distributed + Maenpaa, J. and G. Camarillo, "Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery - (RELOAD)", draft-ietf-p2psip-self-tuning-08 (work in - progress), February 2013. + (RELOAD)", draft-ietf-p2psip-self-tuning-12 (work in + progress), June 2014. [I-D.ietf-p2psip-service-discovery] Maenpaa, J. and G. Camarillo, "Service Discovery Usage for REsource LOcation And Discovery (RELOAD)", - draft-ietf-p2psip-service-discovery-08 (work in progress), - February 2013. + draft-ietf-p2psip-service-discovery-12 (work in progress), + June 2014. [I-D.ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD", - draft-ietf-p2psip-sip-09 (work in progress), - February 2013. + draft-ietf-p2psip-sip-12 (work in progress), January 2014. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. @@ -820,45 +811,49 @@ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. + [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and + H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) + Base Protocol", RFC 6940, January 2014. + Authors' Addresses David A. Bryan - St. Edwards University - Austin, Texas + Cogent Force, LLC + Cedar Park, TX, Texas USA - Email: bryan@ethernot.org + Email: dbryan@ethernot.org Philip Matthews Alcatel-Lucent 600 March Road Ottawa, Ontario K2K 2E6 Canada Phone: +1 613 784 3139 Email: philip_matthews@magma.ca + Eunsoo Shim Samsung Electronics Co., Ltd. San 14, Nongseo-dong, Giheung-gu, Yongin-si, Gyeonggi-do, 446-712 South Korea Email: eunsooshim@gmail.com - Dean Willis Softarmor Systems 3100 Independence Pkwy #311-164 Plano, Texas 75075 USA Phone: +1 214 504 1987 Email: dean.willis@softarmor.com Spencer Dawkins