I think that the problem is that we have different ideas about
what the purpose of this document is.
I, personally, would like to see a document that defines how hosts
should set the flow label, in the absence of knowledge to the
contrary. Something like:
- Start with a random number
- Label each microflow (i.e. one half of a TCP, UDP or
SCTP communication) with a new flow number
- Supply an API for flow label override on a per-microflow
basis
Based on that document, it would be safe for routers to assume
that a non-zero flow-label labels a microflow.
If other WGs want to define signalling mechanisms that run
above IP, those mechanisms can use the aforementioned API to set
the appropriate signalled values. But, anything that wants to do
this would have to be consistent with the fact that some routers
will assume that the src/dest/flow label triplet labels a microflow.
This seems a lot simpler than the current doc, and would allow
routers to make some immediate use of the flow label field to
limit situations where they need to parse into the packet to
find upper-layer ports (parse once, and cache the value based
on src/dst/flow label).
Granted, this might make it harder to use the flow label field for
mechanisms that want to do things other than label microflows, but
it we already have a traffic class field for things that want to
label packets with traffic classes.
Margaret
At 05:05 PM 9/12/02, Brian Haberman wrote:
>Margaret Wasserman wrote:
> >
> > >If
> > >you want to talk DiffServ, IntServ, or something of that flavor, the
> > >flow label would be signaled, the router would recognize it during
> > >packet classification and deal with it how it sees fit.
> >
> > So, all of the routers would have to participate in signalling to
> > know whether the flow label was used for DiffServ, IntServ, etc.?
> >
> > Or, it would just work to use the flow label for load balancing,
> > even it it contained a DiffServ or IntServ value, instead of
> > labeling a microflow?
>
>How DiffServ and IntServ work with the flow label is yet to be
>determined. All I am saying is that the current spec does not
>preclude any of the functions mentioned above. Isn't that the
>point of the draft?
>
>As Matt said, the host knows best what a flow is. Whether that
>flow gets signaled to routers for special handling or not is
>outside the scope of this doc.
>
>Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
