Re: int-serv over e.g. ATM

[Craig Partridge <[e-mail]>]

Mark:
    
    I'll hazard a quick and personal answer to your hnote.

>    It seems to me that RSVP is completely analogous to
>    Signalling in ATM and int-serv is analogous to Traffic
>    Management, as networking technology functions,
>    specification documents, and as working groups.  Of course
>    there are significant differences in the style of the
>    technical solutions (e.g. softstate, etc).  Is there any
>    inaccuracy in this mapping (apart from not wanting to be
>    incriminated by association...)?

I think that's basically right.

>    There is another piece which we seem to lack clear
>    vocabulary for.  That is the mechanism which sits at the
>    edge of e.g. the ATM cloud, and transforms the rsvp/int-serv
>    description of traffic and QOS, into something meaningful
>    for the purpose of forwarding packets across the subnet.

INT-SERV (in our charter) calls this "the subnet interface" and the
idea is that the cannonical IP-to-subnet interface would be enhanced
to allow the IP layer to convey QoS information to some subnet module
(in ATM, something like the Q.2931 signalling code supporting 1577
or MPOA) which would make the appropriate arrangements.

    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).

It is on the INT SERV agenda (our charter says we'll do it), but beyond
periodically pointing out that the QoS that IP is likely to hand to
the ATM subnet matches perfectly with the ATM GCRA parameters, I don't
believe much has been done.

    1)	ES - Rtr(s) - ES
    2)	ES - LAN - ES
    3)	ES - LAN - Rtr(s) - LAN - ES
    4)	ES - LAN - Pub-ATM - LAN - ES
    5)	ES - LAN - Pvt-ATM - LAN - ES
    6)	ES - LAN - Pvt-ATM - Rtr(s) - LAN - ES
    7)	ES - LAN - Rtr(s) - Pub-ATM - Rtr(s) - LAN - ES
    8)	ES - Pvt-ATM - Rtr(s) - Pvt-ATM - ES
    9)	ES - Pvt-ATM - Pub-ATM - Pvt-ATM - ES
    10)	ES - Pvt-ATM - ES

My model says that INT SERV's model easily encompasses anything where
there's an IP device (ES or Rtr) on each side of the subnet (so 1,2,3,7,8,9,10).
Scenarios where there may be bridging in the path (namely 4,5,6)
are more troublesome because I don't know what QoS information crosses
the bridge.  If a LAN-ATM concatenation can do QoS, IP should be able to
use it.

Craig