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]
