rfc3103.txt

RFC 的详细文档！

                        <Error>
                        [Message Counter]
                        [Client ID]
                        [Bind ID]

9.1.3.  Behavior

   An ERROR_RESPONSE message MUST only be transmitted by an RSIP
   gateway.  An RSIP host that detects an error in a message received
   from an RSIP gateway MUST silently discard the message.  There are no
   error conditions that can be caused by an ERROR_RESPONSE.  An
   ERROR_RESPONSE is typically transmitted in response to a request from
   an RSIP host, but also may be transmitted asynchronously by an RSIP
   gateway.

9.2.  REGISTER_REQUEST

9.2.1.  Description

   The REGISTER_REQUEST message is used by an RSIP host to establish
   registration with an RSIP gateway.  An RSIP host MUST register before
   it requests resources or services from an RSIP gateway.  Once an RSIP
   host has registered with an RSIP gateway, it may not register again
   until it has de-registered from that gateway.

9.2.2.  Format

   <REGISTER_REQUEST> ::= <Version>
                          <Message Type>
                          <Overall Length>
                          [Message Counter]

9.2.3.  Behavior

   The following message-specific error conditions exist:

      -  If the host is already registered with the gateway, the gateway
         MUST respond with an ERROR_RESPONSE containing the
         ALREADY_REGISTERED error and the RSIP host's client ID.

      -  If the gateway's policy will not allow the host to register,
         the gateway MUST respond with an ERROR_RESPONSE containing the
         REGISTRATION_DENIED error.



Borella, et al.               Experimental                     [Page 18]

RFC 3103              RSIP Protocol Specification           October 2001


9.3.  REGISTER_RESPONSE

9.3.1.  Description

   The REGISTER_RESPONSE message is used by an RSIP gateway to confirm
   the registration of an RSIP host, and to provide a client ID, flow
   policy, and possibly a message counter and one or more RSIP methods
   and/or tunnel types.

9.3.2.  Format

   <REGISTER_RESPONSE> ::= <Version>
                           <Message Type>
                           <Overall Length>
                           <Client ID>
                           <Lease time>
                           <Flow Policy>
                           [Message Counter]
                           [RSIP Method]...
                           [Tunnel Type]...

9.3.3.  Behavior

   An RSIP gateway MUST assign a different client ID to each host that
   is simultaneously registered with it.  The RSIP gateway MAY respond
   with one or more RSIP methods and tunnel types that it supports.  If
   an RSIP method is not specified, RSAP-IP MUST be assumed.  If a
   tunnel type is not specified, IP-IP MUST be assumed.

9.4.  DE-REGISTER_REQUEST

9.4.1.  Description

   The DE-REGISTER_REQUEST message is used by an RSIP host to de-
   register with an RSIP gateway.  If a host de-registers from the
   assigned state, all of the host's bindings are revoked.  The host
   SHOULD NOT de-register from the unregistered state.

9.4.2.  Format

   <DE-REGISTER_REQUEST> ::= <Version>
                             <Message Type>
                             <Overall Length>
                             <Client ID>
                             [Message Counter]






Borella, et al.               Experimental                     [Page 19]

RFC 3103              RSIP Protocol Specification           October 2001


9.4.3.  Behavior

   The following message-specific error conditions exist:

      -  If the host is not registered with the gateway, the gateway
         MUST respond with an ERROR_RESPONSE containing the
         REGISTER_FIRST error.

      -  If the message contains an incorrect client ID, the gateway
         MUST respond with an ERROR_RESPONSE containing the
         BAD_CLIENT_ID error.

   If there are no errors that result from this message, the gateway
   MUST respond with an appropriate DE-REGISTER_RESPONSE.  Upon de-
   registering a host, an RSIP gateway must delete all binds associated
   with that host and return their resources to the pool of free
   resources.  Once a host has de-registered, it may not use any of the
   RSIP gateway's resources without registering again.

9.5.  DE-REGISTER_RESPONSE

9.5.1.  Description

   The DE-REGISTER_RESPONSE message is used by an RSIP gateway to
   confirm the de-registration of an RSIP host or to force an RSIP host
   to relinquish all of its bindings and terminate its relationship with
   the RSIP gateway.  Upon receiving a DE-REGISTER_RESPONSE message, an
   RSIP host MUST stop all use of the resources that have been allocated
   to it by the gateway.

9.5.2.  Format

   <DE-REGISTER_RESPONSE> ::= <Version>
                              <Message Type>
                              <Overall Length>
                              <Client ID>
                              [Message Counter]

9.5.3.  Behavior

   An RSIP gateway MUST send a DE-REGISTER_RESPONSE in response to a
   valid DE-REGISTER_REQUEST.  An RSIP gateway MUST send a DE-
   REGISTER_RESPONSE to an RSIP host when that host's registration lease
   time times out.  An RSIP gateway SHOULD send a DE-REGISTER_RESPONSE
   if it detects that it will no longer be able to perform RSIP
   functionality for a given host.  An RSIP host MUST be ready to accept
   a DE-REGISTER_RESPONSE at any moment.




Borella, et al.               Experimental                     [Page 20]

RFC 3103              RSIP Protocol Specification           October 2001


9.6.  ASSIGN_REQUEST_RSA-IP

9.6.1.  Description

   The ASSIGN_REQUEST_RSA-IP message is used by an RSIP host to request
   resources to use with RSA-IP.  Note that RSA-IP cannot be used in
   combination with micro-flow based local policy.

9.6.2.  Format

   <ASSIGN_REQUEST_RSA-IP> ::= <Version>
                               <Message Type>
                               <Overall Length>
                               <Client ID>
                               <Address (local)>
                               <Address (remote)>
                               <Ports (remote)>
                               [Message Counter]
                               [Lease Time]
                               [Tunnel Type]

9.6.3.  Behavior

   The RSIP host specifies two address parameters.  The RSIP host may
   request a particular local address by placing that address in the
   first address parameter.  To indicate that it has no preference for
   local address, the RSIP host may place a "don't care" value in the
   address parameter.

   If macro-flow based remote policy is used, the host MUST specify the
   remote address that it will use this binding (if granted) to contact;
   however, the remote port number MAY remain unspecified.  If micro-
   flow based remote policy is used, the host MUST specify the remote
   address and port number that it will use this binding (if granted) to
   contact.  If no flow policy is used, the RSIP host may place a "don't
   care" value in the value fields of the respective address and ports
   parameters.

   The following message-specific error conditions exist:

      -  If the host is not registered with the gateway, the gateway
         MUST respond with an ERROR_RESPONSE containing the
         REGISTER_FIRST error.

      -  If the message contains an incorrect client ID, the gateway
         MUST respond with an ERROR_RESPONSE containing the
         BAD_CLIENT_ID error.




Borella, et al.               Experimental                     [Page 21]

RFC 3103              RSIP Protocol Specification           October 2001


      -  If the local address parameter is a don't care value and the
         RSIP gateway cannot allocate ANY addresses, the RSIP gateway
         MUST respond with an ERROR_RESPONSE containing the
         LOCAL_ADDR_UNAVAILABLE error.

      -  If the local address parameter is not a don't care value there
         are three possible error conditions:

         o  If the RSIP gateway cannot allocate ANY addresses, it MUST
            respond with an ERROR_RESPONSE containing the
            LOCAL_ADDR_UNAVAILABLE error.

         o  If the RSIP gateway cannot allocate the requested address
            because it is in use, the RSIP gateway MUST respond with an
            ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.

         o  If the RSIP gateway cannot allocate the requested address
            because it is not allowed by policy, the RSIP gateway MUST
            respond with an ERROR_RESPONSE containing the
            LOCAL_ADDR_UNALLOWED error.

      -  If macro-flow based remote policy is used and the requested
         remote address is not allowed by the RSIP gateway's policy, the
         RSIP gateway MUST respond with an ERROR_RESPONSE containing the
         REMOTE_ADDR_UNALLOWED error.

      -  If micro-flow based remote policy is used and the requested
         remote address / port pair is not allowed by the RSIP gateway's
         policy, the RSIP gateway MUST respond with an ERROR_RESPONSE
         containing the REMOTE_ADDRPORT_UNALLOWED error.

      -  If an unsupported or unallowed tunnel type is specified, the
         RSIP gateway MUST respond with an ERROR_RESPONSE containing the
         BAD_TUNNEL_TYPE error.

      -  If the host has not specified local or remote address or port
         information in enough detail, the RSIP gateway MUST respond
         with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION
         error.

9.7.  ASSIGN_RESPONSE_RSA-IP

9.7.1.  Description

   The ASSIGN_RESPONSE_RSA-IP message is used by an RSIP gateway to
   deliver parameter assignments to an RSIP host using RSA-IP.  A host-
   wise unique bind ID, lease time, and tunnel type must be provided for
   every assignment.



Borella, et al.               Experimental                     [Page 22]

RFC 3103              RSIP Protocol Specification           October 2001


9.7.2.  Format

   <ASSIGN_RESPONSE_RSA-IP> ::= <Version>
                                <Message Type>
                                <Overall Length>
                                <Client ID>
                                <Bind ID>
                                <Address (local)>
                                <Address (remote)>
                                <Ports (remote)>
                                <Lease Time>
                                <Tunnel Type>
                                [Address (tunnel endpoint)]
                                [Message Counter]
9.7.3.  Behavior

   If no remote flow policy is used, the RSIP gateway MUST use "don't
   care" values for the remote address and ports parameters.  If macro-
   flow based remote policy is used, the remote address parameter MUST
   contain the address specified in the associated request, and the
   remote ports parameter MUST contain a "don't care" value.  If micro-
   flow based remote policy is used, the remote address and remote ports
   parameters MUST contain the address and port information specified in
   the associated request.

   If the host detects an error or otherwise does not "understand" the
   gateway's response, it SHOULD send a FREE_REQUEST with the bind ID
   from the said ASSIGN_RESPONSE_RSA-IP.  This will serve to help
   synchronize the states of the host and gateway.

   The address of a tunnel endpoint that is not the RSIP gateway MAY be
   specified.  If this parameter is not specified, the RSIP gateway MUST
   be assumed to be the tunnel endpoint.

9.8.  ASSIGN_REQUEST_RSAP-IP

9.8.1.  Description

   The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP host to request
   resources to use with RSAP-IP.  The RSIP host specifies two address
   and two port parameters, the first of each, respectively, refer to
   the local address and port(s) that will be used, and the second of
   each, respectively, refer to the remote address and port(s) that will
   be contacted.