Subject: flow label usage?

From: Yong Lucy <[email-masked]>
Date: Wed, 28 Jul 2010 06:58:41 -0500

What is flow label usage?

IMO: it enforces that a set of packets with the same flow label has to be
carried through the networks in the same path or belong to the same
application at host. Is that correct? Is there other usage of flow label?

Regards,

Lucy

---

From: Shane Amante <[email-masked]>
Date: Wed, 28 Jul 2010 14:24:12 +0200

Lucy,

On Jul 28, 2010, at 13:58 GMT+02:00, Yong Lucy wrote:
> IMO: it enforces that a set of packets with the same flow label has to be carried through the networks in the same path or belong to the same application at host. Is that correct?

That appears to be a commonly held view, although that's (perhaps) not completely clear in RFC 3697.

> Is there other usage of flow label?

Please refer to the following draft, which appears to comprehensively document all of the proposals (thus far) on _potential_ uses of the IPv6 flow-label:
http://tools.ietf.org/html/draft-hu-flow-label-cases-00
... however, I would note the word "proposal".  AFAIK, none of these proposals have been deployed in the Internet, (but, may have enjoyed deployment in a closed lab environment and/or campus network for 'experimental' purposes in some cases).

-shane

>  
> Regards,
> Lucy
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Wed, 28 Jul 2010 14:32:37 +0200

Lucy,

On Jul 28, 2010, at 1:58 PM, Yong Lucy wrote:

> IMO: it enforces that a set of packets with the same flow label has to be carried through the networks in the same path or belong to the same application at host. Is that correct? Is there other usage of flow label?

RFC 3697 defines it as:

   A flow is a sequence of packets sent from a particular source to a
   particular unicast, anycast, or multicast destination that the source
   desires to label as a flow.  A flow could consist of all packets in a
   specific transport connection or a media stream.  However, a flow is
   not necessarily 1:1 mapped to a transport connection.

It is intended to label a flow.  It does not specify a path.

Bob

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Jul 2010 21:14:21 +0200

> IMO: it enforces that a set of packets with the same flow label has to be carried through the networks in the same path or belong to the same application at host. Is that correct? Is there other us…

My understanding is that it labels a flow. If the right way to carry a flow is distributed across two network paths, so be it. BTW, a "flow" has many definitions; the type of flow that Tony was mentioning this morning is a single application session; to an ISP, a flow is a stream of traffic from an ingress to an egress, or perhaps the stream of traffic from an ingress to an egress via a path. This means that the IPv6 Working Group wants the flow label to be a hash that helps the network find status for a specific session's or set of sessions' shared' state, while to an ISP it wants to be independent of the source address - associated with the ingress router.

RFC 1710, the original specification for what later because IPv6, said of the flow label:

   The Flow Label field in the SIPP header may be used by a host to
   label those packets for which it requests special handling by SIPP
   routers, such as non-default quality of service or "real-time"
   service.  This labeling is important in order to support applications
   which require some degree of consistent throughput, delay, and/or
   jitter.  The Flow Label is a 28-bit field, internally structured into
   three subfields as follows:

RFC 1752 agreed:

   * Flow Label - This field may be used by a host to label those
     packets for which it is requesting special handling by routers
     within a network, such as non-default quality of service or "real-
     time" service. (28-bit field)

RFC 2460 reads:

      o  Flow Labeling Capability

         A new capability is added to enable the labeling of packets
         belonging to particular traffic "flows" for which the sender
         requests special handling, such as non-default quality of
         service or "real-time" service.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 28 Jul 2010 14:33:56 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 

> My understanding is that it labels a flow. If the right way 
> to carry a flow is distributed across two network paths, so 
> be it. BTW, a "flow" has many definitions; the type of flow 
> that Tony was mentioning this morning is a single application 
> session; to an ISP, a flow is a stream of traffic from an 
> ingress to an egress, or perhaps the stream of traffic from 
> an ingress to an egress via a path. This means that the IPv6 
> Working Group wants the flow label to be a hash that helps 
> the network find status for a specific session's or set of 
> sessions' shared' state, while to an ISP it wants to be 
> independent of the source address - associated with the 
> ingress router.
> 
> 

But didn't we determine in a long thread that such uses by routers were not very robust, because there is no header checksum to protect that flow label?

If I want to use flow label end-to-end, any rule that says that flow label is immutable unless set to zero becomes ambiguous. At the destination host, I would have no idea whether the source host set the label, or whether a router along the path set the label.

But I understand that is how they ARE being used now, so I guess the point becomes moot.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jul 2010 13:49:50 +1200

> It is intended to label a flow.  It does not specify a path.

And that was *not* an oversight by the authors or the WG. On the
contrary, RFC 3697 intentionally did not define any usage model
for the flow label, or even a purpose. It was limited to defining
the behaviour of source hosts.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Jul 2010 09:13:06 +0200

Brian,

> the behaviour of source hosts.

Yes, I agree.

Bob

---

From: Yong Lucy <[email-masked]>
Date: Thu, 29 Jul 2010 03:24:48 -0500

[LY] "a particular source" can be host or network device, is that right?

---

From: Brian Haberman <[email-masked]>
Date: Thu, 29 Jul 2010 04:51:38 -0400

> [LY] "a particular source" can be host or network device, is that right?

My interpretation is that the "particular source" is the source of the
data packet.  That is, the IPv6 node identified by the source address of
the packet.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jul 2010 09:27:34 +1200

> On 7/29/10 4:24 AM, Yong Lucy wrote:

...
> data packet.  That is, the IPv6 node identified by the source address of

Exactly. In the case of a tunnel, and for the outer header, this means the
encapsulating tunnel end point, not the source of the encapsulated packet.

    Brian