diff options
Diffstat (limited to 'doc/rfc/rfc7890.txt')
| -rw-r--r-- | doc/rfc/rfc7890.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7890.txt b/doc/rfc/rfc7890.txt new file mode 100644 index 0000000..fa9d892 --- /dev/null +++ b/doc/rfc/rfc7890.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Bryan +Request for Comments: 7890 Cogent Force, LLC +Category: Informational P. Matthews +ISSN: 2070-1721 Nokia + E. Shim + Samsung Electronics Co., Ltd. + D. Willis + Softarmor Systems + S. Dawkins + Huawei (USA) + June 2016 + + + Concepts and Terminology for Peer-to-Peer SIP (P2PSIP) + +Abstract + + This document defines concepts and terminology for using 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, the REsource LOcation And Discovery (RELOAD) protocol, and the + SIP usage document defined by the working group. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7890. + + + + + + + +Bryan, et al. Informational [Page 1] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + +Copyright Notice + + Copyright (c) 2016 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 + described in the Simplified BSD License. + +Table of Contents + + 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. High-Level Description . . . . . . . . . . . . . . . . . . . 4 + 2.1. Services . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.3. Relationship between P2PSIP and RELOAD . . . . . . . . . 5 + 2.4. Relationship between P2PSIP and SIP . . . . . . . . . . . 5 + 2.5. Relationship between P2PSIP and Other AoR-Dereferencing + Approaches . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.6. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. The Distributed Database Function . . . . . . . . . . . . 12 + 5.2. Using the Distributed Database Function . . . . . . . . . 13 + 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14 + 5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 14 + 5.5. Clients and Connecting Unmodified SIP Devices . . . . . . 15 + 5.6. Architecture . . . . . . . . . . . . . . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 7. Informative References . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + + + + + + + + + + + + + +Bryan, et al. Informational [Page 2] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + +1. Background + + One of the fundamental problems in multimedia communication between + Internet nodes is the rendezvous problem, or 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 a name for the user that is + independent of the host or hosts where the user can be contacted, + while a Contact URI indicates the host where the user can be + contacted. + + In the common SIP-using architectures that we refer to as + "Conventional SIP" or "Client/Server SIP", there is a relatively + fixed hierarchy of SIP routing proxies and SIP user agents. To + deliver a SIP INVITE to the host or hosts at which the user can be + contacted, a SIP UA follows the procedures specified in [RFC3263] to + determine the IP address of a SIP proxy, and then sends the INVITE to + that proxy. The proxy will then, in turn, deliver the SIP INVITE to + the hosts where the user can be contacted. + + 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 mappings of AoRs to Contact URIs 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 [RFC6940], which defines a mechanism for distribution 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 then + design decisions were made that allow RELOAD to be used in other + instances where a DHT is desirable, but only when such decisions did + not add undue complexity to the RELOAD protocol. The RELOAD SIP + document [P2PSIP] specifies how RELOAD is used with the SIP protocol + to enable a distributed, server-less SIP solution. + + + + + + + + + + +Bryan, et al. Informational [Page 3] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + +2. High-Level Description + + A Peer-to-Peer SIP (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. + + A P2PSIP Overlay consists of one or more nodes called "Peers". The + nodes in the Overlay collectively run a distributed database + algorithm. This distributed database algorithm allows data to be + 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. + +2.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 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 Traversal + Using Relays around NAT (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. [RFC7374] describes the mechanism used + in P2PSIP for resource discovery. + +2.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 + + + +Bryan, et al. Informational [Page 4] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + or store information. Clients access the services of the RELOAD + protocol by connecting to a Peer that 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 + [RFC6940]. + + A special Peer may also be a member of the P2PSIP Overlay and may + present the functionality of one or all of a SIP registrar, proxy, or + redirect server to conventional SIP devices (i.e., unmodified SIP + user agent (UA) or client). In this way, existing, unmodified SIP + clients may connect to the P2PSIP network. Note that in the context + of P2PSIP, the unmodified SIP client is also sometimes referred to as + a "client". 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. + +2.3. Relationship between P2PSIP and RELOAD + + The RELOAD protocol defined by the P2PSIP working group implements a + DHT primarily for use by server-less, peer-to-peer SIP deployments. + However, the RELOAD protocol could be used for other applications as + well. As such, a "P2PSIP" deployment is generally assumed to be a + use of RELOAD to implement distributed SIP, but it is possible that + RELOAD is used as a mechanism to distribute other applications, + completely unrelated to SIP. + +2.4. Relationship between P2PSIP and SIP + + Since P2PSIP is about peer-to-peer networks for real-time + communication, it is expected that most Peers and Clients will be + coupled with SIP entities (although RELOAD may be used for other + applications than P2PSIP). For example, one Peer might be coupled + with a SIP UA, another might be coupled with a SIP proxy, while a + third might be coupled with a SIP-to-PSTN gateway. For such nodes, + the Peer or Client portion of the node is logically distinct from the + SIP entity portion. However, there is no hard requirement that every + P2PSIP node (Peer or Client) be coupled to a SIP entity. As an + example, additional Peers could be placed in the Overlay to provide + additional storage or redundancy for the RELOAD Overlay, but might + not have any direct SIP capabilities. + + + + + + + + + + +Bryan, et al. Informational [Page 5] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + +2.5. Relationship between P2PSIP and Other AoR-Dereferencing Approaches + + As noted above, the fundamental task of P2PSIP is to turn an AoR into + a Contact. This task might be approached using zero configuration + techniques such as multicast DNS (mDNS) and DNS Service Discovery + (DNS-SD) [RFC6762] [RFC6763], Link-Local Multicast Name Resolution + [RFC4795], and dynamic DNS [RFC2136]. + + These alternatives were discussed in the P2PSIP working group, and + 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 mDNS and DNS-SD for the + bootstrapping of P2PSIP overlays. + +2.6. NAT Issues + + Network Address Translators (NATs) are impediments to establishing + and maintaining peer-to-peer networks, since NATs hinder direct + 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 + 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. + +3. 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 an ordinary + SIP proxy as well. The figure is not intended to cover all possible + architecture variations, but simply to show a deployment with many + common P2PSIP elements. + + + + + + + + + + + + + + + +Bryan, et al. Informational [Page 6] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + --->PSTN + +------+ N +------+ +---------+ / + | | A | | | Gateway |-/ + | UA |####T#####| UA |#####| Peer |######## + | Peer | N | Peer | | G | # RELOAD + | E | A | F | +---------+ # P2PSIP + | | T | | # Protocol + +------+ N +------+ # | + # A # | + NATNATNATNAT # | + # # | \__/ + NATNATNATNAT +-------+ v / \ + # N | |#####/ UA \ + +------+ A P2PSIP Overlay | Peer | /Client\ + | | T | Q | |___C__| + | UA | N | | + | Peer | A +-------+ + | D | T # + | | N # + +------+ A # RELOAD + # T # P2PSIP + # N +-------+ +-------+ # Protocol + # A | | | | # + #########T####| Proxy |########| Redir |####### + N | Peer | | Peer | + A | P | | R | + T +-------+ +-------+ + | / + | SIP / + \__/ / / + /\ / ______________/ SIP + / \/ / + / UA \/ + /______\ + SIP UA A + + Figure 1: P2PSIP Overlay Reference Model + + Here, the large perimeter depicted by "#" represents a stylized view + of the Overlay (the actual connections could be a mesh, a ring, or + some other structure). Around the periphery of the Overlay + rectangle, we have a number of Peers. Each Peer is labeled with its + coupled SIP entity -- for example, "Proxy Peer P" means that Peer P + is coupled with a SIP proxy. In some cases, a Peer or Client might + be coupled with two or more SIP entities. In this diagram, we have a + Public Switched Telephone Network (PSTN) gateway coupled with Peer + "G", three Peers ("D", "E", and "F") that are each coupled with a UA, + a Peer "P" that is coupled with a SIP proxy, an ordinary Peer "Q" + + + +Bryan, et al. Informational [Page 7] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + with no SIP capabilities, and one Peer "R" that is coupled with a SIP + redirector. Note that because these are all Peers, each is + responsible for storing Resource Records and transporting messages + around the Overlay. + + To the left, two of the Peers ("D" and "E") are behind network + address translators (NATs). These Peers are included in the P2PSIP + Overlay, and thus participate in storing resource records and routing + messages, despite being behind the NATs. + + On the right side, we have a Client "C", which uses the RELOAD + Protocol to communicate with Proxy Peer "Q". The Client "C" uses + RELOAD to obtain information from the Overlay, but has not inserted + itself into the Overlay, and therefore does not participate in + routing messages or storing information. + + Below the Overlay, we have a conventional SIP UA "A" that is not part + of the Overlay, either directly as a Peer or indirectly as a Client. + It does not speak the RELOAD P2PSIP protocol and is not participating + in the Overlay as a Peer or a Client. Instead, it uses SIP to + interact with the Overlay via an adapter Peer or Peers that + communicate with the Overlay using RELOAD. + + Both the SIP proxy coupled with Peer "P" and the SIP redirector + coupled with Peer "R" can serve as adapters between ordinary SIP + devices and the Overlay. Each accepts standard SIP requests and + resolves the next hop by using the P2PSIP protocol to interact with + the routing knowledge of the Overlay, and then processes the SIP + requests as appropriate (proxying or redirecting towards the next + hop). Note that proxy operation is bidirectional -- the proxy may be + forwarding a request from an ordinary SIP device to the Overlay, or + from the P2PSIP Overlay to an ordinary SIP device. + + The PSTN Gateway at Peer "G" provides a similar sort of adaptation to + and from the PSTN. + +4. Definitions + + This section defines a number of concepts that are key to + understanding the P2PSIP work. + + Overlay Network: An overlay network is a computer network that is + built on top of another network. Nodes in the overlay can be + thought of as being connected by virtual or logical links, each of + which corresponds to a path, perhaps through many physical links, + in the underlying network. For example, many peer-to-peer + + + + + +Bryan, et al. Informational [Page 8] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + networks are overlay networks because they run on top of the + Internet. Dial-up Internet is an overlay upon the telephone + network. + + P2P Network: A peer-to-peer (or P2P) computer network is a network + that relies primarily on the computing power and bandwidth of the + participants in the network rather than concentrating it in a + relatively low number of servers. P2P networks are typically used + for connecting nodes via largely ad hoc connections. Such + networks are useful for many purposes. Sharing content files + containing audio, video, data, or anything in digital format is + very common, and real-time data, such as telephony traffic, is + also exchanged using P2P technology. A P2P Network may also be + called a "P2P Overlay", a "P2P Overlay Network", or a "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 [RFC6940], + [RFC7363], [RFC7374], [RFC7851] and [P2PSIP]. + + User: A human that interacts with the Overlay through SIP UAs + located on Peers and Clients (and perhaps in 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 draft 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. + + Overlay Name: A human-friendly name that identifies a specific + P2PSIP Overlay. This is in the format of (a portion of) a URI, + but may or may not have a related record in the DNS. + + 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. + + + + + +Bryan, et al. Informational [Page 9] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + 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 Node- + IDs are completely independent of the identifier of any user of a + user agent associated with a Peer. + + Client: A node that participates in a P2PSIP Overlay but does not + store information or forward messages. A Client can also be + 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. + + Service Name: A unique, human-friendly name for a service. + + Resource: Anything about which information can be stored in the + Overlay. Both Users and Services are examples of Resources. + + Resource-ID: A non-human-friendly value that uniquely identifies a + resource and that is used as a key for storing and retrieving data + about the resource. One way to generate a Resource-ID is by + applying a mapping function to some other unique name (e.g., User + Name or Service Name) for the resource. The Resource-ID is used + by the distributed database algorithm to determine the Peer or + Peers that are responsible for storing data for the Overlay. + + Resource Record: A block of data, stored using the distributed + database mechanism of the Overlay, that includes information + relevant to a specific resource. We presume that there may be + multiple types of resource records. Some may hold data about + Users, and others may 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. + + + + + + +Bryan, et al. Informational [Page 10] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + 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 protocol [RFC6940]. + + Client Protocol: The protocol spoken between Clients and Peers. In + P2PSIP and RELOAD, this is syntactically the same protocol as the + Peer Protocol. The only difference is that Clients are not + routing messages or routing information, and have not (or cannot) + insert themselves into the Overlay. + + Peer Protocol Connection / P2PSIP Client Protocol Connection: + The Transport Layer Security (TLS), Datagram Transport Layer + Security (DTLS), TCP, UDP, or other transport-layer protocol + connection over which the RELOAD Peer Protocol messages are + transported. + + Neighbors: The set of P2PSIP Peers that a Peer or Client know of + directly and can reach without further lookups. + + Joining Peer: A node that is attempting to become a Peer in a + particular Overlay. + + Bootstrap Peer: A Peer in the Overlay that is the first point of + contact for a Joining Peer. It selects the Peer that will serve + as the Admitting Peer and helps the Joining Peer contact the + Admitting Peer. + + Admitting Peer: A Peer in the Overlay that helps the Joining Peer + join the Overlay. The choice of the Admitting Peer may depend on + the Joining Peer (e.g., depend on the Joining Peer's Peer-ID). + For example, the Admitting Peer might be chosen as the Peer which + is "closest" in the logical structure of the Overlay to the future + position of the Joining Peer. The selection of the Admitting Peer + is typically done by the Bootstrap Peer. It is allowable for the + Bootstrap Peer to select itself as the Admitting Peer. + + Bootstrap Server: A network node used by Joining Peers to locate a + Bootstrap Peer. A Bootstrap Server may act as a proxy for + messages between the Joining Peer and the Bootstrap Peer. The + Bootstrap Server itself is typically a stable host with a DNS name + that is somehow communicated (for example, through configuration, + specification on a web page, or using DHCP) to Peers that want to + join the Overlay. A Bootstrap Server is NOT required to be a Peer + or Client, though it may be if desired. + + + + + + + +Bryan, et al. Informational [Page 11] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + Peer Admission: The act of admitting a node (the "Joining Peer") + into an Overlay as a Peer. After the admission process is over, + the Joining Peer is a fully functional Peer of the Overlay. + During the admission process, the Joining Peer may need to present + credentials to prove that it has sufficient authority to join the + Overlay. + + Resource Record Insertion: The act of inserting a P2PSIP Resource + Record into the distributed database. Following insertion, the + data will be stored at one or more Peers. The data can be + retrieved or updated using the Resource-ID as a key. + +5. Discussion + +5.1. The Distributed Database Function + + A P2PSIP Overlay functions as a distributed database. The database + serves as a way to store information about Resources. A piece of + information, called a "Resource Record", can be stored by and + retrieved from the database using a key associated with the Resource + Record called its "Resource-ID". Each Resource must have a unique + Resource-ID. In addition to uniquely identifying the Resource, the + Resource-ID is also used by the distributed database algorithm to + determine the Peer or Peers that store the Resource Record in the + Overlay. + + Users are humans that can use the Overlay to do things like making + and receiving calls. Information stored in the resource record + associated with a user can include things like the full name of the + user and the location of the UAs that the user is using (the user's + SIP AoR). Full details of how this is implemented using RELOAD are + provided in [P2PSIP]. + + 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 [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 [RFC7374]. + + + +Bryan, et al. Informational [Page 12] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + Each service has a human-friendly Service Name that uniquely + identifies the service. Like User Names, the Service Name is not a + Resource-ID, rather the Resource-ID is derived from the service name + using some function defined by the distributed database algorithm + used by the Overlay. + + A class of algorithms known as Distributed Hash Tables (DHTs) are one + way to implement the distributed database. The RELOAD protocol is + extensible and allows many different DHTs to be implemented, but + specifies a mandatory-to-implement DHT in the form of a modified + Chord DHT. For more information, see [Chord]. + +5.2. Using the Distributed Database Function + + While there are a number of ways the distributed database described + in the previous section can be used to establish multimedia sessions + using SIP, the basic mechanism defined in the RELOAD protocol and SIP + usage is summarized below. This is a very simplistic overview. For + more detailed information, please see the RELOAD protocol [RFC6940]. + + Contact information for a user is stored in the resource record for + that user. Assume that a user is using a device, here called "Peer + A", that serves as the contact point for this user. The user adds + contact information to this resource record, as authorized by the + RELOAD certificate mechanism. The resource record itself is stored + with Peer Z in the network, where Peer Z is chosen by the particular + distributed database algorithm in use by the Overlay. + + When the SIP entity coupled with Peer B has an INVITE message + addressed to this user, it retrieves the resource record from Peer Z. + It then extracts the contact information for the various Peers that + are a contact point for the user, including Peer A, and uses the + Overlay to establish a connection to Peer A, including any + appropriate NAT traversal (the details of which are not shown). + + Note that RELOAD is used only to establish the connection. Once the + connection is established, messages between the Peers are sent using + ordinary SIP. + + This exchange is illustrated in the following figure. The notation + "Store(U@A)" is used to show the distributed database operation of + updating the resource record for user U with the contract A, and + "Fetch(U)" illustrates the distributed database operation of + retrieving the resource record for user U. Note that the messages + between the Peers A, B, and Z may actually travel via intermediate + Peers (not shown) as part of the distributed lookup process or so as + to traverse intervening NATs. + + + + +Bryan, et al. Informational [Page 13] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + Peer B Peer Z Peer A + | | | + | | Store(U@A)| + | |<------------------| + | |Store-Resp(OK) | + | |------------------>| + | | | + |Fetch(U) | | + |------------------->| | + | Fetch-Resp(U@A)| | + |<-------------------| | + | | | + (RELOAD IS USED TO ESTABLISH CONNECTION) + | | | + | SIP INVITE(To:U) | | + |--------------------------------------->| + | | | + + Figure 2: SIP Exchange Using Distributed Database Function + +5.3. NAT Traversal + + NAT traversal in P2PSIP using RELOAD treats all Peers as equal and + establishes a partial mesh of connections between them. Messages + from one Peer to another are routed along the edges in the mesh of + connections until they reach their destination. To make the routing + efficient and to avoid the use of standard Internet routing + protocols, the partial mesh is organized in a structured manner. If + the structure is based on any one of a number of common DHT + 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 Interactive Connectivity Establishment + (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. + +5.4. Locating and Joining an Overlay + + Before a Peer can attempt to join a P2PSIP Overlay, it must first + obtain a Node-ID, configuration information, and optionally a set of + credentials. The Node-ID is an identifier that uniquely identifies + the Peer within the Overlay, while the credentials show that the Peer + is allowed to join the Overlay. + + + + + + + + +Bryan, et al. Informational [Page 14] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + The P2PSIP WG does not impose a particular mechanism for how the + Peer-ID and the credentials are obtained, but the RELOAD protocol + does specify the format for the configuration information and how + this information may be obtained, along with credentials and a + Node-ID, from an offline enrollment server. + + Once the configuration information is obtained, RELOAD specifies a + mechanism whereby a Peer may obtain a multicast-bootstrap address in + the configuration file and broadcast to this address to attempt + locating a Bootstrap Peer. Additionally, the Peer may store previous + Peers it has seen and attempt using these as Bootstrap Peers, or it + may obtain an address for a Bootstrap Peer by some other mechanism. + For more information, see the RELOAD protocol. + + The job of the Bootstrap Peer is simple: refer the Joining Peer to a + Peer (called the "Admitting Peer") that will help the Joining Peer + join the network. The choice of the Admitting Peer will often depend + on the Joining Peer -- for example, the Admitting Peer may be a Peer + that will become a neighbor of the Joining Peer in the Overlay. It + is possible that the Bootstrap Peer might also serve as the Admitting + Peer. + + The Admitting Peer will help the Joining Peer learn about other Peers + in the Overlay and establish connections to them as appropriate. The + Admitting Peer and/or the other Peers in the Overlay will also do + whatever else is required to help the Joining Peer become a fully + functional Peer. The details of how this is done will depend on the + distributed database algorithm used by the Overlay. + + At various stages in this process, the Joining Peer may be asked to + present its credentials to show that it is authorized to join the + Overlay. Similarly, the various Peers contacted may be asked to + present their credentials so the Joining Peer can verify that it is + really joining the Overlay it wants to. + +5.5. Clients and Connecting Unmodified SIP Devices + + As mentioned above, in RELOAD, from the perspective of the protocol, + Clients are simply peers that do not store information, do not route + messages, and have not inserted themselves into the Overlay. The + same protocol is used for the actual message exchanged. Note that + while the protocol is the same, the Client need not implement all the + capabilities of a Peer. If, for example, it never routes messages, + it will not need to be capable of processing such messages or + understanding a DHT. + + + + + + +Bryan, et al. Informational [Page 15] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + For SIP devices, another way to realize this functionality is for a + Peer to behave as a proxy/registrar as specified in [RFC3261]. SIP + devices then use standard SIP mechanisms to add, update, and remove + registrations and to send SIP messages to Peers and other Clients. + The authors here refer to these devices simply as a "SIP UA", not a + "P2PSIP Client", to distinguish it from the concept described above. + +5.6. Architecture + + The architecture adopted by RELOAD to implement P2PSIP is shown + below. An application (for example, SIP or another application using + RELOAD) uses RELOAD to locate other Peers and (optionally) to + establish connections to those Peers, potentially across NATs. + Messages may still be exchanged directly between the Peers. The + overall block diagram for the architecture is as follows: + + __________________________ + | | + | SIP, other apps... | + | ___________________| + | | RELOAD Layer | + |______|___________________| + | Transport Layer | + |__________________________| + + Figure 3: Architecture for Implementing P2PSIP + +6. Security Considerations + + This specification is an overview of existing specifications and does + not introduce any security considerations on its own. Please refer + to the security considerations of the respective specifications, + particularly the RELOAD protocol specification ([RFC6940]) for + further details. + +7. Informative References + + [Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., + Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A + scalable peer-to-peer lookup protocol for internet + applications", IEEE/ACM Transactions on Networking, + Volume 11, Issue 1, pp. 17-32, + DOI 10.1109/TNET.2002.808407, February 2003. + + [P2PSIP] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., + Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD", + Work in Progress, draft-ietf-p2psip-sip-21, April 2016. + + + + +Bryan, et al. Informational [Page 16] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, DOI 10.17487/RFC2136, April 1997, + <http://www.rfc-editor.org/info/rfc2136>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <http://www.rfc-editor.org/info/rfc3261>. + + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, + DOI 10.17487/RFC3263, June 2002, + <http://www.rfc-editor.org/info/rfc3263>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <http://www.rfc-editor.org/info/rfc3986>. + + [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local + Multicast Name Resolution (LLMNR)", RFC 4795, + DOI 10.17487/RFC4795, January 2007, + <http://www.rfc-editor.org/info/rfc4795>. + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, + DOI 10.17487/RFC5245, April 2010, + <http://www.rfc-editor.org/info/rfc5245>. + + [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, + DOI 10.17487/RFC5766, April 2010, + <http://www.rfc-editor.org/info/rfc5766>. + + [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, + DOI 10.17487/RFC6762, February 2013, + <http://www.rfc-editor.org/info/rfc6762>. + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + <http://www.rfc-editor.org/info/rfc6763>. + + + + + + +Bryan, et al. Informational [Page 17] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + + [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., + and H. Schulzrinne, "REsource LOcation And Discovery + (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, + January 2014, <http://www.rfc-editor.org/info/rfc6940>. + + [RFC7363] Maenpaa, J. and G. Camarillo, "Self-Tuning Distributed + Hash Table (DHT) for REsource LOcation And Discovery + (RELOAD)", RFC 7363, DOI 10.17487/RFC7363, September 2014, + <http://www.rfc-editor.org/info/rfc7363>. + + [RFC7374] Maenpaa, J. and G. Camarillo, "Service Discovery Usage for + REsource LOcation And Discovery (RELOAD)", RFC 7374, + DOI 10.17487/RFC7374, October 2014, + <http://www.rfc-editor.org/info/rfc7374>. + + [RFC7851] Song, H., Jiang, X., Even, R., Bryan, D., and Y. Sun, + "Peer-to-Peer (P2P) Overlay Diagnostics", RFC 7851, + DOI 10.17487/RFC7851, May 2016, + <http://www.rfc-editor.org/info/rfc7851>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bryan, et al. Informational [Page 18] + +RFC 7890 P2PSIP Concepts and Terminology June 2016 + + +Authors' Addresses + + David A. Bryan + Cogent Force, LLC + Cedar Park, Texas + United States + + Email: dbryan@ethernot.org + + + Philip Matthews + Nokia + 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 + United States + + Phone: +1 214 504 1987 + Email: dean.willis@softarmor.com + + + Spencer Dawkins + Huawei Technologies (USA) + + Phone: +1 214 755 3870 + Email: spencerdawkins.ietf@gmail.com + + + + + + + +Bryan, et al. Informational [Page 19] + |