Subject: Re: Which service class for a scalable flow ?

From: [email-masked] (Mark W Garrett)
Date: Tue, 2 Jul 1996 14:04:51 -0400

OK, so a couple of adjustments to my answer (Thanx Christian
and Henning).  IPv6 has a priority field (3 or 4 bits, depending
on how you count) that could be used for this purpose, though
some usage conventions among implementors would probably need
to be worked out.  And a receiver who doesn't want a particular
layer would simply not subscribe to the multicast tree (in
addition to not sending a reservation).  Then no unappreciated
traffic would flow.

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 1A-220B			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://ftp.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: "Ping P. Pan" <[email-masked]>
Date: Tue, 02 Jul 1996 18:21:23 -0400

Mark:
> to be worked out.

FYI. In IPv4 header, you can use the TOS byte to map priority 
levels. I think router vendors have been using the byte for other
purposes. A few years ago, in NSFNET, where all routers were from IBM,
we had implemented bi-level priority scheme using the TOS byte. The
higher level carries routing control information, while the lower level for
generic traffic.

> There is no mechanism in rsvp (now) to gang the flows together with (loss)
> priority ordering.  Similarly, there is no way to assure that
> they share a common route.

Back to IntServ-RSVP, I assume your solution means there will be a unique
RSVP session-sender pair for each layer (flow). Each layer will then be 
managed by router traffic controller independently. Since each flow has 
its own Tspec/Rspec, I don't think you need to gang them together.
Secondly, I assume all flows will have the same IP source/destination
addresses. As far as RSVP goes, they should share a common route after 
each PATH refresh.
Right?

-Ping Pan

---

From: Prakash Jayaraman <[email-masked]>
Date: Tue, 2 Jul 1996 18:07:42 -0700 (PDT)

> addition to not sending a reservation).  Then no unappreciated
	***********

	I think a proposal to support layered encoding within RSVP was
given by someone in the last IETF at Montreal. According to the proposal,
the layer information (number of layers and the Tspec parameter for each
layer) will be carried by the Path message. The receivers also make
separate reservations for each layer. In this proposal, there is an
ordering of the layers. If a receiver wants to reserve layer i, then all
layers from 1 to i-1 should have been reserved. Someone else argued that
the ordering may not be appropriate depending on what is carried by the
layer. (if audio is in layer 1 and video in layers 2- 5, and I don't want
audio.. what do I do?)  Things will become clear after the minutes are
out.
	Prakash