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

Versions: 00

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]


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