One document matched: draft-marocco-p2psip-xpp-00.txt
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 <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 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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:12 |