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