In this section, we define the parameters and the control message types that uses in our MRSIP framework. We provide a series protocol examples in section 3.3 to demonstrate how the MRSIP works.
3.2.1 Parameter specification and formats
In the original RSIP protocol specification [3] describes the parameters and con-trol messages. Our MRSIP framework extends the specification to provide the ability of authenticate clients and gateways. The extended parameters are de-scribed as follows:
• Client-ID:
A client-ID specifies an MRSIP client’s identity. The client-ID data struc-ture contains a unique 32-bit integers and a string that specifies client’s in-formation. The string can be a private IP address, user’s e-mail address, or
a certificate issued by a particular certificate-authority.
• Gateway-ID:
A Gateway-ID is a string that specifies an MRSIP gateway’s identity. The Gateway-ID data structure contains a unique 32-bit integer and a string that specifies an MRSIP gateway’s identity information.
• Session-ID:
A Session-ID is a unique 32-bit integer that used by MRSIP clients and gateways to differentiate an MRSIP client’s bindings.
• Signature:
The signature is appended in the rest of each request or response message to authenticate the message.
• Client-Ticket:
A client-ticket is issued by a particular MRSIP gateway for a specific client after the registration procedure is succeeded. The client-to-gateway tunnel information and other server information are stored in the client-ticket.
• Session-Ticket:
A session-ticket is issued by a particular MRSIP gateway for a specific client after the address binding procedure is succeeded. The session-ticket contains the assigned IP resources and other parameters given by the gate-way.
• Gateway-Ticket:
A gateway-ticket is issued by a particular MRSIP gateway for the other specific MRSIP gateway after the registration procedure is succeeded. The gateway-ticket contains the MRSIP gateway information.
• Tunnel-Ticket:
A tunnel-ticket is issued by a particular MRSIP gateway for the other spe-cific MRSIP gateway after the tunnel-binding procedure is succeeded. The tunnel-ticket contains the gateway-to-gateway tunnel information, and the IP addresses that can be provided by the remote gateways.
3.2.2 Control message types
In this section we describe the control message types that is used in our MR-SIP protocol. The MRMR-SIP control messages are based on the ”request-response”
model. These control messages contains the register procedures, de-register pro-cedures, tunnel-establishment propro-cedures, address-binding propro-cedures, and host query procedures.
• Registration request and response:
An MRSIP client sends a registration request to its home MRSIP gateway to register itself before requests any resources. An MRSIP gateway should register itself to neighbor gateway before requests any resources or establish tunnels. Both MRSIP client and gateway should not register more than once before it has de-registered. An MRSIP client or gateway should provide his Client-ID or Gateway-ID and signature to the specific gateway, respectively.
The registration response message is used by an MRSIP gateway to confirm
the registration of an MRSIP client or the other MRSIP gateway. A Client-Ticket or a Gateway-Client-Ticket is returned for future operations.
• De-registration request and response:
An MRSIP client or gateway de-registers itself to an MRSIP gateway when the connection is no longer required. If an MRSIP client de-registers itself, all of the client’s address-bindings are revoked. If an MRSIP gateway de-registers itself to the other MRSIP gateway, all of the address binding and tunnels are revoked. The de-registration response message is used by an MRSIP gateway to confirm the request.
• Tunnel-binding request and response:
The tunnel-binding request and response messages are used by an MRSIP gateway to establish a gate-way-to-gateway tunnel with the other MRSIP gateway. An MRSIP gateway should register itself to the specific MRSIP gateway to get one Gateway Ticket before establishing a tunnel between them.
• Free-tunnel request and response:
The free-tunnel request and response are used by an MRSIP gateway to free a tunnel. A tunnel is freed when all the address binding inside the tunnel are all freed.
• Address-query request and response:
An MRSIP client or an MRSIP gateway uses the address-query request mes-sage to ask an MRSIP gateway whether or not a particular address or
net-work is local or remote. The MRSIP client uses this information to deter-mine whether to contact the host directly or via MRSIP gateway. When an MRSIP gateway receives the query-request message, the gateway performs the following procedures if the queried address is not access directly by itself: first, it forwards the query request message to its neighbor MRSIP gateways and wait for response. Second, a tunnel-binding request message will be sent to a specific MRSIP gateway to establish a tunnel between them.
Finally, it returns a response message to the client or gateway that sent the query message.
• Address-binding request and response:
An MRSIP client sends the address-binding request message to its home MRSIP gateway to bind an outside IP address. If the MRSIP gateway cannot allocate the resource requested by the client, it forwards the request to his neighbor gateway. A Session-Ticket is returned to the client and a client-to-gateway tunnel is established between the MRSIP client and its home MRSIP gateway.
• Free-Binding request and response:
When an address binding is no longer required by an MRSIP client, it sends the free-binding request message with a Session-Ticket to the MRSIP gate-way. MRSIP gateway frees the specific resources. If the resource is not own by the gateway, the gateway forwards the request to other MRSIP gateways.
All the unused tunnels between client and gateway will be released.