Subject: RE: Usage of IPv6 flow label

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 16 Nov 2000 05:51:22 +1100

> >Hi all,
> >I have some questions depending the usage of the flow
> >label field within IPv6. Background of my questioning is
> >that actually within 3GPP standardization the discussion 
> >appears if the flow label could be used for bearer 
> >identification if IPv6 would be chosen as transport
> >option within the UMTS Radio Access Networks.
> 
	=> It is also used in the GGSN (default router in IPv6 land)
	as one of the options to identify a flow and make the right 
	QoS decisions.
	The router is informed by the IPv6 node about 
	the flow label value for each connection.

> >- Can intermediate routers change the flow label?
> >  Appendix A of RFC2460 states that hosts or routers that
> >  do not support the flow label should pass the field on 
> >  unchanged. Is this also true for hosts or routers that
> >  do support the flow label? What is the procedure if an
> >  router supports flow labels but has no context about a
> >  specific flow label? 
> 
> 	seems to me, no.
> 
	=> Agreed. Also based on my comment above I 
	don't think it would be a good idea. 
	I can't remember if it's included in the AH calculation 
	or not. 

	Hesham
--------------------------------------------------------------------
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: Wed, 15 Nov 2000 14:14:24 -0800 (PST)

> 	the flow label value for each connection.

   Er, by what protocol does it inform the router?

	  Mike

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 16 Nov 2000 04:09:19 +0900

>	I can't remember if it's included in the AH calculation 

	flow label field is not part of AH calculation, but as RSVP already
	requires it to be end-to-end (not hop-by-hop) i think we shouldn't
	rewrite it in transit.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Thu, 16 Nov 2000 10:58:21 +0100

In your previous mail you wrote:

=> I don't read your argument as you. I'll say it should not be rewritten
in transit if RSVP is in use. A DiffServ edge router can rewrite it
in some situation (it is supposed to know what is RSVP and do the right
thing). Don't forget that in the real world RSVP is not end-to-end and
is managed by smart edge routers, this comes more from practice (the end
user doesn't know how to use RSVP, the edge router manager knows) than
from deep design...

Regards

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Thu, 16 Nov 2000 06:22:53 -0500

Francis,

You bring up a point that is critical regarding the flow and something I
am looking at now.  How and when is the flow label used.  Like you state
when RSVP is being used we should not aloter the flowlabel. I don't want
to use up bits in the flowlabel to identify the type of packet and I
don't think we can count on next header value.  That is why I send mail
stating I liked the idea of a "selector" in an API.  But how we convey
that to the routing layer is the magic we need.  God forgive me but I am
playing with the use of a state machine for the network layer which will
also be useful for site/scopes and anycast for Hosts.  :---)

/jim

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Nov 2000 06:06:02 -0800 (PST)

Francis Dupont writes:
 > thing).

   Why would a diffserv router _want_ to rewrite a flow label?
   It can still rewrite the DSCP if it wants. The only thing
   that I've seen mentioned that could actually take advantage
   in the way you are mentioning is using the flow label for
   MPLS label swapping bits.

	      Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Nov 2000 11:02:18 -0800 (PST)

Alex Conta writes:
 > If flow IDs are used for fast forwarding, without the ability to rewrite
 > them, it seems to me 
 > that a router will not be able to aggregate flows. 

   Boy, I may be missing something really stupid, but
   the DSCP seems like the obvious flow aggregation
   handle to me.

	     Mike
 > Alex
 > Michael Thomas wrote:

---

From: Alex Conta <[email-masked]>
Date: Thu, 16 Nov 2000 13:56:46 -0500

Alex

---

From: Alex Conta <[email-masked]>
Date: Fri, 17 Nov 2000 11:09:28 -0500

You missed my point: the Diffserv field is used for QoS flow aggregation
and not packet forwarding.

Alex

---

From: Steve Deering <[email-masked]>
Date: Fri, 17 Nov 2000 08:35:59 -0800

At 1:56 PM -0500 11/16/00, Alex Conta wrote:
>them, it seems to me  that a router will not be able to aggregate flows. 

Alex,

That is incorrect.  A router can aggregate flows by encapsulation
(similar to, but more powerful than, label stacks), and therefore
not need to rewrite flow IDs.

A system that rewrites flow IDs to do aggregation is unable to
efficiently *de*aggregate at the other end of the aggregating path.

Steve

---

From: Alex Conta <[email-masked]>
Date: Fri, 17 Nov 2000 14:20:17 -0500

Steve,

> Steve Deering wrote:
> That is incorrect.  

You missed a component my argument. We are in fact talking about apples
and oranges. 

Tunneling flows means creating COMPLETELY NEW flows, with completely
different characteristics than the original flows: source, destination,
etc..., with an important impact on the classification criteria that can
be applied.  

> A router can aggregate flows by encapsulation

"More powerful" is relative: for routers that implement both, and for
forwarding within the routing domains were both are supported, one could
argue that it does not apply.

Tunneling is more expensive and less efficient -- packet size issues,
and encapsulation effort in 
terms of header pre pending. Furthermore, tunneling adds cost in terms
of header processing, that is, forwarding is performed twice, once on
the original packet, and second on the tunnel packet.

Additionally, the costs of building such functions add to the costs of a
fast forwarding engine. 

> efficiently *de*aggregate at the other end of the aggregating path.

I disagree. De-aggregation of forwarded traffic based on the 'flow-id'
of tunnel packets is not necessarily more efficient than de-aggregation
of forwarded traffic based on "destination address" of original
(non-tunnel) packets. Here is why:

	1. - A tunnel packet "flow-id" based de-aggregation, requires			
		- a forwarding of the tunnel packet, 		
		- decapsulation, and 
		- a forwarding of the original packet.

	2. - An original packet "destination address" based de-aggregation
requires
		- a forwarding of the original packet

This has implications on the costs of building a fast engine.

Alex

---

From: Steve Deering <[email-masked]>
Date: Fri, 17 Nov 2000 13:08:49 -0800

>You missed a component my argument. We are in fact talking about apples

I wasn't responding to your argument. (Debating the the pros and cons
of MPLS, though one of my favorite topics, is out-of-scope for this

>them, it seems to me that a router will not be able to aggregate flows. 

and pointing out that you were mistaken.

>etc..., with an important impact on the classification criteria that can

Of course.  An aggregate of flows usually has different properties
than its component flows (like bandwidth, for one), so it makes sense
to think of them as separate flows (big pipes with little pipes running
through them, like the classic diagrams of ATM virtual circuits inside
of virtual paths).  It's a feature to be able to classify them separately.

>argue that it does not apply.

I was using "more powerful" in the sense of being a more general mechanism
than can accomplish more than just what MPLS does.  Sure, if all you
care about is what you can do with MPLS, that extra "power" will not
interest you, but it might be of interest to others.

>the original packet, and second on the tunnel packet.

Yes there are lots of little performance trade-offs and different people
weigh their importance differently, and there are more efficient ways of
implementing tunnel entry/exit than you imply.  None of that has
anything to do with your speculation that routers simply won't be able
aggregate flows if they can't rewrite the flow ID.

>Additionally, the costs of building such functions add to the costs of a

I believe IP-in-IP tunneling has become a basic tool that routers need to
support efficiently anyway, so I'd turn it around and ask if it's worth
the additional (and nontrivial) costs of including all the MPLS machinery
as well.  But I won't, because as I said, it's out-of-scope for this list.

Steve

---

From: Alex Conta <[email-masked]>
Date: Fri, 17 Nov 2000 17:52:34 -0500

Since the IPv6 flow label work started, two major efforts in IETF made
significant progress on related topics: Diffserv and MPLS. 

As an extension of the Diffserv aggregation model, the flow label SHOULD
be re-writable. If you think about extending your argument to Diffserv,
then Diffserv aggregated flows should be always tunneled.

Similarly to Diffserv, allowing re-write does not always mean that the
flow label is going to be re-written, so the current specification, or
usage would be in fact a subset.

The argument boils down to **forcing "read-only" onto flow labels does
not pay**. On the contrary.
I think that the MPLS work is a significant progress on the concept, and
mechanisms of labeling flows, and as you know [(-:],  I think IPv6
should borrow from it, rather than going against, or going on a path
that was started before the MPLS effort, but so far didn't go far enough
to be sufficiently significant.

Some of the weight, or basis, or the hidden reason, of your tunneling
argument comes, I think, from the fact that as of now, a flow label
defines uniquely a flow, only when associated with the source address.
Because of the need of the 20 + 128 bits for flow identification, just
re-writing the flow label would not do it: you need a new source address
as well for the flow identification.
But this (148 bits for uniquely identifying a flow), as well as
re-writing, local, or global significance, unicity, etc... are all
things that should be on the table for discussion.

Aggregation implies that some elements of the flows being subject to
aggregation are similar: QoS requirements, destination, etc... Your are
right, tunneling is indeed the most general, and most comprehensive
mechanism. But tunneling means changing all parameters. Is the cost
always justified, or
even when changing one parameter would be sufficient? 

In my opinion, the cost is not justified, in particular if a "flow
label' of 20 bits, can define alone, uniquely, a traffic flow to the
forwarding process.  Rewriting only the flow label for aggregation,
while leaving the rest of the packet's header's fields intact allows,
like in DIffserv, applying criteria of classification to those fields,
and the rest of the packet, similar to those applied to the original
packet, that is, do not require changing, or additional classifications
rules. Please note, and do not ignore the fact that, storing, deleting,
updating and disseminating classification rules is in fact at least if
not more expensive than similar operations done with forwarding table
information.

Alex

---

From: Steve Deering <[email-masked]>
Date: Fri, 17 Nov 2000 17:41:32 -0800

Alex,

Diffserv is in no way related to the Flow Label.  IPv6 has the Traffic
Class field for diffserv-style QoS.  The Flow Label was intended to
serve intserv-style QoS.

>then Diffserv aggregated flows should be always tunneled.

Intserv-style QoS, and the aggregation of intserv flows, is not an
extension of the diffserv aggregation (do you mean reclassification?)
model.  If you want to do diffserv-style aggregation/reclassification,
go ahead and use the  IPv6 Traffic Class field, which is intended for
that purpose.

>not pay**.

We arranged for the Flow Label to be excluded from the AH authentication
function, precisely so it could safely be modified en-route, i.e., far
from "forcing" it to be read only, we have gone out of our way to make it mutable.  We patiently await a spec that says exactly how to use
re-writable flow labels *including* how to allocate flow labels for
multicast flows crossing multi-access links.  It is the messiness and
fragility of solutions to that latter problem that led to the initial
end-to-end, instead of hop-by-hop, design of the Flow Label.

> On the contrary.

MPLS was not designed to address the same problems, across the same range
of link types, as the Flow Label.  (Granted, MPLS's purposes have kept
changing over time, but it's still true today.)  If you all you want is
MPLS for IPv6, go ahead and use MPLS under IPv6.  It works just fine
(or rather, as well as it does for IPv4).

>as well for the flow identification.

No, my arguments for tunneling do not derive from the constraints of
the Flow Label design, and would be the same whether the Flow Label
were end-to-end or hop-by-hop.

The end-to-end Flow Label design derived from the observed problems
with doing label allocation for multi-access links.  (Most of the
complexity of the ST protocol, which has hop-by-hop, layer-3 flow
labels/tags/VCIs, arose from trying to deal with that scenario.)
The end-to-end design avoids those problems, at the cost of a somewhat
more expensive look-up.   Fortunately, router designers have gotten
better with sophisticated look-up algorithms, so we no longer have
to stick with small-integer indexing to get highest-speed forwarding
(MPLS's original raison d'etre).

>things that should be on the table for discussion.

They are on the table for discussion, and have been for years.  That's
why it's in an appendix of the spec.

Steve

---

From: "Thomas Eklund" <[email-masked]>
Date: Sun, 19 Nov 2000 16:32:13 +0100

Hi Steve,

> as well.  But I won't, because as I said, it's out-of-scope

The way I see it is that it is very similar function in the traffic plane of
the router:
- daisy chain of mpls headers
- daisy chain of ipv6 extension headers

Note I'NOT saying they are doing the same things BUT if you want to do layer
4 classification (for stateful inspection, ingress/egress filtering and qos
etc) for v6 with its extension headers it even worse than a mpls-label
stacked packet operation...

Then as we have seen we can argue for a long time whether is it useful or
not..:-)

In fact mpls is much more light weigth tunneling protocol than ip in ip
tunneling... And it could serve as a very nice transition/tunneling
mechanism of an ipv6 based vpn..

MPLS solves one problem: traffic engineering - which is very nice to have in
the backbone for an ISP and the MECHANISMS that mpls have introduced is very
nice...
But when it's run over an ipv6 environment it can be more efficient and
utilize the flowlabel in the core for LSP's and do TE on them but to be more
efficient running over IPv6 and utilize the flow label instead of a new l2
protocol and get better link utilazation...

-- thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Nov 2000 16:13:38 -0600

Jun-ichiro itojun Hagino wrote:
...
>         requires it to be end-to-end (not hop-by-hop) i think we shouldn't

Only if you choose to specify it as part of a Filter Spec. I don't think
this is a convincing argument.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Nov 2000 16:36:27 -0600

Alex,

> significant progress on related topics: Diffserv and MPLS.

Steve's already said this but I want to say it again: no!

The Flow Label is totally orthogonal to diffserv, which has no need
of it, since it has its own mutable 6-bit field (more than enough).

The Flow Label is totally orthogonal to the MPLS Shim, which is at a lower
layer and is edge-to-edge, not end-to-end. 

As has been observed, the Flow Label is accommodated neatly by the IntServ
model.

   Brian

---

From: Jim Bound <[email-masked]>
Date: Tue, 21 Nov 2000 00:18:15 -0500

the flow label should be guranteed e-2-e.  clients should set it.
routers should leave it alone.

/jim

---

From: "JIM FLEMING" <[email-masked]>
Date: Mon, 20 Nov 2000 23:21:02 -0600

In my opinion, the IPv4 TOS should also be "e-2-e"...
...clients should set it....routers should leave it alone....

Jim Fleming
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp

----- Original Message -----
From: Jim Bound <[email-masked]>
To: Alex Conta <[email-masked]>
Cc: Steve Deering <[email-masked]>; Michael Thomas <[email-masked]>;
Francis Dupont <[email-masked]>; Jun-ichiro itojun Hagino
<[email-masked]>; Hesham Soliman (EPA) <[email-masked]>;
Metzler Jochen <[email-masked]>; Ipng (E-Mail)
<[email-masked]>; <[email-masked]>
Sent: Monday, November 20, 2000 11:18 PM
Subject: Re: Usage of IPv6 flow label

---

From: Alex Conta <[email-masked]>
Date: Tue, 21 Nov 2000 15:29:46 -0500

Steve,

Thank you for the elaborate clarifications. 

The dialog is certainly helping in dissipating confusion. The process is
asymptotic though, on some of the points we are parallel rather than
intersecting. For instance, my reference to diffserv was 
relative to aggregation. Your reference to 'intserv', I think is not.
Intserv's "teething" problem was scalability, and "aggregation" was the
solution proposed. But, to be short, all I am saying, is that in terms
of the "mechanics" of aggregation, the solutions should not be
inconsistent, or disjoint. In other words, tunneling should be optional,
not mandatory. I feel relieved by your reminding that AH ignores the
flow label, to allow the rewriting en-route, which is an important
premise.

As I followed closely the design of the IPv6 flow label, I am in
complete agreement with you, that the
reasoning, motivations, and choices made, were optimal several years
ago, when this design took place.
However -- and please excuse me if I repeat myself - circumstances
changed since, if not in the complexity of the problem(s), in the
availability of solutions, that is, architectures and protocols,
which can be entirely, or partially, adopted, or IPv6 can be made easier
to work with.

You are absolutely right that the MPLS work had an emphasis on ATM,
nevertheless, support for other relevant links, such as Frame Relay,
PPP, and LANs was provided since day one, and generic encapsulation (PPP
and LANs) is a basic building block for MPLS forwarding. As I recall
vividly the discussions in the SIPP WG, and later in the IPng WG on the
role and placing of the flow label within the IPv6 header, to facilitate
fast forwarding, and/or filtering, I would argue that the set of
problems that MPLS and IPv6 flow label attempt to resolve, are not, or
do not have to be disjoint. In fact, since MPLS provides a simple
mechanism for destination based, QoS, multicast, etc... forwarding, and
traffic engineering, one could argue that the set of problems that it
resolves is a superset. 

You are right that the emphasis "dans la raison d'etre" of MPLS has
changed, because the research improved drastically the availability of
solutions for IPv4 longest prefix match fast (or wire speed) forwarding.

But if you believe, or imply, that just because of that, the IPv6-ers
should no longer worry, and should no-longer search for mechanisms that
would enrich IPv6 forwarding with simpler and cheaper solutions, or
simplify or improve the existent mechanisms, then I should raise a flag
of warning !!!  

If you look to "L-C tries",  or "binary search on levels", or
"controlled prefix expansion", to mention a few, their complexity is so
much higher than the simple, fixed size label based forwarding, that in
fairness. one can only put their AVAILABILITY ON A PAR, BUT NOT THEIR
COST. Adding the need for additional engines for QoS, and multicasting,
is not making these solutions any cheaper. 

1Gps, and soon 10Gps will be the norm. At 10Gps, within 51 nano-seconds
per packet time constraint, 
the length of the IPv6 address -- which is a given, and not argued here
-- makes, unfortunately, the applicability of some of the IPv4 wire
speed longest prefix match forwarding solutions, both in terms of
lookup, and updating forwarding tables, quite problematic, thus reducing
the number of choices, and making the task of forwarding engines
designers not easier.

Warning flag down,
Alex

---

From: Alex Conta <[email-masked]>
Date: Tue, 21 Nov 2000 15:45:06 -0500

I would agree with that only of flow label's role is an end-to-end, or
host-to-host
processing. But then why bother to carry it in the IPv6 main header,
which is a header that
is for hop-by-hop processing?

Alex

---

From: Alex Conta <[email-masked]>
Date: Tue, 21 Nov 2000 18:52:55 -0500

Brian,

Please re-examine. My point was that both Diffserv, and MPLS, deal with
QoS topics, as the IPv6 flow  label does. Therefore, orthogonality, if I
understand you correctly, as independence from each other, and the rest,
has little relevance to my point. 

In contradiction to earlier calls, and statements on this list, your
message seem to suggest that the flow label is well defined, and its
role well determined...  If that is the case, I should say I am sorry:
this is rather a waste of everybody's time....

Alex

---

From: Jim Bound <[email-masked]>
Date: Tue, 21 Nov 2000 19:43:40 -0500

Hi Alex,

>is for hop-by-hop processing?

Carry in header because it can be also used for setup and traffic
engineering as RSVP is using it today with IPv6 (well not traffic
engineering but I believe it could).  Also I don't want to add it below
the header because I can access the addr+flowlabel tuple immediately in
the header for uses that are not just for routing, as I suggested to
Thomas Eklund (TCP congestion as one example).

regards,
/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Nov 2000 10:36:22 -0600

I didn't imply, or mean to imply, that the flow label is well defined.
That doesn't prevent it being orthogonal.

  Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 24 Nov 2000 16:57:27 +0100

=> I agree but in the real word IntServ stuff (then flow label marking)
is done by an edge router. If doesn't matter if the LAN is fast enough
(and it can be without too much money) and if clients and edge routers
collaborate.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Nov 2000 12:55:14 -0600

Jim,

It still isn't clear to me what the flow label adds to the semantics
used by existing 5-tuple QOS classifiers.

   Brian

---

From: [email-masked]
Date: Sun, 26 Nov 2000 07:00:05 +0900

>used by existing 5-tuple QOS classifiers.

	just checking, here by "5-tuple" you meant:
	- IP address pair (src/dst)
	- layer 4 port number pair (src/dst)
	- protocol type
	is it correct?

	except for IP address, they may be embedded into ESP, or may be buried
	in IP header chain.  so for efficient router operation we need to
	use flow label, which will effectively give us the following 3 items
	(depending on the definition of "flow"):
	- layer 4 port number pair
	- protocol type
	see RFC2205 page 9.
	i believe this (availability of flow label field) is one of important
	value-adds of IPv6 against IPv4.

itojun

---

From: Jim Bound <[email-masked]>
Date: Sun, 26 Nov 2000 21:12:06 -0500

>(and it can be without too much money) and if clients and edge routers

I don't agree.  The cell phone or audio server will set the flowlabel.
See Itojun's draft:

draft-itojun-ipv6-flowlabel-api-00.txt

Which is a good piece of work and I agree with Itojun's presentation of
the flowlabel.  Its set by the end node.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Sun, 26 Nov 2000 21:43:26 -0500

Brian,

>used by existing 5-tuple QOS classifiers.

First go look at RSVP.  Thats one.  In our RSVP implementation apps can
set the flowid and then get reserved resources along the path for audio
or video or even more mundane things like file transfer for mission
critical apps like downloading coordinates to a military operation.

Respond to Itojun's mail it says it all.  The bottom line is the
client or a server can set the flowlabel and with the address none of
those other tuples are needed and it can also be useful when IPsec is
being used to identify connections at a server that has a front end
router parsing connections for a large MP machine as another example and
get us away from monolithic TCP/IP processing.

Itojuns mail attached.  Also look at Itojuns draft.

regards,
/jim

To: Brian E Carpenter <[email-masked]>
Cc: Jim Bound <[email-masked]>, "Ipng (E-Mail)" <[email-masked]>
Subject: Re: Usage of IPv6 flow label
From: [email-masked]
Date: Sun, 26 Nov 2000 07:00:05 +0900
Sender: [email-masked]

itojun

---

From: Grenville Armitage <[email-masked]>
Date: Sun, 26 Nov 2000 21:30:05 -0800

Jim Bound wrote:
> First go look at RSVP.  Thats one.

Although RSVP's use of flowlabel does provide a simpler,
not-munged-by-IPsec syntax for expressing a flow's identity,
I was under the impression the flowlabel+srcaddr is semantically
identical to the 5-tuple.

cheers,
gja

---

From: Francis Dupont <[email-masked]>
Date: Mon, 27 Nov 2000 09:41:02 +0100

>(and it can be without too much money) and if clients and edge routers
   
   I don't agree.

=> What do you not agree about? I agree about the should but not the will.
Technical there is no reason to set the flow label in the edge router but
it is very common for not technical reason to see the edge router doing
the *Serv stuff on the behalf of the real source.

  The cell phone or audio server will set the flowlabel.

=> it is not what happens today then we should not fordid that the edge
router rewrites the flow label.

=> don't confuse the real and the ideal worlds.

Thanks

---

From: Jim Bound <[email-masked]>
Date: Mon, 27 Nov 2000 09:00:24 -0500

I don't agree.

>the *Serv stuff on the behalf of the real source.

There is no flowlabel to set today so don't tell me the real world is
using it.  What they are using is the diffserv bits and other mechanisms
for switching etc...

This is a wide open option and discussion.  As I said in prior mail
we may need to take a bit to define if the flow is rewritable.

>router rewrites the flow label.

This is discussable and you must not have read my mail to Thomas Eklund.

>=> don't confuse the real and the ideal worlds.

Excuse me.  But lets go offline with this I will match the customers in
the real world building real products who want the flowlabel e2e and we
are talking 3GPP, Military Operations, and Video/Audio apps.  

The bottom line is many folks want to use this flowlabel and one of
those folks are those who want it from one client to another client
across the Internet and to NOT BE TOUCHED by a router.

You should not confuse what exists today in IPv4 what can exist in IPv6
tomorrow.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 27 Nov 2000 09:18:35 -0500

Hi Greenville,

>identical to the 5-tuple.

Sure you can take a 5 tuple and get a 2 tuple.  But you also have to
munge down into the packet past the header in IPv4 and this can be
avoided in IPv6, and only if IPsec is not there.

IPsec is mandatory for IPv6.  It will be there unless users turn it off
and I doubt that unless it performs very very bad.  I don't think we can
assume IPsec will not perform good enough to be used, as engineers or 
architects.  So one may not be able to see the TCP port+address+proto-id
without a decrypt operation.

/jim

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Nov 2000 08:48:57 -0800 (PST)

> used by existing 5-tuple QOS classifiers.

   It seems intuitively more efficient for a flow classifier
   to use a single host-defined flow identifier than having
   to walk a potentially long list of extension headers. 
   Another advantage is that, sort of like diffserv, the
   host itself can decide what is to be grouped in a particular
   flow instead of requiring that it match the normal 5-tuple.

		Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Nov 2000 13:13:45 -0600

> identical to the 5-tuple.

No, not until the flow label has some semantics, which it doesn't
today. And itojun's point about IPSEC is important.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Nov 2000 13:12:07 -0600

>         - layer 4 port number pair (src/dst)

Correct. And that will be used by classifiers in both IntServ and DiffServ
implementations. 
>         - layer 4 port number pair

Only if we define a standard way of compressing the ports and protocol type
into the flow label.

>         value-adds of IPv6 against IPv4.

"Could be", not "is", unfortunately. It's very dangerous to use this as a sales
argument before it is actually true.

   Brian

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 28 Nov 2000 07:12:28 +0900

>Only if we define a standard way of compressing the ports and protocol type

	i don't think there needs to be a standard way.  if there's some
	pseudorandom and unique number in flow label field (as suggested in
	RFC2460) it is more than enough.

itjun

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Nov 2000 16:48:37 -0600

>    flow instead of requiring that it match the normal 5-tuple.

Just to make the point again: the 5-tuple has semantics that
allows a classifier to *classify* the traffic. Today at least,
the flow label has no such semantics - it's just plain bits.
That may help in IntServ but it's no use at all in DiffServ.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Nov 2000 17:42:25 -0600

>         RFC2460) it is more than enough.

No, not for diffserv and not for any solution where intserv is used only
somewhere downstream from the host. The classifier needs something
that *encodes* the ports and protocol, so that a QOS policy can
be applied. That's how QOS classifiers work; they can't use pseudorandom
numbers.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2000 10:21:38 -0600

{source address, destination address, source port, destination port, protocol number}

   Brian

Juan Fco Rodriguez Hervella wrote:
...
> Could anyone explain to me what is the "5-tuple" that I am hearing
> everywhere ?
>

---

From: Juan Fco Rodriguez Hervella <[email-masked]>
Date: Tue, 28 Nov 2000 10:08:16 +0100

Thanks.

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Nov 2000 14:16:45 -0500

Brian E Carpenter wrote:
> [...]

It also can be used by an ingress MPLS router to determine a Forwarding
Equivalence Class, 
when an unlabeled packet is being processed (and prepended the MPLS
label stack.)

Alex

---

From: [email-masked]
Date: Wed, 29 Nov 2000 10:31:57 +0900

>	RFC2460) it is more than enough.

	oops, what I meant here was:
	- router/RSVP device looks at full 5-tuple, on the first packet it sees,
	  and remember flow label value
		(need to chase extension headers)
	- for subsequent packets router/RSVP device will classify packets
	  based on flow label value
	there's no need for compression rule from 5-tuple to flow label
	(some other protocol may use something other than 5-tuple!)

	I admit that ESP case is tricky.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Nov 2000 10:24:53 -0600

itojun,

To be more precise, is that what you mean:

The box maintains a cache of currently active flow IDs.

For each arriving packet, it looks to see if the flow ID on that
packet is in the cache.

If no ==>  extract the 5-tuple, cache the flow ID and the 5-tuple, 
           then apply corresponding RSVP or diffserv action.

If yes ==> extract the 5-tuple from the cache,  
           then apply corresponding RSVP or diffserv action.

The problem is that for encrypted packets, the first step is impossible.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]
--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 30 Nov 2000 01:55:10 +0900

>           then apply corresponding RSVP or diffserv action.

	Basically yes.  To be even more precise, see below.  I have never
	talked about diffserv, but it should be possible to do something
	about diffserv.

>The problem is that for encrypted packets, the first step is impossible.

	yup.  but the impression I've got from existing specification is,
	flow label is for optimization (to avoid full 5-tuple lookup in
	intermediate router).  yes, ESP is a problem, but it always is a 
	problem for diffserv/intserv kind of work.

itojun

The originating node will fill flow label field (20 bit) with pseudorandom
value, as documented in RFC2460 appendix A.  The value will be same for a
"flow" - think of it as a TCP session (see my draft for a possible definition
of "flow").

Somewhere, we will have RSVP reservation running behind-the-scene.

Intermediate router has the following database:
  1. database of RSVP filter spec (basically 5 tuple) and RSVP flow spec
     (QoS parameters)
  2. cache table from flow label value, to RSVP flow spec.
When a packet comes into a intermediate router, the router will behave as
follows:
	look at flow label value, and look at database 2;
	if (we have an entry in database 2)
		we got an RSVP flow spec.
	else { /* if we do not have an entry in database 2 */
		chase header chain, obtain full 5 tuple.
		lookup database 1.
		if (we have an entry in database 1) {
			we got an RSVP flow spec.
			register flow label value and RSVP flow spec into
			database 2.  database 2 is a cache, so we can purge
			old entry if it is full.
		} else {
			we don't have an RSVP flow spec.
		}
	}

	forward packet based on RSVP flow spec we've got.

In short, flow label makes it easier for intermediate routers to lookup
QoS flow spec from a packet.
--------------------------------------------------------------------
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: Wed, 29 Nov 2000 13:40:01 -0600

itojun,

OK, I understand. However I would really like to find a solution
that works for ESP packets. The proposal in draft-conta-ipv6-flow-label-00.txt
isn't sufficient (it only conveys half a port number, and a general
purpose QOS classifier needs two port numbers). Also it doesn't
generate pseudo-uniqueness in the flow label, so the classifier
actually has to classify on {source @, dest @, flow label}.
That's not so bad, since it uses only fields at fixed header
locations. But the flow label doesn't contain enough bits
to convey {source port, destination port, protocol}.

    Brian

---

From: Ignatios Souvatzis <[email-masked]>
Date: Wed, 29 Nov 2000 22:08:09 +0100

On Wed, Nov 29, 2000 at 01:40:01PM -0600, Brian E Carpenter wrote:

> that works for ESP packets.

The basic idea about ESP is that we do not want to leak information. 
Putting port of it into the flow label is therefore not what we want to do.

Regards,
	-is

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Nov 2000 15:28:56 -0600

We would have to evaluate the risk (which I guess is traffic analysis)
versus the benefit (ability to provide QOS). That sounds like a
user decision to me.

   Brian

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 30 Nov 2000 10:58:30 +0100

> versus the benefit (ability to provide QOS). That sounds like a

Of course.

Which is, why I think intermediate routers will have to interpret flow labels
as magic cookies. Maybe changing them (I have no strong opinion about this),
maybe internally sorting them according to a flow label - address/protocol/port
mapping for unencrypted packets; but as protocol designers, we can't enforce
a static mapping, else we would make hiding of flow properties through ESP
impossible to the users.

Regards,
	-is