[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         E. Marocco
Internet-Draft                                            Telecom Italia
Intended status: Standards Track                                 E. Ivov
Expires: May 19, 2008                          L. Pasteur University/SIP
                                                            Communicator
                                                       November 16, 2007


                     Extensible Peer Protocol (XPP)
                      draft-marocco-p2psip-xpp-01

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 May 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Marocco & Ivov            Expires May 19, 2008                  [Page 1]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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  . . . . . . . . . . . . . . . . . . . . . 17
     4.7.  Managing XPP Operations  . . . . . . . . . . . . . . . . . 17
   5.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . 18
     5.2.  Retransmissions  . . . . . . . . . . . . . . . . . . . . . 18
     5.3.  Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   8.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     10.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27




Marocco & Ivov            Expires May 19, 2008                  [Page 2]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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.




Marocco & Ivov            Expires May 19, 2008                  [Page 3]


Internet-Draft       Extensible Peer Protocol (XPP)        November 2007


      In fact, Berkeley sockets, the standard interface applications use
      to access network functionalities exposed by the operating system,
      are designed around a client/server model and do not natively
      allow to initiate connections simultaneously.

   Furthermore, other than requiring a correct implementation of the
   full TCP state machine on both endpoints, for the simultaneous
   establishment to succeed it is necessary that all traversed network
   elements (expecially NATs and firewalls) are compliant with the best
   practices specified in [I-D.ietf-behave-tcp].  Such requirements, at
   the time of writing, are certainly much less likely to be satisfied
   by common devices than those necessary for UDP NAT traversal
   [RFC4787].

   Another weakness of TCP is its inability to handle address changes
   within established connections.  While in normal environments it is
   possible to handle mobility at the network layer, in some scenarios
   specifically addressed by P2PSIP maintaining the same IP address
   after a handover or a NAT reboot is often not an option.

   Using TCP would thus make mandatory the usage of ICE-TCP
   [I-D.ietf-mmusic-ice-tcp], at least for handling of simultaneous
   session establishment and mobility.  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.

   On the other hand, 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



Marocco & Ivov            Expires May 19, 2008                  [Page 4]


Internet-Draft       Extensible Peer Protocol (XPP)        November 2007


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

   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 May 19, 2008                  [Page 5]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 <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.

      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 May 19, 2008                  [Page 6]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                  [Page 7]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                  [Page 8]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                  [Page 9]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 10]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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|F|R|L|K|                               |
      | Ver |   Reserved  |Y|C|I|E|F|P|        Sequence Number        |
      |     |             |N|K|N|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 May 19, 2008                 [Page 11]


Internet-Draft       Extensible Peer Protocol (XPP)        November 2007


   FIN:  Session close flag.  Set to 1 if no more non-ACK messages will
      be sent in this direction.

   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.








Marocco & Ivov            Expires May 19, 2008                 [Page 12]


Internet-Draft       Extensible Peer Protocol (XPP)        November 2007


   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
      (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 May 19, 2008                 [Page 13]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 initiated by the signalling
   protocol used for the establishment of the session (a BYE request in
   the case of SIP) and is then followed by acknowledged transmission of
   two XPP messages with the FIN bit set by the two endpoints.



Marocco & Ivov            Expires May 19, 2008                 [Page 14]


Internet-Draft       Extensible Peer Protocol (XPP)        November 2007


      The transmission of a message with the FIN bit set explicitly
      indicates that the sender is not going to send any more messages
      and, from that point in time on, it will only ACK received
      fragments.  Such a mechanism is required to let both endpoints to
      finish transmitting messages already scheduled for sending before
      the session is definitively destroyed.













































Marocco & Ivov            Expires May 19, 2008                 [Page 15]


Internet-Draft       Extensible Peer Protocol (XPP)        November 2007


       Alice                                              Bob
         |                                                 |
         | BYE                                             |
         |================================================>|
         |                                                 |
         | FIN, REL, LFR, SEQ=700                       OK |
         | LID=0xAAAA, RID=0xBBBB      ====================|
         |----------------------     //                    |
         |                      \   //                     |
         |                       \ //                      |
         |                        X/                       |
         |                       //\                       |
         |<======================   \                      |
         |                           --------------------->|
         |                                                 |
         |                          ACK, SEQ=700           |
         |                          LID=0xBBBB, RID=0xAAAA |
         |<------------------------------------------------|
         |                                                 |
         |                          REL, SEQ=600           |
         |                          LID=0xBBBB, RID=0xAAAA |
         |<------------------------------------------------|
         |                                                 |
         | ACK, SEQ=600                                    |
         | LID=0xAAAA, RID=0xBBBB                          |
         |------------------------------------------------>|
         |                                                 |
         |                          REL, LFR, SEQ=601      |
         |                          LID=0xBBBB, RID=0xAAAA |
         |<------------------------------------------------|
         |                                                 |
         | ACK, SEQ=601                                    |
         | LID=0xAAAA, RID=0xBBBB                          |
         |------------------------------------------------>|
         |                                                 |
         |                          FIN, REL, SEQ=602      |
         |                          LID=0xBBBB, RID=0xAAAA |
         |<------------------------------------------------|
         |                                                 |
         | ACK, SEQ=602                                    |
         | LID=0xAAAA, RID=0xBBBB                          |
         |------------------------------------------------>|
         |                                                 |


   Session teardown.  After communicating her intention to close the
   session, Alice sends a fragment with the FIN bit set and stops
   sending non-ACK messages.  On his side Bob agrees agreed to the



Marocco & Ivov            Expires May 19, 2008                 [Page 16]


Internet-Draft       Extensible Peer Protocol (XPP)        November 2007


   session teardown and sends the last message he had in his local queue
   (consisting of two fragments with sequence number 600 and 601) and
   then closes the session sending a fragment with the FIN bit set.

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 May 19, 2008                 [Page 17]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 18]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 19]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 20]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 21]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 22]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 23]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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-behave-tcp]
              Guha, S., "NAT Behavioral Requirements for TCP",
              draft-ietf-behave-tcp-06 (work in progress), April 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.



Marocco & Ivov            Expires May 19, 2008                 [Page 24]


Internet-Draft       Extensible Peer Protocol (XPP)        November 2007


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

   [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 May 19, 2008                 [Page 25]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 26]


Internet-Draft       Extensible Peer Protocol (XPP)        November 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 May 19, 2008                 [Page 27]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/