Subject: Re: int-serv over e.g. ATM

From: [email-masked]
Date: Mon, 6 Nov 1995 17:27:08 -0800

Craig,

I think there is a misunderstanding.  This is not the RSVP working
group of IETF pursuing this, but rather people at ISI (e.g. me).  In
any case, there are issues in running RSVP over internetworks with ATM
subnets and we are studying those issues.  We intend to feed back the
results of our work to the relevant IETF Working Groups.

Steve

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 6 Nov 1995 17:31:56 PST

>     The RSVP group at ISI is looking at these issues.  Right now we are
>     concentrating on the second issue ("reference configurations" other
>     than #1).  We will be talking about our status in the IP over ATM
>     working group meeting at the Dallas IETF.
> 
> Steve:
>     
>     Now that's interesting, since I've always thought IP QoS over ATM
> was an INT SERV problem to solve.  Basically RSVP (like any other
> reservation protocol) tells the IP layer what service it wants, and the
> IP layer negotiates with ATM to get the right thing underneath.
> 
>     Why is RSVP directly involved with ATM?  (I'm curious here, not
> trying to pick a turf war -- trying to understand where our architectural
> views differ).

Craig,

Notice that he said the "RSVP group at ISI", not RSVP WG.
I assume it is an ISI internal work.

Lixia

---

From: [email-masked] (Alagu Periyannan)
Date: Mon, 6 Nov 1995 21:18:43 -0800

At 12:18 PM 11/6/95, Mark W Garrett wrote:
>
>Can people comment on what work is going on in any of {RSVP,
>int-serv, rolc, IPATM, MPOA (ATM Forum)} working groups
>toward creating such an API or the QOS-translation
>interface?  (I know of one item, which is rfc1821 by Borden
>Crawley, Davie, and Batsell, which discusses the two types
>of QOS descriptions and lays out some issues for interoperation).
>
>

The ATM Forum recently completed an ATM API document,
"Native ATM Services: Semantic Description", atm95-0008.
This will go for final vote shortly.

The ATM API document lays out the scheme to be used for
call distribution within an ATM endsystem. As far as "QOS" type
parameters go, the API will essentially allow access to all the ATM
signaling parameters. It is up to the API user to use them
appropriately.

In this case it is up to the IP layer to map the RSVP flowspecs
to ATM QOS and traffic parameters.

In addition to the above work, there is currently work in progress in
the X/Open XNET group to map the ATM Forum API to the XTI syntax.
(XTI is the X/Open Transport Interface.) This will enable native ATM
applications using XTI.

Alagu Periyannan                   [email-masked]

Communications Products and Technology
Apple Computer, Inc.

---

From: Walter Milliken <[email-masked]>
Date: Tue, 07 Nov 95 15:39 EST

You may want to look at my paper, presented to the ip-atm group, on
integrated services IP multicast over ATM.  It can be found, at least
for a while yet, in the Internet Drafts repositories as
draft-milliken-ipatm-services-00.txt.  It attempts to use RSVP as a
uniform IP QoS signalling mechanism, and ties that to the setup of ATM
SVCs with appropriate QoS in ATM-based subnets.  It concentrates on IP
multicast traffic, but the basic concepts will work for unicast as well.
Unfortunately, it needs additional work, which I haven't had the time to
pursue at the moment.  But it might be useful as a starting point.

---Walter

---

From: Charlie Tai <[email-masked]>
Date: Wed, 08 Nov 95 17:54:00 PST

Text item: 

     The ATM Forum API semantic description document exposes in essence all 
     the UNI 3.1 signaling information, which includes the traffic 
     descriptor and QOS classes that are supposed to be used to support the 
     RSVP flow spec.  Note that this is only the semantic definition and it 
     is up to the OS vendors to realize this ATM API in their respective 
     OS's. 
     
     In the case of Windows PC environment, version 2 of the WinSock 
     (Windows Sockets) interface was designed from its inception to support 
     QOS-aware applications and transports.  The WinSock 2 spec took into 
     account emerging networking technologies such as RSVP and ATM among 
     others.  The semantic description of WinSock 2 was submitted to the 
     ATM Forum a year ago as a joint contribution from Intel, Microsoft and 
     IBM, and was adopted as the ATM Forum API baseline text.
     
     WinSock 2 incorporates a general QOS structure which could be mapped 
     to RSVP or ATM QOS mechanism by the transport providers.  In addition, 
     the RSVP and ATM specific QOS extensions will enable RSVP and ATM 
     specific applications, respectively.  Detailed information about 
     WinSock 2 is available via WWW (http://www.intel.com/IAL/winsock2) or 
     anonymous ftp (ftp.intel.com:/pub/winsock2/spec).
     
     As for the mapping from RSVP to ATM, it is up to the RSVP layer to do 
     the conversion.  Some issues have been discussed in RFC 1821.

     -- Charlie Tai
        Intel Architecture Labs
        e-mail: [email-masked]
     
______________________________ Forward Header __________________________________
Subject: Re: int-serv over e.g. ATM
Author:  [email-masked] at Internet_Gateway 
Date:    11/6/95 9:18 PM

     

     

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Length: 1276
Subject: Re: int-serv over e.g. ATM
From: [email-masked] (Alagu Periyannan)
To: [email-masked] (Mark W Garrett), [email-masked], [email-masked],
        [email-masked]
Date: Mon, 6 Nov 1995 21:18:43 -0800
pple.com (8.6.12/8.6.10) with SMTP id VAA23817; Mon, 6 Nov 1995 21:18:43 -0800
Received: from taurus.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef)

     id AA29605; Mon, 6 Nov 1995 21:17:57 +0800
     for [email-masked]
Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.
SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef)
     id AA26046; Mon, 6 Nov 95 21:19:21 -0800
     for [email-masked]
:38:46 -0800
Received: from hermes.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0tChgJ-000twWC; Mon, 6 Nov 95 22:38 PST

---

From: Charlie Tai <[email-masked]>
Date: Wed, 08 Nov 95 17:54:00 PST

Text item: 

     

     -- Charlie Tai
        Intel Architecture Labs

     

     

     

Content-Length: 1276

---

From: [email-masked] (Noel Chiappa)
Date: Sat, 11 Nov 95 12:14:32 -0500

From: Curtis Villamizar <[email-masked]>

    On the other hand, SVCs may cost money. ... If you can often use either a
    shared VC to the router (shared with other traffic from the same router) or
    use a VC to that router rather than a direct VC all the way, you might
    still get the QoS you want and reduce your costs when the router is lightly
    loaded, and get the QoS you want when rejected using a direct VC.

This sounds to me like a pricing anomaly, i.e. an artifact of prices that
don't correspond to the actual resources used. Carrying the packets around
should cost the same in terms of resources consumed, no matter how many layers
of mechanism you use to do it. So, I'm not sure how imporant this case is; it
might go away since the market tends to drive prices toward "real" prices.

About the only reason I can think of where it might be genuinely cheaper is if
you have saved the overhead of state/setup required for a separate VC all
through the net. If this is that big a deal, how come ATM isn't trying to
aggregate VC's? But the "do we have to aggregate flows" is a whole separate
can of worms.

	Noel

---

From: [email-masked] (Andrew Smith)
Date: Mon, 13 Nov 95 18:28:02 PST

> Date: Thu, 9 Nov 1995 17:28:19 +0200
> From: Juha Heinanen <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked]

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 From [email-masked]  Mon Nov 13 11:01:37 1995
Date: Mon, 13 Nov 95 19:01:37 PST
From: [email-masked] (Andrew Smith)
To: int-serv, [email-masked], [email-masked]
Subject: Re: int-serv over e.g. ATM

> Date: Sat, 11 Nov 95 12:14:32 -0500
> From: [email-masked] (Noel Chiappa)
> To: [email-masked], [email-masked], [email-masked], [email-masked]
> Cc: [email-masked]

Noel,

> might go away since the market tends to drive prices toward "real" prices.

Unfortunately, reality intervenes in the short term :-( 

> aggregate VC's? 

The state overhead of VCs is considerable and relatively badly understood. The 
state involved for connectionless (best-effort) forwarding in a router is minimal 
and is well understood. The state for QoS-based forwarding in a router is significantly
less than that for VCs. ATM is trying to crawl before it tries running or even 
walking. VC aggregation into VPs will come later.

> But the "do we have to aggregate flows" is a whole separate
> can of worms.

It is not yet clear whether explicit-QoS flows need to be aggregated (the answer
is probably: "yes, but not urgently right now"). It is clear that best-effort flows 
do need to be, just in order to be able to build ATM-based networks as large as 
existing LAN-based ones are are now, let alone allowing for growth.

> 	Noel

Andrew

********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy Unit				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	[email-masked]
Santa Clara, CA
********************************************************************************