idnits 2.17.1 draft-marocco-p2psip-xpp-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 892. 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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 16, 2007) is 6006 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-06 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-03 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-01 == Outdated reference: A later version (-04) exists of draft-willis-p2psip-concepts-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Marocco 3 Internet-Draft Telecom Italia 4 Intended status: Standards Track E. Ivov 5 Expires: May 19, 2008 L. Pasteur University/SIP 6 Communicator 7 November 16, 2007 9 Extensible Peer Protocol (XPP) 10 draft-marocco-p2psip-xpp-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines the Extensible Peer Protocol (XPP), a 44 lightweight binary protocol for end-to-end sessions between peers in 45 distributed overlay networks. One of the main goals while creating 46 this protocol was support for nodes located behind firewalls and 47 NATs. XPP therefore uses UDP and allows endpoints to simultaneously 48 initiate sessions. Given the choice of the underlying protocol 49 (UDP), XPP also defines mechanisms for message fragmentation and 50 reliability. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Why UDP? . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Relation with other Proposals . . . . . . . . . . . . . . 4 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. XPP Sessions . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2. XPP Operations . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Requests and Responses . . . . . . . . . . . . . . . . . . 7 62 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Session Establishment . . . . . . . . . . . . . . . . . . 8 64 3.2. A Sample XPP Operation Scenario . . . . . . . . . . . . . 9 65 3.3. Message fragmentation . . . . . . . . . . . . . . . . . . 9 66 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.1. XPP Fragment Header . . . . . . . . . . . . . . . . . . . 11 68 4.2. XPP Message . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.4. Session Establishment . . . . . . . . . . . . . . . . . . 13 71 4.5. Session Teardown . . . . . . . . . . . . . . . . . . . . . 14 72 4.6. Session Failure . . . . . . . . . . . . . . . . . . . . . 17 73 4.7. Managing XPP Operations . . . . . . . . . . . . . . . . . 17 74 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 18 76 5.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 18 77 5.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 19 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 86 Intellectual Property and Copyright Statements . . . . . . . . . . 27 88 1. Introduction 90 This document defines the Extensible Peer Protocol (XPP), which 91 provides end-to-end delivery services for data among peers in 92 distributed overlay networks. 94 Given the popularity and wide use of firewalls and NATs in most 95 existing network configurations, one of the main goals of this 96 protocol is to provide support for them. XPP is therefore using UDP 97 as a transport protocol following guidelines provided in 98 [I-D.ietf-tsvwg-udp-guidelines], and defines a way for sessions to be 99 simultaneously initiated by both endpoints in pretty much the same 100 way that standard media sessions are negotiated with SIP [RFC3261] or 101 XMPP [RFC3920]. This makes possible the establishment of direct 102 connections between peers even if both endpoints are located behind 103 RFC 4787 [RFC4787] compliant NATs. 105 The semantics that XPP uses for session initiation and their 106 resemblance with standard call negotiation allow the use of tools 107 like ICE [I-D.ietf-mmusic-ice] and STUN [RFC3489] that further 108 facilitate session establishment. 110 We also define rudimentary mechanisms for fragmentation and 111 reliability. They are, however, not well suited for large amounts of 112 data and may require further work like for example the definition of 113 ACK rolling windows. 115 XPP is a simple protocol designed in a way that makes it easy to 116 implement and extend; it is explicitly meant to be used as the P2PSIP 117 peer protocol described in [I-D.willis-p2psip-concepts]. 119 1.1. Why UDP? 121 The main reason for the choice of UDP as a transport protocol is 122 related to NAT traversal. When two peers behind different NAT 123 devices want to establish a connection and exchange data flows, they 124 have to start sending packets simultaneously, as opposed to waiting 125 for one of the peers to initiate the session. This way, when their 126 NATs receive such packets, they would eventually match them to 127 previous outgoing packets belonging to the same session and forward 128 them to the corresponding peer. 130 It is true that the definition of three-way TCP [RFC0793] handshake, 131 also provides semantics that could be used for simultaneous 132 connection establishment; however, this mechanism is defined for 133 resolving race conditions and is not meant for use as a common 134 practice. 136 In fact, Berkeley sockets, the standard interface applications use 137 to access network functionalities exposed by the operating system, 138 are designed around a client/server model and do not natively 139 allow to initiate connections simultaneously. 141 Furthermore, other than requiring a correct implementation of the 142 full TCP state machine on both endpoints, for the simultaneous 143 establishment to succeed it is necessary that all traversed network 144 elements (expecially NATs and firewalls) are compliant with the best 145 practices specified in [I-D.ietf-behave-tcp]. Such requirements, at 146 the time of writing, are certainly much less likely to be satisfied 147 by common devices than those necessary for UDP NAT traversal 148 [RFC4787]. 150 Another weakness of TCP is its inability to handle address changes 151 within established connections. While in normal environments it is 152 possible to handle mobility at the network layer, in some scenarios 153 specifically addressed by P2PSIP maintaining the same IP address 154 after a handover or a NAT reboot is often not an option. 156 Using TCP would thus make mandatory the usage of ICE-TCP 157 [I-D.ietf-mmusic-ice-tcp], at least for handling of simultaneous 158 session establishment and mobility. Given the higher level of 159 complexity inherent to ICE-TCP compared to ICE Lite and even standard 160 ICE, using it would make XPP a lot more difficult to implement. 162 On the other hand, using UDP as the transport protocol would also 163 give us the possibility to "switch off" reliability if necessary. 164 This is sometimes necessary when using DHT algorithms based on 165 frequent optional routing table updates. 167 1.2. Relation with other Proposals 169 Since we started specifying and implementing XPP there have been two 170 other proposals for peer protocols: dSIP [I-D.bryan-p2psip-dsip] and 171 P2PP [I-D.baset-sipping-p2pcommon]. 173 While dSIP -- a textual protocol substantially based on SIP -- is 174 pretty different, P2PP has many things in common with XPP; mainly, it 175 is binary and uses a very similar encoding for parameters based on 176 type-length-value (TLV) fields. However, it misses a mechanism for 177 simultaneously initiating sessions, which is one of XPP's most 178 important features. 180 1.3. Terminology 182 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 183 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 184 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 185 described RFC 2119 [RFC2119]. 187 XPP Session: a logical relationship between two peers required for 188 transmitting XPP Messages. 190 XPP Message: either an XPP Operation Request or a XPP Operation 191 Response. An XPP Message can be transmitted as one or more XPP 192 Fragments. 194 XPP Fragment: a segment or a whole of an XPP Message not exceeding 195 the path maximum transmission unit (MTU). 197 XPP Operation: a logical relationship between an XPP Operation 198 Request and zero or more XPP Operation Responses. 200 XPP Operation Request: an XPP Message requesting the execution of a 201 given operation. 203 XPP Operation Response: an XPP Message reporting the result of an 204 operation. 206 2. Overview 208 2.1. XPP Sessions 210 XPP sessions are logical end-to-end relationships between pairs of 211 peers. A session is identified by a pair of tags univocally 212 generated by the peers and encoded in Local ID and Remote ID fields 213 of each fragment. 215 For example, an XPP session between Alice and Bob, where Alice's 216 generated tag is LA and Bob's generated tag is LB, will be 217 identified by the pair by Alice and by by Bob. 219 Peers MUST discard fragments with values in Local ID and Remote ID 220 fields not matching an active session, correctly established as 221 described in Section 4.4. 223 It is important to note that received fragments will have inverted 224 Local ID and Remote ID depending on whether they are sent by one 225 side or the other. 227 2.2. XPP Operations 229 An XPP operation contains one operation request and zero or more 230 operation responses. Requests and responses of the same operation 231 MUST be sent in opposite directions. That is, if one side has sent 232 the operation request, it cannot send responses in the same 233 operation. Similarly, if a side has received a request it can only 234 send responses for the corresponding operation and any new request 235 MUST be sent in a new operation. 237 Every XPP operation has a sequence number and an operation type that 238 serve as a way to identify and order operations. The operation 239 number and type for all operation responses must match those of the 240 corresponding request. 242 This document does not define any specific operation type. Such 243 types are to be defined by extensions of the XPP protocol according 244 to their needs. 246 The lifetime of an operation (i.e. the amount of time that the sender 247 of a request must keep the context associated with it) is also left 248 to documents extending this specification as it may vary according to 249 the operation type and the purpose it serves. 251 2.3. Requests and Responses 253 Requests and responses can be distinguished by the value of the 254 Operation Type field. Senders must set this value to the to 255 0x00000000 for all outgoing responses. Operation type values for 256 requests MUST be registered with IANA. 258 Requests and responses may have any number of parameters as specified 259 in extension documents. 261 3. Use Cases 263 3.1. Session Establishment 265 Currently XPP only supports a single mode for session initiation 266 which we refer to as simultaneous session establishment. Prior to 267 the establishment, all parameters of the session need to be 268 negotiated using external rendezvous and negotiation mechanisms such 269 as those provided by SIP [RFC3261] and SDP [RFC4566] as defined in 270 RFC 3264 [RFC3264]. 272 Alice Bob 273 | | 274 | c=IN IP4 10.0.0.10 | 275 | m=application 1234 UDP/XPP * | 276 | a=ltag: 0xAAAA | 277 | ... | 278 |================================================>| 279 | | 280 | c=IN IP4 10.0.0.20 | 281 | m=application 4321 UDP/XPP * | 282 | a=ltag: 0xBBBB | 283 | ... | 284 |<================================================| 285 | | 286 | SYN (0xBBBB, 0xAAAA) | 287 | SYN (0xAAAA, 0xBBBB) ----------------------| 288 |----------------------- / | 289 | \ / | 290 | X | 291 | / \ | 292 |<---------------------- \ | 293 | --------------------->| 294 | ACK | 295 |---------------------- ACK | 296 | \ -----------------------| 297 | \ / | 298 | X | 299 | / \ | 300 | / ---------------------->| 301 |<--------------------- | 303 Simultaneous establishment of an XPP Session. UDP packets are sent 304 between endpoints 10.0.0.10:1234 and 10.0.0.20:4321. Session is 305 identified by ID pairs (0xAAAA, 0xBBBB) and (0xBBBB, 0xAAAA) on Alice 306 and Bob respectively. 308 3.2. A Sample XPP Operation Scenario 310 XPP Operations are initiated by an Operation Request that can be 311 followed by an arbitrary number of responses. In the scenario 312 presented in Figure 2 Alice is the sender of the operation request. 313 Bob ACKs receipt of the request as soon as he gets it. At some point 314 Bob would send an Operation response that in this case would get lost 315 before reaching Alice. According to the XPP retransmission 316 mechanisms described in Section 5.2, Bob would resend the response 317 upon expiration of the corresponding timer and Alice would 318 acknowledge reception as soon as the response has reached her. 320 Alice Bob 321 | XPP Operation Request | 322 |------------------------------------------------>| 323 | ACK | 324 |<------------------------------------------------| 325 | | 326 | | 327 | XPP Operation Response | 328 | X<------------------------------------------| 329 | | 330 | XPP Operation Response |Timeout 331 |<------------------------------------------------| 332 | ACK | 333 |------------------------------------------------>| 335 A sample XPP operation. Alice sends an Operation request to Bob. Bob 336 confirms reception and later sends a response. The response does not 337 reach Alice, so Bob retransmits until the corresponding ACK is 338 received. 340 Figure 2 342 3.3. Message fragmentation 344 When storing data in an overlay, or when simply exchanging 345 information on neighboring zones, P2P applications are likely to have 346 to exchange data chunks exceeding the path MTU. XPP therefore 347 defines mechanisms for fragmentation that allow sending long XPP 348 messages over multiple XPP fragments (see Section 5.1). 350 Figure 3 describes a scenario where Alice is sending to Bob an XPP 351 operation request with a size greater than that of the path MTU. 353 Alice Bob 354 | XPP Operation Request; Fragment 1 | 355 |------------------------------------------------>| 356 | ACK 1 | 357 |<------------------------------------------------| 358 | XPP Operation Request; Fragment 2 | 359 |------------------------------------------------>| 360 | ACK 2 | 361 |<------------------------------------------------| 362 | XPP Operation Request; Fragment 3 | 363 |---------------------------------------->X | 364 | | 365 Timeout| XPP Operation Request; Fragment 3 | 366 |------------------------------------------------>| 367 | ACK 3 | 368 |<------------------------------------------------| 369 | | 370 | ... | 371 | | 372 | XPP Operation Request; Fragment n | 373 |------------------------------------------------>| 374 | ACK n | 375 |<------------------------------------------------| 377 Alice is sending to Bob a message larger than the current path MTU. 378 Fragments are transmitted one by one, and every time Alice sends a 379 packet, she would wait for Bob to respond with an ACK before 380 proceeding. In a case when no ACK is received, Alice would resend 381 the last packet. 383 Figure 3 385 4. Protocol Details 387 All XPP messages are encoded using binary fields. All integer fields 388 are carried in network byte order, that is, most significant byte 389 (octet) first. This byte order is commonly known as big-endian. The 390 transmission order is described in detail in Appendix B of RFC 791 391 [RFC0791]. 393 4.1. XPP Fragment Header 395 All XPP messages start with an 8 byte message header represented on 396 the following figure (Figure 4): 398 0 1 2 3 399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | |S|A|F|R|L|K| | 402 | Ver | Reserved |Y|C|I|E|F|P| Sequence Number | 403 | | |N|K|N|L|R|A| | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Local ID | Remote ID | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | XPP Message Fragment (Optional) ... 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 410 XPP fragment header. 412 Figure 4 414 Fields: 416 Ver: 3-bit XPP version number = 1. 418 Reserved: Flags reserved for use by future versions or extensions of 419 the protocol. MUST be set to zero by the sender and ignored by 420 the receiver. 422 SYN: Session synchronization flag. Set to 1 if this is the first 423 message in a session and 0 otherwise. 425 ACK: Fragment acknowledgment flag. Set to 1 if this message is sent 426 to acknowledge receipt of a previously sent fragment or 0 427 otherwise. 429 FIN: Session close flag. Set to 1 if no more non-ACK messages will 430 be sent in this direction. 432 REL: Fragment reliable flag. Set to 1 if the remote party is to 433 send an acknowledgment upon receipt of this fragment and 0 434 otherwise. 436 LFR: Last fragment flag. Indicates whether this is the last of a 437 series of fragments (1 or more). If a message only consists in a 438 single fragment this flag is to be set to 1. 440 KPA: Keep alive flag. Set to 1 if this is a keep alive packet sent 441 with the sole purpose of maintaining session state in intermediate 442 routing devices. 444 Sequence Number: Contains the sequence number of reliable fragment. 445 Set to a random integer between 0 and 65535 (inclusive) for a 446 first fragment and incremented by 1 for every next fragment. 448 Local ID: The local identifier of an XPP session. 450 Remote ID: The remote identifier of an XPP session. 452 4.2. XPP Message 454 Depending on their size, XPP messages can be transmitted in one or 455 more XPP fragments, one fragment per UDP packet. Every XPP fragment 456 would start with an XPP fragment header, but only the first one would 457 also contain the XPP Message Header specifying the operation number. 459 0 1 2 3 460 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Operation Number | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Operation Type | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Parameters ... 467 +-+-+-+-+-+-+-+-+-+-+-+- 469 XPP Message. 471 Operation Number: The number identifying an operation within a 472 session. 474 Operation Type: A token identifying the operation type. The field 475 is to be set to 0x00000000 for operation responses and to the 476 corresponding value for operation requests. 478 Parameters: A concatenation of parameters, as defined below 479 (Section 4.3). 481 4.3. Parameters 483 0 1 2 3 484 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type | Length | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Value ... 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Parameter. 493 Type: A token identifying the parameter type. 495 Length: The length of the value element, expressed as an unsigned 496 integral number of bytes. 498 Value: The value of the parameter. If the length reported in the 499 Length field is not a multiple of 4, a padding is added so that 500 total parameter length would always be a multiple of 4 bytes. 502 4.4. Session Establishment 504 Currently XPP only supports a single mode for session initiation 505 which we refer to as simultaneous session establishment. Prior to 506 the establishment, all parameters of the session need to be 507 negotiated using external rendezvous and negotiation mechanisms such 508 as those provided by SIP [RFC3261] and SDP [RFC4566] as defined in 509 RFC 3264 [RFC3264]. 511 Alice Bob 512 | | 513 | c=IN IP4 10.0.0.10 | 514 | m=application 1234 UDP/XPP * | 515 | a=ltag: 0xAAAA | 516 | ... | 517 |================================================>| 518 | | 519 | c=IN IP4 10.0.0.20 | 520 | m=application 4321 UDP/XPP * | 521 | a=ltag: 0xBBBB | 522 | ... | 523 |<================================================| 524 | | 525 | SYN, REL, LFR, SEQ=300 | 526 | SYN, REL, LFR, SEQ=500 LID=0xBBBB, RID=0xAAAA | 527 | LID=0xAAAA, RID=0xBBBB ---------------------| 528 |---------------------- / | 529 | \ / | 530 | \ / | 531 | X | 532 | / \ | 533 |<---------------------- \ | 534 | --------------------->| 535 | ACK, SEQ=300 | 536 | LID=0xAAAA, RID=0xBBBB ACK, SEQ=500 | 537 |--------------------- LID=0xBBBB, RID=0xAAAA | 538 | \ ----------------------| 539 | \ / | 540 | \ / | 541 | X | 542 | / \ | 543 | / ---------------------->| 544 |<--------------------- | 545 | | 547 Simultaneous establishment of an XPP Session. UDP packets are sent 548 between endpoints 10.0.0.10:1234 and 10.0.0.20:4321. Session is 549 identified by ID pairs (0xAAAA, 0xBBBB) and (0xBBBB, 0xAAAA) on Alice 550 and Bob respectively. 552 4.5. Session Teardown 554 Teardown of a particular session MUST be initiated by the signalling 555 protocol used for the establishment of the session (a BYE request in 556 the case of SIP) and is then followed by acknowledged transmission of 557 two XPP messages with the FIN bit set by the two endpoints. 559 The transmission of a message with the FIN bit set explicitly 560 indicates that the sender is not going to send any more messages 561 and, from that point in time on, it will only ACK received 562 fragments. Such a mechanism is required to let both endpoints to 563 finish transmitting messages already scheduled for sending before 564 the session is definitively destroyed. 566 Alice Bob 567 | | 568 | BYE | 569 |================================================>| 570 | | 571 | FIN, REL, LFR, SEQ=700 OK | 572 | LID=0xAAAA, RID=0xBBBB ====================| 573 |---------------------- // | 574 | \ // | 575 | \ // | 576 | X/ | 577 | //\ | 578 |<====================== \ | 579 | --------------------->| 580 | | 581 | ACK, SEQ=700 | 582 | LID=0xBBBB, RID=0xAAAA | 583 |<------------------------------------------------| 584 | | 585 | REL, SEQ=600 | 586 | LID=0xBBBB, RID=0xAAAA | 587 |<------------------------------------------------| 588 | | 589 | ACK, SEQ=600 | 590 | LID=0xAAAA, RID=0xBBBB | 591 |------------------------------------------------>| 592 | | 593 | REL, LFR, SEQ=601 | 594 | LID=0xBBBB, RID=0xAAAA | 595 |<------------------------------------------------| 596 | | 597 | ACK, SEQ=601 | 598 | LID=0xAAAA, RID=0xBBBB | 599 |------------------------------------------------>| 600 | | 601 | FIN, REL, SEQ=602 | 602 | LID=0xBBBB, RID=0xAAAA | 603 |<------------------------------------------------| 604 | | 605 | ACK, SEQ=602 | 606 | LID=0xAAAA, RID=0xBBBB | 607 |------------------------------------------------>| 608 | | 610 Session teardown. After communicating her intention to close the 611 session, Alice sends a fragment with the FIN bit set and stops 612 sending non-ACK messages. On his side Bob agrees agreed to the 613 session teardown and sends the last message he had in his local queue 614 (consisting of two fragments with sequence number 600 and 601) and 615 then closes the session sending a fragment with the FIN bit set. 617 4.6. Session Failure 619 Session failure MUST be reported to the application by the XPP 620 protocol stack when detected. The stack may detect such failure upon 621 expiration of a keep alive timeout, or loss of network connectivity. 623 Once failure has been detected, an XPP protocol stack SHOULD stop 624 keeping information about the state of the session and ignore any 625 incoming XPP fragment belonging to that session (just as it would do 626 for non-existing ones). 628 4.7. Managing XPP Operations 630 It is the responsibility of the XPP protocol stack to keep track of 631 currently active XPP operations. An operation is created when the 632 first request that belongs to it has been sent. Implementations 633 SHOULD provide to the application a means of specifying an expiration 634 delay ("D") for every request being sent. 636 The protocol stack would consider an operation terminated "D" ms 637 after the last response for that operation has been received. The 638 stack SHOULD also provide the application with a means of manually 639 ending an operation (e.g. an endOperation(operationID) method). 641 Once an operation has been ended, the protocol stack MAY either 642 ignore all incoming responses belonging to the operation, or pass 643 them to the application without a context associated. 645 5. Transport 647 All XPP messages are transported in UDP datagrams. Depending on its 648 size a single XPP message may be transported in one or more datagrams 649 using the XPP fragmentation mechanisms defined in Section 5.1. 651 Depending on their purpose XPP messages can be transported in both a 652 reliable and unreliable way. Senders must set the REL Section 4.1 653 bit of the fragment header to 1 and apply the retransmission 654 mechanisms described in section Section 5.2. 656 Unreliable messages MUST be transmitted in a single fragment and any 657 attempt to from the application to send data exceeding the size of 658 the current path MTU must result in an error. 660 5.1. Fragmentation 662 If a reliable message cannot fit the path MTU (fragment header 663 included), it MUST be split in as many fragments as necessary. Each 664 fragment MUST have the REL bit set to 1 (see Section 4.1). The value 665 of the Sequence Number in the fragment header MUST be incremented for 666 every following fragment. 668 The LFR bit (see Section 4.1) MUST be set to 1 for only in the last 669 fragment of a message as well as for messages that are not 670 fragmented. It MUST be set to 0 in all other cases. 672 5.2. Retransmissions 674 XPP fragments are transmitted one at a time. Using UDP as a 675 transport implies that some fragments may be dropped by intermediate 676 devices. Reliability is therefore accomplished through XPP fragment 677 retransmissions. Sending party SHOULD retransmit the request as soon 678 as timer T1 fires. Values for T1 would vary across retransmissions 679 starting with an interval of t0 for the first one. t0 is an estimate 680 of the round-trip time (RTT), and it defaults to 100 ms. The 681 interval would double every retransmit until it reaches t1 (1.6s by 682 default), and retransmissions would then continue with intervals of 683 t1 until an XPP ACK with the matching sequence number is received, or 684 a total of r (9 by default) fragment retransmissions have been sent. 685 If no response is received by t1 seconds after the last fragment 686 retransmission has been sent, the sending party SHOULD consider the 687 transmission unsuccessful and report failure to the application. 689 In other words, when using default values (i.e. t0=100ms, t1=1.6s and 690 r=9) fragments would be sent at times 0ms, 100ms, 300ms, 700ms, 691 1500ms, 3100ms, 4700ms, 6300ms, 7900ms, and 9500ms. At 11100ms, the 692 sender considers the transaction to have failed. 694 Note that the retransmission mechanisms that we've just described 695 MUST be used for all messages that require reliability (i.e. those 696 with the REL bit set to 1 in the fragment header) and MUST NOT be 697 applied to those that do not. 699 5.3. Keep-alive 701 In order to guarantee session persistence XPP uses periodically sent 702 keep-alive messages. 704 Every time a fragment is received within a session, timer T2 for that 705 session is set to t2 (default: t2 = 5 sec). When T2 fires, a keep- 706 alive message is sent. The message only contains the XPP fragment 707 header with both the REL and KPA bits Section 4.1 set to 1. The 708 Sequence Number for keep alive messages MUST be incremented just as 709 it would for any other request. 711 When a keep-alive fragment is received, it is acked as usual, but, 712 since it doesn't carry any data, it is not reported to the 713 application. If a keep-alive fragment transmission fails (i.e. if no 714 ack is received after applying the retransmission mechanisms from 715 section Section 5.2) the corresponding session is to be considered 716 inactive and a session failure is to be reported to the application. 718 6. Security Considerations 720 Security of the XPP protocol depends (at least) on: 722 1. security of the signalling channel used for negotiating 723 initialization parameters; 725 2. XPP transport security. Future versions of this document need to 726 give guidance for the use of DTLS [RFC4347]. 728 7. IANA Considerations 730 This document makes use following values which need to be registered 731 with IANA: 733 1. 'ltag' SDP attribute value; 735 2. 'XPP' SDP proto value; 737 8. Open Issues 739 1. Do we need to increment the seq number when sending unreliable 740 requests? 742 2. Do we need to transport operation lifetime in XPP requests? 744 9. Acknowledgments 746 This document is a mere description of what has been implemented 747 initially in SIPDHT and then in SIP Communicator opensource projects. 748 Thanks to all the smart developers contributing there; special thanks 749 to Stefano Marengo, who wrote almost all the code in the second 750 version of SIPDHT. 752 Thanks also to many people working in IETF for providing input in 753 various discussions; thanks in particular to Vijay Gurbani, Henning 754 Schulzrinne and Salman Abdul Baset for giving useful feedback in the 755 very initial phase of this work. 757 10. References 759 10.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 765 Security", RFC 4347, April 2006. 767 10.2. Informative References 769 [I-D.baset-sipping-p2pcommon] 770 Baset, S., "A Protocol for Implementing Various DHT 771 Algorithms", draft-baset-sipping-p2pcommon-00 (work in 772 progress), October 2006. 774 [I-D.bryan-p2psip-dsip] 775 Bryan, D., "dSIP: A P2P Approach to SIP Registration and 776 Resource Location", draft-bryan-p2psip-dsip-00 (work in 777 progress), February 2007. 779 [I-D.ietf-behave-tcp] 780 Guha, S., "NAT Behavioral Requirements for TCP", 781 draft-ietf-behave-tcp-06 (work in progress), April 2007. 783 [I-D.ietf-mmusic-ice] 784 Rosenberg, J., "Interactive Connectivity Establishment 785 (ICE): A Methodology for Network Address Translator (NAT) 786 Traversal for Offer/Answer Protocols", 787 draft-ietf-mmusic-ice-13 (work in progress), January 2007. 789 [I-D.ietf-mmusic-ice-tcp] 790 Rosenberg, J., "TCP Candidates with Interactive 791 Connectivity Establishment (ICE)", 792 draft-ietf-mmusic-ice-tcp-03 (work in progress), 793 March 2007. 795 [I-D.ietf-tsvwg-udp-guidelines] 796 Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 797 Application Designers", draft-ietf-tsvwg-udp-guidelines-01 798 (work in progress), June 2007. 800 [I-D.willis-p2psip-concepts] 801 Willis, D., Bryan, D., Matthews, P., and E. Shim, 802 "Concepts and Terminology for Peer to Peer SIP", 803 draft-willis-p2psip-concepts-00 (work in progress), 804 June 2006. 806 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 807 September 1981. 809 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 810 RFC 793, September 1981. 812 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 813 A., Peterson, J., Sparks, R., Handley, M., and E. 814 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 815 June 2002. 817 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 818 with Session Description Protocol (SDP)", RFC 3264, 819 June 2002. 821 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 822 "STUN - Simple Traversal of User Datagram Protocol (UDP) 823 Through Network Address Translators (NATs)", RFC 3489, 824 March 2003. 826 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 827 Protocol (XMPP): Core", RFC 3920, October 2004. 829 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 830 Description Protocol", RFC 4566, July 2006. 832 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 833 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 834 RFC 4787, January 2007. 836 Authors' Addresses 838 Enrico Marocco 839 Telecom Italia 840 Via G. Reiss Romoli, 274 841 Turin 10148 842 Italy 844 Email: enrico.marocco@telecomitalia.it 846 Emil Ivov 847 Louis Pasteur University and SIP Communicator 848 4 rue Blaise Pascal 849 Strasbourg Cedex F-67070 850 France 852 Email: emcho@sip-communicator.org 854 Full Copyright Statement 856 Copyright (C) The IETF Trust (2007). 858 This document is subject to the rights, licenses and restrictions 859 contained in BCP 78, and except as set forth therein, the authors 860 retain all their rights. 862 This document and the information contained herein are provided on an 863 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 864 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 865 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 866 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 867 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 868 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 870 Intellectual Property 872 The IETF takes no position regarding the validity or scope of any 873 Intellectual Property Rights or other rights that might be claimed to 874 pertain to the implementation or use of the technology described in 875 this document or the extent to which any license under such rights 876 might or might not be available; nor does it represent that it has 877 made any independent effort to identify any such rights. Information 878 on the procedures with respect to rights in RFC documents can be 879 found in BCP 78 and BCP 79. 881 Copies of IPR disclosures made to the IETF Secretariat and any 882 assurances of licenses to be made available, or the result of an 883 attempt made to obtain a general license or permission for the use of 884 such proprietary rights by implementers or users of this 885 specification can be obtained from the IETF on-line IPR repository at 886 http://www.ietf.org/ipr. 888 The IETF invites any interested party to bring to its attention any 889 copyrights, patents or patent applications, or other proprietary 890 rights that may cover technology that may be required to implement 891 this standard. Please address the information to the IETF at 892 ietf-ipr@ietf.org. 894 Acknowledgment 896 Funding for the RFC Editor function is provided by the IETF 897 Administrative Support Activity (IASA).