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

[Brian E Carpenter <[e-mail]>]

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