doc: Add RFC documents

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]
+