draft-ietf-p2psip-concepts-03.txt   draft-ietf-p2psip-concepts-04.txt 
P2PSIP Working Group D. Bryan P2PSIP Working Group D. Bryan
Internet-Draft Cogent Force, LLC Internet-Draft Polycom, Inc.
Intended status: Informational P. Matthews Intended status: Informational P. Matthews
Expires: April 28, 2011 Alcatel-Lucent Expires: May 3, 2012 Alcatel-Lucent
E. Shim E. Shim
Avaya, Inc. Avaya, Inc.
D. Willis D. Willis
Softarmor Systems Softarmor Systems
S. Dawkins S. Dawkins
Huawei (USA) Huawei (USA)
October 25, 2010 October 31, 2011
Concepts and Terminology for Peer to Peer SIP Concepts and Terminology for Peer to Peer SIP
draft-ietf-p2psip-concepts-03 draft-ietf-p2psip-concepts-04
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 mechansims 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
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 April 28, 2011. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 5, line 24 skipping to change at page 5, line 24
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.
A P2PSIP Overlay consists of one or more nodes called Peers. The A P2PSIP Overlay consists of one or more nodes called Peers. The
peers in the overlay collectively run a distributed database nodes in the overlay collectively run a distributed database
algorithm. This distributed database algorithm allows data to be algorithm. This distributed database algorithm allows data to be
stored on peers and retrieved in an efficient manner. It may also stored on nodes and retrieved in an efficient manner. It may also
ensure that a copy of a data item is stored on more than one peer, so ensure that a copy of a data item is stored on more than one node, so
that the loss of a peer does not result in the loss of the data item that the loss of a node does not result in the loss of the data item
to the overlay. to the overlay.
One use of this distributed database is to store the information One use of this distributed database is to store the information
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
skipping to change at page 7, line 29 skipping to change at page 7, line 29
not pursued as a general solution for a number of reasons related to not pursued as a general solution for a number of reasons related to
scalability, the ability to work in a disconnected state, partition scalability, the ability to work in a disconnected state, partition
recovery, and so on. However, there does seem to be some continuing recovery, and so on. However, there does seem to be some continuing
interest in the possibility of using DNS-SD and mDNS for interest in the possibility of using DNS-SD and mDNS for
bootstrapping of P2PSIP overlays. bootstrapping of P2PSIP overlays.
3.6. NAT Issues 3.6. NAT Issues
Network Address Translators (NATs) are impediments to establishing Network Address Translators (NATs) are impediments to establishing
and maintaining peer-to-peer networks, since NATs hinder direct and maintaining peer-to-peer networks, since NATs hinder direct
communication between peers. Some peer-to-peer network architectures communication between nodes. Some peer-to-peer network architectures
avoid this problem by insisting that all peers exist in the same avoid this problem by insisting that all nodes exist in the same
address space. However, RELOAD provides capabilities that allow address space. However, RELOAD provides capabilities that allow
peers to be located in multiple address spaces interconnected by nodes to be located in multiple address spaces interconnected by
NATs, to allow RELOAD messages to traverse NATs, and to assist in NATs, to allow RELOAD messages to traverse NATs, and to assist in
transmitting application-level messages (for example SIP messages) transmitting application-level messages (for example SIP messages)
across NATs. across NATs.
4. Reference Model 4. Reference Model
The following diagram shows a P2PSIP Overlay consisting of a number The following diagram shows a P2PSIP Overlay consisting of a number
of Peers, one Client, and an ordinary SIP UA. It illustrates a of Peers, one Client, and an ordinary SIP UA. It illustrates a
typical P2PSIP overlay but does not limit other compositions or typical P2PSIP overlay but does not limit other compositions or
variations; for example, Proxy Peer P might also talk to a ordinary variations; for example, Proxy Peer P might also talk to a ordinary
skipping to change at page 11, line 7 skipping to change at page 11, line 7
Peer: A node participating in a P2PSIP Overlay that provides storage Peer: A node participating in a P2PSIP Overlay that provides storage
and transport services to other nodes in that P2PSIP Overlay. and transport services to other nodes in that P2PSIP Overlay.
Each Peer has a unique identifier, known as a Peer-ID, within the Each Peer has a unique identifier, known as a Peer-ID, within the
Overlay. Each Peer may be coupled to one or more SIP entities. Overlay. Each Peer may be coupled to one or more SIP entities.
Within the Overlay, the peer is capable of performing several Within the Overlay, the peer is capable of performing several
different operations, including: joining and leaving the overlay, different operations, including: joining and leaving the overlay,
transporting SIP messages within the overlay, storing information transporting SIP messages within the overlay, storing information
on behalf of the overlay, putting information into the overlay, on behalf of the overlay, putting information into the overlay,
and getting information from the overlay. and getting information from the overlay.
Peer-ID: Information that uniquely identifies each Peer within a Node-ID: Information that uniquely identifies each Node within a
given Overlay. This value is not human-friendly -- in a DHT given Overlay. This value is not human-friendly -- in a DHT
approach, this is a numeric value in the hash space. These Peer- approach, this is a numeric value in the hash space. These Node-
IDs are completely independent of the identifier of any user of a IDs are completely independent of the identifier of any user of a
user agent associated with a peer. (Note: This is often called a user agent associated with a peer.
"Node-ID" in the P2P literature).
Client: A node participating in a P2PSIP Overlay but that does not Client: A node participating in a P2PSIP Overlay but that does not
store information or forward messages. A client can also be store information or forward messages. A client can also be
thought of as a peer that has not joined the overlay thought of as a peer that has not joined the overlay. Clients can
store and retrieve information from the overlay.
User Name: A human-friendly name for a user. This name must be User Name: A human-friendly name for a user. This name must be
unique within the overlay, but may be unique in a wider scope. unique within the overlay, but may be unique in a wider scope.
User Names are formatted so that they can be used within a URI User Names are formatted so that they can be used within a URI
(likely a SIP URI), perhaps in combination with the Overlay Name. (likely a SIP URI), perhaps in combination with the Overlay Name.
Service: A capability contributed by a peer to an overlay or to the Service: A capability contributed by a peer to an overlay or to the
members of an overlay. Not all peers and clients will offer the members of an overlay. Not all peers and clients will offer the
same set of services, and P2PSIP provides service discovery same set of services, and P2PSIP provides service discovery
mechanisms to locate services. mechanisms to locate services.
skipping to change at page 15, line 44 skipping to change at page 15, line 44
algorithms, then the maximum number of hops between any two peers is algorithms, then the maximum number of hops between any two peers is
log N, where N is the number of peers in the overlay. Existing log N, where N is the number of peers in the overlay. Existing
connections, along with the ICE NAT traversal techniques [RFC5245], connections, along with the ICE NAT traversal techniques [RFC5245],
are used to establish new connections between peers, and also to are used to establish new connections between peers, and also to
allow the applications running on peers to establish a connection to allow the applications running on peers to establish a connection to
communicate with one another. communicate with one another.
6.4. Locating and Joining an Overlay 6.4. Locating and Joining an Overlay
Before a peer can attempt to join a P2PSIP overlay, it must first Before a peer can attempt to join a P2PSIP overlay, it must first
obtain a Peer-ID, configuration information, and optionally a set of obtain a Node-ID, configuration information, and optionally a set of
credentials. The Peer-ID is an identifier that will uniquely credentials. The Node-ID is an identifier that will uniquely
identify the peer within the overlay, while the credentials show that identify the peer within the overlay, while the credentials show that
the peer is allowed to join the overlay. the peer is allowed to join the overlay.
The P2PSIP WG does not impose a particular mechanism for how the The P2PSIP WG does not impose a particular mechanism for how the
peer-ID and the credentials are obtained, but the RELOAD base draft peer-ID and the credentials are obtained, but the RELOAD base draft
does specify the format for the configuration information, and does specify the format for the configuration information, and
specifies how this information may be obtained, along with specifies how this information may be obtained, along with
credentials and a Peer-ID, from an offline enrollment server. credentials and a Node-ID, from an offline enrollment server.
Once the configuration information is obtained, the RELOAD base draft Once the configuration information is obtained, the RELOAD base draft
specifies a mechanism whereby a peer may obtain a multicast-bootstrap specifies a mechanism whereby a peer may obtain a multicast-bootstrap
address in the configuration file, and can broadcast to this address address in the configuration file, and can broadcast to this address
to attempt to locate a bootstrap peer. Additionally, the peer may to attempt to locate a bootstrap peer. Additionally, the peer may
store previous peers it has seen and attempt to use these as store previous peers it has seen and attempt to use these as
bootstrap peers, or may obtain an address for a bootstrap peer by bootstrap peers, or may obtain an address for a bootstrap peer by
some other mechanism. For more information, see the RELOAD base some other mechanism. For more information, see the RELOAD base
draft. draft.
skipping to change at page 18, line 8 skipping to change at page 18, line 8
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-11 (work in Base Protocol", draft-ietf-p2psip-base-18 (work in
progress), October 2010. progress), August 2011.
[I-D.ietf-p2psip-diagnostics] [I-D.ietf-p2psip-diagnostics]
Yongchao, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP Haibin, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP
Overlay Diagnostics", draft-ietf-p2psip-diagnostics-04 Overlay Diagnostics", draft-ietf-p2psip-diagnostics-06
(work in progress), July 2010. (work in progress), August 2011.
[I-D.ietf-p2psip-self-tuning] [I-D.ietf-p2psip-self-tuning]
Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self- Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self-
tuning Distributed Hash Table (DHT) for REsource LOcation tuning Distributed Hash Table (DHT) for REsource LOcation
And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-02 And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-04
(work in progress), July 2010. (work in progress), July 2011.
[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-01 (work in progress), draft-ietf-p2psip-service-discovery-03 (work in progress),
July 2010. July 2011.
[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., and
H. Schulzrinne, "A SIP Usage for RELOAD", H. Schulzrinne, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-05 (work in progress), July 2010. draft-ietf-p2psip-sip-06 (work in progress), July 2011.
[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 17
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
Cogent Force, LLC Polycom, Inc.
Williamsburg, Virginia San Jose, California
USA USA
Phone: +1 571 314 0256 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
 End of changes. 23 change blocks. 
34 lines changed or deleted 34 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/