Browse Prior Art Database

A method for Realm Specific IP signaling using DHCP

IP.com Disclosure Number: IPCOM000028926D
Original Publication Date: 2004-Jun-08
Included in the Prior Art Database: 2004-Jun-08
Document File: 3 page(s) / 30K

Publishing Venue

IBM

Abstract

Disclosed in this paper is a new method of using existing DHCP implementations as signaling vehicle for RSIP. Current specification for RSIP defines operations on the flow of packets and also signaling that has to happen between RSIP clients and server. The packet flow consists of a) Client preparing the packet with RSIP global address and port and tunneling it with its own address up to RSIP server b) RSIP server stripping the tunnel header and forwarding it to the destination machine c) RSIP server receiving the response packets and tunneling them back to the Client Signaling part consists of a) Client discovering RSIP server b) Client registering with RSIP server c) Client requesting global address, port pair(s). d) Optionally client querying RSIP server to find out whether a particular address to which one of its applications trying to connect is local or remote (outside) of the RSIP server (essentially means whether translation is required or not) Implementing this level of extensive signaling between each client and the RSIP server would be costly in terms of a) Server performance b) Implementation complexity of the signaling vehicle for RSIP resource management

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 3

A method for Realm Specific IP signaling using DHCP

Currently clients that use DHCP addresses, will by default contact DHCP servers at the boot time to lease IP addresses. It is proposed that this communication mechanism should be extended to provide transport vehicle for RSIP signaling. The following diagram describes the entities involved and the interactions among them.

Figure 1: Interaction among entities

In Fig.1 interactions 1-10 are signaling related and are explained as below:

1. Existing DHCP server implementations should be extended to understand RSIP server operations. This component is called RSIP Proxy. Initially, this component requests for a chunk of resources from the RSIP server. Resources in this context are the IP addresses and port numbers that are visible to the other realms.
2. RSIP server responds with a chunk from the available resources
3. On the client machine DHCP client should be extended to understand RSIP client

DHCP

Client

11

     RSIP Server

RSIP Client

12,15

TC

1,2,13,14

RSIP Proxy

5,9

4,8

CAD

                     DHCP 3,6,7,10 Server

1

[This page contains 11 pictures or other non-text objects]

Page 2 of 3

operations. Client machine at the boot time contacts the DHCP server for its regular private IP address and related information.
4. The DHCP server checks from the client's request whether it is RSIP enabled or not. Depending on this information it talks to RSIP proxy to register this client to RSIP network.
5. RSIP proxy adds the registration entry (for this client) to the Client Associations Database (CAD).
6. DHCP server combines the clientID (RSIP registration ID) along with the private IP and related information and sends it back to the client.
7. Now, using the clientID, RSIP client requests for resource (ip, port) to connect to other realms.
8. DHCP server passes this request to the RSIP proxy
9. RSIP proxy matches it with the existing clientID in CAD, allocates new resource for this client and records t...