In your previous mail you wrote:
Unfortunately I think the extension header mechanism is probably
too heavy as Francis says, but I want to think a bit longer about
that (and re-read kre's last message and some of Jarno's messages).
=> this is heavy but we can do more with this than with 20 bits,
in fact we can do more with this than with protocol/ports (*)...
The basic idea is to make (still unknown) avantages greater than
(already known) drawbacks.
Regards
[EMAIL PROTECTED]
(*) I have two different kinds of ideas about this:
- first I don't fully understand what ISPs will do with protocol/ports
because SLAs are not signaling: rules will be very coarse like
"remark TCP port 80 to lower than best effort"... Perhaps protocol/ports
are not designed for classification (:-). Of course, to pack them into
20 bits (or less!) won't make these field more useful!
- if we use available bits with a better semantics both we need less
(even less than 20 bits because we deal with macro flows in Diffserv
but look at the last point) and we can do more with them, for instance
code a stack of DSCPs (a good solution for the rewrite/restore issue).
- a destination option (in a header just after the IPv6 header or
the hop-by-hop/please-use-the-slow-path header) provides a lot of bits
and is expandable, in fact it can (i.e. should) be expandable on the
fly: a stack of annotations for classification? MTU is not a real issue
because backbones have already larger MTUs than edge networks for
other reasons, the last edge router just needs to cleanup the stack.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
