Margaret Wasserman wrote: > 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
This is what it specifically can't do if the host is expecting multiple connections to be treated as a bundle! > - 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). It can be argued that a router never *needs* to parse into the packet beyond the addresses. It can also be argued that if the FL is non-zero that the router has absolutely no business parsing into the packet, because the host has identified anything with this label as needing the same treatement by the router. As far as I can tell the document is about as simple as it can be, and trying to become more specific about how the FL gets used will only complicate it once all the possible uses are added. Tony > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
