Internet DRAFT - draft-hautakorpi-structure-of-p2psip-node

draft-hautakorpi-structure-of-p2psip-node





Network Working Group                                      J. Hautakorpi
Internet-Draft                                              G. Camarillo
Intended status: Informational                                  Ericsson
Expires: April 19, 2007                                       E. Harjula
                                                           Univ. of Oulu
                                                        October 16, 2006


             The Logical Structure of a P2PSIP Overlay Node
            draft-hautakorpi-structure-of-p2psip-node-00.txt

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 April 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the logical structure of a P2PSIP overlay
   peer and client.  The document is not normative in nature, it is
   intended mainly as a clarification for the application developers.
   Editors note: Possible outcomes of this draft are 1) Informational
   RFC, 2) Incorporated to Concepts and Terminology draft, or 3) Seen as
   redundant and discarded altogether.



Hautakorpi, et al.       Expires April 19, 2007                 [Page 1]

Internet-Draft     Structure of a P2PSIP Overlay Node       October 2006


1.  Introduction

   P2PSIP is a mechanism which incorporates Peer-to-Peer (P2P)
   technologies and the Session Initiation Protocol (SIP) [2] signaling
   in a way which allows the transfer of proxy-registrar functionality
   to some of the end-hosts.  This document describes the logical
   structure of those end-hosts, which are referred here as P2PSIP
   Overlay Peers and Clients.  The purpose of this document is just to
   present the logical structure of a P2P-SIP node in a clear way, and
   not to mandate any specific solutions.  We hope that this document
   helps the application developers in their implementation work.

   The information presented in this documents should be fully
   compatible with the network structure presented in [3].  Also the
   logical structure of a P2PSIP node shown here is heavily inspired by
   the work done in the Columbia University [4].


2.  Terminology

   In this document, words which are normally key words, such as "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are used
   COLLOQUIALLY and are not intended to be interpreted as described in
   RFC2119 [1].


3.  Definitions

   The acronyms and terms used in this document are mainly the ones
   defined in [3].  Additionally, the following terms are defined:

   PO:  Acronym meaning "P2PSIP Overlay".

   PO Node:  A PO Node can be either a PO Peer or a PO Client.



4.  The Logical Structure of a PO Node

   There are two types of PO Nodes: PO Peers and PO Clients.  These
   nodes correspond to the P2P terms Supernode and Ordinary node.  From
   the viewpoint of this draft, the biggest difference is that PO Peer
   has an Overlay Layer, and it supports PO Peer Protocol.  The
   differences between the two are explained further in [3].

   The overview of the logical structure of a PO Client is illustrated
   in Figure 2.  The figure introduces two layers (rectanbles), four



Hautakorpi, et al.       Expires April 19, 2007                 [Page 2]

Internet-Draft     Structure of a P2PSIP Overlay Node       October 2006


   components (rounded rectangles), and one Application Programming
   Interface (API):

   o  Protocol Layer
   o  NAT Traversal Layer
   o  PO User Agent Component
   o  PO Core Logic Component
   o  Bootstrap Component
   o  Media Component
   o  Protocol API

   Different layers, components, and APIs are explained in detail on
   Section 5, Section 6, and Section 7, respectively.

                           [ PO User ]
                                |
       +------------------------|--------------------------------+
       | PO Client       /------v--------\                       |
       |                 | PO User Agent |                       |
       |                 \------^--------/                       |
       |                        |                                |
       |                 /------v--------\<-------------------+  |
       |                 | PO Core Logic |                    |  |
       |                 \------^--------/<---------+         |  |
       |                        |                   |         |  |
       |                        = Protocol API    /-v---\   /-v-\|
       |                        |                 |     |   |   ||
       |+-----------------------v-----------+     | B s |   | M ||
       || Protocol Layer                    |     | o t |   | e ||
       |+-----------------------^-----------+     | o r |   | d ||
       |                        |                 | t a |   | i ||
       |+-----------------------v-----------+     | - p |   | a ||
       || NAT Traversal Layer               <.....>     |   |   ||
       |+-----------^----------^------------+     \-^---/   \-^-/|
       +------------|----------|--------------------:---------|--+
                    |PO Client |Traditional         :         |e.g.
                    |Protocol  |SIP                 :         |RTP
                    v          v                    v         v

              Figure 1: The Logical Structure of a PO Client

   The overview from the logical structure of a PO Peer is illustrated
   in Figure 2.  The figure introduces one new layer, an Overlay Layer,
   and a new API, Overlay API.







Hautakorpi, et al.       Expires April 19, 2007                 [Page 3]

Internet-Draft     Structure of a P2PSIP Overlay Node       October 2006


                           [ PO User ]
                                |
       +------------------------|--------------------------------+
       | PO Peer         /------v--------\                       |
       |                 | PO User Agent |                       |
       |                 \------^--------/                       |
       |                        |                                |
       |                 /------v--------\<-------------------+  |
       |                 | PO Core Logic |<---------+         |  |
       |                 \------^--------/<----+    |         |  |
       |                        |              |    |         |  |
       |                        = Overlay API  |    |         |  |
       |                        |              |    |         |  |
       |+-----------------------v-----------+  |    |         |  |
       || Overlay Layer                     |  |    |         |  |
       |+-----------------------^-----------+  |  /-v---\   /-v-\|
       |                        = Protocol API =  |     |   |   ||
       |+-----------------------v-----------+  |  | B s |   | M ||
       || Protocol Layer                    <--+  | o t |   | e ||
       |+-----------------------^-----------+     | o r |   | d ||
       |                        |                 | t a |   | i ||
       |+-----------------------v-----------+     | - p |   | a ||
       || NAT Traversal Layer               <.....>     |   |   ||
       |+-^---------^----------^------------+     \-^---/   \-^-/|
       +--|---------|----------|--------------------:---------|--+
          |PO Peer  |PO Client |Traditional         :         |e.g.
          |Protocol |Protocol  |SIP                 :         |RTP
          v         v          v                    v         v

               Figure 2: The Logical Structure of a PO Peer


5.  Layers

   The layers are a logical way of thinking the protocol functionality
   on a PO Node.  The layers are specific to P2PSIP -related
   functionalities, whereas the components are considered to be
   functional components that are not part of the P2P signaling.

5.1.  Overlay Layer

   The Overlay Layer is present only in PO Peers, and its main
   responsibility is to provide overlay routing and management.  The
   routing and management is based on some distribution algorithm, e.g.,
   on a Distributed Hash Table (DHT), or on a directed flooding
   algorithm.  Overlay Layer has some type of an API for PO Core Logic
   (see Section 7.1).




Hautakorpi, et al.       Expires April 19, 2007                 [Page 4]

Internet-Draft     Structure of a P2PSIP Overlay Node       October 2006


   Another responsibility of Overlay Layer is to provide a credential
   management and authentication.  So, Overlay Layer also handles Peer
   and Resource Enrollments.

   There are two important data structures used and maintained on the
   overlay layer.  The first one is a routing table, which is used and
   maintained by a distribution algorithm.  Routing table contain
   entries to neighboring PO Overlay Peers.  The second data structure
   is used for storing and handling PO Overlay User Records.

5.2.  Protocol Layer

   Aspects related to signaling are handled in the Protocol Layer.  The
   signaling protocol can be, e.g., SIP, somehow extended SIP, or some
   other signaling protocol altogether.  After bootstrapping, the
   Protocol Layer is used e.g., in Peer and Resource Enrollment, and in
   session establishment.  Protocol Layer has an API for encoding
   overlay messages into the form of signaling protocol and vice versa
   (see Section 7.2).

   PO Client and Peer have a need to be able to use multiple protocols
   and so the Protocol Layer contains a multiplexer.  The multiplexer
   can identify and differentiate 1) PO Peer Protocol, 2) PO Client
   Protocol, and 3) traditional SIP.

5.3.  NAT Traversal Layer

   The purpose of NAT Traversal Layer is to enable the utilized
   signaling protocols to traverse through NATs.  The NAT Traversal
   Layer should be based on already existing NAT traversal mechanisms,
   such as Interactive Connectivity Establishment (ICE) [5].

   Open question: Can NAT traversal functionality be presented as layer?


6.  Components

   Some parts of PO Nodes' functionality can be seen as components
   rather than layers, as they are not considered as a part of P2PSIP
   itself.

6.1.  PO User Agent Component

   PO User Agent Component contains an User Interface (UI), and one PO
   Node can include several PO User Agent Components for different
   purposes and services.  For example, a PO User Agent Component can
   provide a buddylist if a PO Node is operating in user agent role, or
   a configuration tool if PO Node is operating in a proxy role (see



Hautakorpi, et al.       Expires April 19, 2007                 [Page 5]

Internet-Draft     Structure of a P2PSIP Overlay Node       October 2006


   Section 6.2).

6.2.  PO Core Logic Component

   The purpose of PO Core Logic Component is to provide a node-specific
   control logic.  It has information about physical capabilities and a
   role of a PO Node.  Because PO Core Logic is situated between the PO
   User Agent and lower layers, it can be seen as a kind of middleware
   component.  Different possible roles of PO Nodes are:

   o  User Agent
   o  Proxy
   o  Redirect server
   o  Registrar
   o  Gateway

6.3.  Bootstrap Component

   Bootstrap Component is responsible for bootstrapping a PO Node to a
   P2PSIP Overlay network.  The Bootstrap Component may use multiple
   methods for finding a suitable bootstrap node, e.g., DNS lookups or
   preset local configuration.

   Bootstrap procedure may open up port(s) to the network.  After the
   bootstrap operations, a PO Node should be aware of the matching
   Overlay Layer and connectivity details.

6.4.  Media Component

   Media Component handles media transfer and streams, i.e., it provides
   media transfer protocols.  It has to exchange information with the
   signaling part before the media starts flowing, as the signaling part
   is used for opening and closing media sessions.  The media component
   may also open up port(s) to the network for media transfer.


7.  The most important APIs

   The Bootstrap Component may determine the matching Overlay Layer for
   a given PO network, so it would be good if the Overlay Layer could be
   easily changed.  The PO Peer has two APIs: Overlay and Protocol API

7.1.  Overlay API

   Overlay API exists only on PO Peer, and it is the interface between
   the Overlay Layer and PO Core Logic.  Its main purpose is to provide
   a possibility for higher layers to access, control, and communicate
   with the Overlay Layer.



Hautakorpi, et al.       Expires April 19, 2007                 [Page 6]

Internet-Draft     Structure of a P2PSIP Overlay Node       October 2006


7.2.  Protocol API

   Protocol API is an interface between the Protocol Layer and PO Core
   Logic on PO Clients, and it is extended to act also as an interface
   between the Protocol Layer and Overlay Layer on PO Peers.  Its main
   purpose is to provide an encoding of overlay and signaling messages
   into the form of a signaling protocol and vice versa.


8.  IANA Considerations

   None.


9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informational References

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

   [3]  Willis, D., "Concepts and Terminology for Peer to Peer SIP",
        draft-willis-p2psip-concepts-01 (work in progress), August 2006.

   [4]  Singh, K. and H. Schultzrinne, "Peer-to-Peer Internet Telephony
        using SIP", Proceedings of the international workshop on network
        and operating systems support for digital audio and video
        (NOSSDAV'05), June 2005.

   [5]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
        Methodology for Network  Address Translator (NAT) Traversal for
        Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in
        progress), October 2006.












Hautakorpi, et al.       Expires April 19, 2007                 [Page 7]

Internet-Draft     Structure of a P2PSIP Overlay Node       October 2006


Authors' Addresses

   Jani Hautakorpi
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Jani.Hautakorpi@ericsson.com


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   Erkki Harjula
   Univ. of Oulu
   Erkki Koiso-Kanttilan katu 3
   University of Oulu  FIN-90014
   Finland

   Email: Erkki.Harjula@ee.oulu.fi
























Hautakorpi, et al.       Expires April 19, 2007                 [Page 8]

Internet-Draft     Structure of a P2PSIP Overlay Node       October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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





Hautakorpi, et al.       Expires April 19, 2007                 [Page 9]