Jason, As co-chair of the diffserv WG, and co-author of the flow label draft, I assure you that your interpretation is incorrect in both cases. Brian Jason Gao wrote: > > > Jason Gao wrote: > > > > > > > Jason Gao wrote: > > > > ... > > > > > --- IPv6 flow label assignment > > > > > > > > > > Transport layer may set a 'control' bit in the IPv6 Traffic Class octet of the initiating packet > > > > > during the setup phase of a connection. > > > > > > > > > > > > > > > > > > > > The edge router inspects the control bit. If it is set, the edge router can further inspect the > > > > > packet, and reserve resource as required by the piggybacked resource reservation header in the > > > > > transport layer packet, allocate and/or assign a flow label to the expected connection, put the flow > > > > > label in the flow label field of the initiating acknowledgement packet. > > > > > > > > No. There is no such usage of the traffic class octet. See RFC 2474. > > > > Also, only the source host of a packet may set the flow label. > > > > See draft-ietf-ipv6-flow-label-03.txt > > > > > > > > Brian > > > > > > > Well, both the draft and RFC 2474 are not the final standard. > > > > RFC 2474 is a Proposed Standard, which means that fundamental > > changes are extremely unlikely. The flow label draft is indeed > > still a draft, but there is very strong WG consensus that flow > > labels must be immutable. > > draft-ietf-ipv6-flow-label-02.txt didn't specify a signaling protocol for the host /end-system and the router / intermediate system to negotiate / assign flow label. The draft said: > > > > " > > The assignment of a packet to a flow takes various forms, presented > > below: > > > > (1) The source MAY take part in a signaling protocol that results in > > assigning certain transport connection(s) or application data > > stream(s) to specific flow(s). > > > > (2) The source MAY be configured to assign certain transport > > connection(s) or application data stream(s) to specific flow(s). > > > > (3) The source SHOULD assign each new application data stream (e.g. > > RTP streams) to a new flow. > > > > (4) The source SHOULD assign each new transport connection (e.g. > > TCP, SCTP) to a new flow. > > " > > > > As: > > --- Yet no standard signaling protocol exists to negotiate the flow label. > > --- If end nodes behave as (3) and (4) require, each new application data stream or new transport connection should need a new flow, it is very likely that before or along with the negotiation of a new transport connection, end nodes also take part in a process of negotiating new flow label, if a signaling protocol is used. > > > > And if we apply fuzzy-layering practices, we may find it is quite convenient to piggy-back the flow-label negotiation signals on the negotiation packets during the setup phase of the transport connection. > > > > We can still require that the flow labels must be immutable after the connection is successfully setup. > > > > > > And both the traffic class octet and the flow label field are subject to further discuss. > > > > If you are referring to the text in RFC 2460, the traffic class is > > definitively specified by RFC 2474. The flow label draft is intended > > to be definitive, as soon as it's agreed. > > > > Brian > > > > > RFC 2474 not only left two pools of codepoint space for experimental / local use but also left the code point number in the pool of 'standards action' unassigned. So I don't think it is definitive. I mean it did not prohibit the use of one bit in the traffic class octet for control purpose. > > Jason. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland