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 PROTECTED]
> [mailto:[EMAIL PROTECTED]]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 PROTECTED]
> 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 PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
