Subject: draft-rajahalme-ipv6-flow-label-00.txt

From: Margaret Wasserman <[email-masked]>
Date: Sun, 16 Dec 2001 20:29:39 -0500

I have a few comments/questions on the general flow label topic.
They are not specific to draft-rajahalame-ipv6-flow-label-00.txt,
but they do apply to this proposal, as well as others.

I've hesitated to raise this issue for fear of being publicly
stoned, but...

It seems to me that an IPv6-specific location within the IPv6
header may not be the right place for a flow label.

I am not an expert in label switching technologies, but the ones
that I do know (VLAN, MPLS) put the label after the link layer
header and before the IP header (conceptually at layer 2-1/2).
This allows the flow label to be located, and used for switching,
without the need to process the layer 3 header at all.  This 
allows the same label switching technology to work in current 
IPv4 and mixed-protocol networks.

Since we may not have large IPv6-only networks for some time, a
flow label within the IPv6 header seems, to me, fundamentally
less useful than a flow label that can be appended before any
layer 3 header (IPv4, IPv6, ??).

Are there reasons for preferring to put a flow label inside the
IPv6 header?  Is this being done on the advice of folks who are
standardizing label switching technologies?

Margaret

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Dec 2001 11:21:53 +0100

> IPv4 and mixed-protocol networks.

Exactly. But that is not the kind of flow label that we have in IPv6.
It isn't used for or intended for MPLS style label-swapping. It's
different.
> layer 3 header (IPv4, IPv6, ??).

But it is a different animal entirely; a separate discussion; not
an IPv6 discussion. And isn't it exactly what MPLS has already
defined?
> standardizing label switching technologies?
No, because it has nothing to do with label switching. It's much 
more to do with QOS than routing. We know how to use the draft-rajahalme-
label for Intserv and Diffserv, but it may well have other QOS
usage as well. It's end2end property is vital for that and completely
different from the swappable MPLS-type label.
 
  Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Dec 2001 09:29:08 -0500

Thanks for the response, Brian.

>different from the swappable MPLS-type label.

But, I still don't understand why an IPv6 QoS/diffserv flow label 
is "completely  different" from an MPLS-type label...

I do understand that MPLS labels are swapped at each intermediate
node, and that IPv6 flow labels will not be.  What are the other
differences?

Will we still use the IPv6 destination address in each packet to 
determine the next-hop router?  Or will routers set-up state 
regarding the next-hop associated with each flow label?  

If the former, then I understand the difference.  An intermediate
router would need to read the IPv6 (or IPv4) header, anyway, in
order to forward the packet.  The IPv6 flow label would just be
some additional information to influence packet queuing or 
processing.

However, if the latter (routers save next-hop state based on flow
labels), wouldn't it be better to develop a mechanism that could
work with both IPv6 and IPv4, so that routers will not have to 
behave differently for IPv6 and IPv4 packets?

If I seem to be missing an important point or concept, please send
some hints or pointers.

Thanks,

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Dec 2001 16:40:17 +0100

> regarding the next-hop associated with each flow label?

The "pure" answer is that only the address will be used, i.e. the
address is necessary & sufficient. But QoS-aware routing can do
whatever it wants; it can look at any non-encrypted field it chooses.
I would expect to see QoS-aware routing using the DSCP which is only
6 bits and defined identically for IPv6 and IPv4, rather than using
the 20 bit flow label. However, if you want a multiprotocol solution to
this, we have one already that does what you describe, and it's
called MPLS.

> some additional information to influence packet queuing or

Exactly; that's the "pure" architecture.
> behave differently for IPv6 and IPv4 packets?

Yes, hence MPLS. The one gap in MPLS is that the "QoS" bits are
technically "experimental" bits - but the diffserv-to-MPLS mapping
makes it pretty clear how to use them for QoS.

> If I seem to be missing an important point or concept, please send

I don't think you are. One intent of draft-rahalme- is to clarify
that the IPv6 flow label is *not* a routing label.

  Brian

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Dec 2001 08:21:26 -0800 (PST)

> If I seem to be missing an important point or concept, please send

Margaret,

I don't think you're alone wondering what all the
fuss is about with the flow label since it's
fairly obvious that normal Intserv classifiers
function equivalently. However, there's two fairly
important things that the flow label brings to the
party:

1) Speed

Speed is primarily due to the fact that the flow's
tag is in the IP header itself at a fixed
location. This simplifies the processing --
helpful for ASIC's -- as well allowing
classification of problematic flows, such
as IPsec and flows which contain destination
options or other things which require that
the header list be traversed.

2) Protocol independence

RSVP normally uses a 5 tuple which implicitly
expect a source and destination port. Other
protocols either disagree (IPsec which requires
classification based on SPI) or are undefined
(SCTP...). Use of the flow label will allow us to
deploy new protocols without having to come up
with new RFC's to describe how to create its own
flow classifier. Better, it will not require
software/hardware upgrades in routers to be able
to give QoS treatment to new IP protocols.

	     Mike

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Dec 2001 10:05:55 -0800

Mike,

You forgot a third:

3) Readable when the packet is encrypted

Thus, QoS can be accomplished even if the
rest of the packet is encrypted.

            jak

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>;
<[email-masked]>
Sent: Monday, December 17, 2001 8:21 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Dec 2001 11:50:12 -0500

Hi All,

I am wondering why we should specify the use of the flow label as
part of the base IPv6 specifications at all.  Why do we need
these rules as part of IPv6?  

The flow label does not, by itself, provide any useful information
that a router can use to classify a flow and/or optimize packet
handling.  In fact, without knowledge of a specific signalling
mechanism or flow-establishment mechanism, the router can't
use the flow label for anything at all.  For example, a router 
cannot use a flow label for QoS queuing or to optimize hop-by-hop 
header processing, unless the router is aware of the signalling/
flow-establishment mechanism in use, since it will not 
know the flow lifetime.

Any rules governing how the flow label is chosen, modified,
authenticated and/or interpreted will be specific to the 
signalling/flow-establishment mechanism in use.  And, all of 
the nodes/routers that are utilizing one of these mechanisms
will be aware of the mechanism.

So why not specify the semantics/use/etc. of the flow label as
part of the signalling/flow establishment protocols?

The IPv6 specifications could merely include the current rule:

"Hosts or routers that do not support the functions of the Flow Label 
field are required to set the field to zero when originating a packet, 
pass the field on unchanged when forwarding a packet, and ignore the 
field when receiving a packet." [from RFC 2460].

This rule should properly protect the flow label, so that
signalling/flow-establishment mechanisms can use the flow
label, as needed by the specific mechanism.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 09:36:16 -0800

> flow-establishment mechanism in use, since it will not

It is valid to say that a flow label can not be used in isolation, but I
believe you are locking it too tightly to current implementations of QoS
handling. If we consider that the flow label could be used as a modifier
to a DSCP, flow lifetime is irrelevant, or more properly 'this packet'.
One conceptual use of a DSCP/FL pair would be to manage congestion on a
DSCP queue either dropping all packets of a single flow or ensuring the
drops are spread across random flows. The choice would depend on the
intended service level of the queue.

> field when receiving a packet." [from RFC 2460].

I think the group is converging on modifing that text to:

Hosts or routers that do not support the functions of the Flow Label
field are required to set the field to zero when originating a packet,
and ignore the field when receiving a packet. All routers are required
to pass the field on unchanged when forwarding a packet.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Dec 2001 13:45:22 -0500

>to a DSCP, flow lifetime is irrelevant, or more properly 'this packet'.

In this case, there would still be a (degenerate) flow-establishment
mechanism in use.  The originating host, and routers in the path, would
need to know that the purpose of the flow label (for this traffic,
anyway) is to modify/augment the DSCP, and they would know that the
flow lifetime was for a single packet only.

In this case, the flow label values should be specified as part
of the DSCP modification/augmentation mechanism.  No special treatment
of the flow label would be required by IPv6 nodes that were not using
that mechanism.

>intended service level of the queue.

There is not way to identify "all packets of a single flow" without
having a set of fields that identify a unique flow (src addr, dest
addr and flow label?) PLUS the concept of a flow lifetime.  
Otherwise, you may end up dropping packets that belong to a later
flow that just happens to share the same flow label.

>to pass the field on unchanged when forwarding a packet.

Why would we want to restrict possible flow-management mechanisms in
this (somewhat arbitrary) way?  I think that the question of whether
the flow label can be modified en route should be left to the 
specific flow-management mechanism.  

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 11:06:02 -0800

> flow that just happens to share the same flow label.

No argument, but why is that a problem? If a router is managing queue
congestion by dropping all packets between src/dst with a specific flow
label, why would it matter that a subsiquent flow was affected? In this
context the lifetime that matters is the period of congestion, and we
really don't want the router maintaining state for any longer than that
if it is not already participating in a signalling scheme.

> specific flow-management mechanism.

Absolutely NOT!!! We already have too many mechanisms that
allow/encourage the value to be modified in route, and this field is the
only one we have left that can have meaning end-to-end. THERE IS NO
REASON TO CREATE ANOTHER ONE! We need to take an architectural stand
here and say that if you want to modify something along the path use the
DSCP or MPLS or VPN or GRE or your favorite random scheme. The
host/application needs a way to inform anyone along the path that may
care, 'this set of packets belong together'. If we allow violation of
that principle simply because the control freaks want to be able to
modify anything and everything, we might as well give up on ever having
applications that expect more than random treatment from the network.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Dec 2001 15:01:43 -0500

At 02:06 PM 12/20/01 , Tony Hain wrote:
>DSCP or MPLS or VPN or GRE or your favorite random scheme. 

Hmmm...  I've apparently hit a nerve here.  But, I still don't
I get it.  What goals would we further by taking "an architectural
stand" on this issue?  What value would this change add to the 
existing standards?

>The

In order for a host/application to _actually_ inform intermediate
routers that a set of packets belong together, we would need to 
define a flow label that achieves that goal.

In my opinion, we have two choices:

         (1) Define these 20-bits of the IPv6 header so that they
                 can be used by any (or many different) flow
                 management system(s).
         (2) Define specific semantics for this field that can be
                 used by intermediate routers to optimize packet
                 processing, without an external flow-management
                 system.

It isn't possible to do both at once.

To achieve (1), we should include only the rules required to keep
non-flow-managed nodes from interfering with mechanisms that use
this field -- those rules are already in RFC 2460.  I don't think
that we should restrict this field any more than is absolutely
necessary.

To achieve (2), we should define how routers will identify a 
_single_ flow using only this field.  In my opinion, this would
involve some mechanism for the routers to understand the flow
lifetime.  This should be defined to be safe across source host
and router re-boots, etc.

I don't understand what we gain by trying to do something
in between.

And, in either case, I don't understand why this would need to 
be specified as part of the core IPv6 specifications.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 12:35:15 -0800

> stand" on this issue?  What value would this change add to the

Locking the value to end-to-end immutable adds value to the process
because there is no other mechanism for an application to assure that
every router along the path that chooses to may see its intent. All the
current mechanisms allow random administrative policies to change the
message from the origin, so why would an application writer bother
setting a value that he has no way of knowing that it will reach the
intended remote target?

> It isn't possible to do both at once.

You are assuming that every router along the path is part of the same
administrative system and would react consistently to the marking. It is
perfectly reasonable for my local administrative domain to have an
interactive system to manage the values, then have some intermediate
domain use a set of canned rules about src/dst/dscp/fl to achieve a
specific service, and finally have a prior administrative arrangement
with the remote domain to treat the packets consistently with the origin
domain. If the intermediate domain is allowed to modify the bits there
is no way for the remote domain to know the origin's intent.

> that we should restrict this field any more than is absolutely

I agree with the last statement, but restricting the field as
architecturally end-to-end immutable IS NECESSARY. If people want to
mangle bits along the path, use the DSCP which is specifically designed
for that purpose.

> and router re-boots, etc.

Again I agree, but the specific mechanism I would leave to a WG focused
on signalling or other interactions that would manage state.

> be specified as part of the core IPv6 specifications.

See first answer above ...

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Dec 2001 16:33:36 -0500

>setting a value that he has no way of knowing that it will reach the

What is wrong with a hop-by-hop option?  Isn't that the "right"
mechanism for an IPv6 host to send a "message" that is processed
by all routers in the path?

>administrative system and would react consistently to the marking. 

No I'm not assuming that all routers in the path will understand
the flow label.  I am assuming, though, that the flow label will
only be _useful_ within an administrative system that has
a consistent (or at least compatible) understanding of its meaning.

>It is

I don't understand how these three systems can usefully interpret 
the same bits in two different ways.  If I am choosing a random 
flow label value at the source (with an "interactive system" that
indicates its meaning out-of-band), why won't I just get random 
behaviour from the intermediate domain in your example?

Could you give a practical example of when this would be useful?

>on signalling or other interactions that would manage state.

Then, why not leave the specification of flow label semantics and
rules to this same WG?

Margaret

---

From: Muhammad Jaseemuddin <[email-masked]>
Date: Thu, 20 Dec 2001 16:37:12 -0500

Margaret:

 I completely agree with you that unless we have a 
signalling/flow-establishment mechanism we cannot really define the 
flow-label usage in a meaninful way. Perhaps we should wait until new 
NSIS sginalling might come-up with some usage and mechanism for this 
bit-space.

- Muhammad Jaseemuddin

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 14:09:58 -0800

> by all routers in the path?

Hop-by-hop options will be slower to process, and the point is that the
origin knows which packets belong together in any specific flow, and
there is no way the routers can deduce that. If the origin specifies
which packets belong together, there is no valid reason for anything
along the path to decide otherwise.

> a consistent (or at least compatible) understanding of its meaning.

I didn't state my argument clearly. I agree that not all routers along
the path may care to pay attention, but as you said your assumption is
that the ones that do are all are part of a single administrative
system. This is not reasonable to assume in the general case, so what I
am arguing is that routers in any independent administrative system in
the path have consistent information to base decisions on. How they
acquire the interpretation is independent of the fact that the bits are
consistent throughout.

> behaviour from the intermediate domain in your example?

You might, but if we allow the intermediate domain to independently
modify the bits there is no hope that the remote domain can get it
right. As I said earlier, it is possible for the intermediate system to
provide a predictable behavior based on the additional knowledge of FL
without explicit knowledge of the semantics, but that might be more
along the lines of drop-probability than EF or the like.

> Then, why not leave the specification of flow label semantics and

Because the participants in those WGs have consistently proven they
don't understand the concept of an architecturally consistent immutable
field which the origin can trust.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 14:17:14 -0800

> NSIS sginalling might come-up with some usage and mechanism for this

But it is the responsibility of this group to restrict their domain of
choices to things that make architectural sense. As I said in the last
note to Margaret, the participants in the QoS WGs have consistently
proven they don't understand the value of an end-to-end constant. If we
don't point out that the DSCP is their mutable field to play with so
leave the FL alone, we will end up with 2 random numbers and application
developers will continue to ignore QoS because they have no means to
express their intent that will be valid at all points in the path.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 12:08:49 +0100

...
> specific flow-management mechanism.

As I said before, this is broken. There is no magic by which all
routers along the path can know which mechanism applies to
which; the only way to construct workable solutions is with
an immutable label. If you want something mutable, use the DSCP.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 12:09:48 +0100

As I said before, this is broken. There is no magic by which all
routers along the path can know which mechanism applies to
which packet; the only way to construct workable solutions is with
      ^^^^^^
an immutable label. If you want something mutable, use the DSCP.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 12:16:05 +0100

Margaret,

The current flow label definition is vague and useless and people
designing line-speed ASICs and network processors can't use it.

If it is defined architecturally as an immutable e2e value, there
are immediate ways to use it in hardware that will work for any
semantics we may later add to it.

If we don't define it properly now, it will simply be 20 dead bits
for ever.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 12:20:28 +0100

Tony is 100% correct in all his comments. I'd add that
hop-by-hop options are not even on the radar screen for
hardware implementation, but for QOS flows we absolutely
need things that hardware can process at line speed.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 12:22:48 +0100

If NSIS came up with something like that, they would be alarmingly
far out of their objectives. That kind of signalling is already
fully defined by intserv and diffserv.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 12:27:08 +0100

Tony Hain wrote:
...
> to pass the field on unchanged when forwarding a packet.

What he said. The last 20 messages or so have strengthened my conviction
that this is what we need (plus draft-rajahalme- updated as a rationale).

   Brian

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 21 Dec 2001 07:30:45 -0600

Beginners may also want to keep up with the current specs for
IPv6 used in infiniBAND. Only the essential elements are used.
http://www.infinibandta.org

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 14:43:39 +0100

In your previous mail you wrote:

   Hosts or routers

=> Nodes ?

   that do not support the functions of the Flow Label
   field are required to set the field to zero when originating a packet,
   and ignore the field when receiving a packet.

   All routers are required
   
=> same objection: the zero value should not be immutable.

Regards

[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Dec 2001 11:15:08 -0500

So, let me get this right...

>field which the origin can trust.

You believe that the IPv6 group should restrict the use of 
the flow label because we can't trust another IETF WG, one
that specializes in flow-management mechanisms, to make 
appropriate architectural decisions?

This is so wrong, on so many counts, that I'm not even sure
how to continue...  

Margaret

---

From: Alex Conta <[email-masked]>
Date: Fri, 21 Dec 2001 12:25:51 -0500

If we had a flow label processing in the network without flow label
setup perhaps I would have agreed with you.

But if we accept that:

 a. the flow label has no semantics
 b. the flow label processing in the Network /depends directly on/is
controlled by/  the flow        setup in the Network devices (forwarding
engines)

then, preserving the meaning given by an application to a flow label
(keeping it as a constant or not) is a function that can be very well
undertaken by "b." (flow setup). That in fact makes the absolute
restriction that you are suggesting UNNECESSARY.  Furthermore, the
restriction has a detrimental effect on the subset of applications that
could take advantage of a changing value. Saying nothing about the flow
label mutability, or leaving it to the flow label processing and setup,
is a more inclusive, and positive architectural approach.

Alex

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Dec 2001 13:18:00 -0500

Hi Brian,

>semantics we may later add to it.

Could you give an example?

 From my understanding of the current draft, the information in the
packet (the flow label, source address and destination address) will
not be sufficient to uniquely identify a single flow.  Without a
knowledge of the flow lifetime (and protection of that lifetime across
reboots, etc.) the same flow label may be used by multiple flows
between a given source/destination pair, without any way for the
routers to detect when one flow ends and another starts.

Basically, a given flow label/source addr/dest addr combination
can only be used to identify a group of flows between the source
and destination.  These flows may not have the same hop-by-hop
options, may not be using the same upper layer protocols, etc.
So, it wouldn't be reasonable for me to cache any information about
the first flow, for fear that it would be used for the second
(potentially very different) flow.

As far as I can tell, this makes it impossible to use the flow label
as current defined (without some out-of-band flow management system
to supply knowledge of flow lifetimes) to identify a single flow.

What am I missing?

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Dec 2001 12:37:56 -0800

> to supply knowledge of flow lifetimes) to identify a single flow.

As I said earlier, you are focused on using the FL in issolation, and
finding that doesn't make sense. In that context you are correct, but
your assumption that all administrative domains in the path need to know
the same context as all others seems to be leading to your confusion. If
an intermediate domain wants to use a static flow management system that
says for the DSCP queue XYZ, when congestion occurs drop all packets
with the same flow until congestion subsides, but for DSCP queue ABC
ensure that drops are spread evenly across all flows, that is as valid
as any signaled system that might be used at the edge. If a source
happens to reuse a FL within the window of congestion in the
intermediate domain, so be it. This is not a particularly likely
scenario since most implementations will use existing randomization
routines to acquire the value for the FL, so why are we still talking
about it?

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Dec 2001 12:40:39 -0800

Alex Conta wrote:
> Furthermore, the
> could take advantage of a changing value.

I am sorry, but those applications should be using the DSCP which is
already mutable. If we allow the FL to be mutable, there will be no
applications that can trust that it will immutable over any random
network. You can't have it both ways.

Tony

---

From: Alex Conta <[email-masked]>
Date: Fri, 21 Dec 2001 16:28:23 -0500

As a general point, I do not think that end-node applications care much
about what happens to flow labels in the network. They rather care of a
certain service from the network. 

If a flow Setup and flow processing for a certain service is defined and
implemented to keep flow labels constant, then it will do that. I do not
understand the trust problem.

Alex

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Dec 2001 17:29:34 -0500

>...so why are we still talking
>about it?

Because I still haven't seen a compelling argument for why
we need additional rules regarding the flow label, beyond
those that are already included in RFC 2460.

You have given one single example (the congestion discard
case), where an ambiguous flow label might have some 
limited usefulness.  [Have you analyzed how this compares
to other congestion management techniques, BTW?]

However, in order to get this limited usefulness, we would
need to place constraints on all possible IPv6 flow management
systems that would use the flow label (specifically, that it
would be e2e, and that the same value would infrequently
be used between the same src/dst pair, such as in the
random case.).

You have not demonstrated (or even tried to argue) why this 
one congestion control technique would warrant placing these
restrictions on all IPv6 flow management mechanisms.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Dec 2001 15:27:43 -0800

Margaret Wasserman wrote:
> limited usefulness.

You asked for an example, and that was the one that came to mind without
any significant study.

> [Have you analyzed how this compares

Not in any detail, I considered it to be a simple example of how one
might augment some of the existing congestion techniques.

> restrictions on all IPv6 flow management mechanisms.

I clearly have not demonstrated it to your satisfaction, but I have
argued that architecturally we need both a mutable and an e2e immutable
field to address different parts of the problem space, and specifically
that the only point with the knowledge to associate packets as a flow is
the origin application/host.

Conversely, those arguing against locking it down have not demonstrated
why the mutability of the DSCP is insufficient for any conceivable
scenario where mutability is required. Specifically what would be the
purpose in having 2 fields that are modified by the routers? Why
wouldn't the existing DSCP be capable of expressing different semantics
through different bit patterns? How does adding a separate 20 bits make
that any different?

If we are simply arguing about who gets to decide, then I believe the
IPv6 WG is the responsible entity for defining the architectural
behavior of the header fields. As such I return to the base issue, at
least one field needs to be end-to-end immutable, and the only one
available is the FL. This of course works well since the origin node is
the only one who could properly define a flow anyway.

Tony

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 21 Dec 2001 18:47:02 -0600

----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 21, 2001 12:18 PM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt

> Could you give an example?

Examples of Architecture ?
http://www.dot-biz.com/RepliGate/VPC/

C@t started in 1982....people "borrowed it" and called it J-something...
....I think we need to let the C@ts loose....

Jim Fleming
http://www.ddj.com/articles/search/search.cgi?q=fleming
Oct93: The C+@ Programming Language

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Dec 2001 18:12:40 -0800

May I offer an updated set of text which focuses on a consistent
use of the term FLOW and tries to issolate it from discussions of
state or the mechanisms to establish that:

>>>-----------------------------------------------------

IPv6 Working Group                                          J. Rajahalme
...

Abstract

   The IPv6 flow label field has been intentionally ambiguous to date.
   This document will define it to allow eliminating
   protocol layer violations and the related problems from flow specific
   packet classifiers.

   The appendix of this document provides an analysis of the current
   state of the IPv6 flow label field definition.

   This document proposes new text to be included in the next revision
   of the IPv6 specification specifically to define the field.

   This document will not specify state establishment mechanisms which
   might be associated with a flow.

...

   Introduction

   Overview

   At the time when the IPv6 specification [RFC2460] was written, the
   requirements for flow label field usage were unclear.

   The last several years of work in IETF provide new perspective and
   framework for the standardization of the IPv6 flow label. Also, the
   new charter of the IPv6 Working Group invites contributions to flow
   label standardization.

   A detailed problem statement is provided in section 1.2, and the
   goals for the flow label definition in 1.3. Section 2 provides an
   analysis of the current definition of the IPv6 flow label [RFC2460,
   RFC1809, RFC2205]. Section 3 details the new definition with its
   implications, with proposed text to be included in the next revision
   of the IPv6 specification. Finally, section 4 provides some useful
   background information on the topic.

   Terminology

   Flow                   A collection or sequence of packets which the
                          origin application or host has declared to be
                          associated. This declaration is intended to
                          establish equal treatment of the set, but
                          the mechanism for deciding what that treatment
                          might be is outside the scope of this
document.

   Classifier             An entity which selects packets based on the
                          content of packet headers according to defined
                          rules.

   Control plane          Part of the router taking care of router
                          control functions, such as routing protocols
                          and flow set-up signaling protocols. Controls
                          the functions of the forwarding plane.

   Forwarding plane       Part of the router receiving and forwarding
                          user packets; also known as "fast path".

   Multi-Field (MF)       A classifier which selects packets based on
   Classifier             the content of some arbitrary number of header
                          fields.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   Problem Statement

   The IPv6 flow label field is designed to enable efficient
   classification of packets that should receive consistent treatment.

   Current IPv4 attempts to accomplish this without the flow label are
   based on snooping the transport header information (port numbers).
   Snooping in the transport header is problematic due to several
factors:
   - The transport header may be unavailable because of either
fragmentation,
   or IPsec encryption.
   - Usage of IPv6 extension headers make finding the transport header
   expensive, even if it is available.
   - Finally, reliance on the transport header information is a layer
   violation and hinders introduction of new transport layer protocols
   (e.g. SCTP).

   Requirements

   The IPv6 protocol specification MUST state architectural rules, if
   any, governing the use of the flow label field by any flow state
   establishment method, and SHOULD enable co-existence of different
flow
   state establishment methods in IPv6 hosts and routers.

   The space of possible flow state establishment methods SHOULD NOT be
   restricted to signaling protocols. For example, the IPv6
   protocol specification should allow for future definition of
   administratively provisioned flow handling.

   The models for the use of the flow label and their specific state
   establishment methods should enable eliminating the layer violations
   in flow specific packet classifiers, thus facilitating evolution of
   the higher protocol layers independent of the specific flow state
   establishment method.

   Changes to the current specification SHOULD be kept minimal, and
   backwards compatibility MUST be maintained.

   Discussion

   For the purpose of this document the rules from the Appendix A of
   [RFC2460] are rearranged as follows:

   (a) A flow is uniquely identified by the combination of a source
       address and a non-zero flow label.

   (b) Packets that do not belong to a flow carry a flow label of zero.

   (c) A flow label is assigned to a flow by the flow's source node.

   (d) New flow labels must be chosen (pseudo-)randomly and uniformly
       from the range 1 to FFFFF hex. The purpose of the random
       allocation is to make any set of bits within the Flow Label field
       suitable for use as a hash key by routers, for looking up the
       state associated with the flow.

   (e) All packets belonging to the same flow must be sent with the same
       source address, destination address, and flow label.

   (f) If packets of a flow include a Hop-by-Hop Options header, then
       they all must be originated with the same Hop-by-Hop Options
       header contents (excluding the Next Header field of the Hop-by-
       Hop Options header).
*** I left this in, but I think it needs to go because this would appear
to preclude an in-line signaling protocol which wanted to
establish/refresh state without requiring every packet in the flow to be
hop-by-hop.

   (g) If packets of a flow include a Routing header, then they all must
       be originated with the same contents in all extension headers up
       to and including the Routing header (excluding the Next Header
       field in the Routing header).

   (h) The routers or destinations are permitted, but not required, to
       verify that these conditions are satisfied. If a violation is
       detected, it should be reported to the source by an ICMP
       Parameter Problem message, Code 0, pointing to the high-order
       octet of the Flow Label field (i.e., offset 1 within the IPv6
       packet).

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
   (i) The maximum lifetime of any flow-handling state established along
       a flow's path must be specified as part of the description of the
       state-establishment mechanism, e.g., the resource reservation
       protocol or the flow-setup hop-by-hop option.

This has to go... we are defining the field here, not a state
establishment mechansim.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-

   (j) A source SHOULD NOT reuse a flow label for a new flow within the
       maximum lifetime of any flow-handling state that might have been
       established for the prior use of that flow label. When a node
       stops and restarts (e.g., as a result of a "crash"), it must be
       careful not to use a flow label that it might have used for an
       earlier flow whose lifetime may not have expired yet.
*** Again, we are defining the lable here, not state establishment
policy. I don't have a problem changing the text to SHOULD NOT, but the
open question is why is reuse of a flow label a problem?

   Applicability of the RFC 2460 Flow Label Definition

   As stated in [RFC2460], the motivation for the Flow Label field is to
   request special handling for the packets belonging to a flow. The
   flow label value itself has no globally recognized semantics,
   but it can be used by
   routers to determine the appertaining of a packet to a certain flow
   (classification), and to find the state containing the definition for
   the "special handling" admitted for that flow. The exact nature of
   the "special handling" is defined through means other than the flow
   label itself.

   At the time of the definition of the rules in [RFC2460] the major
   method for defining the "special handling" by routers was the
   resource reservation signaling protocol (RSVP) of the "Integrated
   Services" architecture [RFC1633, RFC2205]. With the hindsight it
   seems that some of the flow label rules set in [RFC2460] Appendix A
   are quite specific to the Integrated Services model, and block the
   way forward for definition of other flow state establishment methods.

   Some specific points are raised in the following subsections.

   Lacking Support for RSVP WF Reservation Style

   The Wildcard-Filter (WF) reservation style allows the RSVP session
   destination to reserve resources for transmission by any of the
   senders of the RSVP session. All the state that can be utilized for
   packet classification with the WF-style session is in the RSVP
   Session object, since the WF-style reservations have no Filter Specs
   [RFC2205].

   Currently, for end-to-end flows, the Session object can only be
   specified in the terms of the destination address, transport protocol
   identifier (Id), and the destination port number. This results in
   layer violation in packet classification with all the identified
   problems (inefficiency, fragmentation, IPsec) in spite of using the
   flow label Filter Specs.

   For WF-style sessions this situation could be remedied with a new
   type (or "C-Type") of a Session object, where only the destination
   IPv6 address and the flow label are specified (quite much like the
   Session object defined in [RFC3175] for aggregated flows). For other
   flow styles it might be more appropriate to have the session object
   to specify the destination address only, and have each Filter Spec to
   contain the source's flow label.

   The problem with the current flow label rules is that if the flow
   label is set according to information received from the destination
   (e.g. through the Session Announcement Protocol (SAP)), it becomes
   possible that the same flow label value should be used for two
   different flows from the same source simultaneously. This can happen
   if the source is taking part to two different sessions with different
   destinations, and the flow label number generators in the
   destinations happen to pick up the same number. This is in direct
   contrast with the rule (a) above.

   Requesting the destination to pick another flow label would be
   infeasible, if the RSVP sessions already have other senders.

   New Flow Label Specification

   The section proposes new text to be included in the IPv6
   Specification. The section 3.1 is intended to provide a new version
   of the text in [RFC2460] section 6. The text in sections 3.2 and 3.3
   could go to different parts of the IPv6 specification.

   Proposed Flow Label Text for IPv6 Specification

   The 20-bit Flow Label field in the IPv6 header MAY be used by a
   source to label sequences of packets for which it requests special
   handling. A non-zero flow label indicates that the IPv6 packet is
   labeled. IPv6 nodes receiving a labeled IPv6 packet can use the
   Source Address, Flow Label, Destination Address triplet to classify
   the packet. A flow may be given some specific treatment
   based on the state established on a set of IPv6 routers. The
   nature of the specific treatment and the methods for the state
   establishment are out of scope for this specification.

   The host MUST keep track of the Flow Label values in use to avoid
   trying to establish conflicting state. The Flow Label value,
   when set, is end-to-end immutable.

   Hosts or routers that do not support the functions of the Flow Label
   field MUST set the field to zero when originating a packet, and
ignore
   the field when receiving a packet. Routers MUST pass the field on
   unchanged when forwarding a packet.

   Requirements for State Establishment Methods

   The following MUST be considered by all state establishment
   methods:

   (1)  A flow is uniquely identified by the combination of the source
        address, non-zero flow label, and the destination address.

   (2)  All state MUST be created with a state establishment
        method. All such methods are out of scope for this
        specification.

   (3)  Flow state with the flow label value zero SHALL NOT be created.
*** this seems like a bogus point. If someone wants to create a state
for the zero label there is no reason to preclude that.

   (4)  Host implementations SHOULD keep track of the flow label values
        used by any state establishment methods and avoid reuse for a
given
        destination.

   (5)  A flow label value is end-to-end immutable.

   (6)  The maximum lifetime of any established state must be
        specified as part of the state establishment method.
*** We are defining the lable here, not state establishment policy.

   (7)  A source MAY reuse a flow label value any time, unless otherwise
        specified by the state establishment method for the new
        flow.

   (8)  All state establishment methods MUST allow for the case
        where a router determines the offered flow to be in conflict
        with state created with an other state establishment
        method. If a conflict is detected, it SHOULD be reported by the
        state establishment method.
*** Again, we are defining the label here, not state establishment
policy.

   Implications of the New Definition

   - The same flow label value can be used for different flows with the
     same source addresses, provided that the destination addresses are
     different (1).

   - Each (source address, flow label, destination address) triplet can
     uniquely determine a flow which may be used to identify the
relevant
     state, if any (1).

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
     However, multiple different triplets MAY determine the same flow,
     and refer to the same flow state, depending on how the flow was
     defined with the flow state establishment method.

This is an example of the confused definition for flow in this document.
A flow is an end-to-end association of packets between a src/dst pair.
There is no way multiple triplets could define the same flow. The intent
here is obvoiusly to allow multiple flows to share some established
state, but that does not mean we are redefining the context of a flow.
This text has to go.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-

   - The only requirement for a flow label value used for the flow is
     that it MUST be non-zero (3). However, specific state
     establishment methods MAY expect (non-zero) pseudo-random numbers
as
     flow label values.

   - A non-zero flow label value is guaranteed to be received by the
     destination. If the source sends the packet with a zero flow label
     value, a router in the network MAY set the flow label value to a
     non-zero value (5).

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
   - A non-zero flow label value MAY be changed in transit by a router,
     but the original value MUST be restored before the packet leaves
     the domain of the flow state establishment method defining such a
     temporary change (5).

This text is unnecessary and needs to be removed.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-

   - state lifetime may also be indefinite, if so specified by a
     state establishment method. The method MUST also provide the
     means to guarantee no dangling state (6).
**** This is defining state policy, not the flow label characteristics.
Remove the last sentence at least, and the first makes no sense in
isolation.

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
   - If new flow state is signaled through a certain path, the routers
     can flush any old state they might have, and install the new flow
     state (7).
***  This is bogus ... if separate apps on the same src/dst pair are
establishing flows, one MUST NOT be able to affect the other. Remove
this.

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-

   - Some host implementations of state establishment methods might
     be impractical or impossible to synchronize in a host environment
     (e.g., the host OS may implement one method in the kernel with no
     interface to user space, where another state establishment method
     is residing). Therefore the routers MUST be able to return an error
     as part of the state establishment response, if the offered flow is
     deemed conflicting with a state created by another state
     establishment method. Local policy at the router MAY set a
     precedence between the state establishment methods, and MAY be able
     to cancel a lower precedence flow in favor of the new flow (8).

Again, this is defining state establishment policy, not the label. In
addition, if it is intended as a modifier to the previous bogus point,
it needs to go as well.

This is as good a place as any to note that all references to
establishing state have the word flow removed, and in several places the
individual use of the term flow has been replaced by the term state
because that is the correct context.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
   Conceptual Models Relating to the Flow Label

   About Packet Classification

   This section briefly summarizes issues relating to packet
   classification relating to the use of the flow label.

   Packet classification happens in a context of an agreement
   ("contract") between a "customer" and a "provider". The only fields
   in the IP packet header that the provider can utilize in mapping a
   packet to a specific customer's contract are the source and
   destination address fields. We call this "customer classification".
   Other information, such as incoming link, can also be used to map
   packets to the customer's contract.

   In the context of the contract governing the packet, the packet can
   be further classified to a flow. The packet filter rules for the flow
   classifiers in the network are part of the flow state. The flow state
   also specifies what kind of "special handling" the packets of the
   flow should get, and what are the flow traffic parameters (e.g.
   bandwidth, delay, etc.) and contains the flow usage counters.

   It should be noted that the actual values of the header fields
   specified in a flow classifier are immaterial to the network operator
   - the operator assigns no specific semantics to any of the fields.

   Actual implementations will likely combine the "customer
   classification" and flow classification into one filter rule, but the
   conceptual separation between the two is essential.

   Usage of the IPv6 flow label greatly simplifies the filter rules, as
   the classification can be done on the basis of the IP addresses and
   the flow label alone.

   A packet classified to a flow can be further mapped to a Behavior
   Aggregate (BA), enabling other routers in the network bypass flow
   classification. The Differentiated Services Code Point (DSCP) field
   is used to identify the selected BA [RFC2475].

The paragraphs in this section appear to be statements of fact that have
no value in defining the FL field. Either this is introductory material
about why we would even define the field, or it is irrelevant and needs
to go.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-

   Host Considerations for the Flow Label

   Choosing Flow Label Values

   A specific flow state establishment method MAY set requirements on
   the flow label values to be used. In any case, the host
   implementation SHOULD keep track of the actual flow label values
   being used between a local source address and any destination
   addresses. The same facility keeping track of the flow label values
   SHOULD be utilized to check whether the  flow label value chosen by
   the flow state establishment method is currently in use or not
   between the given source and destination address pair, and SHOULD
   also return a flow label value assigned by host implementation
   specific algorithm, if the flow state establishment method did not
   specify any specific value.

   End-to-End Negotiation

   Flow label values for flows SHOULD be included as part of any end-to-
   end signaling dealing with the flow, e.g. RSVP for resource
   reservation, or SIP/SDP for end-to-end session establishment.

   RSVP usage is analogous to the familiar MF classifier, but now the
   flow label replaces the need to specify the transport protocol and
   port numbers for the flow classifier.

   In the case of SIP either the source or the destination could have a
   preference for the flow label value to be used. For example, the
   destination could have an agreement with its access provider
   effecting flow state for "special handling" for all packets marked
   with a certain flow label value towards the destination. Therefore
   the source SHOULD honor the destination's request to mark the packets
   with the flow label value specified.

   Relation to the Other Packet Header Fields

   A flow is uniquely identified by the (source address, flow label,
   destination address) triplet. Any possible constraints for the rest
   of the IPv6 header fields or extension headers are to be specified by
   the flow state establishment method defining the flow semantics.

   Flow state establishment methods SHOULD include the Mobile IP Home
   Addresses of the source and the destination in the state
   establishment process, if available. This enables avoiding state
   duplication on fixed portions of the path when either end changes its
   Care-of Address.

   Router Considerations for the Flow Label

   Flow Label is End-to-End Immutable

   Routers MUST NOT change the end-to-end flow label value. The
   flow state establishment method SHOULD be able to tell the
destination
   which value to expect on the received packets.

   Flow Label Values Have No Globally Known Properties

   The router MUST NOT assume any specific property on the flow label
   values assigned by hosts. Router performance SHOULD NOT be dependent
   on the overall distribution of the flow label values of the
   established flows.

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
State mechanisms are not being defined here.

   Conceptual Model for Flow State

   This section lays out a simple conceptual model for minimal flow
   state in the router forwarding plane. Actual implementations may
   choose any implementation methods they like.

   Router forwarding plane needs to maintain at least the following
   information (flow state) for each defined flow:

     Source Address,    The triplet identifying the flow.
     Flow Label,
     Destination
     Address

     Flow Accounting    Counter of the number of bytes or packets of
     Information        the flow data forwarded. The router control
                         plane can see from this if the flow has been
                         active (since it was last checked), and how
                         much data has been forwarded (useful for
                         accounting purposes).

     Forwarding         Defines the actual "special handling" the flow
     Treatment          packets are subjected to.

   The flow state is created by the router control plane via a flow
   state establishment method. The flow state establishment method
   definitions are out of scope for this specification.

   Stale flow state is deleted by the router control plane after the
   flow expires, or when a new flow state overriding the old is created.
   The flow state can also be explicitly deleted via the flow state
   establishment method.

   Classification

   Packet classification is done by the router forwarding plane on the
   flat 20-bit flow label, and the source and destination address
   fields.

   When matching flow state has been found, the router will be able to
   update the Flow Accounting Information and forward the packet with
   the "special handling" as specified by the Forwarding Treatment in
   the flow state.

   If flow state can not be located for a packet it is forwarded as if
   the flow label was zero, but the flow label is left intact. No flow
   state is maintained for unknown flows.

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-

**** This text was moved from the begining, and should become an
appendix to explain why this document is doing something different.
There is no need for a laborious analysis of history as part of the base
definition for the FL field. At this point there is enough hacking on
the text that further effort needs to be done in context of a rewritten
draft.

   Current non-normative text in the Appendix A of [RFC2460] seems to be
   specific to the Integrated Services service model, unnecessarily
   restricting future work on defining new state establishment methods,
   but at the same time falls short in enabling flow label based
   classification of RSVP defined end-to-end flows in all cases.

   The current normative specification of the flow label field in
   [RFC2460] is providing inadequate guidance for different flow state
   establishment methods to be defined.

   See section 2.2 for more detailed analysis of the problems with
   Appendix A definition.

2.  Analysis of the RFC 2460 Flow Label Specification

2.1  RFC 2460 Definition of the Flow Label

   The IPv6 Flow Label is defined in [RFC2460] as a 20 bit field in the
   IPv6 header which may be used by a source to label sequences of
   packets for which it requests special handling by the IPv6 routers,
   such as non-default quality of service or "real-time" service.

   The Flow Label aspect of IPv6 is stated to be "still experimental and
   subject to change". The only rule set for the flow label in the main
   body of the [RFC2460] is that if the Flow Label field use is not
   supported, it is set to zero when originating the packet, passed on
   unchanged when forwarding the packet, and ignored when receiving the
   packet.

2.1.1  Appendix A - Semantics and Usage of the Flow Label Field

   The characteristics of IPv6 flows and flow labels, and the rules that
   govern the flow label functions are further defined in [RFC2460]
   Appendix A (non-normative text).

   Background information on the documented semantics can be found in
   [RFC1809].

   According to [RFC2460], the nature of the special handling might be
   conveyed to the routers by a control protocol, such as a resource
   reservation protocol, or by information within the flow's packets
   themselves, e.g., in a hop-by-hop option.

   Too Restricted Flow Classifier

   The rule (a) states that a flow is uniquely identified by the source
   address and the flow label. Rule (e) states that all the packets in
   the flow must also have the same destination address.

   This means that the source may not use the same flow label value for
   flows to two different destination addresses. As stated above, this
   is in violation with RSVP model, but also is unnecessarily hindering
   introduction of other flow state establishment methods.

2.2.3  RSVP/Integrated Services Specific Rules

   The rules (f) and (g) state that any hop-by-hop or routing headers
   must be the same for all packets in a flow. This matches the Intserv
   practice of nailing down the path for the flow. The intent has
   probably been to enable the router to by-pass next-hop look-up and to
   supply pre-processed routing header contents for the packets in the
   flow.

   These rules are clearly specific to the RSVP flow state establishment
   method, and should not be required of flows in general. The RSVP flow
   state establishment method would still mandate these rules for
   Integrated Services flows. The forwarding path of a IntServ capable
   router would also be able to enforce these rules for IntServ flows.

2.2.4  Too Restricting Rule for Flow Label Value Re-use

   The rule (j) defines guard periods on re-use of flow label values.
   This is too restrictive even in the case of Intserv flows. There
   would be no harm in a (rebooted) node reusing a flow label value, as
   the RSVP signaling would enable the routers to flush any old state
   for the same flow classifier.

2.2.5  Unnecessary Rule for Flow Label Value Selection

   Finally, it has been concluded that routers can't actually rely on
   the random distribution of the flow label values as required by the
   rule (d). In practice routers MUST be able to utilize algorithms that
   do not depend on the statistical distribution of the flow label
   values. Therefore, the rule (d) SHOULD be relaxed for flow labels in
   general. However, specific flow state establishment methods MAY still
   use pseudo-random numbers as flow label values.

Appendix A:  Why no Flow Label Format?

   The choice to not introduce any internal format for the flow label
   represents the "minimal modification" policy and is intended to ease
   the process of the acceptance of this specification by the IPv6
   community.

   This is also in line with the removal of any "flags" from the IPv6
   main header design, and the recent deprecation of the term "format
   prefix" in conjunction of IPv6 addresses.

   In the same way as next-hop lookup should function independent of any
   "format prefixes" or administrative boundaries in the IPv6 addresses,
   the flow label lookup should remain independent of any possible
   internal structure for the flow label values themselves.

   Abstaining from eating in to the 20 bits of the flow label also keeps
   maximal possibilities open for future refinement of this
   specification.

Appendix B:  Why no Pseudo-Random Values?

   [RFC2460] motivates the requirement for pseudo random flow label
   field with easing the hash key computation in routers doing flow
   classification. Hashing has to deal with the problem of large hash
   buckets due to unbalanced hash key distribution. If the router trusts
   on the hosts to generate good hash keys, it places itself on the
   mercy of the hosts. A not-so-good generator in any widely used host
   platform may become problematic for the router.

   In recent years the hardware implementations of the classifiers have
   advanced, and schemes like search trees and Content Addressable
   Memory (CAM) are widely used for classification. It is the authors'
   view that the flow label specification SHOULD NOT favor any
   individual classification implementation strategy, especially when it
   provides no functional value for the purpose of the flow label
   itself, and seems to hinder future use of the flow label for non-
   signaled flow state establishment methods.

   Hash implementations in routers can compute a hash key over the
   (source address, flow label, destination address) triplet.

References

...

---

From: Richard Carlson <[email-masked]>
Date: Sun, 23 Dec 2001 10:16:02 -0600

I concur.  The flow label should be set by the source host and remain 
immutable as it travels over the network.

Rich

> > field which the origin can trust.

------------------------------------

Richard A. Carlson				e-mail: [email-masked]
Network Research Section			phone:  (630) 252-7289
Argonne National Laboratory			fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 24 Dec 2001 09:26:54 -0600

----- Original Message ----- 
From: "Richard Carlson" <[email-masked]>

> immutable as it travels over the network.

Just like the TOS field in IPv4 ?

Jim Fleming
http://www.IPv8.info

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Dec 2001 10:32:41 -0500

> immutable as it travels over the network.

great!  now if we'd only make the same declaration for the source 
and destination address...

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 24 Dec 2001 10:02:54 -0600

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Richard Carlson" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; "Tony Hain" <[email-masked]>; "Margaret Wasserman" <[email-masked]>;
<[email-masked]>
Sent: Monday, December 24, 2001 9:32 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt

> and destination address...

It does not matter because the entire header gets absorbed
at the first GateKeeper....[IPv4][IPv6] ---> [IPv4][IPv8]
...the IPv6 Header is just an extension to IPv4....and it has
mostly redundant information....it is very inefficient....networks
do not work well filled with extra bits that have no meaning...

Jim Fleming
http://www.IPv8.info

---

From: "Subrata Goswami" <[email-masked]>
Date: Mon, 24 Dec 2001 09:12:21 -0800

Just a thought. Is it not be possible to launch a DoS attack by
flooding a flow ? In such a situation how would intermediate
routers behave if flow bits mutable ver immutable vs local vs global ?

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Richard Carlson
Sent: Sunday, December 23, 2001 8:16 AM
To: Brian E Carpenter; Tony Hain
Cc: Margaret Wasserman; [email-masked]
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt

Rich

---

From: "Perry E. Metzger" <[email-masked]>
Date: 24 Dec 2001 12:26:19 -0500

Am I correct in saying that, at this point, the flow label is at most
a way for intermediate routers to avoid layer violations, since a flow
is immutable and is properly given as a <srcaddr,dstaddr,flownum> tuple?

One must ask what kind of layer violations this is intended to
stop, and what the purpose of those layer violations is. Generally
speaking, routers only reach in to the lower layers to determine how
to differentiate traffic between two hosts for purposes of
prioritization.

If it is intended to stop routers looking at the different layers to
prioritize traffic, it is a failure, since the flow label tells an
intermediate router nothing it needs to know to prioritize traffic
other than "this is flow #N". You can't decided "hmm, interactive
traffic -- better bump that above bulk file transfer" based on the
flow label. At best, you can use the flow label for doing something
like penalizing flows with non-friendly flow control
characteristics.

Is that the entire goal? To label flows so that they can be penalized?
Is there any other possible use of the field as defined by the proposal?

If that's all we're gaining here, seems like a lot of mechanism for a
pretty small effect -- especially since at this point, there is no
chance of getting the overwhelming bulk of the world's v6 hosts to
insert such a label for many years -- XP and friends have already
shipped -- so your ASICs still need to know how to unwrap the TCP/UDP
headers anyway.

Perry
--
Perry E. Metzger		[email-masked]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Dec 2001 15:27:12 -0800 (PST)

> is immutable and is properly given as a <srcaddr,dstaddr,flownum> tuple?
 
   Yes.

 > to differentiate traffic between two hosts for purposes of

   UDP ports in ESP encrypted payloads. Tunnels inside
   tunnels inside tunnels inside tunnels. New protocols
   which may not even have abstracted ports. New Protocols
   period. TCAM widths that lose to Moore's Law.

   Need I go on?
 
 > like penalizing flows with non-friendly flow control

   RSVP is your friend.

	   Mike

---

From: "Perry E. Metzger" <[email-masked]>
Date: 24 Dec 2001 18:48:50 -0500

>    period. TCAM widths that lose to Moore's Law.

Yes, you need to go on. For the most part, I'm not sure this is going
work out. As I note, we've already deployed. Windows XP and such
aren't going to be obeying any of this, so the routers have to look at
the contents of the packets anyway. For many of the protocols we're
dealing with here (such as tunnels inside tunnels) it isn't clear
there is a clean way for the mechanisms to actually extract an
appropriate flow label under the new definition, and, most
importantly, as I noted earlier, you can't figure out how to
prioritize traffic using the flow label anyway.

>  > like penalizing flows with non-friendly flow control

The century that RSVP is implemented and deployed I'm sure it will be
used, at least once in a while. (I don't expect our descendants to see
that day, but...)

Meanwhile, in practice what people tend to do on things like congested
leaf routers is prioritize based on traffic type.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Dec 2001 16:10:44 -0800 (PST)

If you don't believe in signaled QoS, you don't
believe in any use of a flow label qua flow label.
Fine; many people don't. For those people, you
have the DSCP and the luck of the draw. It's
infinitely mutable, etc, etc. Be happy because
there's nothing to be done here.

And XP can make flow labels along with DSCP's as
soon as the current or next gen worm is done
rewriting their kernels.

		Mike

---

From: "Perry E. Metzger" <[email-masked]>
Date: 24 Dec 2001 19:27:29 -0500

> believe in any use of a flow label qua flow label.

I thought we had a "traffic class" to permit "signaled QoS" for some
value of "signaled QoS". I was unaware flow labels were intended for
this purpose.

> soon as the current or next gen worm is done

I'm an old fashioned kind of engineer. I'd like to see some folks from
router vendors give us precise information about the *exact* use
they'll put the flow label information to, and quantitative
information about how much better it will be for them to have the flow
label than not to have it. Engineering by committee is bad enough --
engineering by committee and by hearsay simultaneously is far worse.

Perry

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Dec 2001 16:53:46 -0800 (PST)

> value of "signaled QoS". I was unaware flow labels were intended for

   DSCP's aren't guaranteed to be end to end.
 
 > engineering by committee and by hearsay simultaneously is far worse.

   If we want to future proof some of the bits,
   we can reserve 2 or 4 bits and make 0 be
   this definition. This is *hardly* a new and
   unexpected semantics fo the flow label. Indeed,
   it's seems to be all of the hangwringing over
   the obvious definition for these bits that
   has managed to shoot IPv6 in the foot, re
   fast flow clasification.

   But I'm not sure what you're asking for.
   Do you really have any doubt that forming
   the flow key from fixed postions in the
   IP6 header is going to not kick butt on 
   chasing down header chains with a half
   dozen different rules dependent on protocol
   value to hopefully find a 5 tuple? Yeah,
   yeah, some (edge) routers will have to do that
   anyway, but this is *such* a no-brainer
   for the host that they deserve lousy (degraded)
   service if they can't be bothered to implement
   either diffserv or setting flow labels.

		   Mike

---

From: "Perry E. Metzger" <[email-masked]>
Date: 24 Dec 2001 20:20:07 -0500

>    DSCP's aren't guaranteed to be end to end.

And what does that have to do with the "traffic class" byte in the
IPv6 header?

>    unexpected semantics fo the flow label.

All you're doing is saying "we can afford to waste the bits". Fine. I
don't care about the bits. Can we afford to waste the time writing
code that doesn't help anything? Repeating, I'd like to see evidence
that we actually are going to have a benefit from doing this work.

>    Indeed,

There isn't a flow label in IPv4 and it seems to be well deployed.

>    value to hopefully find a 5 tuple?

Yes, I have substantial doubts on this. First of all, people already
have silicon that does this astonishingly fast. Second of all, they
don't yet have silicon that will do anything with the "flow label" and
it will be years before they could have deployed hardware like
that. Third, they'd have to chase down the header chains anyway,
because stuff like XP isn't going away. (In other words, we've
deployed, it is too late.) Fourth, I have yet to see any real
explanation of what this is going to do for people in
practice. Repeating my earlier request:

>    Yeah, yeah, some (edge) routers will have to do that anyway, but
>    this is *such* a no-brainer for the host that they deserve lousy
>    (degraded) service if they can't be bothered to implement either
>    diffserv or setting flow labels.

If it is such a no brainer, I'm sure it would be easy for you to
explain, as I've asked:

1) What exact use you will put the flow label to
2) Precisely what quantitative improvements you're expecting over
   existing hardware classification mechanisms by having the flow
   label.

When I hear folks at Juniper mumbling that they already have their
hardware v6 support out in the field in their existing router line,
and I hear folks from Extreme mumbling that they have their packet
classifiers built (and they're hardly the only ones), and I look at
the fact that there are a whole lot of v6 enabled systems already out
there in the field that aren't going away, I feel like I have to start
asking hard questions.

If we're going to start mandating people do something new at this late
stage of the game, we'd better have a good engineering rationale for
it, along with good measurements to back up that rationale.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Dec 2001 10:22:44 -0800 (PST)

> There isn't a flow label in IPv4 and it seems
  
   Uh, make up your mind. Flow classification for
   QoS is not well deployed. If your entire
   point is that signaled QoS is a load of hooey,
   state that so we can all save time.

 > have silicon that does this astonishingly fast. 

   Define "astonishingly"; I don't know of anything
   that does IP6 vaguely approaching "astonishingly"
   except in slideware. IP6 adds the concept of
   header chaining which, though possible in IP4,
   is not common, and the cross product with QoS
   is even less supported (if at all). This is a
   substantial source of heartburn for ASIC
   designers, and is problematic for CAM based
   designs -- which are astonishingly fast --
   where every bit is precious.

 > Second of all, they
 > that.

   ::snort:: 

   What is absolutely for certain is that each
   new protocol and/or tunnel combination will be
   years away each time somebody decides that that
   combination is vital to existence as we know it.

 > Third, they'd have to chase down the header chains anyway,
 > deployed, it is too late.) 

   As if XP is the only thing that will require
   elevated QoS. In fact, I expect that if signaled
   QoS is deployed at all, it will be for voip, etc,
   widgets. Somebody sitting at a PC already has
   low expectations.

 > Fourth, I have yet to see any real

   Then you're hearing what you want to hear.

 > classifiers built (and they're hardly the only ones), 

   Astonishingly fast, no doubt. Look, you can make
   just about anything go "astonishingly fast" with
   enough NRE + RE. The question is whether we should
   keep the IETF QoS full employment act fully funded
   by ignoring the layer violation. It seems that you're
   saying that it's a done deal therefore ignore it.
   What you're not fessing up to is that the reality
   is that NAT's have *really* won and that IP6's
   future is still very much uncertain. So, IMO, we
   either continue with this possible fantasy that
   we can engineer a clean new version of IP, or we
   chuck it all and give in to the least common
   denominator of hacks upon hacks upon hacks. There
   are lots of other things in this class too; my
   favorite bit of suspended disbelief is renumbering.

 > and I look at

   "Whole lot"? Please. And adding a flow label
   to the kernel is *hardly* rocket science.

 > it, along with good measurements to back up that rationale.

   Nobody's "mandating" anything any more than
   "mandating" DSCP marking. If you don't want
   elevated QoS, you are completely at liberty
   to ignore all of this nonsense.

	     Mike

---

From: "Perry E. Metzger" <[email-masked]>
Date: 25 Dec 2001 14:22:35 -0500

Michael Thomas <[email-masked]> writes:
>    Define "astonishingly";

Ran Atkinson says Extreme's implementation (among other things)
extracts the N-tuple in one clock cycle once the packet is in the
ASIC. I may be mis-stating his claim but you can feel free to ask him
about it -- it isn't like he's a shy guy.

>    Then you're hearing what you want to hear.

Nope, I'm not. I've gone through the whole discussion. No one has yet
stated precisely how they will use the field and what sort of speedup
it will mean for them in practice.

I want to see that clearly and distinctly explained well before we go
through the exercise.

I'm looking for statements from several router vendors that look much
like this:

"Big Router Company believes that it is important that we have the
flow label because by implementing it, our studies show we will be
able to reduce time on operation X to 175 microseconds. We intend to
produce the hardware that will do this. Operation X is critical for
packet forwarding because..."

However I haven't seen anything like that. All I see is lots of vague
posturing and comments to the effect that "well, we defined the field,
didn't we? why don't we use it?"

I see no one giving actual figures from experiments for the benefits
of the field. I see no solid engineering explanation of the use of the
field. I see no real claims from vendors that they badly want the
field and will put support for the field into ASICs any decade soon.

>    "Whole lot"? Please.

Yes. Every single new PC shipping with Windows has v6 code in
it. EVERY SINGLE ONE. Amazing, isn't it.

The last major company that isn't shipping v6 support is Apple, and
that will be fixed in OS X very soon.

We defined a protocol and the vendors are now actually shipping it. It
is actually going out to the field. Unfortunately, that makes it a bit
late to make serious changes.

>    And adding a flow label to the kernel is *hardly* rocket science.

Pretty fucking hard to stop the rocket once the SRBs are lit.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Dec 2001 14:15:11 +0100

Margaret,

You're not missing anything. You can use the {source addr, flow label} 2uple
to classify at line speed all packets requiring the *same* QOS treatment.
The classifier doesn't need to know whether it's classifying for
Intserv, Diffserv or some future QOS mechanism that hasn't been
invented yet; it doesn't need to know whether it's classifying a single
flow or a behavior aggregate or some other glob of traffic. Some higher
level QOS mechanism, fed by the classifier, will know about that.
Some higher level control-plane mechanism will configure the relevant
2uples into the hardware classifier.

[Immutability isn't a requirement for this to be true, but immutablility
also makes it unnecessary to have a string-of-SLAs all along the path for
useful classification to be possible. I disagree with Alex on this -
I really do think immutability is a requirement, even if it is subject to
'gentleman's agreement'.]

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Dec 2001 14:18:36 +0100

> network. You can't have it both ways.

Exactly. And operators who break the immutability rule will penalise
their own customers by depriving them of e2e QOS. 

There was a reason diffserv chose to make the DSCP mutable, but the same reason
(QOS policies are ISP-specific) is why the flow label should be immutable.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Dec 2001 15:51:52 +0100

Perry, really, these questions have been asked and answered a dozen times.

I'm not getting at you personally but I am getting very tired of this
discussion going round and round. We (those of use who've been thinking
about QOS for some years in Intserv, Diffserv and elsewhere) didn't
come along with a proposal to clarify the e2e semantics of the flow
label in a vacuum.

Let's either clarify them, as in the one para summary that Tony Hain
sent a few days ago, or simply write the field off as reserved, in which
case IPv6 will have no advantage of IPv4 for QOS purposes.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Dec 2001 15:53:41 +0100

> aren't going to be obeying any of this,

We're designing for 2002 operating systems? I thought we were designing
for the next 50 years.

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Dec 2001 08:22:50 -0800 (PST)

> I'm looking for statements from several router vendors that look much

   I don't speak for Cisco. I speak for myself.
  
   Sorry.

		Mike

---

From: "Perry E. Metzger" <[email-masked]>
Date: 26 Dec 2001 11:45:58 -0500

> case IPv6 will have no advantage of IPv4 for QOS purposes.

I think the notion of making our protocols better for QoS purposes is
an admirable one. My problem is that I don't think anyone has well
demonstrated that the flow label *will* give us an advantage for QoS
purposes.  I understand the arguments. I just haven't seen anyone
step up with the crucial "we at large router vendor have done the
experiment and even though we have to reach into the packet anyway to
do tuple extraction having this in a percentage of the packets will
increase performance in this quantitative way."

I'll repeat (broken-record like), we've already deployed the end point
implementations in the field. We can't change those stacks at this
point.

By the way, as I've often said: the killer app for IPv6 is not QoS or
security or anything else -- all those can be achieved (though
sometimes with greater effort) in IPv4. The killer app for IPv6 is
having an internet again. The mere fact that any user of IPv6 can
reasonably expect to receive as well as to make connections, because
they have a globally routable address, is a profound change from
today's network in which the end to end principle is rapidly
disintegrating. It is, to use my standard metaphor, like a phone
network where most people can only call out -- hardly a good thing.

Or to put it another way, you can't connect to your home machine and
download that report you were working on the previous night but forgot
to bring with you if it is behind a NAT box on your cable
modem. That's why you need IPv6 -- so you'll have an internet, not
because it is better at QoS.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 26 Dec 2001 11:47:59 -0500

> We're designing for 2002 operating systems? I thought we were designing

We're designing for 2002 operating systems if we want to see this
deployed before 50 years from now.

I'm reminded of the old expression "time to shoot the engineers and
ship the product."

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 26 Dec 2001 11:48:44 -0500

>    I don't speak for Cisco. I speak for myself.

Well, speaking for yourself, can you describe your simulations of
hardware performance with and without the flow label?

Perry

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Dec 2001 17:26:58 -0500

> Windows XP and such
> the contents of the packets anyway.

Shall we forever constrain IPv6 to support only what is now supported by 
Microsoft?  

Keith

---

From: "Perry E. Metzger" <[email-masked]>
Date: 26 Dec 2001 17:31:00 -0500

> Shall we forever constrain IPv6 to support only what is now supported by 

No, but the further along the deployment curve you get, the more
seriously you have to examine changes. We're far enough along that
changes have to be made with the utmost of conservatism, and have to
be made under the premise that backward compatibility can no longer be
sacrificed. In other words, yah, we kind of have to accept that a
large chunk of the end nodes are going to run XP for the foreseeable
future.

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Dec 2001 18:01:21 -0500

> seriously you have to examine changes

the more seriously you have to examine *incompatible* changes.

> we kind of have to accept that a

to hell with XP.  if we find a good use for flow label, and XP doesn't
support it, the poor folks using XP (and other legacy systems) will 
either have to deal with either not being able to take advantage of
that feature, or they'll upgrade. 

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Dec 2001 16:29:09 -0800 (PST)

> hardware performance with and without the flow label?

   I'm not especially interested in this game
   because some hardware geek somewhere is 
   bound to throw enough transistors at the 
   problem and claim that it doable. Big deal. 
   It's an empty claim because it doesn't say
   what was given up in the process. I have
   witnessed firsthand hardware engineers on
   high end platforms react somewhere between
   disbelief and outright hostility at the
   prospect of chasing down header chains at
   line rate. CAM's -- as I've mention three
   times now -- are especially sensitive to 
   bone headed standards potato blunders of
   this kind; I forget, but the transistor
   count is O(n^2) or maybe worse with the
   number of bits needed to form the key. IP6
   is already at a big disadvantage given the
   need to key off of ~256 bits vs. 64 bits
   just for addresses. And lest you think
   that I'm just concerned about CAM based forwarding
   planes, think again; they all need to view
   enough of the header to classify, and that
   always impacts silicon as it gets bigger.
   Thus you get these choices: pay more than you
   should have, get worse performance, or delete
   other features you might have liked to go
   faster on a finite transistor budget.

   Oh, and you might ask your hardware vendors
   who claim to do this whether they can deal
   with flow classification of mobile IP with
   route optimization at line rate. And since
   MIPv6 route optimization is about as stable as
   jello, will they have the resilience to change
   their flow classier if it changes too? 

	      Mike

---

From: "Perry E. Metzger" <[email-masked]>
Date: 26 Dec 2001 19:52:17 -0500

>    problem and claim that it doable. Big deal. 

"I'm not interested in this game" = "I don't care to give evidence for
my position -- I'm just going to assert something is needed."

"Hardware geek" = "people that make the routers actually work these
days, and without whom all of us would be up the creek."

>    I have witnessed firsthand hardware engineers on high end
>    platforms react somewhere between disbelief and outright
>    hostility at the prospect of chasing down header chains at line
>    rate.

Given the fact that IPv6 headers have to be processed in some
circumstances by routers -- and perhaps most of the time in the future
-- it would seem that they're going to have to cope with their
disbelief.

Of course, it appears that folks from several vendors already have
coped with this disbelief and have working hardware.

---

From: "Subrata Goswami" <[email-masked]>
Date: Wed, 26 Dec 2001 17:04:14 -0800

Well, the  need to reduce silicon real estate is very noble
indeed. The price and density of silicon goes down by a factor
of 2 every 2 years so, and the flow-label legacy would probably
last beyond that. So the pertinent question to answer would be
how do we assign the bits in a way that they would still be
useful 10 years from now.

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Michael Thomas
Sent: Wednesday, December 26, 2001 4:29 PM
To: Perry E. Metzger
Cc: Michael Thomas; [email-masked]
Subject: Re: Flow Label

	      Mike

---

From: Robert Elz <[email-masked]>
Date: Thu, 27 Dec 2001 13:28:50 +0700

Date:        26 Dec 2001 11:45:58 -0500
    From:        "Perry E. Metzger" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'll repeat (broken-record like), we've already deployed the end point
  | implementations in the field. We can't change those stacks at this
  | point.

There are two points there.    First, as Keith said, this is nonsense,
nothing that is being discussed here has any impact upon deployed nodes
(other things that could be discussed would, this doesn't).  The very worst
is that users of currently shipping OS's might not be able to take advantage
of some benefit in the future, and might need to upgrade.   But that's hardly
a new concept.

But if what you say were true, the result would be that you'd be arguing
for exactly the opposite of what you seem to believe that you are.   That is,
assuming that XP has implemented an interface anything like that defined in
2553 (and while I've never seen an XP, I'd be surprised if they hadn't)
then the ability to set the flow label already exists.

That is ...

struct sockaddr_in6 {
    sa_family_t     sin6_family;    /* AF_INET6 */
    in_port_t       sin6_port;      /* transport layer port # */
    uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */
    struct in6_addr sin6_addr;      /* IPv6 address */
    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
};

That means, that if we were to make the field "reserved, must be zero"
then there's no way the shipped implementations could comply, as they will
probably already allow applications to set the value to anything they want.

On the other hand, if we (or someone) simply define a meaning for the bits,
then all that should be required is for someone to install an application
that uses them in the defined way.

That is, the "already shipping" argument in this case has the exact
opposite effect than you're claiming that it does.

Now for the already shipping IPv6 routers things are different - but the
volume of those is on a different plane, and they tend to be operated by
people who also know how to upgrade them to newer code if that turns out
to be needed to support something they want to offer.  That is, if using the
flow label is needed (or useful) to support some QoS paradigm, and the
router (or its owner) wants to support that, then making the router do it
won't be at all impossible.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 11:21:23 +0100

> increase performance in this quantitative way."

Chicken and egg. People building protocol silicon aren't going to
commit to the flow label until it has a useful definition.

Also, the goal is not to increase total performance; it's to discriminate
between different traffic streams in a quantitative way. That's done
today in plenty of products; the flow label would simply add a tool.
> implementations in the field. We can't change those stacks at this

No, so it's just as well the API supports the flow label :-)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 11:51:17 +0100

Perry, the traffic class is mutable at ISP boundaries.
If the flow label is also mutable, it adds no value
and becomes wasted bits.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 11:58:51 +0100

> about it -- it isn't like he's a shy guy.

I don't think you'll find it works very well for ESP traffic. That is, please
don't forget, why the flow label is a potential solution.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 11:57:40 +0100

Michael Thomas wrote:
...
>  > it will be years before they could have deployed hardware like

Couldn't have said it better :-)

Of course there is no silicon that looks at the flow label. That's because
we haven't ever defined it usefully. If we define it usefully, the silicon
will show up a few years later. 

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 13:37:23 +0100

> coped with this disbelief and have working hardware.

You can do anything, but it costs more money and generates more
heat to dissipate. Believe me, the hardware designers *all* react
as Michael describes: don't ask them to chase down successive headers
as part of the truly optimised line-speed path; that sort of logic will
always be behind the game compared with fixed header fields.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 13:40:06 +0100

Indeed. But we also know that the cost of bandwidth is dropping
faster than Moore's law, so building hardware to keep up with
line speed is actually a little harder every day. That argues
for extreme simplicity. 

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 14:06:53 +0100

> Repeating my earlier request:
> 
>         they'll put the flow label information to, 

Here are the precise definitions the IETF has documented:

1) IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3

[RFC 2205, page 87]

2) diffServMultiFieldClfrFlowId OBJECT-TYPE
    SYNTAX         Unsigned32 (0..1048575)
    MAX-ACCESS     read-create
    STATUS         current
    DESCRIPTION
       "The flow identifier in an IPv6 header."
    ::= { diffServMultiFieldClfrEntry 8 }

[draft-ietf-diffserv-mib-16.txt, approved as PS, page 52]

but these will be largely ignored by implementors until RFC 2460
is cleaned up.

>         and quantitative
>         label than not to have it. 

Nobody is going to publish that sort of competitive data. As noted earlier,
this is quite likely to be either qualitative (ability to classify ESP
traffic) or simply a matter of heat dissipation and the marginal cost of
a chip set.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 14:24:19 +0100

"Perry E. Metzger" wrote:
> sacrificed. 

Couldn't agree more. That is why I support Tony's proposal, which seems to
me to be very conservative, minimalist, and the only viable alternative
to MBZ. Expanding on that, I'd like to propose the following as the
complete and total replacement of Section 6 of RFC 2460.

   The 20-bit Flow Label field in the IPv6 header MAY be used by a
   source to uniquely label sets of packets requiring special handling by 
   IPv6 routers. Nodes that do not support the Flow Label field MUST set 
   the field to zero when originating a packet, and MUST ignore the field 
   when receiving a packet. All routers MUST pass the field on unchanged
   when forwarding a packet.

   This specification does not further define the meaning of the
   Flow Label.

[and delete Appendix A, which is unhelpful.]

      Brian

---

From: "Perry E. Metzger" <[email-masked]>
Date: 27 Dec 2001 10:09:15 -0500

Brian E Carpenter <[email-masked]> writes:
> traffic)

We can already classify ESP traffic. The SPI for a particular host to
host connection is externally visible likely unique for a given
flow in most applications. (The VPN case is a bit different but the
VPN case is, we hope, not the bulk of traffic in the future.)

We can also already label the individual packets according to
traffic class.

> or simply a matter of heat dissipation and the marginal cost of
> a chip set.

Well, if it truly makes no difference, why are we advocating the change?

---

From: "Subrata Goswami" <[email-masked]>
Date: Thu, 27 Dec 2001 07:19:46 -0800

Both of the following example actually only tells you
how to set them, not how to use them and both are
optional.

Given the fact that there are only 20 bits in the flow
label, then globally only 4K flows can be defined - is that
enough ?

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Brian E Carpenter
Sent: Thursday, December 27, 2001 5:07 AM
To: Perry E. Metzger
Cc: Michael Thomas; [email-masked]
Subject: Re: Flow Label

[RFC 2205, page 87]

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 16:35:04 +0100

> VPN case is, we hope, not the bulk of traffic in the future.)

Sorry, the SPI is no good for diffserv classification
because it has no semantics.

> We can also already label the individual packets according to

No, because it's mutable. We need sonmeting that *isn't* mutable
and *does* have semantics for classification.
> Well, if it truly makes no difference, why are we advocating the change?

I didn't say it makes no difference. I said that the difference is more
likely to be in cost and waste heat than in speed.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 16:37:45 +0100

> how to set them, not how to use them and both are

No, they tell you how to use them. A flow_spec is how intserv
identifies flows; a classifier is how diffserv classifies
packets. Yes they are both optional - like many enhancements.

> label, then globally only 4K flows can be defined - is that

It's the 2uple {source address, flow label} or possibly the
3uple {source addr, destination addr, flow label} that has to be
unique.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 16:43:48 +0100

Taking Scott's suggestion, here's another try:

I'd like to propose the following as the
complete and total replacement of Section 6 of RFC 2460.
 
   The 20-bit Flow Label field in the IPv6 header MAY be set by a
   source to uniquely label sets of packets. Nodes that do not support 
   the Flow Label field MUST set the field to zero when originating a 
   packet, and MUST ignore the field when receiving a packet. All routers 
   MUST pass the field on unchanged when forwarding a packet.

 
       Brian

---

From: "Perry E. Metzger" <[email-masked]>
Date: 27 Dec 2001 10:46:55 -0500

> because it has no semantics.

Neither does the flow label. Both are just a number that can be used
to distinguish a bunch of traffic flowing between two hosts from other
traffic flowing between two hosts. Neither has any semantics beyond
that.

> and *does* have semantics for classification.

I am perhaps a bit thick, Brian, but all the flow label seems to
indicate is that a host believes that a bunch of traffic going to
another host is distinct from a bunch of other traffic by some
mysterious criterion it has itself selected. Since we've imposed more
or less no other implications in the draft (am I mistaken here?) it
doesn't have particularly any semantics for classification there
either.

> likely to be in cost and waste heat than in speed.

Given that the manufacturers who are doing this are already building
the transistors in to walk the header chain...

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 27 Dec 2001 11:08:43 -0500

Actually, I would take out the word "uniquely".  I am
not sure that we want to confine possible QoS solutions
to "uniquely" labeling anything.

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 16:43:48 +0100

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 27 Dec 2001 11:08:43 -0500

Margaret

---

From: "James Kempf" <[email-masked]>
Date: Thu, 27 Dec 2001 09:43:35 -0800

Agree.

            jak

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Dec 2001 12:27:27 -0800 (PST)

> traffic flowing between two hosts. Neither has any semantics beyond

   Bzzt. You're overloading semantics. SPI's enumerate
   the set of packets for which a given security policy
   applies. That may have exactly zero to do with the
   QoS policies you'd like to apply.

 > the transistors in to walk the header chain...

   By all means, let's just ignore silicon considerations.
   Moore's Law trumps all, obviously.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Perry E. Metzger" <[email-masked]>
Date: 28 Dec 2001 16:11:37 -0500

>    QoS policies you'd like to apply.

In the scheme proposed, flow labels just enumerate a set of packets
that a host has chosen to designate as a "flow" because, say, they're
all using the same TCP socket -- which may also have exactly zero to
do with the QoS policies you'd like to apply. How is it any different
than the SPI situation?

>    Moore's Law trumps all, obviously.

If they have to build tuple extraction into the hardware anyway to
deal with the implementations that don't do flow labels (i.e any
deployed in the next few years), how can we claim that we're going to
get around people having to build hardware? Given that several vendors
have already designed the hardware, how are we going to be helping?

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Dec 2001 13:47:49 -0800 (PST)

> do with the QoS policies you'd like to apply. How is it any different

   Again, security policy is not identical to
   QoS policy. The only way to make them identical
   is to have separate IPsec SA's for each QoS flow.
   This would be a huge waste, both on the signaling
   front as well as the SADB cost.

   And I don't see what TCP sockets have to do
   with anything; how a host OS allows packets
   to be marked is an API issue just like setting
   the DSCP.

 > have already designed the hardware, how are we going to be helping?

   There's a huge difference between "building it in
   hardware" and "building it in hardware at speed".
   I have infinite optimism in the creativity of
   hardware geeks except for one thing: they
   always tell you what set of things fit into a
   die and that you get to choose which ones to
   delete when they don't all fit. The bigger you
   make certain modules the less you have for
   other things. In this case, fixed fields are
   good; linked lists are bad. Doable but bad is
   still bad.
  
   Also: you seem to be under the illusion that
   QoS classifiers are set in stone. They are not.
   I just took a quick look at SCTP: its ports
   are not in the same place as TCP/UDP; hence,
   hardware change. Each new IP protocol that we
   come up with will have the same problem. The
   flow label has the potential to stop that
   problem now and forever.

	       Mike

---

From: "Perry E. Metzger" <[email-masked]>
Date: 28 Dec 2001 16:50:04 -0500

>    front as well as the SADB cost.

Er, you already in practice have an SPI for every flow. See my other
message on this subject.

.pm

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Dec 2001 14:02:14 -0800 (PST)

> Er, you already in practice have an SPI for every flow. See my other

   Uh, no. In practice there's a single SPI for
   all of the traffic. Also: in practice the
   cross product of QoS and IPsec is pretty rare.
   I expect that will change with the advent of
   lots of IP phones going across VPN's, but 
   when that happens you want hard coupling of
   QoS and Security even less: VPN concentrators
   have finite memory/hardware for SA's. Since
   there's no security benefit, you're just adding
   cost to achieve feature parity. This would not
   be the case with the flow label.

	     Mike

---

From: Alex Conta <[email-masked]>
Date: Sun, 30 Dec 2001 11:25:50 -0500

Brian,

Brian E Carpenter wrote:
> [...]

The mutability by itself does not require the flow setup mechanism (you
choose a string of SLAs) to say or do anything about it - by default,
routers would treat the flow label as immutable. 

However, when for any reason, it is useful to have the field mutable,
the flow setup mechanism (SLAs, or anything else) MUST provide the
necessary information to a subset of routers on the path that modify the
field. The "subset" is anything between "one" to "all" routers on the
path.

Alex

---

From: Alex Conta <[email-masked]>
Date: Sun, 30 Dec 2001 12:34:44 -0500

Making the field "immutable" by "default", but "mutable" when a router
is so instructed by a flow setup and flow processing mechanism is a
compromise that would satisfy all current and future possible cases.

Therefore I think last sentence of the first paragraph 

    All routers MUST pass the field on unchanged when forwarding a
packet.

should be something like:

    All routers MUST leave the field unchanged, by default, when
forwarding a packet.
    A specific flow setup/processing mechanism MAY give a "mutable"
character to the field,  
    by requesting routers, supporting the mechanism, to change the field
in certain ways.
    Routers supporting such a mechanism MUST follow the steps indicated
by the flow 
    setup and flow processing mechanism.

Alex

---

From: Alex Conta <[email-masked]>
Date: Sun, 30 Dec 2001 12:47:59 -0500

The default behavior can be "immutable", which I think would satisfy the
concerns I hear. But restricting all possible (including future ones)
flow setup and flow processing mechanism to "immutability" is too much. 

Alex