RFC 1809 (rfc1809) - Page 3 of 6


Using the Flow Label Field in IPv6



Alternative Format: Original Text Document



RFC 1809                                                       June 1995


   In any case, it is clear that treating this situation as an error
   and, say dropping the datagram and sending an ICMP message, is
   inappropriate.  Indeed, it seems likely that in most cases, simply
   forwarding the datagram as one would a datagram with a zero Flow
   Label would give better service to the flow than dropping the
   datagram.

   Of course, there will be situations in which routing the datagram as
   if its Flow Label were zero will cause the wrong result.  An example
   is a router which has two paths to the datagram's destination, one
   via a high-bandwidth satellite link and the other via a low-bandwidth
   terrestrial link.  A high bandwidth flow obviously should be routed
   via the high-bandwidth link, but if the router loses the flow state,
   the router may route the traffic via the low-bandwidth link, with the
   potential for the flow's traffic to swamp the low-bandwidth link.  It
   seems likely, however, these situations will be exceptions rather
   than the rule.   So it seems reasonable to handle these situations
   using options that indicate that if the flow state is absent, the
   datagram needs special handling.  (The options may be Hop-by-Hop or
   only handled at some routers, depending on the flow's needs).

   It would clearly be desirable to have some method for signalling to
   end systems that the flow state has been lost and needs to be
   refreshed.  One possibility is to add a state-lost bit to the Flow
   Label field, however there is sensitivity to eating into the precious
   24-bits of the field.  Other possibilities include adding options to
   the datagram to indicate its Flow Label was unknown or sending an
   ICMP message back to the flow source.

   In summary, the view is that the default rule should be that if a
   router receives a datagram with an unknown Flow Label, it treats the
   datagram as if the Flow Label is zero.  As part of forwarding, the
   router will examine any hop-by-hop options and learn if the the
   datagram requires special handling.  The options could include simply
   the information that the datagram is to be dropped if the Flow Label
   is unknown or could contain the flow state the router should have.
   There is clearly room here for experimentation with option design.

Flushing Old Flow Labels

   The flow mechanism assumes that state associated with a given Flow
   Label is somehow deposited in routers, so they know how to handle
   datagrams that carry the Flow Label.  A serious problem is how to
   flush Flow Labels that are no longer being used (stale Flow Labels)
   from the routers.

   Stale Flow Labels can happen a number of ways, even if we assume that
   the source always sends a message deleting a Flow Label when the



Partridge                    Informational