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.
> > >
S/MIME Cryptographic Signature
