As per Relevance of the word datagram, we have this rfc below:
Network Working Group C.
Request for Comments: 1809 BBN Systems and
Category: Informational June 1995
Using the Flow Label Field in IPv
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The purpose of this memo is to distill various opinions
suggestions of the End-to-End Research Group regarding the
of Flow Labels into a set of suggestions for IPv6. This memo is
information purposes only and is not one of the IPv6 specifications
Distribution of this memo is unlimited
This memo originated as the report of a discussion at an End-to-
Research Group meeting in November 1994. At that meeting the
discussed several issues regarding how to manage flow identifiers
IPv6. A report of the meeting was then circulated to the IPv
community. Feedback from that community resulted in changes to
memo and in changes to the IPv6 specification to fix some
problems the End-to-End Group had raised
While many of the ideas in this memo have found their way into
IPv6 specification, the explanation of why various design
were made have not. This memo is intended to provide some
context for interested parties
Brief Description of the Flow
The current draft of the IPv6 specification states that every IPv
header contains a 24-bit Flow Label. (Originally the
called for a 28-bit Flow ID field, which included the flow label
a 4-bit priority field. The priority field is now distinct,
reasons discussed at the end of this memo).
Partridge Informational [Page 1]
RFC 1809 June 1995
The Flow Label is a pseudo-random number between 1 and FFFFFF (hex
that is unique when combined with the source address. The zero
Label is reserved to say that no Flow Label is being used.
specification requires that a source must not reuse a Flow
value until all state information for the previous use of the
Label has been flushed from all routers in the internet
The specification further requires that all datagrams with the
(non-zero) Flow Label must have the same Destination Address, Hop
by-Hop Options header, Routing Header and Source Address contents
The notion is that by simply looking up the Flow Label in a table
the router can decide how to route and forward the datagram
examining the rest of the header
Flow Label
The IPv6 specification originally left open a number of questions,
which these three were among the most important
1. What should a router do if a datagram with a (non-zero
Flow Label arrives and the router has no state for
Flow Label
2. How does an internet flush old Flow Labels
3. Which datagrams should carry (non-zero) Flow Labels
This memo summarizes the End-to-End Group's attempts to answer
questions
What Does a Router Do With Flow Labels for Which It Has No State
If a datagram with a non-zero Flow Label arrives at a router and
router discovers it has no state information for that Flow Label
what is the correct thing for the router to do
The IPv6 specification allows routers to ignore Flow Labels and
allows for the possibility that IPv6 datagrams may carry flow
information in their options. Unknown Flow Labels may also occur
a router crashes and loses its state. During a recovery period,
router will receive datagrams with Flow Labels it does not know,
this is arguably not an error, but rather a part of the
period. Finally, if the controversial suggestion that each
connection be assigned a separate Flow Label is adopted, it may
necessary to manage Flow Labels using an LRU cache (to avoid
Label cache overflow in routers), in which case an active
infrequently used flow's state may have been intentionally discarded
Partridge Informational [Page 2]
RFC 1809 June 1995
In any case, it is clear that treating this situation as an
and, say dropping the datagram and sending an ICMP message,
inappropriate. Indeed, it seems likely that in most cases,
forwarding the datagram as one would a datagram with a zero
Label would give better service to the flow than dropping
datagram
Of course, there will be situations in which routing the datagram
if its Flow Label were zero will cause the wrong result. An
is a router which has two paths to the datagram's destination,
via a high-bandwidth satellite link and the other via a low-
terrestrial link. A high bandwidth flow obviously should be
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
potential for the flow's traffic to swamp the low-bandwidth link.
seems likely, however, these situations will be exceptions
than the rule. So it seems reasonable to handle these
using options that indicate that if the flow state is absent,
datagram needs special handling. (The options may be Hop-by-Hop
only handled at some routers, depending on the flow's needs).
It would clearly be desirable to have some method for signalling
end systems that the flow state has been lost and needs to
refreshed. One possibility is to add a state-lost bit to the
Label field, however there is sensitivity to eating into the
24-bits of the field. Other possibilities include adding options
the datagram to indicate its Flow Label was unknown or sending
ICMP message back to the flow source
In summary, the view is that the default rule should be that if
router receives a datagram with an unknown Flow Label, it treats
datagram as if the Flow Label is zero. As part of forwarding,
router will examine any hop-by-hop options and learn if the
datagram requires special handling. The options could include
the information that the datagram is to be dropped if the Flow
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
The flow mechanism assumes that state associated with a given
Label is somehow deposited in routers, so they know how to
datagrams that carry the Flow Label. A serious problem is how
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
the source always sends a message deleting a Flow Label when
Partridge Informational [Page 3]
RFC 1809 June 1995
source finishes using a Flow. An internet may have partioned
the flow was created. Or the deletion message may be lost
reaching all routers. Furthermore, the source may crash before
can send out a Flow Label deletion message. The point here is
we cannot expect the source (or, for the same reasons, a third party
always to clear out stale Flow Labels. Rather, routers will have
find some mechanism to flush Flow Labels themselves
The obvious mechanism is to use a timer. Routers should discard
Labels whose state has not been refreshed within some period of time
At the same time, a source that crashes must observe a quiet time
during which it creates no flows, until it knows that all Flow
from its previous life must have expired. (Sources can avoid
time restrictions by keeping information about active Flow Labels
stable storage that survives crashes). This is precisely how
initial sequence numbers are managed and it seems the same
should work well for Flow Labels
Exactly how the Flow Label and its state should be refreshed
some study. There are two obvious options. The source
periodically send out a special refresh message (such as an RSVP
message) to explicitly refresh the Flow Label and its state. Or,
router could treat every datagram that carries the Flow Label as
implicit refresh or sources could send explicit refresh options.
choice is between periodically handling a special update message
doing an extra computation on each datagram (namely noting in
Flow Label's entry that the Flow Label has been refreshed).
Which Datagrams Should Carry (Non-Zero) Flow Labels
Interestingly, this is the problem on which the least progress
been made
There were some points of basic agreement. Small exchanges of
should have a zero Flow Label, because it is not worth creating
flow for a few datagrams. Real-time flows must obviously always
a Flow Label, since flows are a primary reason Flow Labels
created. The issue is what to do with peers sending large amounts
best effort traffic (e.g., TCP connections). Some people want
long-term TCP connections to use Flow Labels, others do not
The argument in favor of using Flow Labels on individual
connections is that even if the source does not request
service, a network provider's routers may be able to recognize
large amount of traffic and use the Flow Label field to establish
special route that gives the TCP connection better service (e.g.,
lower delay or bigger bandwidth). Another argument is to assist
efficient demux at the receiver (i.e., IP and TCP demuxing could
Partridge Informational [Page 4]
RFC 1809 June 1995
done once).
An argument against using Flow Labels in individual TCP
is that it changes how we handling route caches in routers
Currently one can cache a route for a destination host, regardless
how many different sources are sending to that destination host
I.e., if five sources each have two TCP connections sending data to
server, one cache entry containing the route to the server
all ten TCPs' traffic. Putting Flow Labels in each datagram
the cache into a Flow Label cache, in which there is a cache
for every TCP connection. So there's a potential for
explosion. There are ways to alleviate this problem, such
managing the Flow Label cache as an LRU cache, in which
used Flow Labels get discarded (and then recovered later). It is
clear, however, whether this will cause cache thrashing
Observe that there is no easy compromise between these positions
One cannot, for instance, let the application decide whether to use
Flow Label. Those who want different Flow Labels for every
connection assume that they may optimize a route without
application's knowledge. And forcing all applications to use
Labels will force routing vendors to deal with the cache
issue, even if we later discover that we don't want to
individual TCP connections
Note about the Priority
The original IPv6 specification combined the Priority and Flow
fields and allowed flows to redefine the means of different values
the Priority field. During its discussions, the End-to-End
realized this meant that if a router forwarded a datagram with
unknown Flow Label it had to ignore the Priority field, because
priority values might have been redefined. (For instance,
priorities might have been inverted). The IPv6 community
this behavior was undesirable. Indeed, it seems likely that when
Flow Label are unknown, the router will be able to give much
service if it use the Priority field to make a more informed
decision. So the Priority field is now a distinct field,
by the Flow Label
I would like to acknowledge the assistance of the members of
End-To-End Research Group, chaired by Bob Braden, whose
produced this memo. I would also like to particularly thank
Estrin for her help in putting this memo together. Also thanks
Richard Fox, Noel Chiappa, and Tony Li for insightful comments on
draft
Partridge Informational [Page 5]
RFC 1809 June 1995
Security
Security issues are not discussed in this memo
Author's
Craig
BBN Systems and
10 Moulton St
Cambridge, MA 02138
EMail: craig@aland.bbn.
Partridge Informational [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
