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]