Re: Fuzzy-layering and its suggestion - Towards better QoS solution in the IPv6 network

["Jason Gao" <[e-mail]>]

> 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.