draft-ietf-p2psip-concepts-04.txt   draft-ietf-p2psip-concepts-05.txt 
P2PSIP Working Group D. Bryan P2PSIP Working Group D. Bryan
Internet-Draft Polycom, Inc. Internet-Draft St. Edwards University
Intended status: Informational P. Matthews Intended status: Informational P. Matthews
Expires: May 3, 2012 Alcatel-Lucent Expires: January 13, 2014 Alcatel-Lucent
E. Shim E. Shim
Avaya, Inc. Samsung Electronics Co., Ltd.
D. Willis D. Willis
Softarmor Systems Softarmor Systems
S. Dawkins S. Dawkins
Huawei (USA) Huawei (USA)
October 31, 2011 July 12, 2013
Concepts and Terminology for Peer to Peer SIP Concepts and Terminology for Peer to Peer SIP
draft-ietf-p2psip-concepts-04 draft-ietf-p2psip-concepts-05
Abstract Abstract
This document defines concepts and terminology for the use of the This document defines concepts and terminology for the use of the
Session Initiation Protocol in a peer-to-peer environment where the Session Initiation Protocol in a peer-to-peer environment where the
traditional proxy-registrar and message routing functions are 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 implemented using a distributed hash table or other distributed data
mechanism with similar external properties. This document includes a mechanism with similar external properties. This document includes a
high-level view of the functional relationships between the network high-level view of the functional relationships between the network
elements defined herein, a conceptual model of operations, and an elements defined herein, a conceptual model of operations, and an
outline of the related problems addressed by the P2PSIP working group outline of the related problems addressed by the P2PSIP working group
and the RELOAD protocol ([I-D.ietf-p2psip-base], and the RELOAD protocol ([I-D.ietf-p2psip-base],
[I-D.ietf-p2psip-sip]) defined by the working group. [I-D.ietf-p2psip-sip]) defined by the working group.
Status of this Memo Status of this Memo
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Editor's Notes and Changes To This Version . . . . . . . . . . 4 1. Editor's Notes and Changes To This Version . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. High Level Description . . . . . . . . . . . . . . . . . . . . 5 3. High-Level Description . . . . . . . . . . . . . . . . . . . . 5
3.1. Services . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Services . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Relationship Between P2PSIP and RELOAD . . . . . . . . . . 6 3.3. Relationship Between P2PSIP and RELOAD . . . . . . . . . . 6
3.4. Relationship Between P2PSIP and SIP . . . . . . . . . . . 6 3.4. Relationship Between P2PSIP and SIP . . . . . . . . . . . 6
3.5. Relationship Between P2PSIP and Other AoR 3.5. Relationship Between P2PSIP and Other AoR
Dereferencing Approaches . . . . . . . . . . . . . . . . . 7 Dereferencing Approaches . . . . . . . . . . . . . . . . . 7
3.6. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 7 4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 7
5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. The Distributed Database Function . . . . . . . . . . . . 13 6.1. The Distributed Database Function . . . . . . . . . . . . 13
6.2. Using the Distributed Database Function . . . . . . . . . 14 6.2. Using the Distributed Database Function . . . . . . . . . 14
6.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15 6.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Locating and Joining an Overlay . . . . . . . . . . . . . 15 6.4. Locating and Joining an Overlay . . . . . . . . . . . . . 15
6.5. Clients and Connecting Unmodified SIP Devices . . . . . . 16 6.5. Clients and Connecting Unmodified SIP Devices . . . . . . 16
6.6. Architecture . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Architecture . . . . . . . . . . . . . . . . . . . . . . . 17
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Informative References . . . . . . . . . . . . . . . . . . . . 17 8. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Editor's Notes and Changes To This Version 1. Editor's Notes and Changes To This Version
This version of the draft represents a substantial revision from the This version of the draft represents a minor revision of version -04
previous version. Until -02, this work was tracking open questions and is intended to restart conversation on this draft in the group,
and being used to help reach consensus on a draft. With the to identify open issues, address them, and complete work on the
eselection of RELOAD as the protocol for this WG, the focus of the document.
group turned to completing the RELOAD drafts, and the WG directed the
editors to update the document to reflect the decisions made in Version -03 represented a substantial revision from the previous
RELOAD upon completion. 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. Please see Section 7 for the list of major open issues.
2. Background 2. Background
One of the fundamental problems in multimedia communication between One of the fundamental problems in multimedia communication between
Internet nodes is discovering the host at which a given user can be Internet nodes is discovering the host at which a given user can be
reached. In the Session Initiation Protocol (SIP) [RFC3261] this reached. In the Session Initiation Protocol (SIP) [RFC3261] this
problem is expressed as the problem of mapping an Address of Record 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 (AoR) for a user into one or more Contact URIs [RFC3986]. The AoR is
skipping to change at page 5, line 11 skipping to change at page 5, line 16
needed to convey this information. This DHT protocol was designed needed to convey this information. This DHT protocol was designed
specifically with the purpose of enabling a distributed SIP registrar specifically with the purpose of enabling a distributed SIP registrar
in mind. While designing the protocol other applications were in mind. While designing the protocol other applications were
considered, and when possible design decisions were made that allow considered, and when possible design decisions were made that allow
RELOAD to be used in other instances where a DHT is desirable, but 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 only when making such decisions did not add undue complexity to the
RELOAD protocol. The RELOAD sip draft [I-D.ietf-p2psip-sip] RELOAD protocol. The RELOAD sip draft [I-D.ietf-p2psip-sip]
specifies how RELOAD is used with the SIP protocol to enable a specifies how RELOAD is used with the SIP protocol to enable a
distributed, server-less SIP solution. 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 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 fashion for the purpose of enabling real-time communication using the
Session Initiation Protocol (SIP). Collectively, the nodes in the Session Initiation Protocol (SIP). Collectively, the nodes in the
overlay provide a distributed mechanism for mapping names to overlay overlay provide a distributed mechanism for mapping names to overlay
locations. This provides for the mapping of Addresses of Record locations. This provides for the mapping of Addresses of Record
(AoRs) to Contact URIs, thereby providing the "location server" (AoRs) to Contact URIs, thereby providing the "location server"
function of [RFC3261]. An Overlay also provides a transport function function of [RFC3261]. An Overlay also provides a transport function
by which SIP messages can be transported between any two nodes in the by which SIP messages can be transported between any two nodes in the
overlay. overlay.
skipping to change at page 5, line 42 skipping to change at page 5, line 47
required to provide the mapping between AoRs and Contact URIs for the required to provide the mapping between AoRs and Contact URIs for the
distributed location function. This provides a location function distributed location function. This provides a location function
within each overlay that is an alternative to the location functions within each overlay that is an alternative to the location functions
described in [RFC3263]. However, the model of [RFC3263] is used described in [RFC3263]. However, the model of [RFC3263] is used
between overlays. between overlays.
3.1. Services 3.1. Services
The nature of peer-to-peer computing is that each peer offers The nature of peer-to-peer computing is that each peer offers
services to other peers to allow the overlay to collectively provide services to other peers to allow the overlay to collectively provide
larger functions. In P2PSIP, peers offer storage and transport larger functions. In P2PSIP, peers offer both distributed storage
services to allow the distributed database function and distributed and distributed message routing services, allowing these functions to
transport function to be implemented. Additionally, the RELOAD be implemented across the overlay. Additionally, the RELOAD protocol
protocol offers a simplistic discovery mechanism specific to the TURN 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.
[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 [I-D.ietf-p2psip-service-discovery] describes the mechanism used in
P2PSIP for resource discovery. P2PSIP for resource discovery.
3.2. Clients 3.2. Clients
An overlay may or may not also include one or more nodes called An overlay may or may not also include one or more nodes called
clients. Clients are supported in the RELOAD protocol as peers that clients. Clients are supported in the RELOAD protocol as peers that
have not joined the overlay, and therefore do not route messages or have not joined the overlay, and therefore do not route messages or
store information. Clients access the services of the RELOAD store information. Clients access the services of the RELOAD
protocol by connecting to a peer which performs operations on the protocol by connecting to a peer which performs operations on the
skipping to change at page 17, line 29 skipping to change at page 17, line 29
| | | |
| SIP, other apps... | | SIP, other apps... |
| ___________________| | ___________________|
| | RELOAD Layer | | | RELOAD Layer |
|______|___________________| |______|___________________|
| Transport Layer | | Transport Layer |
|__________________________| |__________________________|
7. Open Issues 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 OPEN ISSUE: Should we include a section that documents previous
decisions made, to preserve the historical debate and prevent past decisions made, to preserve the historical debate and prevent past
issues from being raised in the future, or simply rely on the mailing issues from being raised in the future, or simply rely on the mailing
list to address these concerns? list to address these concerns?
OPEN ISSUE: Should we include the use cases from OPEN ISSUE: Should we include the use cases from
draft-bryan-p2psip-app-scenarios-00 (now expired)? There was some draft-bryan-p2psip-app-scenarios-00 (now long expired)? There was
interest in doing so in previous versions, but no conclusion was some interest in doing so in previous versions, but no conclusion was
reached. reached.
8. Informative References 8. Informative References
[Chord] Singh, K., Stoica, I., Morris, R., Karger, D., Kaashock, [Chord] Singh, K., Stoica, I., Morris, R., Karger, D., Kaashock,
M., Dabek, F., and H. Balakrishman, "Chord: A scalable M., Dabek, F., and H. Balakrishman, "Chord: A scalable
peer-to-peer lookup protocol for internet applications", peer-to-peer lookup protocol for internet applications",
IEEE/ACM Transactions on Neworking Volume 11 Issue 1, pp. IEEE/ACM Transactions on Neworking Volume 11 Issue 1, pp.
17-32, Feb. 2003. 17-32, Feb. 2003.
Copy available at Copy available at
http://pdos.csail.mit.edu/chord/papers/paper-ton.pdf http://pdos.csail.mit.edu/chord/papers/paper-ton.pdf
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-18 (work in Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), August 2011. progress), February 2013.
[I-D.ietf-p2psip-diagnostics] [I-D.ietf-p2psip-diagnostics]
Haibin, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP Song, H., Jiang, X., Even, R., and D. Bryan, "P2P Overlay
Overlay Diagnostics", draft-ietf-p2psip-diagnostics-06 Diagnostics", draft-ietf-p2psip-diagnostics-11 (work in
(work in progress), August 2011. progress), March 2013.
[I-D.ietf-p2psip-self-tuning] [I-D.ietf-p2psip-self-tuning]
Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self- Maenpaa, J. and G. Camarillo, "A Self-tuning Distributed
tuning Distributed Hash Table (DHT) for REsource LOcation Hash Table (DHT) for REsource LOcation And Discovery
And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-04 (RELOAD)", draft-ietf-p2psip-self-tuning-08 (work in
(work in progress), July 2011. progress), February 2013.
[I-D.ietf-p2psip-service-discovery] [I-D.ietf-p2psip-service-discovery]
Maenpaa, J. and G. Camarillo, "Service Discovery Usage for Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)", REsource LOcation And Discovery (RELOAD)",
draft-ietf-p2psip-service-discovery-03 (work in progress), draft-ietf-p2psip-service-discovery-08 (work in progress),
July 2011. February 2013.
[I-D.ietf-p2psip-sip] [I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
H. Schulzrinne, "A SIP Usage for RELOAD", Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-06 (work in progress), July 2011. draft-ietf-p2psip-sip-09 (work in progress),
February 2013.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 19, line 17 skipping to change at page 19, line 29
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
April 2010. April 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
Authors' Addresses Authors' Addresses
David A. Bryan David A. Bryan
Polycom, Inc. St. Edwards University
San Jose, California Austin, Texas
USA USA
Phone: +1 408 883 5601
Email: bryan@ethernot.org Email: bryan@ethernot.org
Philip Matthews Philip Matthews
Alcatel-Lucent Alcatel-Lucent
600 March Road 600 March Road
Ottawa, Ontario K2K 2E6 Ottawa, Ontario K2K 2E6
Canada Canada
Phone: +1 613 784 3139 Phone: +1 613 784 3139
Email: philip_matthews@magma.ca Email: philip_matthews@magma.ca
skipping to change at page 19, line 32 skipping to change at page 20, line 4
Email: bryan@ethernot.org Email: bryan@ethernot.org
Philip Matthews Philip Matthews
Alcatel-Lucent Alcatel-Lucent
600 March Road 600 March Road
Ottawa, Ontario K2K 2E6 Ottawa, Ontario K2K 2E6
Canada Canada
Phone: +1 613 784 3139 Phone: +1 613 784 3139
Email: philip_matthews@magma.ca Email: philip_matthews@magma.ca
Eunsoo Shim Eunsoo Shim
Avaya, Inc. Samsung Electronics Co., Ltd.
233 Mt. Airy Road San 14, Nongseo-dong, Giheung-gu,
Basking Ridge, New Jersey 07920 Yongin-si, Gyeonggi-do, 446-712
USA South Korea
Email: eunsooshim@gmail.com Email: eunsooshim@gmail.com
Dean Willis Dean Willis
Softarmor Systems Softarmor Systems
3100 Independence Pkwy #311-164 3100 Independence Pkwy #311-164
Plano, Texas 75075 Plano, Texas 75075
USA USA
Phone: +1 214 504 1987 Phone: +1 214 504 1987
Email: dean.willis@softarmor.com Email: dean.willis@softarmor.com
Spencer Dawkins Spencer Dawkins
skipping to change at page 20, line 17 skipping to change at page 20, line 25
Plano, Texas 75075 Plano, Texas 75075
USA USA
Phone: +1 214 504 1987 Phone: +1 214 504 1987
Email: dean.willis@softarmor.com Email: dean.willis@softarmor.com
Spencer Dawkins Spencer Dawkins
Huawei Technologies (USA) Huawei Technologies (USA)
Phone: +1 214 755 3870 Phone: +1 214 755 3870
Email: spencer@wonderhamster.org Email: spencerdawkins.ietf@gmail.com
 End of changes. 27 change blocks. 
51 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/