TOC 
Network Working GroupE. Marocco
Internet-DraftTelecom Italia
Intended status: Standards TrackE. Ivov
Expires: December 17, 2007L. 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 © The IETF Trust (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
    1.1.  Why UDP?
    1.2.  Relation with other Proposals
    1.3.  Terminology
2.  Overview
    2.1.  XPP Sessions
    2.2.  XPP Operations
    2.3.  Requests and Responses
3.  Use Cases
    3.1.  Session Establishment
    3.2.  A Sample XPP Operation Scenario
    3.3.  Message fragmentation
4.  Protocol Details
    4.1.  XPP Fragment Header
    4.2.  XPP Message
    4.3.  Parameters
    4.4.  Session Establishment
    4.5.  Session Teardown
    4.6.  Session Failure
    4.7.  Managing XPP Operations
5.  Transport
    5.1.  Fragmentation
    5.2.  Retransmissions
    5.3.  Keep-alive
6.  Security Considerations
7.  IANA Considerations
8.  Open Issues
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

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] (Eggert, L. and G. Fairhurst, “UDP Usage Guidelines for Application Designers,” June 2007.), 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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] or XMPP (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) [RFC3920]. This makes possible the establishment of direct connections between peers even if both endpoints are located behind RFC 4787 (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) [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 (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” January 2007.) [I‑D.ietf‑mmusic‑ice] and STUN (Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, “STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs),” March 2003.) [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] (Willis, D., Bryan, D., Matthews, P., and E. Shim, “Concepts and Terminology for Peer to Peer SIP,” June 2006.).



 TOC 

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 (Postel, J., “Transmission Control Protocol,” September 1981.) [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 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] (Rosenberg, J., “TCP Candidates with Interactive Connectivity Establishment (ICE),” March 2007.). 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.



 TOC 

1.2.  Relation with other Proposals

Since we started specifying and implementing XPP there have been two other proposals for peer protocols: dSIP (Bryan, D., “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) [I‑D.bryan‑p2psip‑dsip] and P2PP (Baset, S., “A Protocol for Implementing Various DHT Algorithms,” October 2006.) [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.



 TOC 

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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).
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.



 TOC 

2.  Overview



 TOC 

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 <LA, LB> by Alice and by <LB, LA> 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 (Session Establishment).

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.



 TOC 

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.



 TOC 

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.



 TOC 

3.  Use Cases



 TOC 

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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] and SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] as defined in RFC 3264 (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [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.



 TOC 

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 (Retransmissions), 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 



 TOC 

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 (Fragmentation)).

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.



       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 



 TOC 

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 (Postel, J., “Internet Protocol,” September 1981.) [RFC0791].



 TOC 

4.1.  XPP Fragment Header

All XPP messages start with an 8 byte message header represented on the following figure:



    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.
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.



 TOC 

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.
Parameters:
A concatenation of parameters, as defined below (Parameters).



 TOC 

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.



 TOC 

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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] and SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] as defined in RFC 3264 (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [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, 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.



 TOC 

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.



 TOC 

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).



 TOC 

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.



 TOC 

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 (Fragmentation).

Depending on their purpose XPP messages can be transported in both a reliable and unreliable way. Senders must set the REL Section 4.1 (XPP Fragment Header) bit of the fragment header to 1 and apply the retransmission mechanisms described in section Section 5.2 (Retransmissions).

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.



 TOC 

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 (XPP Fragment Header)). The value of the Sequence Number in the fragment header MUST be incremented for every following fragment.

The LFR bit (see Section 4.1 (XPP Fragment Header)) 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.



 TOC 

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.

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.



 TOC 

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 (XPP Fragment Header) 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 (Retransmissions)) the corresponding session is to be considered inactive and a session failure is to be reported to the application.



 TOC 

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 (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.) [RFC4347].



 TOC 

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;



 TOC 

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?



 TOC 

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.



 TOC 

10.  References



 TOC 

10.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4347] Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” RFC 4347, April 2006.


 TOC 

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 (TXT, PDF).
[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.
[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 (TXT, HTML, XML).
[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.


 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment