>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.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
