--- 1/draft-ietf-p2psip-concepts-03.txt 2011-10-31 17:14:22.378755996 +0100 +++ 2/draft-ietf-p2psip-concepts-04.txt 2011-10-31 17:14:22.422754600 +0100 @@ -1,25 +1,25 @@ P2PSIP Working Group D. Bryan -Internet-Draft Cogent Force, LLC +Internet-Draft Polycom, Inc. Intended status: Informational P. Matthews -Expires: April 28, 2011 Alcatel-Lucent +Expires: May 3, 2012 Alcatel-Lucent E. Shim Avaya, Inc. D. Willis Softarmor Systems S. Dawkins Huawei (USA) - October 25, 2010 + October 31, 2011 Concepts and Terminology for Peer to Peer SIP - draft-ietf-p2psip-concepts-03 + draft-ietf-p2psip-concepts-04 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 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 @@ -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 April 28, 2011. + This Internet-Draft will expire on May 3, 2012. 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. 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 @@ -156,25 +156,25 @@ 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. 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 - stored on peers 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 - that the loss of a peer does not result in the loss of the data item + 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 node, so + that the loss of a node does not result in the loss of the data item to the overlay. One use of this distributed database is to store the information 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 @@ -257,24 +257,24 @@ not pursued as a general solution for a number of reasons related to scalability, the ability to work in a disconnected state, partition recovery, and so on. However, there does seem to be some continuing interest in the possibility of using DNS-SD and mDNS for bootstrapping of P2PSIP overlays. 3.6. NAT Issues Network Address Translators (NATs) are impediments to establishing and maintaining peer-to-peer networks, since NATs hinder direct - communication between peers. Some peer-to-peer network architectures - avoid this problem by insisting that all peers exist in the same + communication between nodes. Some peer-to-peer network architectures + avoid this problem by insisting that all nodes exist in the same 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 transmitting application-level messages (for example SIP messages) across NATs. 4. Reference Model The following diagram shows a P2PSIP Overlay consisting of a number of Peers, one Client, and an ordinary SIP UA. It illustrates a typical P2PSIP overlay but does not limit other compositions or variations; for example, Proxy Peer P might also talk to a ordinary @@ -420,30 +420,30 @@ Peer: A node participating in a P2PSIP Overlay that provides storage and transport services to other nodes in that P2PSIP Overlay. 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. Within the Overlay, the peer is capable of performing several different operations, including: joining and leaving the overlay, transporting SIP messages within the overlay, storing information on behalf of the overlay, putting information into 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 - 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 - user agent associated with a peer. (Note: This is often called a - "Node-ID" in the P2P literature). + user agent associated with a peer. Client: A node participating in a P2PSIP Overlay but that does not 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 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 (likely a SIP URI), perhaps in combination with the Overlay Name. 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 same set of services, and P2PSIP provides service discovery mechanisms to locate services. @@ -645,30 +645,30 @@ 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 connections, along with the ICE NAT traversal techniques [RFC5245], are used to establish new connections between peers, and also to allow the applications running on peers to establish a connection to communicate with one another. 6.4. Locating and Joining an Overlay Before a peer can attempt to join a P2PSIP overlay, it must first - obtain a Peer-ID, configuration information, and optionally a set of - credentials. The Peer-ID is an identifier that will uniquely + obtain a Node-ID, configuration information, and optionally a set of + credentials. The Node-ID is an identifier that will uniquely identify the peer within the overlay, while the credentials show that the peer is allowed to join the overlay. The P2PSIP WG does not impose a particular mechanism for how the peer-ID and the credentials are obtained, but the RELOAD base draft does specify the format for the configuration information, and 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 specifies a mechanism whereby a peer may obtain a multicast-bootstrap address in the configuration file, and can broadcast to this address to attempt to locate a bootstrap peer. Additionally, the peer may store previous peers it has seen and attempt to use these as bootstrap peers, or may obtain an address for a bootstrap peer by some other mechanism. For more information, see the RELOAD base draft. @@ -748,44 +748,44 @@ 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-11 (work in - progress), October 2010. + Base Protocol", draft-ietf-p2psip-base-18 (work in + progress), August 2011. [I-D.ietf-p2psip-diagnostics] - Yongchao, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP - Overlay Diagnostics", draft-ietf-p2psip-diagnostics-04 - (work in progress), July 2010. + Haibin, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP + Overlay Diagnostics", draft-ietf-p2psip-diagnostics-06 + (work in progress), August 2011. [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-02 - (work in progress), July 2010. + And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-04 + (work in progress), July 2011. [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-01 (work in progress), - July 2010. + draft-ietf-p2psip-service-discovery-03 (work in progress), + July 2011. [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-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, "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 +806,25 @@ 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 - Cogent Force, LLC - Williamsburg, Virginia + Polycom, Inc. + San Jose, California USA - Phone: +1 571 314 0256 + 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