Network Working Group E. Marocco Internet-Draft Telecom Italia Intended status: Standards Track E. Ivov Expires: December 17, 2007 L. Pasteur University/SIP Communicator June 15, 2007 Extensible Peer Protocol (XPP) draft-marocco-p2psip-xpp-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 17, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Marocco & Ivov Expires December 17, 2007 [Page 1] Internet-Draft Extensible Peer Protocol (XPP) June 2007 Abstract This document defines the Extensible Peer Protocol (XPP), a lightweight binary protocol for end-to-end sessions between peers in distributed overlay networks. One of the main goals while creating this protocol was support for nodes located behind firewalls and NATs. XPP therefore uses UDP and allows endpoints to simultaneously initiate sessions. Given the choice of the underlying protocol (UDP), XPP also defines mechanisms for message fragmentation and reliability. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Why UDP? . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Relation with other Proposals . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. XPP Sessions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. XPP Operations . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Requests and Responses . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Session Establishment . . . . . . . . . . . . . . . . . . 8 3.2. A Sample XPP Operation Scenario . . . . . . . . . . . . . 9 3.3. Message fragmentation . . . . . . . . . . . . . . . . . . 9 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. XPP Fragment Header . . . . . . . . . . . . . . . . . . . 11 4.2. XPP Message . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Session Establishment . . . . . . . . . . . . . . . . . . 13 4.5. Session Teardown . . . . . . . . . . . . . . . . . . . . . 14 4.6. Session Failure . . . . . . . . . . . . . . . . . . . . . 15 4.7. Managing XPP Operations . . . . . . . . . . . . . . . . . 15 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 16 5.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Marocco & Ivov Expires December 17, 2007 [Page 2] Internet-Draft Extensible Peer Protocol (XPP) June 2007 1. Introduction This document defines the Extensible Peer Protocol (XPP), which provides end-to-end delivery services for data among peers in distributed overlay networks. Given the popularity and wide use of firewalls and NATs in most existing network configurations, one of the main goals of this protocol is to provide support for them. XPP is therefore using UDP as a transport protocol following guidelines provided in [I-D.ietf-tsvwg-udp-guidelines], and defines a way for sessions to be simultaneously initiated by both endpoints in pretty much the same way that standard media sessions are negotiated with SIP [RFC3261] or XMPP [RFC3920]. This makes possible the establishment of direct connections between peers even if both endpoints are located behind RFC 4787 [RFC4787] compliant NATs. The semantics that XPP uses for session initiation and their resemblance with standard call negotiation allow the use of tools like ICE [I-D.ietf-mmusic-ice] and STUN [RFC3489] that further facilitate session establishment. We also define rudimentary mechanisms for fragmentation and reliability. They are, however, not well suited for large amounts of data and may require further work like for example the definition of ACK rolling windows. XPP is a simple protocol designed in a way that makes it easy to implement and extend; it is explicitly meant to be used as the P2PSIP peer protocol described in [I-D.willis-p2psip-concepts]. 1.1. Why UDP? The main reason for the choice of UDP as a transport protocol is related to NAT traversal. When two peers behind different NAT devices want to establish a connection and exchange data flows, they have to start sending packets simultaneously, as opposed to waiting for one of the peers to initiate the session. This way, when their NATs receive such packets, they would eventually match them to previous outgoing packets belonging to the same session and forward them to the corresponding peer. It is true that the definition of three-way TCP [RFC0793] handshake, also provides semantics that could be used for simultaneous connection establishment; however, this mechanism is defined for resolving race conditions and is not meant for use as a common practice. Such a mechanism is likely to only work in certain situations (i.e. when both peers are located behind NATs). In a case Marocco & Ivov Expires December 17, 2007 [Page 3] Internet-Draft Extensible Peer Protocol (XPP) June 2007 where both endpoints have public addresses and are able to communicate directly, any attempt to simultaneously establish a connection will almost always fail as the reception of a first SYN request would usually trigger an RST response before the application has had the chance of sending a second corresponding SYN. Using TCP would also make mandatory usage of ICE-TCP [I-D.ietf-mmusic-ice-tcp]. Given the higher level of complexity inherent to ICE-TCP compared to ICE Lite and even standard ICE, using it would make XPP a lot more difficult to implement. Using UDP as the transport protocol would also give us the possibility to "switch off" reliability if necessary. This is sometimes necessary when using DHT algorithms based on frequent optional routing table updates. 1.2. Relation with other Proposals Since we started specifying and implementing XPP there have been two other proposals for peer protocols: dSIP [I-D.bryan-p2psip-dsip] and P2PP [I-D.baset-sipping-p2pcommon]. While dSIP -- a textual protocol substantially based on SIP -- is pretty different, P2PP has many things in common with XPP; mainly, it is binary and uses a very similar encoding for parameters based on type-length-value (TLV) fields. However, it misses a mechanism for simultaneously initiating sessions, which is one of XPP's most important features. 1.3. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described RFC 2119 [RFC2119]. XPP Session: a logical relationship between two peers required for transmitting XPP Messages. XPP Message: either an XPP Operation Request or a XPP Operation Response. An XPP Message can be transmitted as one or more XPP Fragments. XPP Fragment: a segment or a whole of an XPP Message not exceeding the path maximum transmission unit (MTU). Marocco & Ivov Expires December 17, 2007 [Page 4] Internet-Draft Extensible Peer Protocol (XPP) June 2007 XPP Operation: a logical relationship between an XPP Operation Request and zero or more XPP Operation Responses. XPP Operation Request: an XPP Message requesting the execution of a given operation. XPP Operation Response: an XPP Message reporting the result of an operation. Marocco & Ivov Expires December 17, 2007 [Page 5] Internet-Draft Extensible Peer Protocol (XPP) June 2007 2. Overview 2.1. XPP Sessions XPP sessions are logical end-to-end relationships between pairs of peers. A session is identified by a pair of tags univocally generated by the peers and encoded in Local ID and Remote ID fields of each fragment. For example, an XPP session between Alice and Bob, where Alice's generated tag is LA and Bob's generated tag is LB, will be identified by the pair by Alice and by by Bob. Peers MUST discard fragments with values in Local ID and Remote ID fields not matching an active session, correctly established as described in Section 4.4. It is important to note that received fragments will have inverted Local ID and Remote ID depending on whether they are sent by one side or the other. 2.2. XPP Operations An XPP operation contains one operation request and zero or more operation responses. Requests and responses of the same operation MUST be sent in opposite directions. That is, if one side has sent the operation request, it cannot send responses in the same operation. Similarly, if a side has received a request it can only send responses for the corresponding operation and any new request MUST be sent in a new operation. Every XPP operation has a sequence number and an operation type that serve as a way to identify and order operations. The operation number and type for all operation responses must match those of the corresponding request. This document does not define any specific operation type. Such types are to be defined by extensions of the XPP protocol according to their needs. The lifetime of an operation (i.e. the amount of time that the sender of a request must keep the context associated with it) is also left to documents extending this specification as it may vary according to the operation type and the purpose it serves. Marocco & Ivov Expires December 17, 2007 [Page 6] Internet-Draft Extensible Peer Protocol (XPP) June 2007 2.3. Requests and Responses Requests and responses can be distinguished by the value of the Operation Type field. Senders must set this value to the to 0x00000000 for all outgoing responses. Operation type values for requests MUST be registered with IANA. Requests and responses may have any number of parameters as specified in extension documents. Marocco & Ivov Expires December 17, 2007 [Page 7] Internet-Draft Extensible Peer Protocol (XPP) June 2007 3. Use Cases 3.1. Session Establishment Currently XPP only supports a single mode for session initiation which we refer to as simultaneous session establishment. Prior to the establishment, all parameters of the session need to be negotiated using external rendezvous and negotiation mechanisms such as those provided by SIP [RFC3261] and SDP [RFC4566] as defined in RFC 3264 [RFC3264]. Alice Bob | | | c=IN IP4 10.0.0.10 | | m=application 1234 UDP/XPP * | | a=ltag: 0xAAAA | | ... | |================================================>| | | | c=IN IP4 10.0.0.20 | | m=application 4321 UDP/XPP * | | a=ltag: 0xBBBB | | ... | |<================================================| | | | SYN (0xBBBB, 0xAAAA) | | SYN (0xAAAA, 0xBBBB) ----------------------| |----------------------- / | | \ / | | X | | / \ | |<---------------------- \ | | --------------------->| | ACK | |---------------------- ACK | | \ -----------------------| | \ / | | X | | / \ | | / ---------------------->| |<--------------------- | Simultaneous establishment of an XPP Session. UDP packets are sent between endpoints 10.0.0.10:1234 and 10.0.0.20:4321. Session is identified by ID pairs (0xAAAA, 0xBBBB) and (0xBBBB, 0xAAAA) on Alice and Bob respectively. Marocco & Ivov Expires December 17, 2007 [Page 8] Internet-Draft Extensible Peer Protocol (XPP) June 2007 3.2. A Sample XPP Operation Scenario XPP Operations are initiated by an Operation Request that can be followed by an arbitrary number of responses. In the scenario presented in Figure 2 Alice is the sender of the operation request. Bob ACKs receipt of the request as soon as he gets it. At some point Bob would send an Operation response that in this case would get lost before reaching Alice. According to the XPP retransmission mechanisms described in Section 5.2, Bob would resend the response upon expiration of the corresponding timer and Alice would acknowledge reception as soon as the response has reached her. Alice Bob | XPP Operation Request | |------------------------------------------------>| | ACK | |<------------------------------------------------| | | | | | XPP Operation Response | | X<------------------------------------------| | | | XPP Operation Response |Timeout |<------------------------------------------------| | ACK | |------------------------------------------------>| A sample XPP operation. Alice sends an Operation request to Bob. Bob confirms reception and later sends a response. The response does not reach Alice, so Bob retransmits until the corresponding ACK is received. Figure 2 3.3. Message fragmentation When storing data in an overlay, or when simply exchanging information on neighboring zones, P2P applications are likely to have to exchange data chunks exceeding the path MTU. XPP therefore defines mechanisms for fragmentation that allow sending long XPP messages over multiple XPP fragments (see Section 5.1). Figure 3 describes a scenario where Alice is sending to Bob an XPP operation request with a size greater than that of the path MTU. Marocco & Ivov Expires December 17, 2007 [Page 9] Internet-Draft Extensible Peer Protocol (XPP) June 2007 Alice Bob | XPP Operation Request; Fragment 1 | |------------------------------------------------>| | ACK 1 | |<------------------------------------------------| | XPP Operation Request; Fragment 2 | |------------------------------------------------>| | ACK 2 | |<------------------------------------------------| | XPP Operation Request; Fragment 3 | |---------------------------------------->X | | | Timeout| XPP Operation Request; Fragment 3 | |------------------------------------------------>| | ACK 3 | |<------------------------------------------------| | | | ... | | | | XPP Operation Request; Fragment n | |------------------------------------------------>| | ACK n | |<------------------------------------------------| Alice is sending to Bob a message larger than the current path MTU. Fragments are transmitted one by one, and every time Alice sends a packet, she would wait for Bob to respond with an ACK before proceeding. In a case when no ACK is received, Alice would resend the last packet. Figure 3 Marocco & Ivov Expires December 17, 2007 [Page 10] Internet-Draft Extensible Peer Protocol (XPP) June 2007 4. Protocol Details All XPP messages are encoded using binary fields. All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in Appendix B of RFC 791 [RFC0791]. 4.1. XPP Fragment Header All XPP messages start with an 8 byte message header represented on the following figure (Figure 4): 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |S|A|R|L|K| | | Ver | Reserved |Y|C|E|F|P| Sequence Number | | | |N|K|L|R|A| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ID | Remote ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | XPP Message Fragment (Optional) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- XPP fragment header. Figure 4 Fields: Ver: 3-bit XPP version number = 1. Reserved: Flags reserved for use by future versions or extensions of the protocol. MUST be set to zero by the sender and ignored by the receiver. SYN: Session synchronization flag. Set to 1 if this is the first message in a session and 0 otherwise. ACK: Fragment acknowledgment flag. Set to 1 if this message is sent to acknowledge receipt of a previously sent fragment or 0 otherwise. Marocco & Ivov Expires December 17, 2007 [Page 11] Internet-Draft Extensible Peer Protocol (XPP) June 2007 REL: Fragment reliable flag. Set to 1 if the remote party is to send an acknowledgment upon receipt of this fragment and 0 otherwise. LFR: Last fragment flag. Indicates whether this is the last of a series of fragments (1 or more). If a message only consists in a single fragment this flag is to be set to 1. KPA: Keep alive flag. Set to 1 if this is a keep alive packet sent with the sole purpose of maintaining session state in intermediate routing devices. Sequence Number: Contains the sequence number of reliable fragment. Set to a random integer between 0 and 65535 (inclusive) for a first fragment and incremented by 1 for every next fragment. Local ID: The local identifier of an XPP session. Remote ID: The remote identifier of an XPP session. 4.2. XPP Message Depending on their size, XPP messages can be transmitted in one or more XPP fragments, one fragment per UDP packet. Every XPP fragment would start with an XPP fragment header, but only the first one would also contain the XPP Message Header specifying the operation number. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameters ... +-+-+-+-+-+-+-+-+-+-+-+- XPP Message. Operation Number: The number identifying an operation within a session. Operation Type: A token identifying the operation type. The field is to be set to 0x00000000 for operation responses and to the corresponding value for operation requests. Marocco & Ivov Expires December 17, 2007 [Page 12] Internet-Draft Extensible Peer Protocol (XPP) June 2007 Parameters: A concatenation of parameters, as defined below (Section 4.3). 4.3. Parameters 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter. Type: A token identifying the parameter type. Length: The length of the value element, expressed as an unsigned integral number of bytes. Value: The value of the parameter. If the length reported in the Length field is not a multiple of 4, a padding is added so that total parameter length would always be a multiple of 4 bytes. 4.4. Session Establishment Currently XPP only supports a single mode for session initiation which we refer to as simultaneous session establishment. Prior to the establishment, all parameters of the session need to be negotiated using external rendezvous and negotiation mechanisms such as those provided by SIP [RFC3261] and SDP [RFC4566] as defined in RFC 3264 [RFC3264]. Marocco & Ivov Expires December 17, 2007 [Page 13] Internet-Draft Extensible Peer Protocol (XPP) June 2007 Alice Bob | | | c=IN IP4 10.0.0.10 | | m=application 1234 UDP/XPP * | | a=ltag: 0xAAAA | | ... | |================================================>| | | | c=IN IP4 10.0.0.20 | | m=application 4321 UDP/XPP * | | a=ltag: 0xBBBB | | ... | |<================================================| | | | SYN, REL, LFR, SEQ=300 | | SYN, REL, LFR, SEQ=500 LID=0xBBBB, RID=0xAAAA | | LID=0xAAAA, RID=0xBBBB ---------------------| |---------------------- / | | \ / | | \ / | | X | | / \ | |<---------------------- \ | | --------------------->| | ACK, SEQ=300 | | LID=0xAAAA, RID=0xBBBB ACK, SEQ=500 | |--------------------- LID=0xBBBB, RID=0xAAAA | | \ ----------------------| | \ / | | \ / | | X | | / \ | | / ---------------------->| |<--------------------- | | | Simultaneous establishment of an XPP Session. UDP packets are sent between endpoints 10.0.0.10:1234 and 10.0.0.20:4321. Session is identified by ID pairs (0xAAAA, 0xBBBB) and (0xBBBB, 0xAAAA) on Alice and Bob respectively. 4.5. Session Teardown Teardown of a particular session MUST be handled through the semantics of the same protocol used for the establishment of that session. In the case of SIP this would mean sending a BYE request into the dialog established with the original INVITE request. Marocco & Ivov Expires December 17, 2007 [Page 14] Internet-Draft Extensible Peer Protocol (XPP) June 2007 4.6. Session Failure Session failure MUST be reported to the application by the XPP protocol stack when detected. The stack may detect such failure upon expiration of a keep alive timeout, or loss of network connectivity. Once failure has been detected, an XPP protocol stack SHOULD stop keeping information about the state of the session and ignore any incoming XPP fragment belonging to that session (just as it would do for non-existing ones). 4.7. Managing XPP Operations It is the responsibility of the XPP protocol stack to keep track of currently active XPP operations. An operation is created when the first request that belongs to it has been sent. Implementations SHOULD provide to the application a means of specifying an expiration delay ("D") for every request being sent. The protocol stack would consider an operation terminated "D" ms after the last response for that operation has been received. The stack SHOULD also provide the application with a means of manually ending an operation (e.g. an endOperation(operationID) method). Once an operation has been ended, the protocol stack MAY either ignore all incoming responses belonging to the operation, or pass them to the application without a context associated. Marocco & Ivov Expires December 17, 2007 [Page 15] Internet-Draft Extensible Peer Protocol (XPP) June 2007 5. Transport All XPP messages are transported in UDP datagrams. Depending on its size a single XPP message may be transported in one or more datagrams using the XPP fragmentation mechanisms defined in Section 5.1. Depending on their purpose XPP messages can be transported in both a reliable and unreliable way. Senders must set the REL Section 4.1 bit of the fragment header to 1 and apply the retransmission mechanisms described in section Section 5.2. Unreliable messages MUST be transmitted in a single fragment and any attempt to from the application to send data exceeding the size of the current path MTU must result in an error. 5.1. Fragmentation If a reliable message cannot fit the path MTU (fragment header included), it MUST be split in as many fragments as necessary. Each fragment MUST have the REL bit set to 1 (see Section 4.1). The value of the Sequence Number in the fragment header MUST be incremented for every following fragment. The LFR bit (see Section 4.1) MUST be set to 1 for only in the last fragment of a message as well as for messages that are not fragmented. It MUST be set to 0 in all other cases. 5.2. Retransmissions XPP fragments are transmitted one at a time. Using UDP as a transport implies that some fragments may be dropped by intermediate devices. Reliability is therefore accomplished through XPP fragment retransmissions. Sending party SHOULD retransmit the request as soon as timer T1 fires. Values for T1 would vary across retransmissions starting with an interval of t0 for the first one. t0 is an estimate of the round-trip time (RTT), and it defaults to 100 ms. The interval would double every retransmit until it reaches t1 (1.6s by default), and retransmissions would then continue with intervals of t1 until an XPP ACK with the matching sequence number is received, or a total of r (9 by default) fragment retransmissions have been sent. If no response is received by t1 seconds after the last fragment retransmission has been sent, the sending party SHOULD consider the transmission unsuccessful and report failure to the application. In other words, when using default values (i.e. t0=100ms, t1=1.6s and r=9) fragments would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, 7900ms, and 9500ms. At 11100ms, the sender considers the transaction to have failed. Marocco & Ivov Expires December 17, 2007 [Page 16] Internet-Draft Extensible Peer Protocol (XPP) June 2007 Note that the retransmission mechanisms that we've just described MUST be used for all messages that require reliability (i.e. those with the REL bit set to 1 in the fragment header) and MUST NOT be applied to those that do not. 5.3. Keep-alive In order to guarantee session persistence XPP uses periodically sent keep-alive messages. Every time a fragment is received within a session, timer T2 for that session is set to t2 (default: t2 = 5 sec). When T2 fires, a keep- alive message is sent. The message only contains the XPP fragment header with both the REL and KPA bits Section 4.1 set to 1. The Sequence Number for keep alive messages MUST be incremented just as it would for any other request. When a keep-alive fragment is received, it is acked as usual, but, since it doesn't carry any data, it is not reported to the application. If a keep-alive fragment transmission fails (i.e. if no ack is received after applying the retransmission mechanisms from section Section 5.2) the corresponding session is to be considered inactive and a session failure is to be reported to the application. Marocco & Ivov Expires December 17, 2007 [Page 17] Internet-Draft Extensible Peer Protocol (XPP) June 2007 6. Security Considerations Security of the XPP protocol depends (at least) on: 1. security of the signalling channel used for negotiating initialization parameters; 2. XPP transport security. Future versions of this document need to give guidance for the use of DTLS [RFC4347]. Marocco & Ivov Expires December 17, 2007 [Page 18] Internet-Draft Extensible Peer Protocol (XPP) June 2007 7. IANA Considerations This document makes use following values which need to be registered with IANA: 1. 'ltag' SDP attribute value; 2. 'XPP' SDP proto value; Marocco & Ivov Expires December 17, 2007 [Page 19] Internet-Draft Extensible Peer Protocol (XPP) June 2007 8. Open Issues 1. Do we need to increment the seq number when sending unreliable requests? 2. Do we need to transport operation lifetime in XPP requests? Marocco & Ivov Expires December 17, 2007 [Page 20] Internet-Draft Extensible Peer Protocol (XPP) June 2007 9. Acknowledgments This document is a mere description of what has been implemented initially in SIPDHT and then in SIP Communicator opensource projects. Thanks to all the smart developers contributing there; special thanks to Stefano Marengo, who wrote almost all the code in the second version of SIPDHT. Thanks also to many people working in IETF for providing input in various discussions; thanks in particular to Vijay Gurbani, Henning Schulzrinne and Salman Abdul Baset for giving useful feedback in the very initial phase of this work. Marocco & Ivov Expires December 17, 2007 [Page 21] Internet-Draft Extensible Peer Protocol (XPP) June 2007 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. 10.2. Informative References [I-D.baset-sipping-p2pcommon] Baset, S., "A Protocol for Implementing Various DHT Algorithms", draft-baset-sipping-p2pcommon-00 (work in progress), October 2006. [I-D.bryan-p2psip-dsip] Bryan, D., "dSIP: A P2P Approach to SIP Registration and Resource Location", draft-bryan-p2psip-dsip-00 (work in progress), February 2007. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in progress), January 2007. [I-D.ietf-mmusic-ice-tcp] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-tcp-03 (work in progress), March 2007. [I-D.ietf-tsvwg-udp-guidelines] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", draft-ietf-tsvwg-udp-guidelines-01 (work in progress), June 2007. [I-D.willis-p2psip-concepts] Willis, D., Bryan, D., Matthews, P., and E. Shim, "Concepts and Terminology for Peer to Peer SIP", draft-willis-p2psip-concepts-00 (work in progress), June 2006. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. Marocco & Ivov Expires December 17, 2007 [Page 22] Internet-Draft Extensible Peer Protocol (XPP) June 2007 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. Marocco & Ivov Expires December 17, 2007 [Page 23] Internet-Draft Extensible Peer Protocol (XPP) June 2007 Authors' Addresses Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy Email: enrico.marocco@telecomitalia.it Emil Ivov Louis Pasteur University and SIP Communicator 4 rue Blaise Pascal Strasbourg Cedex F-67070 France Email: emcho@sip-communicator.org Marocco & Ivov Expires December 17, 2007 [Page 24] Internet-Draft Extensible Peer Protocol (XPP) June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Marocco & Ivov Expires December 17, 2007 [Page 25]