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.