Re: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS

FWIW, there are already IPv4 option codepoints assigned for experiments, 
provided they're deployed in a controlled environment (i.e., can be 
cleaned up when the experiment is over). See RFC4727.

If a more permanent option number is assigned, a standards-track doc 
might be required*, but this might need to go the route of a temporary, 
controlled experiment first anyway.

Joe

*IANA's registry doesn't talk about the level of review required for an 
IPv4 option codepoint, but I would assume it's at least as difficult to 
get as a persistent TCP option codepoint.

On 2/12/2014 2:06 PM, Fred Baker (fred) wrote:
>
> On Feb 12, 2014, at 9:43 AM, sajjad akbar <sajjad_akr@yahoo.com> wrote:
>
>>   Thanks for referring the RFC. I just go through to it, yes, there may be issue of acceptability for OPTION headers.
>>
>> However, OPTION headers provides opportunity to pass some information to the networks. For the proof of concepts, we can do this until to explore a new way :)to survive FlowLable information.
>
> I see no problem with specifying an experimental flow label option in IPv4. I'd suggest that you write an 'experimental' internet draft and get an option number from IANA using the usual procedures. It will likely need to be run through the Independent Submissions Editor, as the IETF is not currently working on significant enhancements to IPv4.
>
> It may be simpler for you to get IPv6 service on the network path in question, however. If you're going to the effort to put the flow label into a tunnel header, I have to believe that you plan to in some way use that optional information, and you will need to specify and implement that as well. It seems, frankly, like a diversion of effort; you have more to show at the end of the experiment if it's in IPv6 and you can recommend deployment.
>
>> looking forward for comments.
>>
>> Regards
>> Sajjad
>> Team Lead IPv6 Project
>> Pakistan
>>
>>
>>
>>
>>
>> On Wednesday, February 12, 2014 8:38 PM, joel jaeggli <joelja@bogus.com> wrote:
>> On 2/12/14, 6:42 AM, sajjad akbar wrote:
>>>
>>>
>>> Dear fellows
>>>
>>> We are working on 2 year funded project "Design and Development of Hybrid IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Application" in Pakistan under research group CoReNeT (www.corenet.edu.pk). loss
>>> Flowlabel information lost in case of tunneling and translation as IPv4 header does not have such QoS field. We have design an algorithm which stores Flowlabel information in IPv4 header.For storage we use the OPTION field of IPv4(24 bit long).Further, each intermediate router (IPv4 only)will extract the Flowlable information and will provide flow base service to a long session of multimedia communication.
>>>
>>> Please guide us in this regard that either our direction is right or you suggest some modification.
>>
>> new IP options don't have a good history with respect to acceptance by
>> the network.
>>
>> http://tools.ietf.org/html/rfc7126#section-3
>>
>>
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> If at first the idea is not absurd, then there is no hope for it.
> Albert Einstein
>
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>