rfc3103.txt

RFC 的详细文档！

   As mentioned above, an RSIP gateway maintains a mapping of the
   assigned public parameters as demultiplexing fields for uniquely
   mapping them to RSIP host private addresses.  When a packet from the
   public realm arrives at the RSIP gateway and it matches a given set
   of demultiplexing fields, then the RSIP gateway will tunnel it to the
   appropriate RSIP host.  The tunnel headers of outbound packets from X
   to Y, given that X has been assigned Nb, are as follows:

            +---------+---------+---------+
            | X -> Na | Nb -> Y | payload |
            +---------+---------+---------+





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


   There are two basic flavors of RSIP: RSA-IP and RSAP-IP.  RSIP hosts
   and gateways MUST support RSAP-IP and MAY support RSA-IP.  Details of
   RSA-IP and RSAP-IP are found in [RSIP-FRAME].

5.  Transport Protocol

   RSIP is an application layer protocol that requires the use of a
   transport layer protocol for end-to-end delivery of packets.

   RSIP gateways MUST support TCP, and SHOULD support UDP.  Due to the
   fact that RSIP may be deployed across a wide variety of network
   links, RSIP hosts SHOULD support TCP, because of TCP's robustness
   across said variety of links.  However, RSIP hosts MAY support UDP
   instead of TCP, or both UDP and TCP.

   For RSIP hosts and gateways using UDP, timeout and retransmissions
   MUST occur.  We recommend a binary exponential backoff scheme with an
   initial duration of 12.5 ms, and a maximum of six retries (seven
   total attempts before failure).  However, these parameters MAY be
   adjusted or tuned for specific link types or scenarios.

   Once a host and gateway have established a registration using either
   TCP or UDP, they may not switch between the two protocols for the
   duration of the registration.  The decision of whether to use TCP or
   UDP is made by the client, and is determined by the transport
   protocol of the first packet sent by a client in a successful
   registration procedure.

6.  Host / Gateway Relationships

   An RSIP host can be in exactly one of three fundamental relationships
   with respect to an RSIP gateway:

   Unregistered: The RSIP gateway does not know of the RSIP host's
      existence, and it will not forward or deliver globally addressed
      packets on behalf of the host.  The only valid RSIP-related action
      for an RSIP host to perform in this state is to request
      registration with an RSIP gateway.

   Registered: The RSIP gateway knows of the RSIP host and has assigned
      it a client ID and has specified the flow policies that it
      requires of the host.  However, no resources, such as addresses or
      ports, have been allocated to the host, and the gateway will not
      forward or deliver globally addressed packets on behalf of the
      host.  All registrations have an associated lease time.  If this
      lease time expires, the RSIP host automatically reverts to the
      unregistered state.




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


   Assigned: The RSIP gateway has granted one or more bindings of
      resources to the host.  The gateway will forward and deliver
      globally addressed packets on behalf of the host.  Each binding
      has an associated lease time.  If this lease time expires, the
      binding is automatically revoked.

   Architectures in which an RSIP host is simultaneously registered with
   more than one RSIP gateway are possible.  In such cases, an RSIP host
   may be in different relationships with different RSIP gateways at the
   same time.

   An RSIP gateway MAY redirect an RSIP host to use a tunnel endpoint
   for data traffic that is not the RSIP gateway itself, or perhaps is a
   different interface on the RSIP gateway.  This is done by specifying
   the tunnel endpoint's address as part of an assignment.  In such an
   architecture, it is desirable (though not necessary) for the RSIP
   gateway to have a method with which to notify the tunnel endpoint of
   assignments, and the expiration status of these assignments.

   Lease times for bindings and registrations are managed as follows.
   All lease times are given in units of seconds from the current time,
   indicating a time in the future at which the lease will expire.
   These expiration times are used in the ensuing discussion.

   An initial expiration time (R) is given to a registration.  Under
   this registration, multiple bindings may be established, each with
   their own expiration times (B1, B2, ...).  When each binding is
   established or extended, the registration expiration time is adjusted
   so that the registration will last at least as long as the longest
   lease.  In other words, when binding Bi is established or extended,
   the following calculation is performed: R = max(R, Bi).

   Under this scheme, a registration will never expire while any
   binding's lease is still valid.  However, a registration may expire
   when the last binding's lease expires, or at some point thereafter.

7.  Gateway Flow Policy and State

   Since an RSIP gateway is likely to reside on the boundary between two
   or more different administrative domains, it is desirable to enable
   an RSIP gateway to be able to enforce flow-based policy.  In other
   words, an RSIP gateway should have the ability to explicitly control
   which local addresses and ports are used to communicate with remote
   addresses and ports.

   In the following, macro-flow policy refers to controlling flow policy
   at the granularity level of IP addresses, while micro-flow policy
   refers to controlling flow policy at the granularity of IP address



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


   and port tuples.  Of course there may be no policy at all, which
   indicates that the RSIP gateway does not care about the flow
   parameters used by RSIP hosts.  We consider two levels of local flow
   policy and three levels of remote flow policy.

7.1.  Local Flow Policy

   Local flow policy determines the granularity of control that an RSIP
   gateway has over the local addressing parameters that an RSIP host
   uses for particular sessions.

   Since an RSIP host must use at least an IP address allocated by the
   gateway, the loosest level of local flow policy is macro-flow based.
   Under local macro-flow policy, an RSIP host is allocated an IP
   address (RSA-IP) or an IP address and one or more ports to use with
   it (RSAP-IP).  However, the host may use the ports as it desires for
   establishing sessions with public hosts.

   Under micro-flow policy, a host is allocated exactly one port at a
   time.  The host may request more ports, also one at a time.  This
   policy gives the gateway very tight control over local port use,
   although it affords the host less flexibility.

   Note that only local macro-flow policy can be used with RSA-IP, while
   either local macro-flow or local micro-flow policy may be used with
   RSAP-IP.

   Examples of how RSIP flow policy operates are given in Appendix C.

7.2.  Remote Flow Policy

   Remote flow policy determines the granularity of control that an RSIP
   gateway has over the remote (public) hosts with which an RSIP host
   communicates.  In particular, remote flow policy dictates what level
   of detail that a host must specify addressing parameters of a remote
   host or application before the RSIP gateway allows the host to
   communicate with that host or application.

   The simplest and loosest form of flow policy is no policy at all.  In
   other words, the RSIP gateway allocates addressing parameters to the
   host, and the host may use these parameters to communicate with any
   remote host, without explicitly notifying the gateway.

   Macro-flow policy requires that the host identify the remote address
   of the host that it wishes to communicate with as part of its request
   for local addressing parameters.  If the request is granted, the host
   MUST use the specified local parameters only with the remote address
   specified, and MUST NOT communicate with the remote address using any



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


   local parameters but the ones allocated.  However, the host may
   contact any port number at the remote host without explicitly
   notifying the gateway.

   Micro-flow policy requires that the host identify the remote address
   and port of the host that it wishes to communicate with as part of
   its request for local addressing parameters.  If the request is
   granted, the host MUST use the specified local parameters only with
   the remote address and port specified, and MUST NOT communicate with
   the remote address and port using any local parameters but the ones
   allocated.

   Remote flow policy is implemented in both the ingress and egress
   directions, with respect to the location of the RSIP gateway.

7.3.  Gateway State

   An RSIP gateway must maintain state for all RSIP hosts and their
   assigned resources.  The amount and type of state maintained depends
   on the local and remote flow policy.  The required RSIP gateway state
   will vary based on the RSIP method, but will always include the
   chosen method's demultiplexing parameters.

7.3.1.  RSA-IP State

   An RSIP gateway serving an RSIP host using the RSA-IP method MUST
   maintain the following minimum state to ensure proper mapping of
   incoming packets to RSIP hosts:

      -  Host's private address
      -  Host's assigned public address(es)

7.3.2.  RSAP-IP State

   An RSIP gateway serving an RSIP host using the RSAP-IP method MUST
   maintain the following minimum state to ensure proper mapping of
   incoming packets to RSIP hosts:

      -  Host's private address
      -  Host's assigned public address(es)
      -  Host's assigned port(s) per address

7.3.3.  Flow State

   Regardless of whether the gateway is using RSA-IP or RSAP-IP,
   additional state is necessary if either micro-flow based or macro-
   flow based remote policy is used.




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


   If the gateway is using macro-flow based remote policy, the following
   state must be maintained:

      -  Remote host's address

   If the gateway is using micro-flow based remote policy, the following
   state must be maintained:

      -  Remote host's address
      -  Remote host's port

   More state MAY be used by an RSIP gateway if desired.  For example,
   ToS/DS bytes may be recorded in order to facilitate quality of
   service support.

8.  Parameter Specification and Formats

   In this section we define the formats for RSIP parameters.  Each RSIP
   message contains one or more parameters that encode the information
   passed between the host and gateway.  The general format of all
   parameters is TLV (type-length-value) consisting of a 1-byte type
   followed by a 2-byte length followed by a 'length' byte value as
   shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Length             |     Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Value ...
   +-+-+-+-+-+-+-+-+-+-+-+

   The value field may be divided into a number of other fields as per
   the type of the parameter.  Note that the length field encodes the
   number of bytes in the value field, NOT the overall number of bytes
   in the parameter.

8.1.  Address

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = 1   |            Length             |    Addrtype   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Address...
   +-+-+-+-+-+-+-+-+-+-+-+





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


   The address parameter contains addressing information, either an IPv4
   address or netmask, an IPv6 address or netmask, or a fully qualified
   domain name (FQDN).  The Addrtype field is 1 byte in length,
   indicating the type of address.

             Addrtype       Length of address field (in bytes)
             ----           --------------------------------
      0      Reserved       0
      1      IPv4           4
      2      IPv4 netmask   4
      3      IPv6           16
      4      FQDN           varies

   For FQDN (Fully qualified domain name), the length of the address
   field will be one less than the value of the length field, and the
   name will be represented as an ASCII string (no terminating
   character).

   In some cases, it is necessary to specify a "don't care" value for an
   address.  This is signified by a setting the length field to 1 and