Cell Relay Archive

[albert.e.manfredi@boeing.com]

In article <360BA7DC.F5AB62@newbridge.com>,
  Scott Brim <swb@newbridge.com> wrote:
> Stu Card wrote:
> >
> > On Wed, 23 Sep 1998 15:38:21 -0400, Scott Brim <swb@newbridge.com>
> > wrote:
> >
> > >... TOS bit uses, grandfathered into diff-serv...
> >
> > >... Configured rules, in the gateways...
> >
> > Any good references you can give me on these?
>
> For how the TOS bits are honored in diff-serv, check out the diff-serv
> drafts, in particular
> http://www.ietf.org/internet-drafts/draft-ietf-diffserv-header-02.txt
> and http://www.ietf.org/internet-drafts/draft-ietf-diffserv-af-00.txt
>
> As for configured rules, those are vendor-specific.  However, in MPOA
> there's a new contribution attempting to standardize packet
> classification rules, from Barbara Fox at Lucent.  We'll be arguing
> about it at the ATM Forum meeting in two weeks.  (Actually, I've already
> done my arguing and am happy with the result.)  Once we get agreement in
> MPOA we hope to extend it to all "distributed router" situations, i.e.
> where IP services are provided over ATM or other virtualized subnetwork
> and where route computation intelligence is separate from forwarding
> execution.
>
> For developments in signaling requests, check out the RAP working
> group.  Start at http://www.ietf.org/html.charters/rap-charter.html.

Interesting insights, Scott. To get back to Stu's original query, I would give
the following generic replies.

1. IP applications today, virtually all, might have a sort of implied QoS
perhaps, but they have no real, explicit QoS requirements, nor any way to
present these to the network.

2. The idea of using the Type of Service (TOS) byte in the IP header for this
is perhaps not really workable, although that was the original intent of that
field. TOS might be good enough to implement prioritized queues at routers.

3. RSVP part of what ATM's call setup does. RSVP finds a path from
destination (s) to source and reserves router capacity along that path so as
to guarantee a specific QoS until that path is dissolved. (ATM does this from
source to destination instead.) But this means even more extra work on the
part of the IP applications than specifying a TOS field would have meant. And
RSVP does not incorporate the routing problem: how to find a route that meets
the QoS needs, where other routes might not. That is a different topic. And
RSVP also allows tunnelling of RSVP traffic over non-RSVP-enabled routers,
which creates the obvious vulnerability to any specified "guarantees."

4. Finally, RSVP over ATM seems (to me) to be another complicated layered
approach, where two inherently different QoS "guarantee" mechanisms are
layered one on top of the other. One example is that even though ATM virtual
circuits are inherently two-way, with QoS specified for each direction of the
single circuit during the setup process, RSVP over ATM cannot make use of
this ideal feature. RSVP must follow a procedure defined for datagram
networks, using ATM signaling only to set up one-way paths and worrying about
the return path with a different, RSVP process. But as long as ATM is "just
another possible link layer over which to send IP datagrams," it's hard to
come up with anything better (other than using only part of ATM, e.g. MPLS).

Bert
manfredi@arl.bna.boeing.com

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum