idnits 2.17.1 draft-ietf-p2psip-service-discovery-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == Line 238 has weird spacing: '...ExtType type...' -- The document date (April 1, 2012) is 4407 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-21 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group J. Maenpaa 3 Internet-Draft G. Camarillo 4 Intended status: Standards Track Ericsson 5 Expires: October 3, 2012 April 1, 2012 7 Service Discovery Usage for REsource LOcation And Discovery (RELOAD) 8 draft-ietf-p2psip-service-discovery-05.txt 10 Abstract 12 REsource LOcation and Discovery (RELOAD) does not define a generic 13 service discovery mechanism as part of the base protocol. This 14 document defines how the Recursive Distributed Rendezvous (ReDiR) 15 service discovery mechanism used in OpenDHT can be applied to RELOAD 16 overlays to provide a generic service discovery mechanism. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on October 3, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 4 55 4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . . 6 56 4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. Selecting the Starting Level . . . . . . . . . . . . . . . 7 58 4.3. Service Provider Registration . . . . . . . . . . . . . . 7 59 4.4. Refreshing Registrations . . . . . . . . . . . . . . . . . 8 60 4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 9 61 4.6. Removing Registrations . . . . . . . . . . . . . . . . . . 9 62 5. Access Control Rules . . . . . . . . . . . . . . . . . . . . . 9 63 6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 10 64 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8. Overlay Configuration Document Extension . . . . . . . . . . . 12 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 10.1. Access Control Policies . . . . . . . . . . . . . . . . . 13 69 10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 13 70 10.3. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . . 13 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] is a 80 peer-to-peer signaling protocol that can be used to maintain an 81 overlay network, and to store data in and retrieve data from the 82 overlay. Although RELOAD defines a Traversal Using Relays around 83 Network Address Translation (TURN) specific service discovery 84 mechanism, it does not define a generic service discovery mechanism 85 as part of the base protocol. This document defines how the 86 Recursive Distributed Rendezvous (ReDiR) service discovery mechanism 87 [Redir] used in OpenDHT can be applied to RELOAD overlays. 89 In a Peer-to-Peer (P2P) overlay network such as a RELOAD Overlay 90 Instance, the peers forming the overlay share their resources in 91 order to provide the service the system has been designed to provide. 92 The peers in the overlay both provide services to other peers and 93 request services from other peers. Examples of possible services 94 peers in a RELOAD Overlay Instance can offer to each other include a 95 TURN relay service, a voice mail service, a gateway location service, 96 and a transcoding service. Typically, only a small subset of the 97 peers participating in the system are providers of a given service. 98 A peer that wishes to use a particular service faces the problem of 99 finding peers that are providing that service from the Overlay 100 Instance. 102 A naive way to perform service discovery is to store the Node-IDs of 103 all nodes providing a particular service under a well-known key k. 104 The limitation of this approach is that it scales linearly in the 105 number of nodes that provide the service. The problem is two-fold: 106 the node n that is responsible for service s identified by key k may 107 end up storing a large number of Node-IDs and most importantly, may 108 also become overloaded since all service lookup requests for service 109 s will need to be answered by node n. An efficient service discovery 110 mechanism does not overload the nodes storing pointers to service 111 providers. In addition, the mechanism must ensure that the load of 112 providing a given service is distributed evenly among the nodes 113 providing the service. 115 ReDiR implements service discovery by building a tree structure of 116 the nodes that provide a particular service and embedding it into the 117 RELOAD Overlay Instance using RELOAD Store and Fetch requests. Each 118 service provided in the Overlay Instance has its own tree. The nodes 119 in a ReDiR tree contain pointers to service providers. During 120 service discovery, a peer wishing to use a given service fetches 121 ReDiR tree nodes one-by-one from the RELOAD Overlay Instance until it 122 finds a service provider responsible for its Node-ID. It has been 123 proved that ReDiR can find a service provider using only a constant 124 number of Fetch operations [Redir]. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 This document uses the terminology and definitions from the Concepts 133 and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] 134 draft. 136 DHT: Distributed Hash Tables (DHTs) are a class of decentralized 137 distributed systems that provide a lookup service similar to a 138 hash table. Given a key, any participating peer can retrieve the 139 value associated with that key. The responsibility for 140 maintaining the mapping from keys to values is distributed among 141 the peers. 143 H(x): Hash calculated over x. 145 I(l,k): The unique interval at level l in the ReDiR tree that 146 encloses key k. 148 n.id: Node-ID of node n. 150 Namespace: An arbitrary identifier that identifies a service 151 provided in the RELOAD Overlay Instance. An example of a 152 namespace is "voice-mail". The namespace is an UTF-8 text string. 154 numBitsInNodeId: Number of bits in a Node-ID. 156 ReDiR tree: A tree structure of the nodes that provide a particular 157 service. The nodes embed the ReDiR tree into the RELOAD Overlay 158 Instance using RELOAD Store and Fetch requests. 160 Successor: The successor of identifier k in namespace ns is the node 161 that has joined ns whose identifier most immediately follows k. 163 3. Introduction to ReDiR 165 Recursive Distributed Rendezvous (ReDiR) [Redir] does not require new 166 functionality from the RELOAD base protocol. This is possible since 167 ReDiR interacts with the RELOAD overlay through a put/get API using 168 RELOAD Store and Fetch requests. ReDiR builds a tree structure of 169 the nodes that provide a particular service and embeds it into the 170 RELOAD Overlay Instance using the Store and Fetch requests. ReDiR 171 performs lookup in a logarithmic number of Fetch operations with high 172 probability. Further, if the tree's height is estimated based on 173 past lookups, the average lookup can be reduced to a constant number 174 of Fetch operations assuming that Node-IDs are distributed uniformly 175 at random. 177 In ReDiR, each service provided in the overlay is identified by an 178 arbitrary identifier, called its namespace. All service providers 179 join a namespace and peers wishing to use a service perform lookups 180 within the namespace of the service. A ReDiR lookup for identifier k 181 in namespace ns returns a node that has joined ns whose identifier is 182 the closest successor of k. 184 Each tree node in the ReDiR tree contains a list of Node-IDs of peers 185 providing a particular service. Each node in the tree has a level. 186 The root is at level 0, the immediate children of the root are at 187 level 1, and so forth. The ReDiR tree has a branching factor, whose 188 value is determined by a new element in the RELOAD overlay 189 configuration document, called branching-factor. At every level i in 190 the tree, there are at most branching-factor^i nodes. The nodes at 191 any level are labeled from left to right, such that a pair (i,j) 192 uniquely identifies the jth node from the left at level i. This tree 193 is embedded into the RELOAD Overlay Instance node by node, by storing 194 the values of node (i,j) at key H(namespace,i,j). As an example, the 195 root of the tree for a voice mail service is stored at H("voice- 196 mail",0,0). Each node (i,j) in the tree is associated with 197 branching-factor intervals of the DHT keyspace as follows: 199 [2^numBitsInNodeID*b^(-i)*(j+(b'/b)), 200 2^numBitsInNodeID*b^(-i)*(j+((b'+1)/b))), for 0<=b'; 240 opaque namespace<0..2^16-1>; 241 uint16 level; 242 uint16 node; 243 uint16 length; 245 select (type) { 246 /* This type may be extended */ 247 } extension; 249 } RedirServiceProvider; 251 The contents of the RedirServiceProvider Resource Record are as 252 follows: 254 type 255 The type of an extension to the RedirServiceProvider Resource 256 Record. Unknown types are allowed. 258 detination_list 259 A list of IDs through which a message is to be routed to reach the 260 service provider. The destination list consists of a sequence of 261 Destination values. The contents of the Destination structure are 262 as defined in RELOAD base [I-D.ietf-p2psip-base]. 264 namespace 265 An opaque string containing the namespace. 267 level 268 The level in the ReDiR tree. 270 node 271 The position of the node storing this RedirServiceProvider record 272 at the current level in the ReDiR tree. 274 length 275 The length of the rest of the Resource Record. 277 extension 278 An extension value. The RedirServiceProvider Resource Record can 279 be extended to include for instance service or service provider 280 specific information. 282 4.2. Selecting the Starting Level 284 Before registering as a service provider or performing a service 285 lookup, a peer needs to determine the starting level Lstart for the 286 registration or lookup operation in the ReDiR tree. It is 287 RECOMMENDED that Lstart is initially set to 2. In subsequent 288 registrations, Lstart MUST be set to the lowest level at which 289 registration last completed. 291 In the case of service lookups, nodes MUST record the levels at which 292 the last 16 service lookups completed and take Lstart to be the mode 293 of those depths. 295 4.3. Service Provider Registration 297 A node MUST use the following procedure to register as a service 298 provider in the RELOAD Overlay Instance: 300 1. A node n with Node-ID n.id wishing to register as a service 301 provider starts from level Lstart (see Section 4.2 for the 302 details on selecting the starting level). Therefore, node n sets 303 level=Lstart. 304 2. Node n MUST send a RELOAD Fetch request to fetch the contents of 305 the tree node associated with I(level,n.id). An interval I(l,k) 306 is defined as the unique interval at level l in the ReDiR tree 307 that encloses key k. The fetch MUST be a wildcard fetch. 308 3. Node n MUST send a RELOAD Store request to add its 309 RedirServiceProvider entry to the dictionary stored in the tree 310 node associated with I(level,n.id) 311 4. If node n's Node-ID is the numerically lowest or highest among 312 the Node-IDs stored in the tree node associated with 313 I(Lstart,n.id), node n MUST continue up the tree towards the root 314 (level 0), repeating steps 2 and 3. Node n MUST continue this 315 until it reaches either the root or a level at which n.id is not 316 the lowest or highest Node-ID in the interval I(level,n.id). 317 5. Node n MUST also walk down the tree through tree nodes associated 318 with the intervals I(Lstart,n.id),I(Lstart+1,n.id),..., at each 319 step fetching the current contents of the tree node, and storing 320 its RedirServiceProvider record if n.id is the lowest or highest 321 Node-ID in the interval. Node n MUST end this downward walk when 322 it reaches a level at which it is the only service provider in 323 the interval. 325 Note that above, when we refer to 'the tree node associated with 326 I(l,k)', we mean the entire tree node (that is, all the intervals 327 within the tree node) responsible for interval I(l,k). In contrast, 328 I(l,k) refers to a specific interval within a tree node. 330 4.4. Refreshing Registrations 332 All state in the ReDiR tree is soft. Therefore, a service provider 333 needs to periodically repeat the registration process to refresh its 334 RedirServiceProvider Resource Record. If a record expires, it MUST 335 be dropped from the dictionary by the peer storing the tree node. 336 Deciding an appropriate lifetime for the RedirServiceProvider 337 Resource Records is up to each service provider. Every service 338 provider MUST repeat the entire registration process periodically 339 until it leaves the RELOAD Overlay Instance. 341 Note that no new mechanisms are needed to keep track of the remaining 342 lifetime of RedirServiceProvider records. The 'storage_time' and 343 'lifetime' fields of RELOAD's StoredData structure can be used for 344 this purpose in the usual way. 346 4.5. Service Lookups 348 The purpose of a service lookup on identifier k in namespace ns is to 349 find the node that has joined ns whose identifier most immediately 350 follows identifier k. 352 A service lookup is similar to the registration operation. The 353 service lookup starts from some level level=Lstart (see Section 4.2 354 for the details on selecting the starting level). At each step, the 355 node n wishing to discover a service provider MUST fetch the tree 356 node associated with the current interval I(level,n.id) using a 357 RELOAD Fetch request and MUST determine where to look next as 358 follows: 360 1. If the successor of node n is not present in the tree node 361 associated with I(level,n.id), then its successor must occur in a 362 larger range of the keyspace. Node n MUST set level=level-1 and 363 try again. 364 2. If n.id is sandwiched between two Node-IDs in I(level,n.id), the 365 successor must lie somewhere in I(level,n.id). Node n MUST set 366 level=level+1 and repeat. 367 3. Otherwise, there is a Node-ID s stored in the node associated 368 with I(level,n.id) whose identifier succeeds n.id, and there are 369 no Node-IDs between n.id and s. Thus, s must be the closest 370 successor of n.id, and the lookup is done. 372 Note that above, when we refer to 'the tree node associated with 373 I(l,k)', we mean the entire tree node (that is, all the intervals 374 within the tree node) responsible for interval I(l,k). In contrast, 375 I(l,k) refers to a specific interval within a tree node. 377 4.6. Removing Registrations 379 Before leaving the RELOAD Overlay Instance, a service provider MUST 380 remove the RedirServiceProvider records it has stored by storing 381 exists=False values in their place, as described in 382 [I-D.ietf-p2psip-base]. 384 5. Access Control Rules 386 As specified in RELOAD base [I-D.ietf-p2psip-base], every kind which 387 is storable in an overlay must be associated with an access control 388 policy. This policy defines whether a request from a given node to 389 operate on a given value should succeed or fail. Usages can define 390 any access control rules they choose, including publicly writable 391 values. 393 ReDiR requires an access control policy that allows multiple nodes in 394 the overlay read and write access to the ReDiR tree nodes stored in 395 the overlay. Therefore, none of the access control policies 396 specified in RELOAD base [I-D.ietf-p2psip-base] is sufficient. 398 This document defines a new access control policy, called NODE-ID- 399 MATCH. In this policy, a given value MUST be written and overwritten 400 only if the the request is signed with a key associated with a 401 certificate whose Node-ID is equal to the dictionary key. In 402 addition, provided that exists=TRUE, the Node-ID MUST belong to one 403 of the intervals associated with the tree node (the number of 404 intervals each tree node has is determined by the branching-factor 405 parameter). Finally, provided that exists=TRUE, 406 H(namespace,level,node), where namespace, level, and node are taken 407 from the RedirServiceProvider structure being stored, MUST be equal 408 to the Resource-ID for the resource. The NODE-ID-MATCH policy may 409 only be used with dictionary types. 411 6. REDIR Kind Definition 413 This section defines the REDIR kind. 415 Name 416 REDIR 418 Kind IDs 419 The Resource Name for the REDIR Kind-ID is created by 420 concatenating three pieces of information: namespace, level, and 421 node number. Namespace is a string identifying a service, such as 422 "voice-mail". Level is an integer specifying a level in the ReDiR 423 tree. Node number is an integer identifying a ReDiR tree node at 424 a specific level. The data stored is a RedirServiceProvider 425 structure that was defined in Section 4.1. 427 Data Model 428 The data model for the REDIR Kind-ID is dictionary. The 429 dictionary key is the Node-ID of the service provider. 431 Access Control 432 The access control policy for the REDIR kind is the NODE-ID-MATCH 433 policy that was defined in Section 5. 435 7. Example 437 Figure 2 shows an example of a ReDiR tree containing information 438 about four different service providers whose Node-IDs are 2, 3, 4, 439 and 7. In the example, numBitsInNodeID=4. Initially, the ReDiR tree 440 is empty. 442 Level 0 ____2_3___4_____7_|__________________ 443 | | 444 Level 1 ____2_3_|_4_____7 ________|________ 445 | | | | 446 Level 2 ___|2_3 4__|__7 ___|___ ___|___ 447 | | | | | | | | 448 Level 3 _|_ _|3 _|_ _|_ _|_ _|_ _|_ _|_ 450 Figure 2: Example of a ReDiR tree 452 First, peer 2 whose Node-ID is 2 joins the namespace. Since this is 453 the first registration peer 2 performs, peer 2 sets the starting 454 level Lstart to 2, as was described in Section 4.2. Also all other 455 peers in this example will start from level 2. First, peer 2 fetches 456 the contents of the tree node associated with interval I(2,2) from 457 the overlay. Peer 2 also stores its RedirServiceProvider record in 458 that tree node. Since peer 2's Node-ID is the only Node-ID stored in 459 the tree node (i.e., peer 2's Node-ID fulfills the condition that it 460 is the numerically lowest or highest among the keys stored in the 461 node), peer 2 continues up the tree. In fact, peer 2 continues up in 462 the tree all the way to the root inserting its own Node-ID in all 463 levels since the tree is empty (which means that peer 2's Node-ID 464 always fulfills the condition that it is the numerically lowest or 465 highest Node-ID in the interval I(level, 2) during the upward walk). 466 As described in Section 4.3, peer 2 also walks down the tree. The 467 downward walk peer 2 does ends at level 2 since peer 2 is the only 468 node in its interval at that level. 470 The next peer to join the namespace is peer 3, whose Node-ID is 3. 471 Peer 3 starts from level 2. At that level, peer 3 stores its 472 RedirServiceProvider record in the same interval I(2,3) that already 473 contains the Node-ID of peer 2. Since peer 3 has the numerically 474 highest Node-ID in the tree node associated with I(2,3), peer 3 475 continues up the tree. Peer 3 stores its RedirServiceProvider record 476 also at levels 1 and 0 since its Node-ID is numerically highest among 477 the Node-IDs stored in the intervals to which its own Node-ID 478 belongs. Peer 3 also does a downward walk which starts from level 2 479 (i.e., the starting level). Since peer 3 is not the only node in 480 interval I(2,3), it continues down the tree to level 3. The downward 481 walk ends at this level since peer 3 is the only service provider in 482 the interval I(3,3). 484 The third peer to join the namespace is peer 7, whose Node-ID is 7. 486 Like the two earlier peers, also peer 7 starts from level 2 because 487 this is the first registration it performs. Peer 7 stores its 488 RedirServiceProvider record at level 2. At level 1, peer 7 has the 489 numerically highest (and lowest) Node-ID in its interval I(1,7) 490 (because it is the only node in interval I(1,7); peers 2 and 3 are 491 stored in the same tree node but in a different interval) and 492 therefore it stores its Node-ID in the tree node associated with that 493 interval. Peer 7 also has the numerically highest Node-ID in the 494 interval I(0,7) associated with its Node-ID at level 0. Finally, 495 peer 7 performs a downward walk, which ends at level 2 because peer 7 496 is the only node in its interval at that level. 498 The final peer to join the ReDiR tree is peer 4, whose Node-ID is 4. 499 Peer 4 starts by storing its RedirServiceProvider record at level 2. 500 Since it has the numerically lowest Node-ID in the tree node 501 associated with interval I(2,4), it continues up in the tree to level 502 1. At level 1, peer 4 stores its record in the tree node associated 503 with interval I(1,4) because it has the numerically lowest Node-ID in 504 that interval. Next, peer 4 continues to the root level, at which it 505 stores its RedirServiceProvider record and finishes the upward walk 506 since the root level was reached. Peer 4 also does a downward walk 507 starting from level 2. The downward walk stops at level 2 because 508 peer 4 is the only peer in the interval I(2,4). 510 8. Overlay Configuration Document Extension 512 This document extends the RELOAD overlay configuration document by 513 adding a new element "branching-factor" inside the new "REDIR" kind 514 element: 516 redir:branching-factor: The branching factor of the ReDir tree. The 517 default value is 10. 519 This new element is formally defined as follows: 521 namespace redir = "urn:ietf:params:xml:ns:p2p:service-discovery" 523 parameter &= element redir:branching-factor { xsd:unsignedInt } 525 The 'redir' namespace is added into the element 526 in the overlay configuration file. 528 9. Security Considerations 530 There are no new security considerations introduced in this document. 531 The security considerations of RELOAD [I-D.ietf-p2psip-base] apply. 533 10. IANA Considerations 535 10.1. Access Control Policies 537 This document introduces one additional access control policy to the 538 "RELOAD Access Control Policy" Registry: 540 NODE-ID-MATCH 542 This access control policy was described in Section 5. 544 10.2. Data Kind-ID 546 This document introduces one additional data Kind-ID to the "RELOAD 547 Data Kind-ID" Registry: 549 +--------------+------------+----------+ 550 | Kind | Kind-ID | RFC | 551 +--------------+------------+----------+ 552 | REDIR | 104 | RFC-AAAA | 553 +--------------+------------+----------+ 555 This Kind-ID was defined in Section 6. 557 10.3. ReDiR Namespaces 559 IANA SHALL create a "ReDiR Namespaces" Registry. Entries in this 560 registry are strings denoting ReDiR namespace values. The initial 561 contents of this registry are: 563 +----------------+----------+ 564 | Namespace | RFC | 565 +----------------+----------+ 566 | turn-server | RFC-AAAA | 567 +----------------+----------+ 568 | voice-mail | RFC-AAAA | 569 +----------------+----------+ 571 11. Acknowledgments 573 The authors would like to thank Marc Petit-Huguenin for his comments 574 on the draft. 576 12. References 578 12.1. Normative References 580 [I-D.ietf-p2psip-base] 581 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 582 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 583 Base Protocol", draft-ietf-p2psip-base-21 (work in 584 progress), March 2012. 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 12.2. Informative References 591 [I-D.ietf-p2psip-concepts] 592 Bryan, D., Willis, D., Shim, E., Matthews, P., and S. 593 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 594 draft-ietf-p2psip-concepts-04 (work in progress), 595 October 2011. 597 [Redir] Rhea, S., Godfrey, P., Karp, B., Kubiatowicz, J., 598 Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open 599 DHT: A Public DHT Service and Its Uses". 601 Authors' Addresses 603 Jouni Maenpaa 604 Ericsson 605 Hirsalantie 11 606 Jorvas 02420 607 Finland 609 Email: Jouni.Maenpaa@ericsson.com 610 Gonzalo Camarillo 611 Ericsson 612 Hirsalantie 11 613 Jorvas 02420 614 Finland 616 Email: Gonzalo.Camarillo@ericsson.com