Submitted to NAT Working Group                                C. Zaccone
                                                    Y. T'Joens, B. Sales
INTERNET DRAFT                                                   Alcatel
<draft-zaccone-nat-rsip-gen-arch-00.txt>
                                                        October 15, 1999
                                                  Expires April 15, 2000

                   RSIP generic network architecture

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


Abstract

   Currently, the RSIP architecture [RSIP-FRAM] concentrates all the
   functionalities of the system and associated databases into a single
   location, the edge router. This approach may introduce weaknesses and
   restrictions when multiple edge routers are available either towards
   a unique ISP, or towards multiple ISPs (multi-homing environment).

   This document introduces a generic architecture where functionalities
   are distributed and that is designed with the aim of increasing the
   robustness of the system while enabling to gain benefit of
   multihoming towards one or more ISPs.








Zaccone, et al.          Expires April 15, 2000                 [Page 1]

Internet Draft   draft-zaccone-nat-rsip-gen-arch-00.txt October 15, 1999


Table of Contents

   1.   Introduction
   2.   Generic architecture
   2.1. Edge Routers
   2.2. Internet Session Manager (ISM)
   2.3. Configuration Manager (CM)
   2.4. Public DNS server (PUDS)
   2.5. Private DNS server (PRDS)
   2.6. Policy Manager (PM)
   3.   Functional options
   3.1. Determination of the locality of destination
   3.2. Transport configuration
   4.   Operations
   4.1. Outbound session
   4.2. Inbound session
   5.   References

1. Introduction

   The next figure depicts the RSIP architecture as described in [RSIP-
   FRAM]. This architecture builds upon the assumption where two
   different addressing realms are connected via a single router. In
   this architecture, all functions of authentication, authorization,
   configuration and the management of RSIP clients's Internet sessions
   are concentrated into a single point, the RSIP server.

           .--.                                   .--.
    RSIP   |  |                            Inet   |  |
    client ----               RSIP           host ----
          /    \               server            /    \
          ------              +--+               ------
             +---------------+|  |+----------------+
                              +--+
               Addressing                Addressing
                  realm A                   realm B
                             RSIP architecture

   The architecture to be described in this document, is designed in a
   more generic way covering a broader set of topologies, including
   single and multiple connections to one or more ISPs (multi-homed
   environment).

   This generic architecture also proposes to decouple a set of
   functions from the RSIP server and assign them to other entities with
   the aim to have a more robust and extensible solution. Moreover, when
   multiple connection scenarios are taken into account, decoupling the
   functions enables the system to be more scalable and manageable.



Zaccone, et al.          Expires April 15, 2000                 [Page 2]

Internet Draft   draft-zaccone-nat-rsip-gen-arch-00.txt October 15, 1999


2. Generic architecture

   The following figure gives an overview of the architecture.  The
   architecture is composed of the following components:

                      Private                    Externals
                         realm                     realms
         Policy
           management entity(s)
                (PME)           |
           +--------------------|
                                |      Edge
                                |       router i
        Internet session        |       1<i<Nb1
          management entity(s)  |          +--+
               (ISM)            |---------+|  |+--- ISP 1
           +--------------------|          +--+
                                |
                                |       Edge
                                |        router j
       Configuration            |        1<j<Nb2
          management entity(s)  |          +--+
               (CM)             |---------+|  |+---- ISP 2
           +--------------------|          +--+
                                |       ....         ISP ...
                                |
                                |       Edge
                                |        router k
       Configuration            |        1<k<NbX
          management entity(s)  |          +--+
               (CM)             |---------+|  |+---- ISP X
           +--------------------|          +--+
                                |
       Public                   |       .--.Host
            DNS server          |       |  | (RSIP Client)
           +--------------------|       ----
                                |      /    \
       Private                  |      ------
           DNS server           |--------+
           +--------------------|
                                |

                           Generic architecture

   Note that the picture merely gives a functional decomposition of the
   system, where the engineering approach may possibly combine some of
   these functions in a single physical device (e.g.: see further
   private and public DNS servers).



Zaccone, et al.          Expires April 15, 2000                 [Page 3]

Internet Draft   draft-zaccone-nat-rsip-gen-arch-00.txt October 15, 1999


2.1. Edge Routers

   The architecture is composed of a set of Nb1 edge routers towards ISP
   1, Nb2 edge routers towards ISP 2, ... NbX edge routers towards ISP
   X.

2.2. Internet Session Manager (ISM)

   The Internet Session Manager is responsible for the management of
   information related to current RSIP client Internet sessions. The
   information managed by the ISM includes (a) the RSIP session
   parameters (mapping between public IP address (port range) to private
   IP address of the host in present possession), (b) the data related
   to the transport mechanism (responsible edge router(s),
   tunnel/transport path related information ...)  (c) host/user
   accounting data.

   The ISM works in close collaboration with the Configuration Manager
   concerning  parameters (e.g.: IP address, port range, ...) related to
   the Internet sessions. It also collaborates with the Edge Routers in
   order to realize information synchronization and potential
   restoration in case of failure. Finally, it also works in
   collaboration with the Policy Manager in the context of host/user
   accounting.

   Note that the ISM may be replicated for reliability and fault
   tolerance purposes.

2.3. Configuration Manager (CM)

   The Configuration Manager is responsible for the management of IP
   address pools. In extenso, it is in charge of the ISP selection, the
   assignment/release  of the address reuse parameters (IP address, port
   range, supplementary identifier, edge routers IP adresses) and the
   configuration of RSIP clients.

   The configuration of RSIP client may be initiated within  the RSIP
   client itself or via an external stimulus (e.g. name request to the
   public DNS server). For the latter possibility, the RSIP client must
   be able to be externally triggered.

   The CM collaborates with the Internet Session Manager in order to
   create/remove Internet sessions.

   Note that the CM may be replicated for reliability and fault
   tolerance purposes.

2.4. Public DNS server (PUDS)



Zaccone, et al.          Expires April 15, 2000                 [Page 4]

Internet Draft   draft-zaccone-nat-rsip-gen-arch-00.txt October 15, 1999


   The public DNS server is responsible for DNS requests issued from
   external realms. That is to say, it acts as the public authoritative
   name server for the private domain. This name server handles requests
   concerning hostnames of the private domain and public IP addresses
   from the available address pools. Moreover, it is also responsible
   for DNS requests issued by any private DNS server related to
   hostnames and IP addresses of external (public) realms (it acts as
   the root DNS server of the private network).

   It is further responsible for the management of inbound session
   towards publicaly available hosts and servers.  Indeed, when a
   request concerns a hostname which is currently not bound to an IP
   address, the public DNS server is responsible to trigger the RSIP
   client configuration by informing the Configuration Manager.

   Note that the public DNS server and Configuration Manager have to be
   in close relation in order to maintain the information up-to-date and
   accurate. Moreover, the public DNS server has to be permanently
   globaly reachable and therefore requires a permanently assigned
   public IP address.

2.5. Private DNS server (PRDS)

   The private DNS server is responsible for DNS requests issued from
   the private realm. In fact relative to the private domain, this name
   server is authoritative and mapping records for hostnames of the
   domain point always to private IP addresses ([PRIV-ADDR-ALLOC]). By
   being authoritative, we can ensure that private communications will
   never require the use of a public IP address.

   For requests which concern public domains, the private DNS  server
   contacts its root name server which is here the public DNS server.

   Note that both private and public DNS servers may be logically hosted
   by a single name server as soon as this name server is able to react
   differently according to the origin of a DNS request.

2.6. Policy Manager (PM)

   The Policy Manager is responsible for the management of Internet
   access policies. It manages RSIP client/user access rights to gain
   Internet connectivity. This component collaborates with the CM in the
   context of granting Internet access to hosts/users, with the Internet
   Session Manager in the context of host/user accounting.

   Note that the PM may be replicated for reliability and fault
   tolerance purposes.




Zaccone, et al.          Expires April 15, 2000                 [Page 5]

Internet Draft   draft-zaccone-nat-rsip-gen-arch-00.txt October 15, 1999


3. Functional options

   This section briefly describes some functionalities for which the
   location is open.

3.1. Determination of the locality of destination

   In the RSIP architecture ([RSIP-ARCH]) the host has to determine
   whether to transmit a datagram for local delivery, or utilise the
   Internet connectivity technology offered by the network.

   This functionality can be mapped upon two different locations.
   [RSIP-FRAM] proposes to map this functionality on the RSIP server
   (i.e.: the RSIP client queries the RSIP server).  In the context of
   the here proposed architecture, this would coincide with a mapping on
   the Internet Session Manager. On the other hand, it is possible to
   locate this task at the RSIP client, by introducing some routes into
   its local IP stack.

3.2. Transport configuration

   Typically, two transport schemes may be deployed to transfer the
   public destinated IP datagrams within the private network ([TRANSP-
   FRAM]), a tunneled approach and a non-tunneled approach. In the first
   scheme, a transport path consists of an IP tunnel which has to be
   established between the RSIP client and and edge routers connected to
   the ISP which owns the IP address assigned to the RSIP client. In the
   second scheme, the transport path is the native IP transport
   mechanism provided within the network by the installation of routing
   information within a set of internal routers.

   For the tunneled transport scheme, the RSIP client could be
   responsible for the setup of a transport path.  Indeed, after its
   configuration, the RSIP client may know which edge router is
   designated to be the endpoint of the tunnel and therefore set up the
   tunnel. Note that the CM has also communicated the assigned
   parameters to the edge router (via the ISM) so that the RSIP client
   may not use it with modified parameters (non assigned parameters).

   For the non-tunneled approach scheme, the RSIP client may also be
   responsible for the transport path setup as described in [TRANSPORT-
   MECH].

4. Operations

   This section describes how the architecture is used for both outbound
   and inbound sessions. Note that when two functional components do not
   co-reside, the interface specification should be standardized.



Zaccone, et al.          Expires April 15, 2000                 [Page 6]

Internet Draft   draft-zaccone-nat-rsip-gen-arch-00.txt October 15, 1999


4.1 Outbound session

   As soon as a RSIP client determines that it needs Internet
   connectivity (either by querying the responsible entity, either by
   self-determination), it contacts the CM in order to start the
   Internet access setup procedure. This setup procedure goes through 3
   phases.

   In the first phase, the RSIP client is authenticated (the CM proxy
   the request to the PM), if the current policy authorizes the RSIP
   client to gain Internet access the second phase is authorized and
   started otherwise the process stops here. During the second phase,
   the CM determines which ISP will be used and the negotiation about
   the parameters to assign is started. When the negotiation is done,
   the third phase starts. During that phase, the CM contacts the public
   name server in order to update the current record for the RSIP client
   (however, this is only realized if the IP address will not be shared
   amongst multiple RSIP clients). It also contacts the ISM in order to
   communicate the assignment of the parameters. In the meanwhile, the
   transport path is established. Note that the edge routers contact the
   ISM in order to check if the request is authorized.

4.2 Inbound session

   Access to hosts/servers from the Internet is possible using hostnames
   as global identifier. Indeed, Internet hosts should try to contact
   hosts/servers of the private domain by first making a name resolution
   request. If no IP address is available in the mapping record, when
   the authoritative name server processes this request, it will contact
   the CM in order to trigger the configuration of the corresponding
   RSIP client.

   When the CM receives the trigger, it will contact the PM to check if
   the RSIP client is authorized to accept inbound session. If this is
   the case, the CM will trigger the RSIP client. The process after this
   is the same as for the outbound session (except perhaps for the first
   phase which may be useless).

   Note that this scheme is not designed to operate at the port
   translation address reuse level as we can not know in advance which
   port the initiator of the name request will try to connect to.
   Indeed, assume that an IP address is assigned to multiple RSIP
   clients, let us say hosts A and B, that the public DNS server has
   assigned a record for host A and that a name request came out for
   host A. As the DNS server has a record for host A, it will resolve
   the mapping, but if afterwards the initiator of the name request
   tries to connect to host A using a port assigned to host B, the
   connection will not be the expected one.



Zaccone, et al.          Expires April 15, 2000                 [Page 7]

Internet Draft   draft-zaccone-nat-rsip-gen-arch-00.txt October 15, 1999


   However, this scheme may be applicable for well known services, since
   for these services, one may know in advance the port that will be
   used. Indeed, assume that in the example above host A was offering
   web services (and then assigned port 80) and that the name request
   was for ' www.company.com', as the www port is wel know we can ensure
   that web request will correctly be destinated to host A.

5. References


   [RSIP-FRAM]
           M. Borella, D. Grabelsky, "Realm Specific IP: A Framework",
           Internet Draft <draft-ietf-nat-rsip-framework-01.txt>, Mai
           1999.


   [PRIV-ADDR-ALLOC]
           Rekhter Y., Moskowitz B., Karrenberg D., G. de Groot, and
           Lear E.,  "Address Allocation for Private Internets", RFC
           1918.


   [TRANSP-FRAM]
           C. Zaccone, Y. T'Joens, B. Sales, "Framework for end-2-end
           native transport",  Internet Draft <draft-zaccone-nat-
           transp-fram-00.txt>, October 1999.


   [TRANSP-MECH]
           C. Zaccone, Y. T'Joens, B. Sales, "Mechanims for end-2-end
           native transport",  Internet Draft <draft-zaccone-nat-
           transport-01.txt>, October 1999.

Authors Addresses

   Carmelo Zaccone
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-8344
   Fax   : 32-3-240-9932
   E-mail: Carmelo.Zaccone@Alcatel.be

   Yves T'Joens
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-7890
   Fax   : 32-3-240-9932
   E-mail: Yves.Tjoens@Alcatel.be



Zaccone, et al.          Expires April 15, 2000                 [Page 8]

Internet Draft   draft-zaccone-nat-rsip-gen-arch-00.txt October 15, 1999


   Bernard Sales
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-9574
   Fax   : 32-3-240-9932
   E-mail: Bernard.Sales@Alcatel.be













































Zaccone, et al.          Expires April 15, 2000                 [Page 9]