Brian,
I am a bit puzzled by your reference to the 5 tuple as "enabling diffserv."
I think you have a model there in which the diffserv bits are set by some
intermediate router, after examining the "5 tuple" of the packet. In this
context, the five-tuple works somewhat. But it does not work well with IPSEC
(ports are hidden), it does not work well with floating port applications
such as VoIP, and it leads to some interesting header manipulation when we
encounter stacks of IPv6 headers.
There are at least two other ways to "enable diffserv." One way would be to
just let the hosts set the diffserv bits, and then let the intermediate
router do accounting, charging, and maybe rationing. Another way is to use
RSVP to convey the requested quality of service, and the user credentials,
to the intermediate routers; then, the flow-id can be use for flow
classification, and the intermediate routers can on this basis set the
diffserv bits however they see fit.
-- Christian Huitema
> -----Original Message-----
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 27, 2000 2:49 PM
> To: Michael Thomas
> Cc: Jim Bound; Ipng (E-Mail)
> Subject: Re: Usage of IPv6 flow label
>
>
> Michael Thomas wrote:
> >
> > Brian E Carpenter writes:
> > > Jim,
> > >
> > > It still isn't clear to me what the flow label adds to
> the semantics
> > > 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.
>
> 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
> --------------------------------------------------------------------
> 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]
--------------------------------------------------------------------
