--- 1/draft-ietf-p2psip-concepts-04.txt 2013-07-12 20:14:24.233746293 -0700 +++ 2/draft-ietf-p2psip-concepts-05.txt 2013-07-12 20:14:24.277747426 -0700 @@ -1,32 +1,32 @@ P2PSIP Working Group D. Bryan -Internet-Draft Polycom, Inc. +Internet-Draft St. Edwards University Intended status: Informational P. Matthews -Expires: May 3, 2012 Alcatel-Lucent +Expires: January 13, 2014 Alcatel-Lucent E. Shim - Avaya, Inc. + Samsung Electronics Co., Ltd. D. Willis Softarmor Systems S. Dawkins Huawei (USA) - October 31, 2011 + July 12, 2013 Concepts and Terminology for Peer to Peer SIP - draft-ietf-p2psip-concepts-04 + draft-ietf-p2psip-concepts-05 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 mechansims may be + 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], [I-D.ietf-p2psip-sip]) defined by the working group. Status of this Memo @@ -36,24 +36,24 @@ 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 May 3, 2012. + This Internet-Draft will expire on January 13, 2014. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2013 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 @@ -68,50 +68,55 @@ the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Editor's Notes and Changes To This Version . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. High Level Description . . . . . . . . . . . . . . . . . . . . 5 + 3. High-Level Description . . . . . . . . . . . . . . . . . . . . 5 3.1. Services . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Relationship Between P2PSIP and RELOAD . . . . . . . . . . 6 3.4. Relationship Between P2PSIP and SIP . . . . . . . . . . . 6 3.5. Relationship Between P2PSIP and Other AoR Dereferencing Approaches . . . . . . . . . . . . . . . . . 7 3.6. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 7 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. The Distributed Database Function . . . . . . . . . . . . 13 6.2. Using the Distributed Database Function . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . 17 + 8. Informative References . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Editor's Notes and Changes To This Version - This version of the draft represents 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 - eselection 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 update the document to reflect the decisions made in - RELOAD upon completion. + 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. + + 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 + 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 problem is expressed as the problem of mapping an Address of Record (AoR) for a user into one or more Contact URIs [RFC3986]. The AoR is @@ -143,21 +148,21 @@ 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 +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 by which SIP messages can be transported between any two nodes in the overlay. @@ -174,30 +179,30 @@ required to provide the mapping between AoRs and Contact URIs for the distributed location function. This provides a location function within each overlay that is an alternative to the location functions described in [RFC3263]. However, the model of [RFC3263] is used between overlays. 3.1. Services The nature of peer-to-peer computing is that each peer offers services to other peers to allow the overlay to collectively provide - larger functions. In P2PSIP, peers offer storage and transport - services to allow the distributed database function and distributed - transport function to be implemented. Additionally, the RELOAD - protocol offers a simplistic discovery mechanism specific to the TURN - [RFC5766] protocol used for NAT traversal. It is expected that - individual peers may also offer other services as an enhancement to - P2PSIP functionality (for example to support voicemail) or to support - other applications beyond SIP. To support these additional services, - peers may need to store additional information in the overlay. + larger functions. In P2PSIP, peers offer both distributed storage + and distributed message routing services, allowing these functions to + be implemented across the overlay. Additionally, the RELOAD protocol + offers a simplistic discovery mechanism specific to the TURN + [RFC5766] protocol used for NAT traversal. Individual peers may also + offer other services as an enhancement to P2PSIP functionality (for + example to support voicemail) or to support other applications beyond + SIP. To support these additional services, peers may need to store + additional information in the overlay. [I-D.ietf-p2psip-service-discovery] describes the mechanism used in P2PSIP for resource discovery. 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 @@ -724,68 +729,80 @@ | | | SIP, other apps... | | ___________________| | | 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? + 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 expired)? There was some - interest in doing so in previous versions, but no conclusion was + draft-bryan-p2psip-app-scenarios-00 (now long expired)? There was + some interest in doing so in previous versions, but no conclusion was reached. 8. Informative References [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-18 (work in - progress), August 2011. + Base Protocol", draft-ietf-p2psip-base-26 (work in + progress), February 2013. [I-D.ietf-p2psip-diagnostics] - Haibin, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP - Overlay Diagnostics", draft-ietf-p2psip-diagnostics-06 - (work in progress), August 2011. + Song, H., Jiang, X., Even, R., and D. Bryan, "P2P Overlay + Diagnostics", draft-ietf-p2psip-diagnostics-11 (work in + progress), March 2013. [I-D.ietf-p2psip-self-tuning] - Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self- - tuning Distributed Hash Table (DHT) for REsource LOcation - And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-04 - (work in progress), July 2011. + Maenpaa, J. and G. Camarillo, "A Self-tuning Distributed + Hash Table (DHT) for REsource LOcation And Discovery + (RELOAD)", draft-ietf-p2psip-self-tuning-08 (work in + progress), February 2013. [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-03 (work in progress), - July 2011. + draft-ietf-p2psip-service-discovery-08 (work in progress), + February 2013. [I-D.ietf-p2psip-sip] - Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and - H. Schulzrinne, "A SIP Usage for RELOAD", - draft-ietf-p2psip-sip-06 (work in progress), July 2011. + 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. [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. @@ -806,25 +823,24 @@ 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. Authors' Addresses David A. Bryan - Polycom, Inc. - San Jose, California + St. Edwards University + Austin, Texas USA - Phone: +1 408 883 5601 Email: bryan@ethernot.org Philip Matthews Alcatel-Lucent 600 March Road Ottawa, Ontario K2K 2E6 Canada Phone: +1 613 784 3139 Email: philip_matthews@magma.ca @@ -821,28 +837,28 @@ Email: bryan@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 - Avaya, Inc. - 233 Mt. Airy Road - Basking Ridge, New Jersey 07920 - USA + 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 @@ -842,11 +858,11 @@ Plano, Texas 75075 USA Phone: +1 214 504 1987 Email: dean.willis@softarmor.com Spencer Dawkins Huawei Technologies (USA) Phone: +1 214 755 3870 - Email: spencer@wonderhamster.org + Email: spencerdawkins.ietf@gmail.com