Subject: RE: Usage of IPv6 flow label

From: "Thomas Eklund" <[email-masked]>
Date: Fri, 1 Dec 2000 12:21:16 +0100

Jim,
those end-to-end customers you refer do they have a service provider that
can deliver their voice/video application all the way from the source to the
destination without having to go through a transit provider? (Most of the
3GPP ISP cant)

If not I dont see how the flow label could have a unique definition along
several service providers. Then you will have to integrate your RSVP
signalling from operator a to b and c and d and so forth and then we are
back to the old scaling problem with RSVP.

What I think they want is a combination of a per flow semantics in the
access because  a flow label only make sense there where it identifies a
flow (TCP/UDP session).

In the backbone the service provider wants to control his network and do
traffic engineering for protection and restoration issues and to load
balance the traffic in the backbone (goeas for both a mesh based or a ring
based topology) and the only way to do this today is to use the mpls flow
label. But in the backbone the flow label means that the routers have a
chance to map incoming traffic onto a mpls tag which is just a traffic
trunk - in other words do not confuse it with the session identifier that it
represents in the access.

So I want a dual semantic
- per session identifier in the access
- per traffic trunk identifier in the core

And regarding diffserv and mpls. mpls optimizes the resources in a domain
and do traffic engineering and load balancing etc depending on how flashy
implementation you have. Diffserv on the other hand is per hop which is more
a tool to optimize the router buffers according to the Qos model you chosse
to you configure in your router. Diffserv though is a very nice QoS
mechanism that is so generic that anything can me mapped onto it (mpls,
intserv etc).

But it is very unclear how you use diffserv over an entire domain (some
people might clame that COPS is a solution - other do not)... Someone might
ask whats the relationship between DSCP (per traffic trunk, 2^6) and flow
label (per traffic class, 2^20) etc...

-- thomas

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Bound
> Sent: den 27 november 2000 15:00
> To: Francis Dupont
> Cc: Jim Bound; Alex Conta; Steve Deering; Michael Thomas; Jun-ichiro
> itojun Hagino; Hesham Soliman (EPA); Metzler Jochen; Ipng (E-Mail);
> [email-masked]
> Subject: Re: Usage of IPv6 flow label
>
>
>
>    >
>    >=> 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.
>
>    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.
>
> 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.
>
>   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.
>
> This is discussable and you must not have read my mail to
> Thomas Eklund.
>
>    Which is a good piece of work and I agree with Itojun's
> presentation of
>    the flowlabel.  Its set by the end node.
>
> >=> 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
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>

--------------------------------------------------------------------
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: Fri, 1 Dec 2000 07:35:53 -0800 (PST)

> back to the old scaling problem with RSVP.

   1) RSVP across multiple providers doesn't require write access
      to the five-tuple, so I don't see why it would require access
      to the flow label either. Sounds like you're conflating it
      with DSCP rewriting
   2) Check out the RSVP aggregation work. 
 
		Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Dec 2000 10:38:08 -0600

Thomas Eklund wrote:
..
> label (per traffic class, 2^20) etc...

There are several misunderstandings of diffserv here.

There is nothing about "traffic trunks" in the diffserv model. At a stretch,
you can think of a DSCP as labelling a "service class", but formally
it simply labels a "traffic aggregate", i.e. all the traffic that receives
the same QOS treatment on a given hop. However, we *do* assume in the
model that DSCP values are invariant across an entire domain, with the
routers in the domain being centrally configured. That configuration
may be done using COPS, or SNMP, or HTTP, or telnet, or by telefax
for that matter - it's of no importance for this discussion.

DSCP mutability applies at diffserv domain boundaries, which will
typically be ISP/ISP boundaries or customet/ISP boundaries.

As of today, there is *no* defined relationship between DSCP and
Flow Label. But I tend to agree with Jim that defining the Flow Label
as immutable across domain boundaries (as well as being visible
in encrypted packets) has distinct advantages.

   Brian

---

From: Jim Bound <[email-masked]>
Date: Fri, 01 Dec 2000 12:53:52 -0500

Thomas,

>destination without having to go through a transit provider? (Most of the

Some yes as they control completely their Internet (which is also mobile
and an interesting property).  But most have the $$$$$$$$ to force the
SLAs yes.

/jim