idnits 2.17.1 draft-willis-p2psip-concepts-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1129. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1142. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1070 has weird spacing: '...ologies and C...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2007) is 6234 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-06 == Outdated reference: A later version (-01) exists of draft-irtf-p2prg-survey-search-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group D. Bryan 3 Internet-Draft SIPeerior Technologies and 4 Intended status: Informational College of William and Mary 5 Expires: September 5, 2007 P. Matthews 6 Avaya 7 E. Shim 8 Locus Telecommunications 9 D. Willis 10 Cisco Systems 11 March 4, 2007 13 Concepts and Terminology for Peer to Peer SIP 14 draft-willis-p2psip-concepts-04 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 5, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document defines concepts and terminology for use of the Session 48 Initiation Protocol in a peer-to-peer environment where the 49 traditional proxy-registrar function is replaced by a distributed 50 mechanism that might be implemented using a distributed hash table or 51 other distributed data mechanism with similar external properties. 52 This document includes a high-level view of the functional 53 relationships between the network elements defined herein, a 54 conceptual model of operations, and an outline of the related open 55 problems that might be addressed by an IETF working group. 57 Table of Contents 59 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. High Level Description . . . . . . . . . . . . . . . . . . . . 3 63 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.1. The Distributed Database . . . . . . . . . . . . . . . . . 11 69 5.2. Using the Distributed Database . . . . . . . . . . . . . . 13 70 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 16 71 5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 18 72 5.5. Possible Client Behavior . . . . . . . . . . . . . . . . . 19 73 5.6. Interacting with non-P2PSIP entities . . . . . . . . . . . 20 75 6. Additional Questions . . . . . . . . . . . . . . . . . . . . . 20 76 6.1. Selecting between Multiple Peers offering the Same 77 Service . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 6.2. Visibility of Messages to Intermediate Peers . . . . . . . 21 79 6.3. Hybrid Domains . . . . . . . . . . . . . . . . . . . . . . 21 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 94 Intellectual Property and Copyright Statements . . . . . . . . . . 26 96 1. Background 98 One of the fundamental problems in multimedia communications between 99 Internet nodes is that of a discovering the IP address at which a 100 given correspondent can be reached. Correspondents are frequently 101 identified by distinguished names, perhaps represented in the form of 102 a universal resource indicator (URI) [RFC3986]. 104 The Session Initiation Protocol (SIP) [RFC3261] commonly addresses 105 this task assuming that the domain part of the URI indicates an 106 internet host address or internet domain name using the Domain Name 107 System (DNS) [RFC1034]. SIP's location process [RFC3263] assumes 108 that the host part of the URI indicates either the target SIP user 109 agent (UA), or a proxy that has knowledge of how to reach the target 110 UA, presumably gained through SIP's registration process. 112 This approach, referred to herein as "Conventional SIP" or "Client/ 113 Server SIP", assumes a relatively fixed hierarchy of SIP routing 114 proxies (servers) and SIP user agents (clients). The routing proxies 115 are typically resolvable using conventional Internet mechanisms with 116 static IP addresses and associated DNS entries. This structure may 117 not be ideal in all cases, including specifically ad-hoc, serverless, 118 and reduced-administration scenarios. As an alternative, several 119 authors [I-D.bryan-p2psip-dsip] [I-D.shim-sipping-p2p-arch] 120 [I-D.johnston-sipping-p2p-ipcom] 121 [I-D.matthews-sipping-p2p-industrial-strength] have proposed using 122 peer-to-peer (P2P) [I-D.irtf-p2prg-survey-search] approaches to 123 solving the problem of locating the correspondent. The motivations 124 for a P2P approach in SIP have been documented in 125 [I-D.bryan-sipping-p2p-usecases]. 127 This document offers a consolidation of the more important terms and 128 concepts from several of the above documents, presented in the 129 context of a reference model for peer-to-peer SIP (P2PSIP). It is 130 intended that this document serve as a starting point for describing 131 the work needed to resolve a number of open questions such that an 132 IETF working group can do the work needed to resolve these questions 133 and present a standard solution. The authors believe that this goal 134 is roughly consistent with that of a Protocol Model as defined in 135 [RFC4101]. 137 2. High Level Description 139 A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer 140 fashion for the purpose of enabling real-time communication using the 141 Session Initiation Protocol (SIP). Collectively, the nodes in the 142 overlay provide a distributed implementation of the location service 144 [RFC3261] for mapping Addresses of Record (AoRs) to Contact URIs. 145 They also provide a transport service by which SIP messages can be 146 transported between any two nodes in the overlay. 148 A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers. 149 The peers in the overlay collectively run a distributed database 150 algorithm. This distributed database algorithm allows data to be 151 stored on peers and retrieved in an efficient manner. It may also 152 ensure that a copy of a data item is stored on more than one peer, so 153 that the loss of a peer does not result in the loss of the data item 154 to the overlay. 156 One use of this distributed database is to store the information 157 required to provide the mapping between AoRs and Contact URIs for the 158 distributed location service. 160 The nature of peer-to-peer computing is that each peer offers 161 services to other peers to allow the overlay to collectively provide 162 larger services. In P2PSIP, each individual peer needs to offer a 163 storage service and a transport service to allow the distributed 164 database service and distributed transport service to be implemented. 165 It is expected that individual peers may also offer other services. 166 Some of these additional services (for example, a STUN server service 167 [I-D.ietf-behave-rfc3489bis]) may be required to allow the overlay to 168 form and operate, while others (for example, a voicemail service) may 169 be enhancements to the basic P2PSIP functionality. 171 To allow peers to offer these additional services, the distributed 172 database may need to store information about services. For example, 173 it may need to store information about which peers offer which 174 services. 176 An overlay may or may not also include one or more nodes called 177 P2PSIP Clients. The role of a client in the P2PSIP model is still 178 under discussion, with a number of suggestions for roles being put 179 forth, and some arguing that clients are not needed at all. However, 180 if they exist, then people agree that they will also be able to store 181 and retrieve information from the overlay. Section 5.5 discusses the 182 possible roles of a client in more detail. 184 Peers in an overlay need to speak some protocol between themselves to 185 maintain the overlay and to store and retrieve data. Until a better 186 name is found, this protocol has been dubbed the P2PSIP Peer 187 Protocol. The details of this protocol are still very much under 188 debate: some have suggested that the protocol should be SIP with some 189 extensions, while others have suggested that it should be an entirely 190 new protocol. 192 If the P2PSIP model also contains clients, then a protocol is needed 193 for client - peer communication. Until a better name is found, this 194 protocol has been dubbed the P2PSIP Client Protocol. The details of 195 this protocol are also very much under debate. However, if the 196 client protocol exists, then it is agreed that it should be a logical 197 subset of the peer protocol. In other words, the syntax of the peer 198 and client protocols may be completely different, but any operation 199 supported by client protocol is also supported by the peer protocol. 200 This implies that clients cannot do anything that peers cannot also 201 do. 203 Since P2PSIP is about peer-to-peer networks for real-time 204 communication, it is expected that most (if not all) peers and 205 clients will be coupled with SIP entities. For example, one peer 206 might be coupled with a SIP UA, another might be coupled with a SIP 207 proxy, while a third might be coupled with a SIP-to-PSTN gateway. 208 For such nodes, we think of the peer or client portion of the node as 209 being distinct from the SIP entity portion. 211 Network Address Translators (NATs) are impediments to establishing 212 and maintaining peer-to-peer networks, since NATs hinder direct 213 communication between peers. Some peer-to-peer network architectures 214 avoid this problem by insisting that all peers exist in the same 215 address space. However, in the P2PSIP model, it has been agreed that 216 peers can live in multiple address spaces interconnected by NATs. 217 This implies that Peer Protocol connections must be able to traverse 218 NATs. It also means that the peers must collectively provide a 219 transport service that allows a peer to send a SIP message to any 220 other peer in the overlay - without this service two peers in 221 different address spaces might not be able to exchange SIP messages. 223 3. Reference Model 225 The following diagram shows a P2PSIP Overlay consisting of a number 226 of P2PSIP Peers and one P2PSIP Client. It also shows an ordinary SIP 227 UA. 229 --->PSTN 230 +------+ N +------+ +---------+ / 231 | | A | | | Gateway |-/ 232 | UA |####T#####| UA |#####| Peer |######## 233 | Peer | N | Peer | | G | # P2PSIP 234 | E | A | F | +---------+ # Client 235 | | T | | # Protocol 236 +------+ N +------+ # | 237 # A # | 238 NATNATNATNAT # | 239 # # | \__/ 240 NATNATNATNAT +-------+ v / \ 241 # N | |=====/ UA \ 242 +------+ A P2PSIP Overlay | Proxy | /Client\ 243 | | T | Peer | |___C__| 244 | UA | N | Q | 245 | Peer | A +-------+ 246 | D | T P2PSIP Peer Protocol # 247 | | N # 248 +------+ A # 249 # T # 250 # N +-------+ +-------+ # 251 # A | | | | # 252 #########T####| Proxy |########| Redir |####### 253 N | Peer | | Peer | 254 A | P | | R | 255 T +-------+ +-------+ 257 \__/ 258 /\ 259 / \ 260 / UA \ 261 /______\ 262 SIP UA A 264 Figure: P2PSIP Overlay Reference Model 266 Here, the large perimeter depicted by "#" represents a stylized view 267 of the P2PSIP Overlay (the actual connections could be a mesh, a 268 ring, or some other structure). Around the periphery of the P2PSIP 269 Overlay rectangle, we have a number of P2PSIP Peers. Each peer is 270 labeled with its coupled SIP entity -- for example, "Proxy Peer P" 271 means that peer P which is coupled with a SIP proxy. In some cases, 272 a peer or client might be coupled with two or more SIP entities. In 273 this diagram we have a PSTN gateway coupled with peer "G", three 274 peers ("D", "E" and "F") which are each coupled with a UA, two peers 275 ("P" and "Q") which are each coupled with a SIP proxy, and one peer 276 "R" which is coupled with a SIP Redirector. Note that because these 277 are all P2PSIP Peers, each is responsible for storing P2PSIP Resource 278 Records and transporting messages around the P2PSIP Overlay. 280 To the left, two of the peers ("D" and "E") are behind network 281 address translators (NATs). These peers are included in the P2PSIP 282 overlay and thus participate in storing resource records and routing 283 messages, despite being behind the NATs. 285 Below the P2PSIP Overlay, we have a conventional SIP UA "A" which is 286 not part of the P2PSIP Overlay, either directly as a peer or 287 indirectly as a client. It speaks neither the P2PSIP Peer nor P2PSIP 288 Client protocols. Instead, it uses SIP to interact with the P2PSIP 289 Overlay. 291 On the right side, we have a P2PSIP client "C", which uses the P2PSIP 292 Client Protocol depicted by "=" to communicate with Proxy Peer "Q". 293 The P2PSIP client "C" could communicate with a different peer, for 294 example peer "F", if it establishes a connection to "F" instead of or 295 in addition to "Q". The exact role that this client plays in the 296 network is still under discussion (see Section 5.5). 298 Both the SIP proxy coupled with peer "P" and the SIP redirector 299 coupled with peer "R" can serve as adapters between ordinary SIP 300 devices and the P2PSIP Overlay. Each accepts standard SIP requests 301 and resolves the next-hop by using the P2PSIP overlay Peer Protocol 302 to interact with the routing knowledge of the P2PSIP Overlay, then 303 processes the SIP requests as appropriate (proxying or redirecting 304 towards the next-hop). Note that proxy operation is bidirectional - 305 the proxy may be forwarding a request from an ordinary SIP device to 306 the P2PSIP overlay, or from the P2PSIP overlay to an ordinary SIP 307 device. 309 The PSTN Gateway at peer "G" provides a similar sort of adaptation to 310 and from the public switched telephone network (PSTN). 312 4. Definitions 314 This section defines a number of concepts that are key to 315 understanding the P2PSIP work. 317 Overlay Network: An overlay network is a computer network which is 318 built on top of another network. Nodes in the overlay can be 319 thought of as being connected by virtual or logical links, each of 320 which corresponds to a path, perhaps through many physical links, 321 in the underlying network. For example, many peer-to-peer 322 networks are overlay networks because they run on top of the 323 Internet. Dial-up Internet is an overlay upon the telephone 324 network. 326 P2P Network: A peer-to-peer (or P2P) computer network is a network 327 that relies primarily on the computing power and bandwidth of the 328 participants in the network rather than concentrating it in a 329 relatively low number of servers. P2P networks are typically used 330 for connecting nodes via largely ad hoc connections. Such 331 networks are useful for many purposes. Sharing content files (see 332 ) containing audio, 333 video, data or anything in digital format is very common, and 334 realtime data, such as telephony traffic, is also exchanged using 335 P2P technology. . A 336 P2P Network may also be called a "P2P Overlay" or "P2P Overlay 337 Network" or "P2P Network Overlay", since its organization is not 338 at the physical layer, but is instead "on top of" an existing 339 Internet Protocol network. 341 P2PSIP: A suite of communications protocols related to the Session 342 Initiation Protocol (SIP) [RFC3261] that enable SIP to use peer- 343 to-peer techniques for resolving the targets of SIP requests, 344 providing SIP message transport, and providing other SIP-related 345 services. The exact contents of this protocol suite are still 346 under discussion, but is likely to include the P2PSIP Peer 347 Protocol and may include a P2PSIP Client Protocol (see definitions 348 below). 350 P2PSIP Overlay: A P2PSIP Overlay is an association, collection, or 351 federation of nodes that provides SIP registration, SIP message 352 transport, and similar functions using a P2P organization, as 353 defined by "P2P Network" above. 355 P2PSIP Overlay Name: A human-friendly name that identifies a 356 specific P2PSIP Overlay. This is in the format of (a portion of) 357 a URI, but may or may not have a related record in the DNS. 359 P2PSIP Peer: A node participating in a P2PSIP Overlay that provides 360 storage and transport services to other nodes in that P2PSIP 361 Overlay. Each P2PSIP Peer has a unique identifier, known as a 362 Peer-ID, within the P2PSIP Overlay. Each P2PSIP Peer may be 363 coupled to one or more SIP entities. Within the P2PSIP Overlay, 364 the peer is capable of performing several different operations, 365 including: joining and leaving the overlay, transporting SIP 366 messages within the overlay, storing information on behalf of the 367 overlay, putting information into the overlay, and getting 368 information from the overlay. 370 P2PSIP Peer-ID: Information that uniquely identifies each P2PSIP 371 Peer within a given P2PSIP Overlay. This value is not human- 372 friendly -- in a DHT approach, this is a numeric value in the hash 373 space. These Peer-IDs are completely independent of the 374 identifier of any user of a user agent associated with a peer. 375 (Note: This is often called a "Node-ID" in the P2P literature). 377 P2PSIP Client: A node participating in a P2PSIP Overlay that is less 378 capable than a P2PSIP Peer in some way. The role of a P2PSIP 379 Client is still under debate, with a number of competing 380 proposals, and some have suggested removing the concept entirely 381 (see the discussion on this later in the document). If clients 382 exist, then it has been agreed that they do have the ability to 383 add, modify, inspect, and delete information in the overlay. Note 384 that the term client does not imply that this node is a SIP UAC. 385 Some have suggested that the word 'client' be changed to something 386 else to avoid both this confusion and the implication of a client- 387 server relationship. 389 User: A human that interacts with the overlay through SIP UAs 390 located on peers and clients (and perhaps other ways). 392 P2PSIP User Name: A human-friendly name for a user. This name must 393 be unique within the overlay, but may be unique in a wider scope. 394 User Names are formatted so that they can be used within a URI 395 (likely a SIP URI), perhaps in combination with the Overlay Name. 397 P2PSIP Service: Actions that a peer (and perhaps a client) can do 398 for the benefit of other peers and clients. Examples include 399 acting as a STUN server, and acting as a voicemail server. It is 400 expected that not all peers and clients will offer the same set of 401 services, so a means of finding peers (and perhaps clients) that 402 offer a particular service is required. 404 P2PSIP Service Name: A unique, human-friendly, name for a service. 406 P2PSIP Resource: Anything about which information can be stored in 407 the overlay. Both Users and Services are examples of Resources. 409 P2PSIP Resource-ID: A non-human-friendly value that uniquely 410 identifies a resource and which is used as a key for storing and 411 retrieving data about the resource. One way to generate a 412 Resource-ID is by applying a mapping function to some other unique 413 name (e.g., User Name or Service Name) for the resource. The 414 Resource-ID is used by the distributed database algorithm to 415 determine the peer or peers that are responsible for storing the 416 data for the overlay. 418 P2PSIP Resource Record: A block of data, stored using distributed 419 database mechanism of the P2PSIP Overlay, that includes 420 information relevant to a specific resource. We presume that 421 there may be multiple types of resource records. Some may hold 422 data about Users, and others may hold data about Services, and the 423 working group may define other types. The types, usages, and 424 formats of the records are a question for future study. 426 P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay 427 peers to share information and organize the P2PSIP Overlay 428 Network. 430 P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients 431 and P2PSIP Peers. It is used to store and retrieve information 432 from the P2P Overlay. The nature of this protocol, and even its 433 existence, is under discussion. However, if it exists, it has 434 been agreed that the Client Protocol is a functional subset of the 435 P2P Peer Protocol, but may differ in syntax and protocol 436 implementation (i.e., may not be syntactically related). 438 P2PSIP Peer Protocol Connection / P2PSIP Client Protocol Connection: 439 The TCP, UDP or other transport layer protocol connection over 440 which the P2PSIP Peer Protocol (or respectively the Client 441 protocol) is transported. 443 P2PSIP Neighbors: The set of P2PSIP Peers that either a P2PSIP Peer 444 or P2PSIP Client know of directly and can reach without further 445 lookups. 447 P2PSIP Joining Peer: A node that is attempting to become a P2PSIP 448 Peer in a particular P2PSIP Overlay. 450 P2PSIP Bootstrap Peer: A P2PSIP Peer in the P2PSIP Overlay that is 451 the first point of contact for a P2PSIP Joining Peer. It selects 452 the peer that will serve as the P2PSIP Admitting Peer and helps 453 the joining peer contact the admitting peer. 455 P2PSIP Admitting Peer: A P2PSIP Peer in the P2PSIP Overlay which 456 helps the P2PSIP Joining Peer join the Overlay. The choice of the 457 admitting peer may depend on the joining peer (e.g., depend the 458 joining peer's P2PSIP Peer-ID). For example, the admitting peer 459 might be chosen as the peer which is "closest" in the logical 460 structure of the overlay to the future position of the joining 461 peer. The selection of the admitting peer is typically done by 462 the bootstrap peer. It is allowable for the bootstrap peer to 463 select itself as the admitting peer. 465 P2PSIP Bootstrap Server: A network node used by P2PSIP Joining Peers 466 to locate a P2PSIP Bootstrap Peer. Typically, a P2PSIP Bootstrap 467 Server acts as a proxy for messages between the P2PSIP Joining 468 Peer and the P2PSIP Bootstrap Peer. The P2PSIP Bootstrap Server 469 itself is typically a stable host with a DNS name that is somehow 470 communicated (for example, through configuration) to peers that 471 want to join the overlay. A P2PSIP Bootstrap Server is NOT 472 required to be a peer or client, though it may be if desired. 474 P2PSIP Peer Admission: The act of admitting a node (the "P2PSIP 475 Joining Peer") into a P2PSIP Overlay as a P2PSIP Peer. After the 476 admission process is over, the joining peer is a fully-functional 477 peer of the overlay. During the admission process, the joining 478 peer may need to present credentials to prove that it has 479 sufficient authority to join the overlay. 481 P2PSIP Resource Record Insertion: The act of inserting a P2PSIP 482 Resource Record into the distributed database. Following 483 insertion, the data will be stored at one or more peers. The data 484 can be retrieved or updated using the P2PSIP Resource-ID as a key. 486 5. Discussion 488 5.1. The Distributed Database 490 A P2PSIP Overlay functions as a distributed database. The database 491 serves as a way to store information about things called Resources. 492 A piece of information, called a Resource Record, can be stored by 493 and retrieved from the database using a key associated with the 494 Resource Record called its Resource-ID. Each Resource must have a 495 unique Resource-ID. In addition to uniquely identifying the 496 Resource, the Resource-ID is also used by the distributed database 497 algorithm to determine the peer or peers that store the Resource 498 Record in the overlay. 500 It is expected that the P2PSIP working group will standardize the 501 way(s) certain types of resources are represented in the distributed 502 database. 504 One type of resource representation that the working group is 505 expected to standardize is information about users. Users are humans 506 that can use the overlay to do things like making and receiving 507 calls. Information stored in the resource record associated with a 508 user might include things like the full name of the user and the 509 location of the UAs that the user is using. 511 Before information about a user can be stored in the overlay, a user 512 needs a User Name. The User Name is a human-friendly identifier that 513 uniquely identifies the user within the overlay. The User Name is 514 not a Resource-ID, rather the Resource-ID is derived from the User 515 Name using some mapping function (often a cryptographic hash 516 function) defined by the distributed database algorithm used by the 517 overlay. 519 The overlay may also require that the user have a set of credentials. 520 Credentials may be required to authenticate the user and/or to show 521 that the user is authorized to use the overlay. 523 Another type of resource representation that the working group is 524 expected to standardize is information about services. Services 525 represent actions that a peer (and perhaps a client) can do to 526 benefit other peers and clients in the overlay. Information that 527 might be stored in the resource record associated with a service 528 might include the peers (and perhaps clients) offering the service. 530 Each service has a human-friendly Service Name that uniquely 531 identifies the service. Like User Names, the Service Name is not a 532 resource-id, rather the resource-id is derived from the service name 533 using some function defined by the distributed database algorithm 534 used by the overlay. 536 It is expected that the working group will standardize at least one 537 service. For each standardized service, the working group will 538 likely specify the service name, the nature and format of the 539 information stored in the resource record associated with the 540 service, and the protocol used to access the service. 542 The overlay may require that the peer (or client) have a set of 543 credentials for a service. For example, credentials might be 544 required to show that the peer (or client) is authorized to offer the 545 service, or to show that the peer (or client) is a providing a 546 trustworthy implementation of the service. 548 It is expected that the P2PSIP WG will not standardize how a User 549 Name is obtained, nor how the credentials associated with a User Name 550 or a Service Name are obtained, but merely standardize at least one 551 acceptable format for each. To ensure interoperability, it is 552 expected that at least one of these formats will be specified as 553 "mandatory-to-implement". 555 A class of algorithms known as Distributed Hash Tables 556 are one way to implement 557 the Distributed Database. In particular, both the Chord and Bamboo 558 algorithms have been suggested as good choices for the distributed 559 database algorithm. However, no decision has been taken so far. 561 5.2. Using the Distributed Database 563 There are a number of ways the distributed database described in the 564 previous section might be used to establish multimedia sessions using 565 SIP. In this section, we give four possibilities as examples. It 566 seems likely that the working group will standardize at least one way 567 (not necessarily one of the four listed here), but no decisions have 568 been taken yet. 570 The first option is to store the contact information for a user in 571 the resource record for the user. A peer Y that is a contact point 572 for this user adds contact information to this resource record. The 573 resource record itself is stored with peer Z in the network, where 574 peer Z is chosen by the distributed database algorithm. 576 When the SIP entity coupled with peer X has an INVITE message 577 addressed to this user, it retrieves the resource record from peer Z. 578 It then extracts the contact information for the various peers that 579 are a contact point for the user, including peer Y, and forwards the 580 INVITE onward. 582 This exchange is illustrated in the following figure. The notation 583 "Put(U@Y)" is used to show the distributed database operation of 584 updating the resource record for user U with the contract Y, and 585 "Get(U)" illustrates the distributed database operation of retrieving 586 the resource record for user U. Note that the messages between the 587 peers X, Y and Z may actually travel via intermediate peers (not 588 shown) as part of the distributed lookup process or so as to traverse 589 intervening NATs. 591 Peer X Peer Z Peer Y 592 | | | 593 | | Put(U@Y) | 594 | |<---------------| 595 | | Put-Resp(OK) | 596 | |--------------->| 597 | | | 598 | Get(U) | | 599 |---------------->| | 600 | Get-Resp(U@Y)| | 601 |<----------------| | 602 | INVITE(To:U) | | 603 |--------------------------------->| 604 | | | 606 The second option also involves storing the contact information for a 607 user in the resource record of the user. However, SIP entity at peer 608 X, rather than retrieving the resource record from peer Z, instead 609 forwards the INVITE message to the proxy at peer Z. The proxy at peer 610 Z then uses the information in the resource record and forwards the 611 INVITE onwards to the SIP entity at peer Y and the other contacts. 613 Peer X Peer Z Peer Y 614 | | | 615 | | Put(U@Y) | 616 | |<---------------| 617 | | Put-Resp(OK) | 618 | |--------------->| 619 | | | 620 | INVITE(To:U) | | 621 |-----------------| INVITE(To:U) | 622 | |--------------->| 623 | | | 625 The third option is for a single peer W to place its contact 626 information into the resource record for the user (stored with peer 627 Z). A peer Y that is a contact point for the user retrieves the 628 resource record from peer Z, extracts the contact information for 629 peer W, and then uses the standard SIP registration mechanism 630 [RFC3261] to register with peer W. When the SIP entity at peer X has 631 to forward an INVITE request, it retrieves the resource record and 632 extracts the contact information for W. It then forwards the INVITE 633 to the proxy at peer W, which proxies it onward to peer Y and the 634 other contacts. 636 Peer X Peer Z Peer Y Peer W 637 | | | | 638 | | Put(U@W) | | 639 | |<---------------------------------| 640 | | Put-Resp(OK) | | 641 | |--------------------------------->| 642 | | | | 643 | | | | 644 | | | REGISTER(To:U) | 645 | | |---------------->| 646 | | | 200 | 647 | | |<----------------| 648 | | | | 649 | | | | 650 | Get(U) | | | 651 |---------------->| | | 652 | Get-Resp(U@W)| | | 653 |<----------------| | | 654 | INVITE(To:U) | | | 655 |--------------------------------------------------->| 656 | | | INVITE(To:U) | 657 | | |<----------------| 658 | | | | 660 The fourth option works as in option 3, with the exception that, 661 rather than X retrieving the resource record from Z, peer X forwards 662 the INVITE to a SIP proxy at Z, which proxies it onward to W and 663 hence to Y. 665 Peer X Peer Z Peer Y Peer W 666 | | | | 667 | | Put(U@W) | | 668 | |<---------------------------------| 669 | | Put-Resp(OK) | | 670 | |--------------------------------->| 671 | | | | 672 | | | | 673 | | | REGISTER(To:U) | 674 | | |---------------->| 675 | | | 200 | 676 | | |<----------------| 677 | | | | 678 | | | | 679 | INVITE(To:U) | | | 680 |---------------->| INVITE(To:U) | | 681 | |--------------------------------->| 682 | | | INVITE(To:U) | 683 | | |<----------------| 684 | | | | 686 The pros and cons of option 1 and 3 are briefly discussed in 687 [Using-an-External-DHT]. 689 5.3. NAT Traversal 691 Two approaches to NAT Traversal for P2PSIP Peer Protocol have been 692 suggested. The working group has not many any decision yet on the 693 approach that will be selected. 695 The first, the traditional approach adopted by most peer-to-peer 696 networks today, divides up the peers in the network into two groups: 697 those with public IP addresses and those without. The networks then 698 select a subset of the former group and elevate them to "super peer" 699 status, leaving the remaining peers as "ordinary peers". Since super 700 peers all have public IP addresses, there are no NAT problems when 701 communicating between them. The network then associates each 702 ordinary peer with (usually just one) super peer in a client-server 703 relationship. Once this is done, an ordinary peer X can communicate 704 with another ordinary peer Y by sending the message to X's super 705 peer, which forwards it to Y's super peer, which forwards it to Y. 706 The connection between an ordinary peer and its super peer is 707 initiated by the ordinary peer, which makes it easy to traverse any 708 intervening NATs. In this approach, the number of hops between two 709 peers is at most 3. 711 The second approach treats all peers as equal and establishes a 712 partial mesh of connections between them. Messages from one peer to 713 another are then routed along the edges in the mesh of connections 714 until they reach their destination. To make the routing efficient 715 and to avoid the use of standard Internet routing protocols, the 716 partial mesh is organized in a structured manner. If the structure 717 is based on any one of a number of common DHT algorithms, then the 718 maximum number of hops between any two peers is log N, where N is the 719 number of peers in the overlay. 721 The first approach is significantly more efficient than the second in 722 overlays with large numbers of peers. However, the first approach 723 assumes there are a sufficient number of peers with public IP 724 addresses to serve as super peers. In some usage scenarios 725 envisioned for P2PSIP, this assumption does not hold. For example, 726 this approach fails completely in the case where every peer is behind 727 a distinct NAT. 729 The second approach, while less efficient in overlays with larger 730 numbers of peers, is efficient in smaller overlays and can be made to 731 work in many use cases where the first approach fails. 733 Both of these approaches assume a method of setting up Peer Protocol 734 connections between peers. Many such methods exist; the now expired 735 [I-D.iab-nat-traversal-considerations] is an attempt to give a fairly 736 comprehensive list along with a discussion of their pros and cons. 737 After a consideration of the various techniques, the P2PSIP working 738 group has decided to select the Unilateral Self-Address Fixing method 739 [RFC3424] of NAT Traversal, and in particular the ICE 740 [I-D.ietf-mmusic-ice] implementation of this approach. 742 The above discussion covers NAT traversal for Peer Protocol 743 connections. For Client Protocol connections, the approach depends 744 on the role adopted for clients and we defer the discussion on that 745 point until the role becomes clearer. 747 In addition to Peer Protocol and Client Protocol messages, a P2PSIP 748 Overlay must also provide a solution to the NAT Traversal problem for 749 SIP messages. If it does not, there is no reliable way for a peer 750 behind one NAT to send a SIP INVITE to a peer behind another NAT. 751 One way to solve this problem is to transport SIP messages along Peer 752 and Client Protocol connections: this could be done either by 753 encapsulating the SIP messages inside Peer and Client Protocol 754 messages or by multiplexing SIP with the Peer (resp.Client) Protocol 755 on a Peer (resp. Client) Protocol connection. 757 Finally, it should be noted that the NAT traversal problem for media 758 connections signaled using SIP is outside the scope of the P2PSIP 759 working group. As discussed in [I-D.ietf-sipping-nat-scenarios], the 760 current recommendation is to use ICE. 762 5.4. Locating and Joining an Overlay 764 Before a peer can attempt to join a P2PSIP overlay, it must first 765 obtain a Peer-ID and optionally a set of credentials. The Peer-ID is 766 an identifier that will uniquely identify the peer within the 767 overlay, while the credentials show that the peer is allowed to join 768 the overlay. 770 The P2PSIP WG will not standardize how the peer-ID and the 771 credentials are obtained, but merely standardize at least one 772 acceptable format for each. To ensure interoperability, it is 773 expected that at least one of these formats will be specified as 774 "mandatory-to-implement". 776 Once a peer (the "joining peer") has a peer-ID and optionally a set 777 of credentials, it can attempt to join the overlay. To do this, it 778 needs to locate a bootstrap peer for the Overlay. 780 A bootstrap peer is a peer that serves as the first point of contact 781 for the joining peer. The joining peer uses a bootstrap mechanism to 782 locate a bootstrap peer. Locating a bootstrap peer might be done in 783 any one of a number of different ways: 785 o By remembering peers that were part of the overlay the last time 786 the peer was part of the overlay; 788 o Through a multicast discovery mechanism; 790 o Through manual configuration; or 792 o By contacting a P2PSIP Bootstrap Server, and using its help to 793 locate a bootstrap peer. 795 The joining peer might reasonably try each of the methods (and 796 perhaps others) in some order or in parallel until it succeeds in 797 finding a bootstrap peer. 799 The job of the bootstrap peer is simple: refer the joining peer to a 800 peer (called the "admitting peer") that will help the joining peer 801 join the network. The choice of admitting peer will often depend on 802 the joining node - for example, the admitting peer may be a peer that 803 will become a neighbor of the joining peer in the overlay. It is 804 possible that the bootstrap peer might also serve as the admitting 805 peer. 807 The admitting peer will help the joining peer learn about other peers 808 in the overlay and establish connections to them as appropriate. The 809 admitting peer and/or the other peers in the overlay will also do 810 whatever else is required to help the joining peer become a fully- 811 functional peer. The details of how this is done will depend on the 812 distributed database algorithm used in the overlay. 814 At various stages in this process, the joining peer may be asked to 815 present its credentials to show that it is authorized to join the 816 overlay. Similarly, the various peers contacted may be asked to 817 present their credentials so the joining peer can verify that it is 818 really joining the overlay it wants to. 820 5.5. Possible Client Behavior 822 As mentioned above, a number of people have proposed a second type of 823 P2PSIP entity, known as a "P2PSIP client". The question of whether 824 the concept of a "client" is needed and, if it is needed, its exact 825 nature, is still very much under debate. This section presents some 826 of the alternatives that have been suggested for the possible role of 827 a client. 829 In one alternative, a client interacts with the P2PSIP overlay 830 through an associated peer (or perhaps several such peers) using the 831 Client Protocol. The client does not run the distributed database 832 algorithm, does not store resource records, and is not involved in 833 routing messages to other peers or clients. Though interactions with 834 its associated peer, a client can insert, modify, examine, and remove 835 resource records. A client can also send SIP messages to its 836 associated peer for routing through the overlay. In this 837 alternative, a client is a node that wants to take advantage of the 838 overlay, but is unable or unwilling to contribute resources back to 839 the overlay. 841 One way to realize this alternative is for a peer to behave as 842 [RFC3261] proxy/registrar. Clients then use standard SIP mechanisms 843 to add, update, and remove registrations and to send SIP messages to 844 peers and other clients. If this is done, there is no need for a 845 separate Client Protocol and no need for P2PSIP to define a distinct 846 "P2PSIP Client" concept. 848 In a second alternative, a client behaves in a way similar to the way 849 described in first alternative, except that it does store resource 850 records. In essence, the client contributes its storage capacity to 851 its associated peer. A peer which needs to store a resource record 852 may elect to store this on one of its associated clients instead, 853 thus boosting its effective storage capacity. 855 In a third alternative, a client acts almost the same as a peer, 856 except that it does not store any resource records. In this 857 alternative, a client has a "peer-ID" and joins the overlay in the 858 same way as a peer, perhaps establishing the same network of 859 connections that a peer would. Clients participate in the 860 distributed database algorithm, and can help in transporting messages 861 to other peers and clients. However, the distributed database 862 algorithm does not assign resource records to clients. The role of a 863 client in this model has been described as "a peer with bad memory". 865 In these three alternatives, clients can act as SIP entities and make 866 and receive calls on behalf of users. They can also use services 867 offered by peers, and depending on the details of how services are 868 defined, they may also be able to offer services to other clients and 869 peers. 871 5.6. Interacting with non-P2PSIP entities 873 It is possible for network nodes that are not peers or clients to 874 interact with a P2PSIP overlay. Such nodes would do this through 875 mechanisms not defined by the P2PSIP working group provided they can 876 find a peer or client that supports that mechanism and which will do 877 any related P2PSIP operations necessary. In this section, we briefly 878 describe two ways this might be done. (Note that these are just 879 examples and the descriptions here are not recommendations). 881 One example is a peer that also acts as a standard SIP proxy and 882 registrar. SIP UAs can interact with it using mechanisms defined in 883 [RFC3261]. The peer inserts registrations for users learned from 884 these UAs into the distributed database, and retrieves contact 885 information when proxying INVITE messages. 887 Another example is a peer that has a fully-qualified domain name 888 (FQDN) that matches the name of the overlay and acts as a SIP proxy 889 for calls coming into the overlay. A SIP INVITE addressed to 890 "user@overlay-name" arrives at the peer (using the mechanisms in 891 [RFC3263]) and this peer then looks up the user in the distributed 892 database and proxies the call onto it. 894 6. Additional Questions 896 This section lists some additional questions that the proposed P2PSIP 897 Working Group may need to consider in the process of defining the 898 Peer and Client protocols. 900 6.1. Selecting between Multiple Peers offering the Same Service 902 If a P2PSIP network contains two or more peers that offer the same 903 service, then how does a peer or client that wishes to use that 904 service select the peer to use? This question comes up in a number 905 of contexts: 907 o When two or more peers are willing to serve as a STUN Relay, how 908 do we select a peer that is close in the netpath sense and is 909 otherwise appropriate for the call? 911 o When two or more peers are willing to serve as PSTN gateways, how 912 do we select an appropriate gateway for a call that is both 913 netpath efficient and provides good quality or inexpensive PSTN 914 routing? 916 It has been suggested that, at least initially, the working group 917 should restrict itself to defining a mechanism that can return a list 918 of peers offering a service and not define the mechanism for 919 selecting a peer from that list. 921 6.2. Visibility of Messages to Intermediate Peers 923 When transporting SIP messages through the overlay, are the headers 924 and/or bodies of the SIP messages visible to the peers that the 925 messages happen to pass through? If they are, what types of security 926 risks does this pose in the presence of peers that have been 927 compromised in some way? 929 6.3. Hybrid Domains 931 If a given UA is capable of operating in both P2PSIP and conventional 932 SIP modalities (especially simultaneously), is it possible for it to 933 use and respond to the same AOR using both conventional and P2PSIP? 934 An example of such a topology might be a UA that registers an AOR 935 (say, "sip:alice@example.com" conventionally with a registrar and 936 then inserts a resource record for that resource into a P2PSIP 937 topology, such that both conventional SIP users and P2PSIP users 938 (within the overlay or a federation thereof) would be able to contact 939 the user without necessarily traversing some sort of gateway. Is 940 this something that we want to make work? 942 7. Security Considerations 944 Building a P2PSIP system has many security considerations, many of 945 which we have only begun to consider. We anticipate that the 946 protocol documents describing the actual protocols will deal more 947 thoroughly with security topics. 949 8. IANA Considerations 951 This document presently raises no IANA considerations. 953 9. Open Issues 955 Here are some open issues in this document: 957 1. The word "service" is being overloaded to refer both to what the 958 overlay provides (distributed location service, distributed 959 transport service) and what an individual peer or client 960 provides. How can we fix this? 962 2. Does P2PSIP provide a distributed location service or an 963 alternative mechanism to RFC 3263? The answer seems to be both, 964 but what is the relationship between these? 966 10. Acknowledgements 968 This document draws heavily from the contributions of many 969 participants in the P2PSIP Mailing List but the authors are 970 especially grateful for the support of Spencer Dawkins, Cullen 971 Jennings, and Henning Schulzrinne, all of whom spent time on phone 972 calls about this document or provided text. In addition, Spencer 973 contributed the Reference Model figure. 975 11. References 977 11.1. Normative References 979 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 980 STD 13, RFC 1034, November 1987. 982 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 983 A., Peterson, J., Sparks, R., Handley, M., and E. 984 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 985 June 2002. 987 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 988 Protocol (SIP): Locating SIP Servers", RFC 3263, 989 June 2002. 991 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 992 Resource Identifier (URI): Generic Syntax", STD 66, 993 RFC 3986, January 2005. 995 11.2. Informative References 997 [I-D.bryan-p2psip-dsip] 998 Bryan, D., "dSIP: A P2P Approach to SIP Registration and 999 Resource Location", draft-bryan-p2psip-dsip-00 (work in 1000 progress), February 2007. 1002 [I-D.bryan-sipping-p2p-usecases] 1003 Bryan, D., "Use Cases for Peer-to-Peer Session Initiation 1004 Protocol (P2P SIP)", draft-bryan-sipping-p2p-usecases-00 1005 (work in progress), December 2005. 1007 [I-D.iab-nat-traversal-considerations] 1008 Rosenberg, J., "Considerations for Selection of Techniques 1009 for NAT Traversal", 1010 draft-iab-nat-traversal-considerations-00 (work in 1011 progress), October 2005. 1013 [I-D.ietf-behave-rfc3489bis] 1014 Rosenberg, J., "Simple Traversal Underneath Network 1015 Address Translators (NAT) (STUN)", 1016 draft-ietf-behave-rfc3489bis-05 (work in progress), 1017 October 2006. 1019 [I-D.ietf-mmusic-ice] 1020 Rosenberg, J., "Interactive Connectivity Establishment 1021 (ICE): A Methodology for Network Address Translator (NAT) 1022 Traversal for Offer/Answer Protocols", 1023 draft-ietf-mmusic-ice-13 (work in progress), January 2007. 1025 [I-D.ietf-sipping-nat-scenarios] 1026 Boulton, C., "Best Current Practices for NAT Traversal for 1027 SIP", draft-ietf-sipping-nat-scenarios-06 (work in 1028 progress), March 2007. 1030 [I-D.irtf-p2prg-survey-search] 1031 Risson, J. and T. Moors, "Survey of Research towards 1032 Robust Peer-to-Peer Networks: Search Methods", 1033 draft-irtf-p2prg-survey-search-00 (work in progress), 1034 March 2006. 1036 [I-D.johnston-sipping-p2p-ipcom] 1037 Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet 1038 Communications", draft-johnston-sipping-p2p-ipcom-02 (work 1039 in progress), March 2006. 1041 [I-D.matthews-sipping-p2p-industrial-strength] 1042 Matthews, P., "Industrial-Strength P2P SIP", 1043 draft-matthews-sipping-p2p-industrial-strength-00 (work in 1044 progress), February 2005. 1046 [I-D.shim-sipping-p2p-arch] 1047 Shim, E., "An Architecture for Peer-to-Peer Session 1048 Initiation Protocol (P2P SIP)", 1049 draft-shim-sipping-p2p-arch-00 (work in progress), 1050 March 2006. 1052 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1053 Self-Address Fixing (UNSAF) Across Network Address 1054 Translation", RFC 3424, November 2002. 1056 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1057 June 2005. 1059 [Using-an-External-DHT] 1060 Singh, K. and H. Schulzrinne, "Using an External DHT as a 1061 SIP Location Service", Columbia University Computer 1062 Science Dept. Tech Report 388). 1064 Copy available at http://mice.cs.columbia.edu/ 1065 getTechreport.php?techreportID=388/ 1067 Authors' Addresses 1069 David A. Bryan 1070 SIPeerior Technologies and College of William and Mary 1071 3000 Easter Circle 1072 Williamsburg, Virginia 23188 1073 USA 1075 Phone: +1 757 565 0101 1076 Email: bryan@sipeerior.com 1077 Philip Matthews 1078 Avaya 1079 1135 Innovation Drive 1080 Ottawa, Ontario K2K 3G7 1081 Canada 1083 Phone: +1 613 592 4343 x224 1084 Email: philip_matthews@magma.ca 1086 Eunsoo Shim 1087 Locus Telecommunications 1088 111 Sylvan Avenue 1089 Englewood Cliffs, New Jersey 07632 1090 USA 1092 Phone: unlisted 1093 Email: eunsooshim@gmail.com 1095 Dean Willis 1096 Cisco Systems 1097 3100 Independence Pkwy #311-164 1098 Plano, Texas 75075 1099 USA 1101 Phone: unlisted 1102 Email: dean.willis@softarmor.com 1104 Full Copyright Statement 1106 Copyright (C) The IETF Trust (2007). 1108 This document is subject to the rights, licenses and restrictions 1109 contained in BCP 78, and except as set forth therein, the authors 1110 retain all their rights. 1112 This document and the information contained herein are provided on an 1113 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1114 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1115 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1116 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1117 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1118 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1120 Intellectual Property 1122 The IETF takes no position regarding the validity or scope of any 1123 Intellectual Property Rights or other rights that might be claimed to 1124 pertain to the implementation or use of the technology described in 1125 this document or the extent to which any license under such rights 1126 might or might not be available; nor does it represent that it has 1127 made any independent effort to identify any such rights. Information 1128 on the procedures with respect to rights in RFC documents can be 1129 found in BCP 78 and BCP 79. 1131 Copies of IPR disclosures made to the IETF Secretariat and any 1132 assurances of licenses to be made available, or the result of an 1133 attempt made to obtain a general license or permission for the use of 1134 such proprietary rights by implementers or users of this 1135 specification can be obtained from the IETF on-line IPR repository at 1136 http://www.ietf.org/ipr. 1138 The IETF invites any interested party to bring to its attention any 1139 copyrights, patents or patent applications, or other proprietary 1140 rights that may cover technology that may be required to implement 1141 this standard. Please address the information to the IETF at 1142 ietf-ipr@ietf.org. 1144 Acknowledgment 1146 Funding for the RFC Editor function is provided by the IETF 1147 Administrative Support Activity (IASA).