As I just said - I don't believe the flow label is signalled in the
intserv model - but you are on a good point, the classifier at the
input to a router that is running both intserv and diffserv has to
kick the packets into one of three paths (intserv, diffserv, default).
For that choice the flow label should be an opaque value; it would
only be treated as having semantics within the diffserv path.
Brian
[EMAIL PROTECTED] wrote:
>
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
