Alex,
My point was that even in the case of a router doing both diffserv and
intserv if could tell the flow labels apart by the signaling that was done
for intserv.
As a HW person, could you enlighten me if the flow label look-up for a
packet ("data plane") would need to be different in the intserv and diffserv
cases? My understanding has been that the difference would remain only in
the population of the flow-label tables/data ("control plane").
Jarno
> -----Original Message-----
> From: ext Alex Conta [mailto:[EMAIL PROTECTED]]
> Sent: 24. elokuuta 2001 0:46
> To: Brian E Carpenter
> Cc: Rajahalme Jarno (NRC/Helsinki); [EMAIL PROTECTED]
> Subject: Re: Higher level question about flow label
>
>
> Brian,
>
> You covered the essence, so, I will just expend a little on the use of
> MSB:
>
> The differentiation between Intserv, and Diffserv flow label values is
> helpful when a. and b. bellow are both true:
>
> a. - packet source nodes send both Intserv and Diffserv
> traffic to the
> same router, or set of routers, and
> b. - the router or the set of routers receiving the Intserv and
> Diffserv traffic, do both Intserv and Diffserv classification.
>
> If b. is not true, e.g. the router, or set of routers do Intserv, or
> Diffserv, but not both in the same time, then the
> differentiation is not
> really necessary. Can we be sure that b. is not true.
> I do not think so.
>
> If a. is true, it is sufficient for the source node to pick up flow
> label values from two distinct sets of numbers. The set can be
> interleaved, as long, as the Diffserv values are known the router(s),
> and the Intserv values are signaled to the routers. For instance 1, 2,
> 4, 7 can be Intserv, 3, 5, 6 can be Diffserv. 1, 2, 4, 7 are
> signaled to
> the routers, 3, 5, 6 are known to the routers. Using MSB draws a
> separation line that makes things simple.
>
> Jarno's idea to have just one way of setting the bits in the
> flow label
> has value, if we leave to the source node the problem of making sure
> Intserv and Diffserv values do not overlap, or if we make sure that a
> router would never do both Intserv, and DIffserv
> classification. If the
> values overlap, it is OK, as long as NO router does both Intserv, and
> Diffserv. If a router does
> both Intserv, and Diffserv, and values overlap, then the
> result is quite
> unpredictable.
>
> Regards,
> Alex
>
>
> Brian E Carpenter wrote:
> >
> > I certainly don't care about the pseudo-random requirement
> for unique-per-host
> > opaque flow labels, but if we agree that the flow label may
> be used for diffserv
> > then it has to have semantics (i.e. it is not an opaque
> value). For that I am sure
> > we need the MSB as a flag bit, so that a classifier can
> tell whether it is looking
> > at an opaque value or at a value with semantics.
> >
> > Brian
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > Brian,
> > >
> > > Let's then just say that it would be architecturally
> better to only have one
> > > format that satisfies all the needs. With better I mean
> things like less
> > > text in the specification, simpler implementations, less
> bugs, better
> > > interoperability etc.
> > >
> > > At this point no-one has established that there is a need
> or a requirement
> > > for multiple formats of flow labels. You and Alex have
> brought up a
> > > requirement that the flow label value needs to be somehow
> constant for the
> > > diffserv for a form of MF classification for diffserv
> usage. The traditional
> > > intserv has no requirement to the specific value being
> used, as the value is
> > > being explicitly signaled.
> > >
> > > It seems that both the old ("intserv") and new
> ("diffserv") requirements can
> > > be met with single flow label format (current format with
> no pseudo-random
> > > requirement).
> > >
> > > Earlier it has been thought that the pseudo-random nature
> of the flow label
> > > would make lookups easier by allowing the flow label to
> be used as a hash as
> > > such. There are some specific difficulties with this, however:
> > >
> > > 1) Routers can not know how good pseudo random numbers
> the flow-labels
> > > injected by hosts are in practice. Bad pseudo random
> numbers used by large
> > > class of hosts could constitute a kind of DoS attack
> against router
> > > implementations relying on the pseudo-random number
> nature of the flow
> > > label. [Maybe someone actually implementing look-ups on
> hardware based on
> > > the flow label could bring additional light on this
> matter (Alex?)]
> > >
> > > 2) If there is an alternative format, that is not
> pseudo-random (as being
> > > proposed), the routers will have to implement look-ups
> that function
> > > efficiently with that format. Since we do not know what
> portion of the
> > > traffic in the future would use this non-pseudo-random format, the
> > > implementations have to assume that all traffic can be
> labeled with this
> > > alternative format.
> > >
> > > It follows that there is no additional benefit of the
> pseudo-random nature
> > > of the original format. Therefore it would be best to
> combine these formats
> > > into one, that is non-pseudo-random. I.e. the current
> format with no
> > > pseudo-random requirement. This would present the minimal
> change to the
> > > current specification. Also, current (intserv)
> implementations could keep on
> > > using the current pseudo-random numbers without breaking anything.
> > >
> > > Jarno
> > >
> > > > -----Original Message-----
> > > > From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> > > > Sent: 21. elokuuta 2001 23:31
> > > > To: [EMAIL PROTECTED]
> > > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED];
> > > > [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > > > [EMAIL PROTECTED]
> > > > Subject: Re: Higher level question about flow label
> > > >
> > > >
> > > > Jarno,
> > > >
> > > > The Carpenter/Conta proposal does include two formats for the
> > > > label (one aimed
> > > > at intserv flows and one aimed at diffserv flows), but if you
> > > > use the field
> > > > only for rapid routing lookup, you don't care about that; in
> > > > both cases you can treat
> > > > the label as 20 opaque bits I think.
> > > >
> > > > You only care which format it is when you are doing specific
> > > > intserv or diffserv
> > > > packet classification.
> > > >
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
