Subject: RSIP QoS interaction

From: Jeffrey Lo <[email-masked]>
Date: Thu, 9 Dec 1999 18:13:46 -0800 (PST)

Hi,

In an attempt to write up a section for the RSIP framework draft
<draft-ietf-nat-rsip-framework-03.txt> on RSIP interaction with Intserv
QoS signalling model using RSVP, I would like to hear more about your
opinion on how the RSVP model would fit into the RSIP scenario. In
particular, we are interested in the more general case of having a
unicast receiver on the private network contacting a sender on the
internet, as follows :

		    Tunnel                    Internet
	Receiver ============= RSIP gateway ------------- Sender

There are a number of scenarios to consider and it seems that some of the
ideas mentioned in draft-ietf-rsvp-tunnel-04.txt are relevant. Any
thoughts of how RSIP implementation on the RSIP gateway would complicate
RSVP or vice versa?

What's the status of draft-ietf-rsvp-tunnel-04.txt?

----

Jeffrey Lo
C&C Research Labs,
NEC USA, Inc.
Tel : (408) 943 3033
Fax : (408) 943 3099

---

From: Andreas Terzis <[email-masked]>
Date: Thu, 9 Dec 1999 20:05:03 -0800 (PST)

> What's the status of draft-ietf-rsvp-tunnel-04.txt?

Well, I can at least answer this question :-)

draft-ietf-rsvp-tunnel-04.txt is waiting in the RFC Editor's queue to 
become a draft standard. 

Unfortunately I cannot help you with the other questions, since I don't
have a clue about RSIP. If you could explain a little bit...

regards,

-andreas

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Andreas A. Terzis,                  | UCLA Computer Science Department
[email-masked]                  | Internet Research Lab 
http://irl.cs.ucla.edu/~terzis      |
PGP Signature available at http://www.cs.ucla.edu/~terzis/pub_key.asc

---

From: Jeffrey Lo <[email-masked]>
Date: Mon, 13 Dec 1999 11:22:05 -0800 (PST)

Andreas,

I have attached the "Architecture" section of the RSIP framework doc. For
more information, kindly refer to the draft 
<draft-ietf-nat-rsip-framework-02.txt>. There are a few cases to consider.

1. RSVP unaware cloud within private realm and on RSIP server.
I think this case is the simplest and will work. 

2. RSVP aware cloud within private realm and on RSIP server.
This case requires usage of technologies mentioned in the RSVP tunnel
draft, be it type1, type 2 or type3 tunnels between the RSIP client and
RSIP server. However, as soon as a RSVP daemon is run on the RSIP server,
I think it raises the following possible complications:

a. The RSVP daemon on RSIP server may not see the RSVP messages. In the
case of RSA-IP, the RSIP module may encapsulate the RSVP path messages
coming from the public side within a private IP header before handling
over to IP layer. Hence, the packet will get routed using the encapsulated
header and not be de-multiplex to RSVP daemon.

b. Even if the RSVP daemon gets the messages, the destination address
within the session object is actually addressed to one of the RSIP
router's interface (Conceptually, RSIP essentially enables the RSIP client
a temporal presence on the RSIP server), RSVP signalling may just
terminates there. 

Jeffrey Lo

-------------------------------------------------------------------------

In a typical scenario where RSIP is deployed, there are some number
of hosts within one addressing realm connected to another addressing
realm by the RSIP server.  This model is diagrammatically represented
as follows:

         RSIP Client             RSIP Server                    Host
            Xa                    Na   Nb                       Yb
         [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
                  (  Network   )            (  Network   )

   Hosts X and Y belong to different addressing realms A and B,
   respectively, and N is an RSIP server (which may also act as a NAT
   router).  N has two interfaces: Na on address space A, and Nb on
   address space B. N may have a pool of addresses in address space B
   which it can assign to or lend to X and other hosts in address space
   A.  These addresses are not shown above, but they can be denoted as
   Nb1, Nb2, Nb3 and so on. As is often the case, the hosts within
   address space A are likely to use private addresses while the RSIP
   server is multi-homed with one or more private addresses from address
   space A in addition to it's public addresses from address space B.
   Host X wishing to establish an end-to-end connection to a network
   entity Y situated within address space B first negotiates and obtains
   assignment of the resources (e.g. addresses and other routing
   parameters of address space B) from the RSIP server. Upon assignment
   of these parameters, the RSIP server creates a mapping, known as a
   bind, of X's addressing information and the assigned resources. This
   binding enables the RSIP server to correctly de-multiplex and forward
   inbound traffic generated by Y for X. If permitted by the RSIP
   server, X may create multiple such bindings on the same RSIP server.
   A lease time SHOULD be associated with each bind.
   Using the public parameters assigned by the RSIP server, RSIP clients
   route (usually tunnel) data packets to the RSIP server within address
   space A. If tunneling is used, the RSIP server acts as the end point
   of such tunnels, stripping off the outer headers and routing the
   inner packets onto the public realm. As mentioned above, an RSIP
   server maintains a mapping of the assigned public parameters as
   demultiplexing tuples for uniquely mapping them to RSIP client
   private addresses.  When a packet from the public realm arrives at
   the RSIP server and it matches a given set of demultiplexing tuples,
   then the RSIP server will tunnel it to the appropriate RSIP client.
   A disadvantage of RSIP is that it requires modification of RSIP
   clients to enable RSIP client-server negotiation, usage of the
   assigned resources and in the case when tunneling is used, to tunnel
   the data packets to the RSIP server.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Dec 1999 15:45:48 -0600

BTW, RSIP also has to interact with the diffserv QOS model. This just seems
to be a special case of "diffserv and tunnels" which is a current diffserv
WG item. 

  Brian

Jeffrey Lo wrote:
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe nat' in the body of the message.

---

From: Jeffrey Lo <[email-masked]>
Date: Mon, 13 Dec 1999 22:20:09 -0800 (PST)

Brian,

There will be a section in the framework draft discussing this. Thanks

----

Jeffrey Lo
C&C Research Labs,
NEC USA, Inc.
Tel : (408) 943 3033
Fax : (408) 943 3099