P2PSIP M. Zangrilli
Internet-Draft SIPeerior Technologies
Intended status: Informational B. Lowekamp
Expires: September 14, 2007 SIPeerior; William & Mary
March 13, 2007
Why SIP should be used for encoding the P2PSIP Peer Protocol.
draft-zangrilli-p2psip-whysip-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 September 14, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The P2PSIP working group's charter charges the group to define a
P2PSIP peer protocol that defines how peers "collectively provide for
user and resource location in a SIP environment with no or minimal
centralized servers." The charter also states that the group may
define a peer protocol that is syntactically based on SIP. This
document outlines the motivation and merits of using conventional SIP
messages as the syntax to encode the P2PSIP peer protocol and
Zangrilli & Lowekamp Expires September 14, 2007 [Page 1]
Internet-Draft P2PSIP March 2007
discusses arguments made against this design decision.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why SIP should be used . . . . . . . . . . . . . . . . . . . . 3
3.1. Proposed SIP uses . . . . . . . . . . . . . . . . . . . . 4
4. Why SIP implemtation is easy . . . . . . . . . . . . . . . . . 5
5. Arguments against SIP as the Peer Protocol . . . . . . . . . . 5
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Zangrilli & Lowekamp Expires September 14, 2007 [Page 2]
Internet-Draft P2PSIP March 2007
1. Introduction
There are several reasons to use SIP messages to implement the P2PSIP
Peer Protocol. In order to properly implement a P2PSIP protocol, it
is necessary to have mechanisms to store, retrieve, and query the
locations of resources, as well as to route information. Pluggable
DHT algorithms require the Peer Protocol to support negotiation of
protocol extensions. Several NAT traversal and security mechanisms
must be supported by the Peer Protocol. We have found that SIP
offers mechanisms that meet all of these requirements today, has well
defined security mechanisms, and additionally works well with the
IETF suite of NAT traversal techniques: STUN, TURN, and ICE. Because
all this work would need to be redefined in a new P2PSIP Peer
Protocol, and because all P2PSIP devices must, by definition,
implement SIP anyway, we feel the only reasonable syntax choice for
the P2PSIP Peer Protocol is SIP.
2. Requirements
The following requirements are based on the P2PSIP working group's
charter.
1. A P2PSIP Peer Protocol must provide a distributed mechanism for
locating resources (users) in a SIP environment with minimal use
of centralized servers.
2. The protocol must work, as much as possible, in environments that
contain NATs and firewalls.
3. SIP must be used for session establishment. The charter further
states that P2PSIP protocols cannot modify baseline SIP behavior
or create a new or similar protocol for session establishment.
4. Peer protocols should define one base P2P algorithm but be
designed for pluggable P2P algorithms to be interchanged.
5. Peer protocols should provide security mechanisms that
authenticate data being stored in the overlay, allow clients to
establish authenticated signaling dialogs through untrusted
relays, and possibly address privacy issues of peers storing data
or routing requests for other peers in the system.
6. The charter states that the scope of the working group is to
create P2P SIP protocols and explicitly forbids (first thing
excluded on the charter) creating a more general distributed
lookup for use with applications other than SIP.
3. Why SIP should be used
Fundamentally, the DHT overlay used in P2PSIP is a distributed
registrar. In this sense, queries that would generally be sent to a
Zangrilli & Lowekamp Expires September 14, 2007 [Page 3]
Internet-Draft P2PSIP March 2007
conventional registrar are now performed within the DHT. Similarly,
once the target resource has been located, further communication
proceeds directly between the UAs (or designated adapter peers) as
with conventional SIP communications. We see no reason that any
messages used to register, locate, or communicate with other users
should be implemented in P2PSIP by anything other than SIP.
The second class of messages that must be exchanged in a P2PSIP
overlay is inter-peer communication. These messages are used to
join, leave, and maintain the overlay; transfer registrations between
peers; and to route SIP messages between endpoints to establish
communication. We see three reasons to use SIP for these messages:
o Joining and maintaining the overlay primarily consists of
establishing the connections for each peer's routing table that
form the topology of the overlay. These connections form long-
lived sessions over which the peers exchange information and route
requests. As such, these sessions are appropriately established
using SIP, the Session Initiation Protocol.
o As the registrations stored are intended for use by SIP, they must
be stored in a SIP format, and using SIP to exchange and refresh
them seems natural.
o The overlay is needed to route messages between endpoints for NAT
traversal. Because the messages between P2PSIP endpoints will be
SIP messages, routing them using SIP and leveraging the routing
capabilities already built into SIP makes sense.
NAT traversal must work for both inter-peer traffic and end-to-end
session establishment traffic. If routing behavior is needed for
relay anyway, it is a clear win to have both DHT messages and the
session establishment messages get routed by the peers -- INVITEs
between Alice and Bob get routed by the same peers that pass DHT SIP
messages. The NAT traversal problem needs only be solved once if
routing of DHT and session establishment messages are both SIP and
the solution can leverage existing NAT traversal solutions proposed
for conventional SIP.
3.1. Proposed SIP uses
Two of the ways in which SIP can be used to encode P2PSIP Peer
Protocols are to 1) use newly defined headers for SIP messages to
pass DHT information and 2) embed the DHT information in the body of
the SIP messages. In either case, the work already done in the areas
of NAT traversal, security, etc. are leveraged by the peer protocols
using SIP as the syntax.
The dSIP [I-D.bryan-p2psip-dsip] P2PSIP Peer Protocol proposes the
first approach where newly defined headers are used to pass DHT
Zangrilli & Lowekamp Expires September 14, 2007 [Page 4]
Internet-Draft P2PSIP March 2007
information. The dSIP draft outlines using SIP REGISTER messages to
manipulate and maintain the DHT. dSIP and RFC 3261 both use REGISTER
messages to "add, remove, and query bindings." The difference
between dSIP and SIP, is that in addition to distributing the
conventional SIP registrar functionality across the overlay, dSIP
uses the REGISTER messages to bind neighbors in DHT maintenance
operations.
We feel that the similarity of registering a Contact mapping and
registering a peer entry in a routing table are similar enough to
justify the use of REGISTER, but acknowledge that whether the
REGISTER method or a new method is used for DHT maintenance purposes
is still an open question. One example of such a new method is in
the P2PSIP Peer Protocol, written by Hautakorpi and
Camarillo[I-D.hautakorpi-p2psip-peer-protocol], proposes using a new
SIP method, LOCSER, with a well-defined XML message body.
4. Why SIP implemtation is easy
P2PSIP Peer Protocols that use SIP syntax do not have to implement
new stacks to handle P2P maintenance messages. P2PSIP Peer Protocols
must use SIP for session establishment, so a SIP stack will be part
of P2PSIP implementations. Rather than implement multiple stacks,
the SIP stack can be minimally modified to support P2P while not
breaking interaction with conventional SIP clients and servers. This
saves development time and also saves the overhead (processing time,
runtime footprint, memory) that would be involved in implementing an
additional stack.
5. Arguments against SIP as the Peer Protocol
Baset and Schulzrinne devote Section 4.2 of their P2PSIP peer
protocol draft [I-D.baset-p2psip-p2pcommon] to argue why SIP should
not be used as the underlying syntax for a P2PSIP protocol.
Argument 1: SIP is a session establishment protocol SIP is a
protocol for initiating, modifying, and terminating interactive
sessions[RFC3261]. Communicating with other nodes to form and
maintaining an overlay does not create an interactive session.
Response: Communicating or registering your user information with a
SIP server/proxy does not create an interactive session either.
In plain SIP and P2PSIP, registering resource information does not
create the session, but rather enables you to create that session
when needed.
Zangrilli & Lowekamp Expires September 14, 2007 [Page 5]
Internet-Draft P2PSIP March 2007
Note: we'll classify "communicating with other nodes to form and
maintain an overlay" as dht maintenance for simplicity in the
remainder of this document.
Argument 2: SIP is not a general Remote Procedure Call (RPC) A peer-
to-peer protocol designed on top of SIP will merely use it as a
remote procedure call (RPC) mechanism. The SIP guidelines
document [RFC4485] prohibits the use of SIP as a RPC mechanism.
Response: The argument that registering a contact for an AoR, as
done by the conventional SIP REGISTER, is not an RPC, but
registering a peer in a DHT routing table is an RPC seems dubious.
DHT maintenance does not use SIP as an RPC mechanism. The dht
maintenance between nodes is an (distributed) equivalent of
registering resources with SIP servers. If you don't keep a list
of how/where to contact resources, sessions can't be established
at all. The point is that maintaining information on who to send
INVITEs to is done via dht maintenance in P2PSIP and therefore,
using SIP messages is appropriate.
The justification in RFC 4485 for not supporting general-purpose
RPC is that "None of its user discovery and registration
capabilities are needed for RPC, and neither are most of its proxy
functions." For establishing connections between peers in dSIP,
the discovery, registration, and proxy functions are all integral
and necessary parts of the DHT maintenance phase.
Quoting RFC 4485, "The primary purpose of SIP is a rendezvous
function, to allow a request initiator to deliver a message to a
recipient wherever they may be. Such a rendezvous is needed to
establish a session, but it can be used for other purposes related
to communications, such as querying for capabilities or delivery
of an instant message." DHT maintenance is a necessity for
discovery and registration -- it implements a rendezvous function
which is clearly called out as being in scope of SIP by name in
RFC 4485. The P2PSIP working group is specifically chartered to
create a P2P rendezvous for SIP, so using SIP as the underlying
messages (i.e. in dht maintenance) in the P2P rendezvous function
seems to be very appropriate.
Argument 3: SIP is not a general purpose transfer protocol One
possible way to design the peer-to-peer protocol is to incorporate
it as a SIP message body, possibly in XML, leaving the SIP headers
unchanged. The peer-to-peer protocol is, however, unrelated to
SIP's operation and the SIP guideline document [RFC4485] prohibits
sending large amounts of data unrelated to SIP's operation. Such
a mechanism would use SIP as a RPC, which, as stated earlier, is
prohibited by the SIP guidelines document.
Zangrilli & Lowekamp Expires September 14, 2007 [Page 6]
Internet-Draft P2PSIP March 2007
Response: DHT maintenance information is related to SIP's operation
as a registrar in a distributed fashion. It is rendezvous and
user location, explicitly called out as in scope and the task that
the P2PSIP working group is chartered to convert to P2P.
Argument 4: SIP is not a lookup protocol SIP is not a lookup
protocol; it relies on DNS to locate an appropriate SIP server.
Insert and lookup functionality is essential for any peer-to-peer
protocol. Using SIP as a peer-to-peer protocol requires
integrating lookup functionality into SIP which goes against its
design philosophy.
Response: To address this argument, we will use the following
distinction between lookup and discovery: lookup is similar to
looking up a value for a known key in a hash table, whereas
discovery is like getting a new key as well as its value.
Saying that SIP does discovery but not lookup is a little
disingenuous. While one could certainly make the case that SIP
endpoints only do discovery, they in general rely on proxies and
registration servers, and these servers certainly do lookups.
Because peers are performing the functions of a SIP registrar, the
lookup aspect is just more obvious.
Taken another way, is this argument claiming we need something
other than SIP so it can do general lookup? We are not doing (or
at least should not be as chartered!) a general P2P lookup. We
are making a P2P rendezvous for SIP, and the maintenance of this
is part of sharing that information among entities in the system,
just as register is used today to share that information between
endpoints and the registrar in conventional SIP.
Argument 5: SIP headers overhead SIP has headers that are not
necessarily needed for a peer-to-peer protocol. Examples of such
headers are Call-ID, and Contact.
Response: It's really too early to tell if Call-ID and Contact (or
others) are headers that aren't useful for p2psip using SIP as the
underlying protocol. dSIP relies on both of these headers in its
messages. In general, many of the headers will be used for the
same purposes because the purposes are very similar: identifying
dialogs, request/reply/replay prevention, routing options,
security, etc.
6. Summary
We find there to be significant and compelling reasons to use SIP as
Zangrilli & Lowekamp Expires September 14, 2007 [Page 7]
Internet-Draft P2PSIP March 2007
the Peer Protocol for P2PSIP. SIP is a mature, established protocol
that already has well-defined mechanisms to support the necessary
capabilities of routing options, security, NAT traversal, and
extensibility. SIP can be extended for use as the Peer Protocol
through the addition of a small number of new headers, message
bodies, or methods as demonstrated by several submitted drafts. We
question whether an entirely new protocol with similar power and
flexibility could be designed that would be significantly simpler and
easier to implement than the necessary components of SIP.
Furthermore, because all P2PSIP UAs must already have a SIP
implementation, using SIP as the Peer Protocol is likely to be
simpler and lower-cost than including a separate stack for an
unrelated Peer Protocol. dSIP [I-D.bryan-p2psip-dsip] and The Peer
Protocol [I-D.hautakorpi-p2psip-peer-protocol] present two possible
methods for implementing a Peer Protocol over SIP, and we hope the
working group will produce and evaluate a number of candidates to
determine the best mechanism for implementing the Peer Protocol in
the near future.
7. Security Considerations
There are important security considerations in any Peer Protocols.
Each addresses its issues in their respective drafts.
8. IANA Considerations
This document has no actions for IANA.
9. Informative References
[I-D.baset-p2psip-p2pcommon]
Baset, S. and H. Schulzrinne, "Peer-to-Peer Protocol
(P2PP)", Internet Draft draft-baset-p2psip-p2pcommon-01,
February 2007.
[I-D.bryan-p2psip-dsip]
Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P
Approach to SIP Registration and Resource Location",
Internet Draft draft-bryan-p2psip-dsip-00, February 2007.
[I-D.hautakorpi-p2psip-peer-protocol]
Hautakorpi, J. and G. Camarillo, "Peer-to-Peer Protocol
(P2PP)", Internet
Draft draft-hautakorpi-p2psip-peer-protocol-00,
February 2007.
Zangrilli & Lowekamp Expires September 14, 2007 [Page 8]
Internet-Draft P2PSIP March 2007
[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.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, May 2006.
Authors' Addresses
Marcia Zangrilli
SIPeerior Technologies
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone: +1 757 565 0101
Email: marcia@sipeerior.com
Bruce B. Lowekamp
SIPeerior; William & Mary
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone: +1 757 565 0101
Email: lowekamp@sipeerior.com
Zangrilli & Lowekamp Expires September 14, 2007 [Page 9]
Internet-Draft P2PSIP March 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).
Zangrilli & Lowekamp Expires September 14, 2007 [Page 10]