Brian,
What you propose below is already MUCH better. If you can achieve what you
think is needed for diffserv usage with that, I'm all for it.
0. You may want to REVERSE the usage of the MSB you suggested below:
presumably '00000' will need to remain to mean "best effort". This value has
the MSB as '0', and definitely is "non-unique value". Also, if '0' is used
for "non-unique value", then '00000' will likely match with the value for
the Default PHB?
See my comments below:
Brian E Carpenter wrote:
> How would people feel about this encoding for the flow label
> (deemed to be immutable end to end)?
>
> 0 1
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |0| Per-microflow unique value |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
1. so this should be the case where MSB = '1' (see my comment above)
2. Does NOT need to be a PRN
3. this case needs to be end-to-end immutable (to protect against router
failures and resulting state loss in a portion of a network; routers still
having the state would have the right value
The current (RFC2460 App.A) semantics does NOT require "microflow"
semantics, but only the IP addressing & routing aspects of the packets with
the same flow label need to be the same. I.e. same "flow" may include
different transport protocols and source and destination ports for each
packet. Presumably the flow label will be set by the source so that the
packets marked by the same flow label, however, belong logically to the same
"flow". Usually this would map 1:1 to a microflow. Therefore:
4. this should not be restricted to a "microflow", but the source may bundle
multiple microflows to the same "flow label"-flow, as long as they have the
same source address, destination address, and routing related option
headers.
5. the significance of this form of a flow label must be established
out-of-band (relative to the flow label itself), i.e. this kind of a flow
label does not carry any semantics by itself.
>
> 0 1
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |1| Non-unique value |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
6. so this should be the case where MSB = '0'
7. source & destination addresses, as well as any routing headers may have
different values for packets marked with the same flow label of this type.
8. values and their meanings are standardized, registered with IANA, no
local mapping! Routers may employ a number of methods to get the
configuration needed (INCLUDING signaling), this is admin.. domain specific.
9. this form is MUTABLE:
If the intention is to enable contractual aggregation needed by e.g. the
diffserv model, domain must be able to remark the value (change it), but
also the new value needs to be taken from the set of standardized values, so
that the semantics of the value is always unambiguous. The mutability allows
cutting off "freeloaders" (as put so eloquently by Steve Blake), and enables
the diffserv aggregation model.
10. This form may be further subdivided FOR ADMINISTRATIVE reasons. This
subdivision SHOULD have no HW/ASIC/NP classification code implications. The
highest nibble of '0' (bits: '0000') should be used for the PHB-ID name
space to utilize the all-zeroes == Default PHB == best effort semantics.
Four highest bits of '0111' could signify an administratively reserved name
space for the rest of the bits, but this should be IGNORED by HW/ASIC/NP
implementations implementing look-up.
11. IANA please: Do not use any of the reserved namespace for duplicating
any info in the transport headers (Maybe this should go in the IANA
considerations section :-)
12. Note that knowing the difference between the MSB 0/1 CAN be utilized by
HW implementations to ignore the addressing in the lookup for the
"non-unique" form.
> I'm not yet 100% convinced that the second case is sufficient for
> diffserv, but at least it would be a more generic approach
> than reserving half the space for diffserv.
>
I think we can have it both ways. This more generic definition should keep
all specifics of e.g. diffserv usage on the control plane, allowing people
to build generic HW classifiers, when the MSB is the only bit that affects
how other IP header fields ought to be used in the classification.
With regards,
Jarno
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
