Re: int-serv over e.g. ATM

[Mark W Garrett <[e-mail]>]

Well, thanks for all the comments.  Sorry about creating a monster
by posting to all three groups.  (I'm getting 4 copies of all
replies!)

A few notes:

On reference configurations:  someone commented that these things
always break because a real network is never as simple as any of
them.  Of course this is true.  They are only useful as abstractions
to clarify particular items you're trying to discuss.  Or as a
systematic way to ask whether a given solution works in a variety
of situations.  The real network has all of these things and
more complex permutations going on.  Yes, you always design for
the most general case, and none of the drawings is intended to
represent that.

 > This is very elementary stuff that shouldn't have to be said, but your
 > message made me think that it might need saying, much to my surprise.
 > Steve [Deering]

Yes, much of this discussion is definitely Network-Architecture-101
material.  But, you know, if you don't talk about your assumptions
sooner, you'll end up discovering them later.  Especially when we're
into IP over ATM, we have the collision of two worlds of independently
grown assumptions.  The only way to get productive, I think, is to go
through a bit of identifying the obvious.

I understand the model you describe.  It is the pure-Internet model.
I think as we get into the implementation of IP with QOS, though, and
especially as ATM comes up to speed, some of the assumptions and
implications of that model will break down.  For example, one of the
logical conclusions is that ATM is just another subnet du jour.
(Lixia has been advocating this point recently.)  While ATM *can* be
deployed that way, it is also expected to be deployed in ways that
will challenge the subnet model.  Imagine ATM LANs connected to ATM
public networks with ATM over satellite to the All-Europe ATM cloud,
with connections to the proper Internet at multiple points.  As a
subnet, it's not pretty.  Maybe we can ignore this aspect of ATM,
or maybe some small but elegant feature in the routing tables will
make it all work right, but I'm not prepared to call it a non-problem.


On APIs:  Curtis points out that if reference configurations are
construed (or unwittingly taken) to require different abstractions
of QOS etc, we've got real problems.  Agreed.


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

Again, I probably don't have the best vocabulary handy for this, but I
would recommend a distinction between the piece of the "IP layer" that
slaps a header on the data and forwards it through the network, and
the function in the router (or elsewhere) that receives an RSVP
message and translates it appropriately into control messages (i.e.
other than encapsulated user data) for the next subnet.  OK (reading
another message), you're calling this "the subnet interface".  Still,
the name doesn't strongly distinguish between "in the data path" and not.


 > 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

Because RSVP and int-serv syntactically and semantically define what
the source can say about QOS/Traffic, and these notions need to be
translated appropriately.  To build the translation function we have
to understand both sets of syntax/semantics.  You have suggested that
int-serv is independent of rsvp, and that's a nice concept, but
practically, what you say is significantly shaped by the language
you're permitted to use to say it.

Regards,
-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 2L-237			[phone]
Mark W. Garrett		445 South St.			[e-mail]
			Morristown NJ 07960-6438  USA	     (FAX [phone])
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------