Michael Thomas wrote:
>
> Brian E Carpenter writes:
> > The issue is that if the packet is classified prior to being
> > encrypted, what do you do if a downstream ISP declines to
> > believe the classification (DCSP value) and wishes to reclassify
> > the packet? The proposal is to put enough semantics in the flow
> > label to allow some degree of classification.
>
> I'm sorry, but this sounds like you're approaching the
> problem backward. If you want transport friendliness so
> that you can reclassify packets, you should beat up on
> the Ipsec WG to revive the transport friendly ESP as
> working group item. Trying to jam the relevant transport
> header into a 20 bit field sounds like a *way* losing
> proposition which has a zero percent possibility of being
> future proof. It's bad enough that we have these middle
> boxes trying to look at L4+ headers, but trying to
> *replicate* data into an obviously too small field for
> every unknown and uninvented protocol going forward...
> ick.
>
The problem is simple, in spite of all the twists and spins.
You need to identify flows, and for that you use some fields in the
network header and/or host-to-host header. Reviving the transport
friendly ESP would do only partial good, since the problem of
walking though all the extension headers remains.
And thus, the validity of the request to have the flow label available
for all IP QoS, including Diffserv, remains.
Alex
S/MIME Cryptographic Signature
