A Hierarchical P2P-SIP Architecture
draft-shi-p2psip-hier-arch-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 February 23, 2007.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

This document outlines the hierarchical P2P-SIP architecture, which makes the combination of P2P and SIP practical. In this architecture, heterogeneous overlays are inter-connected via a decentralized manner provided by the hierarchical P2P-SIP architecture. The overhead of the session control process is reduced since the P2P overlay is used by SIP as the underlying peer locating approach. Some nodes in the overlay are proposed to be stateful to improve the reliability of the overlay. Finally, a session initial example is presented to illustrate this architecture.This work is being discussed on the p2psip@cs.columbia.edu mailing list.

Table of Contents

1.  Introduction
    1.1.  Background
    1.2.  Motivation
2.  Requirements notation
3.  Hierarchical P2P-SIP Architecture
    3.1.  Network architecture
    3.2.  Protocol Stack Architecture
4.  Generic P2P Overlay Service
    4.1.  Bootstrap
    4.2.  Node Operations
        4.2.1.  Node Registration
        4.2.2.  Node Leaving and Failure
    4.3.  Resource Operations
5.  P2P-SIP Naming
6.  P2P Proxy
    6.1.  P2P Proxy Election
    6.2.  P2P Proxy Behavior on Routing the SIP Message
    6.3.  P2P Proxy Leaving and Failure
7.  An example of Inter-Domain Communication Process
8.  Security Considerations
9.  Open Issues
    9.1.  Stateful and Stateless Problems
    9.2.  Decentralized Bootstrap Process
10.  Acknowledgements
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

1.1.  Background

Many benefits can be gained from the combination of SIP [2] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Scholler, “SIP: session initiation protocol,” June 2002.) and P2P [3] (Milojicic, D., Kalogeraki, V., Lukose, R., Nagaraja, K., Pruyne, J., Richard, B., Rollins, S., and Z. Xu, “Peer-to-peer computing,” Mar 2002.). From the SIP point of view, central servers such as the proxy and registrar can be removed to reduce the deployment and maintenance cost, and the robustness of SIP will also be increased. From the P2P point of view, the introducing of SIP will make the overlay controllable, and specific applications such as P2P Internet Phone and IM can be enabled.

1.2.  Motivation

To combine P2P and SIP together, there are two approaches: P2P-over-SIP [4] (Singh, K. and H. Schulzrinne, “Peer-to-peer Internet Telephony using SIP,” June 2005.) [10] (Bryan, D., Lowekamp, B., and C. Jennings, “A P2P Approach to SIP Registration and Resource Location,” Mar 2006.) and SIP-over-P2P [11] (Shim, E., Narayanan, S., and G. Daley, “An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP),” Feb 2006.). The former approach focuses on using SIP messages to maintain P2P overlay networks. The approach is motivated by specific multimedia session control requirements in P2P overlays. The upper layer SIP provides the P2P overlay with control functions and establishes multimedia sessions over unreliable P2P overlay networks. However, the primary disadvantage of the approach is that P2P-over-SIP needs to maintain many SIP dialog states during the overlay control course. For example, using P2P-over-SIP, we need to forward over 17 kinds of SIP messages from joining DHT to finishing registering and each SIP message has its own dialog states in user agents.

An alternative approach is to layer SIP over the P2P overlay network. The underlying P2P overlay networks such as Chord [5] (Stoica, I., Morris, R., and D. Karger, “Chord A Scalable Peer-to-peer Lookup Service for Internet Applications,” 2001.), CAN [6] (Ratnasamy, Sylvia., Francis, Paul., Handley, Mark., Karp, Richard., and Scott. Shenker, “A Scalable Content-Addressable Network,” 2001.), Pastry [7] (Rowstron, Antony. and Peter. Druschel, “Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems,” 2001.) and etc provides SIP with the peer locating service. That is to say, the traditional centralized SIP trapezoid will be replaced by the decentralized P2P location service. Thus we can reduce the deploying cost of P2P-SIP and increase the robustness of the network. However, when we use P2P overlays as the SIP's peer locating service, there are some problems need to be solved. First, one of the essential design targets of SIP is to find the peer anytime and anywhere using DNS, however, when we replace the DNS and SIP Proxy with P2P overlays, heterogeneous overlays will cause the connectivity problem. A peer in one P2P overlay (such as Chord) is difficult to route the SIP message to another P2P overlay (such as Pastry) based on their individual P2P peer locating service. Second, SIP is a stateful protocol which controls the session establishing, modifying and terminating process over stateless IP networks, however, when we use the P2P overlay to provide the peer locating service, how to inherit features of stateful proxy from the traditional SIP is unclear.

Here we summarize some crucial issues need to be considered when we combine P2P and SIP together.

1. When SIP is made serverless, we should retain the connectivity of SIP especially when heterogeneous P2P overlays are served as the underlying peer locating service simultaneously.
2. When the P2P overlay is controlled by SIP, some approaches should be proposed to reduce the overhead caused by too many SIP dialogs.
3. When P2P and SIP are combined together, the emerging P2P-SIP protocol should also inherit the routing feature of the stateful proxy of traditional SIP.

The above issues motivate this document of the hierarchical architecture for P2P and SIP combination. P2P overlays are used by SIP as the underlying peer locating protocol thus the overhead will be significantly reduced compared with the P2P-over-SIP approach . Then, each overlay will elect one or more powerful peers to be P2P proxies which logically construct an upper level overlay and forward messages among heterogeneous overlays. Thus the connectivity problem is solved. Furthermore, it is also proposed to make several peers in an overlay to be starteful to inherit the controllable feature of stateful SIP proxies.

2.  Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Terminology defined in RFC 3261 [2] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Scholler, “SIP: session initiation protocol,” June 2002.) and in P2PSIP concepts draft [12] (Willis., D., Byran, D., and P. Matthews, “Concepts and Terminology for Peer to Peer SIP,” June 2006.) is used without definition.

Local P2P Overlay: A basic P2P overlay network that provides the location and routing functionalities.

Global P2P Overlay: An upper level P2P overlay that inter-connects hierarchical local P2P overlays.

P2P Proxy: A SIP proxy elected from P2P Proxy candidates. It runs both local P2P overlay and global P2P overlay's stack, and it is responsive for inter-overlay SIP message exchange.

P2P Proxy Candidates: A node elected from the P2P-SIP Overlay Peer prepares to become the P2P Proxy when the proxy current leaves or fails.

P2P-SIP User URI: A SIP URI used for identifying the P2P-SIP user

P2P-SIP Overlay URI: A SIP URI used for identify the P2P-SIP overlay.

3.  Hierarchical P2P-SIP Architecture

3.1.  Network architecture

Figure 1 illustrates the proposed hierarchical P2P-SIP structure. Various P2P overlays (such as Pastry, CAN and etc, we call it the local overlay. Their real overlay structures may not be ring-based and here we only use ring for illustratation) are respectively used as the underlying route discovery protocol for the decentralized SIP scheme, that is, when two peers of a call are in the same overlay network, the callee lookup course will be base on the overlay's specific resource locating process. In this way, the communication overhead will be significantly reduced since relaying nodes need not maintain dialog-states.

        0     1     2              0     1     2
         0----N----N                0----0----0
        /           \              /           \
    15 0             0 3       15 0             N 3
      /               \          /               \
  14 0     Pastry      0 4   14 0       CAN       0 4
     |   (P2P Domain)  |        |   (P2P Domain)  |
  13 N                 N 5   13 0                 N 5
     | Hash(sip:bob    |        |                 |
  12 0  @bupt.pastry)  0 6   12 0                 0 6
      \               /          \               /
    11 0             0------------N             0 7
        \           / 7         11 \           /
         N----0----N                0----0----0
       10     9   / 8             10 \   9     8
                 /                    \
                0                      0
                |   Hash(sip:overlay   |
                |    @pastry)          |
                |   (Global Overlay)   |
                |                      |
                |                      |
                0                      0
                 \    0     1     2   /
                  \   0----0----0    /
                   \ /           \  /
                 15 N-------------N 3
                   /               \
               14 0                 0 4
                  |                 |
               13 0                 0 5
                  |       BT        |
               12 0   (P2P Domain)  0 6
                   \               /
                 11 0             0 7
                     \           /
                      0----0----0
                    10     9     8

Hierarchical P2P-SIP Structure

3.2.  Protocol Stack Architecture

Protocols are composed of two separate layers, the upper layer is the SIP layer and the lower one is the P2P overlay layer. The SIP layer is responsible for sending, receiving and processing SIP messages so as to establish or terminate multimedia sessions. The P2P overlay layer handles all the P2P overlay functions, including formation, maintenance, lookup, as well as offering peer locating service to the SIP layer.

For a peer node, the SIP layer can be a SIP User Agent; while for the proxy node, the SIP layer can be a B2BUA. Both SIP UA and B2BUA act the same as defined in the traditional SIP protocol except for the peer locating service. The upper layer SIP gets the location (i.e. IP address) of the destination user from the P2P overlay layer instead of location severs. That is, we implement the function of location related severs in a distributed manner, using P2P overlay networks.

The P2P overlay layer of ordinary peer nodes differs from that of P2P proxy nodes. There is only one specific P2P technology in a normal peer node. Peers with the same P2P technology will logically form a P2P overlay. However, in a P2P Proxy node, the P2P overlay layer has double stacks. One is the P2P approach used in Local P2P Overlay, and the other is the Global P2P Overlay approach (i.e. Chord in Fig.I). On the one hand, a proxy node joins to form the Local P2P Overlay with other peer nodes in the specific overlay; on the other hand, all the elected P2P proxy nodes will join together to form a Global P2P Overlay network. Nodes located in different P2P domains can communicate with each other via this global overlay network.

   Peer Node       P2P Proxy Node         P2P Proxy Node    Peer Node
  |--------|     |------|---------|     |---------|-----|    |-----|
  |        |     |      |         |     |         |     |    |     |
  |  SIP   |     | SIP  | SIP     |     | SIP     | SIP |    | SIP |
  |        |     |      |         |     |         |     |    |     |
  |        |     |      |         |     |         |     |    |     |
  |--------|     |------|---------|     |---------|-----|    |-----|
  |        |     |      |         |     |         |     |    |     |
  | Pastry |     |Pastry|  Chord  |     |  Chord  | CAN |    | CAN |
  |(local  |     |      | (global |     | (global |     |    |     |
  |overlay)|     |      | Overlay)|     | Overlay)|     |    |     |
  |        |     |      |         |     |         |     |    |     |
 ----------------------------------------------------------------------
 |                        SocketAPI                                   |
 ----------------------------------------------------------------------

Protocol stack architecture

4.  Generic P2P Overlay Service

Generic P2P overlay service is used by SIP as the underlying peer locating service. In this section, we describes the generic DHT-based P2P overlay functions. Any non-DHT based approach is also acceptable for the P2P-SIP implementation.

4.1.  Bootstrap

When a node intends to join an existing overlay, it must first locate some nodes that are already active in the overlay. Then it can join the overlay with the help of that node. We call this process bootstrap. There are several methods for bootstrap implementation.

1. Web Station
   We can maintain a web station, which provides the information of the nodes that are already active in the overlay. This kind of bootstrap can refer to the Gnutella Web Caching System[8] (Karbhari, Pradnya., Ammar, Mostafa., Dhamdhere, Amogh., Raj, Himanshu., Riley, George., and Ellen. Zegura, “Bootstrapping in Gnutella: A Measurement Study,” 2004.).
2. Cached Address
   A node may cache some addresses during its prior connection. The cached list enables it to find the bootstrap node directly.
3. Pre-configured Methods
   Some nodes in the overlay may be persistent, and have well known addresses. These addresses could be pre-configured into nodes.
4. Broadcast
   The node that wants to join the overlay could also broadcast messages in the local network to locate a node that has already joined the overlay.

4.2.  Node Operations

4.2.1.  Node Registration

Node registration enables a peer node to join the structured overlay network with its Node-ID. The Node-ID is generated by the specific Hash algorithms the overlay adopts, that is:

Node-ID = Hash(Node-IP)

Then the joining peer will contact the bootstrap node to help it join the overlay. Specific DHT algorithms such as Chord, Pastry, CAN and etc have specified the node registration process. Note that in the hierarchical P2P-SIP overlay, the P2P proxy should register its Node-ID to both the local overlay and the global overlay, thus it can inter-connect various overlays.

4.2.2.  Node Leaving and Failure

The maintenance of node leaving and failure is described in specific DHT algorithm and we do not discuss it in detail here. When a node leaves the overlay, another node should be notified to be responsible for the resources of the leaving node. When a node fails, the self-recovery approach should be adopted to re-organize the overlay network.

The P2P proxy node is particularly important in the hierarchical P2P-SIP overlay, and the leaving and failure of the P2P proxy is described in section 6.3 (P2P Proxy Leaving and Failure).

4.3.  Resource Operations

In the hierarchical P2P-SIP overlay network, there are primarily two kinds of resources need to be managed, that is, the P2P-SIP user's identifier (P2P-SIP User URI) and the P2P overlay's identifier (P2P-SIP Overlay URI). The former URI is used to uniformly identify P2P-SIP users and the latter URI is used to identify various overlays. The naming rule is described in section 5 (P2P-SIP Naming).

P2P overlays provide the approach which manages URI resources in a distributed manner. Thus the route discovery related elements such as DNS servers could be replaced by the distributed resource management functions provided by the P2P overlay.

1. In the local overlay, the P2P-SIP User URI is hashed as the User-Resource-ID, and then the User-Resource-ID is registered to a node in the local overlay.
   
   User-Resource-ID = Hash(P2PSIP-User-URI)
   
   
2. In the global overlay, the P2P-SIP Overlay URI is hashed as the Overlay-Resource-ID, and then the Overlay-Resource-ID is registered to a P2P proxy in the global overlay.
   
   Overlay-Resource-ID = Hash(P2PSIP-Overlay-URI)
   
   

In the hierarchical P2P-SIP protocol, two new SIP headers called Overlay-ID and Node-ID are added to identify the P2P-SIP scheme. For example, some headers of an INVITE Message might look like this:

INVITE sip: bob@bupt.pastry SIP/2.0
Via: SIP/2.0/UDP 59.64.186.33; branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Bob <sip:bob@bupt.pastry>;tag=1928301774
Call-ID: a84b4c76e66710@59.64.186.33
CSeq: 314159 INVITE
Contact: <sip:bob@59.64.186.33>
Node-ID: <sip:bob@bupt.pastry>
Overlay-ID: <sip:overlay@pastry>
Content-Type: application/sdp
Content-Length: 142

5.  P2P-SIP Naming

There should be a district name that identifies the specific P2P-SIP user and overlay. The specific naming rule can refer to the SIP Address of Record (AOR).

Although the P2P-SIP paradigms intend to remove the dependence on central servers such as the DNS server, P2P-SIP User ID can also inherit the hierarchical organization feature of DNS. In this way, top level labels identify heterogeneous overlays such as CAN and Pastry in Figure 1, while the second level labels identify the specific users or groups within each overlay network. Furthermore, since there're two kinds of URI in the P2P-SIP overlay, the overlay URI should be automatically generated by the P2P proxy using the user URI.

For instance, the URI sip:bob@bupt.pastry can be one of the implementation of the P2P-SIP user identifier. Bob at Beijing University of Posts and Telecommunications (BUPT) should register the P2P-SIP User URI sip:bob@bupt.pastry to the Pastry overlay based on the Pastry algorithm and one or more P2P proxies of BUPT in the Pastry overlay should register the P2P-SIP Overlay URI sip:overlay@pastry to the top level overlay. Then when Bob wants to call Alice (sip:alice@pku.can) at Peking University in the CAN overlay, the request message will first be routed to the P2P proxy at BUPT since the callee's URI does not belong to the Pastry overlay. Then the proxy will forward the message to the P2P proxy at Peking University in the CAN overlay based on the overlay's URI (sip:overlay@can). Finally the P2P proxy at Peking University will route the message to Alice based on the user ID (sip:alice @pku.can).

Note that this kind of naming and addressing method significantly differs from that of DNS although both of them are hierarchically organized. The addressing process in DNS is based on centralized DNS servers while that in P2P paradigms is based on self-organized overlay hosts. Thus we can call it the P2P Domain System.

6.  P2P Proxy

6.1.  P2P Proxy Election

The P2P proxy election approach is proposed to make the proxies to be more stable and powerful. The election metrics should be online time, bandwidth, CPU capacity and etc. Then specific utility functions could be formulated to evaluate the peer's capacity.

U = f(online, bandwidth, cpu, others)

Based on the utility function, each node is evaluated and assigned a score. Nodes with higher score will become P2P proxy candidates. Then the P2P proxy will be elected from the P2P proxy candidates.

The elected proxy candidates do not perform as P2P proxies, but only monitor the P2P proxy and prepare to replace it when it leaves or fails. Thus we call the P2P proxy candidate inactivated proxy. Each overlay should maintain its inactivated proxy list. Thus when the P2P proxy fails, the connectivity can be fast recovered.

6.2.  P2P Proxy Behavior on Routing the SIP Message

The P2P proxy serves as a gateway-like element among heterogeneous overlay networks, and it runs double stacks (i.e. the local overlay protocol and global overlay protocol). The P2P proxy registers to both the local overlay and the global overlay using respective protocol stacks.

When peers in the local overlay detect that the callee's domain name doesn't belong to the overlay, they will send the SIP message to the P2P proxy. Then the P2P proxy is responsible for routing the message to another P2P domain using the upper level overlay's peer locating service. When the P2P proxy in the callee's overlay receives the inter-domain routed SIP message, it will send it to the callee's UA using the local overlay's peer locating service. Examples in section 7 (An example of Inter-Domain Communication Process) illustrate the routing behavior of the P2P proxy.

6.3.  P2P Proxy Leaving and Failure

The local overlay will maintain an inactivated P2P proxy list, and members in the list are considered as the P2P proxy candidates. P2P proxy candidate will periodically send the HELLO message to the P2P proxy so as to determine whether the proxy is alive. When the P2P proxy fails, a P2P proxy candidate in the list will be elected to become the active P2P proxy which joins the upper level overlay. If the P2P proxy leaves, it will elect a candidate to make it the proxy.

7.  An example of Inter-Domain Communication Process

_______   _________  _______    _________ _______   _________ _________
|Bob's|   |Pastry |  |  P1 |    | chord | | P2  |   |  CAN  | |Alice's|
| UA  |   |Overlay|  |Proxy|    |Overlay| |Proxy|   |Overlay| |   UA  |
|_____|   |_______|  |_____|    |_______| |_____|   |_______| |_______|
   |          |          |          |        |           |         |
   |  F1 Get  |          |          |        |           |         |
   |  Local   |          |          |        |           |         |
   |  Proxy   |          |          |        |           |         |
   |--------->|          |          |        |           |         |
   |          |          |          |        |           |         |
   |          |          |          |        |           |         |
   |F2 Addr Of|          |          |        |           |         |
   |LocalProxy|          |          |        |           |         |
   |<---------|          |          |        |           |         |
   |          |          |          |        |           |         |
   |------F3 INVITE----->|          |        |           |         |
   |          |          |          |        |           |         |
   |<---F4 100 TRYING----|          |        |           |         |
   |          |          | F5 Get   |        |           |         |
   |          |          |Addr of P2|        |           |         |
   |          |          |--------->|        |           |         |
   |          |          |    F6    |        |           |         |
   |          |          |Addr of P2|        |           |         |
   |          |          |<---------|        |           |         |
   |          |          |          |        |           |         |
   |          |          |-----F7 INVITE---->|           |         |
   |          |          |          |        |           |         |
   |          |          |--F8 100 TRYINGG-->|           |         |
   |          |          |          |        |  F9 Get   |         |
   |          |          |          |        |Alice's UA |         |
   |          |          |          |        |---------->|         |
   |          |          |          |        |           |         |
   |          |          |          |        |F10 Addr of|         |
   |          |          |          |        |Alice's UA |         |
   |          |          |          |        |---------->|         |
   |          |          |          |        |           |         |
   |          |          |          |        |----F11 INVITNE----->|
   |          |          |          |        |           |         |
   |          |          |          |        |<--F12 180 RINGING---|
   |          |          |          |        |           |         |
   |          |          |<--F13 180 RINGING-|           |         |
   |          |          |          |        |           |         |
   |<---F14 180 RINGING--|          |        |           |         |
   |          |          |          |        |           |         |
   |          |          |          |        |<----F15 20OOK-------|
   |          |          |          |        |           |         |
   |          |          |<-----F16 200OK----|           |         |
   |          |          |          |        |           |         |
   |<----F17 200OK-------|          |        |           |         |
   |          |          |          |        |           |         |
   |-----------------------F18 ACK-------------------------------->|
   |          |          |          |        |           |         |
  /___________|__________|__________|________|___________|__________\
 /                        Multimedia Session                         \
 \ __________________________________________________________________/
  \                                                                 /

1. Caller Bob's UA first determines whether the callee's domain pku.can is in its domain .pastry, and it finds that it is not. Then it finds the P2P proxy in its overlay which joins the upper level overlay based on the specific global P2P approach.
2. Caller Bob's UA generates an INVITE message based on RFC 3261, and sets the Request-URI to be the Address-of-Record of the callee Alice.
3. Bob's UA sends the INVITE message to the P2P proxy (P1) in the Pastry overlay.
4. P1 looks up Alice's overlay via the top level overlay Chord, and gets the P2P proxy's IP address of the CAN overlay.
5. P1 adds its address in the VIA header of the INVITE message and forwards that message to P2; P1 also sends a 100 Trying to Bob's UA.
6. When P2 receives the INVITE message, it looks up the address of Alice's UA via the CAN overlay.
7. P2 adds its address in the VIA header of the INVITE message and forwards that message to Alice's UA; P2 also sends a 100 Trying to P1.
8. When Alice's UA receives the INVITE message, it deals with the message according to the specification in RFC 3261.
9. When the INVITE message arrives at Alice's UA, the 180 Ring message is sent back via the information in its Via header.
10. When Alice picks up the phone, the 200 OK message is sent back to Bob's UA
11. When Bob's UA receives the 200 OK message, it sends the ACK message to Alice via the information in the Contact header.
12. Finally, the peer to peer multimedia session between Bob's UA and Alice's UA is established.

8.  Security Considerations

Security related problems such as DoS attack are not discussed in this document. However, the attacker may have powerful machine to DoS the proxy node and these problems need to be considered in the future draft.

9.  Open Issues

9.1.  Stateful and Stateless Problems

SIP can be base on the control of stateful proxy which makes the session management reliable. However, when we use the P2P overlay as SIP's route discovery protocol, the state in peers is unclear. The essence is the tradeoff between controllability and overhead when we consider whether the peers should be stateful or stateless.

One of the design choices is to make some peers such as the P2P proxy to be stateful, and both P2P-SIP UA and the stateful node will be aware of the state of the underlying overlay. For example, the P2P proxy mentioned in this draft should be stateful.

9.2.  Decentralized Bootstrap Process

Although several approaches are proposed to implement the bootstrap process, the decentralized zero-configure bootstrap is still hard to achieve. Thus the session initial process can not be absolutely decentralized.

It is practical to deploy a centralized bootstrap server, however, if we want the SIP to be absolutely decentralized, we should seek for some novel decentralized bootstrap methods.

10.  Acknowledgements

The authors wish to thank Yao Wang, Hua Xu, Xiaosheng Tang, Xu Wang and Zhiyong Feng for their comments. The authors would like to thank Hui Wang and Ning Zhang for the help of review.

11.  References

11.1. Normative References

11.2. Informative References

Authors' Addresses

Full Copyright Statement

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