Re: int-serv over e.g. ATM

[Andrew Smith <[e-mail]>]

> Date: Thu, 9 Nov 1995 17:28:19 +0200
> From: Juha Heinanen <[e-mail]>
> To: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail],
>         [e-mail], [e-mail]
> Subject: Re: int-serv over e.g. ATM

Juha,

> lets assume that you have a atm lan with 500 hosts and one single
> router.  let also assume that the hosts don't all share a common address
> prefix.  now if a wants to talk to b and a and b have different address
> prefixes, how can the source figure out by looking into qos only if it
> should send the the rsvp request to the router or create a direct vc?

This is a fairly fundamental question for L3 over ATM. MPOA group in ATM Forum
has been studying this issue for some time now, still with no concensus on
how to tackle it. Here's my cut:

There are at least 2 major cases with several minor variants:

1. IP-over-LAN host, via router onto ATM: LAN host signals desired QoS via RSVP. 
   The "best" we can hope for is a lightly-loaded LAN and then a
   shortcut VCC from the router onwards. Router translating into ATM world 
   needs to decide next hop, either a traditional hop-by-hop next hop or a shortcut. 
   The router has the information needed to make an informed decision: it runs 
   a routing protocol to get cost metrics and, based on the application's RSVP signal 
   it can match up the requested QoS (and the price the application is prepared
   to pay for the service) with what is available, based on local information. 
   If that router is also in touch with the ATM-layer "costs" by running PNNI, 
   so much the better. Even better if that router can intelligently map from the 
   L3 costs to ATM costs (ATM Forum is studying a protocol known as "Integrated 
   PNNI" which will do this efficiently. End of commercial).

2. IP-over-ATM host: application passes desired QoS down to IP. IP can either 
 (a) select a traditional hop-by-hop next hop using its conventional routing 
     table.
 (b) defer this decision to the "network" and send off something like an NHRP request
     and let it decide what next hop to use. Host also needs to signal the QoS 
     somehow - either piggyback this in the NHRP request or else generate RSVP signals
     and ensure somehow that the first-hop NHS is also listening to the
     RSVP signals and can match up the two.

 A host could choose which of (a) and (b) to use based on any of the following: 
 (i)   a priori knowledge of whether to shortcut or not, 
 (ii)  use some policy/rule based on the requested QoS (e.g. use NHRP for explicit 
       QoS, use hop-by-hop for best effort).
 (iii) run a routing protocol to keep in touch with the current network state (this 
       degenerates into the router case above).

 Note that case (b) above degenerates into the router case too: the first "Next-
  Hop Server" gets to make the decision as a proxy for the host, based on the signals 
  supplied by the ATM host (convergence in NHRP + resource reservation in RSVP, or 
  else combine the two by adding QoS stuff to NHRP).

> if everybody would always go through the router, the router would be
> very soon swamped and couldn't serve any more flows.  so my rule would
> be "switch always when you can and route if you can't", i.e., that
> shortcut would be the default.

A better first cut approximation might be: "use shortcut VCCs for identifiable flows
and buy a bigger router if you run out, otherwise use hop-by-hop forwarding for 
best effort traffic". If you want this thing to scale at all, you'd better not use 
shortcut as the default. If you make applications generate explicit signals then 
at least you know who to charge for the router upgrade :-) 


BTW, I deleted the RSVP cc: so you should all now only get 2 copies of this :-)
 
> -- juha
> 

Andrew


********************************************************************************
Andrew Smith					TEL:	[phone]
Technology Synergy Unit				FAX:	[phone]
Bay Networks, Inc.				E-m:	[e-mail]
Santa Clara, CA
********************************************************************************