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

Thanks for sharing your concerns and suggestions. I have discussed your feedback with Dr.Amir Qayyum (Project Director)as well. Yes, its not an easy task to do as currently IETF is not working on IPv4 enhancement. We can go for "experimental" Internet draft as well.

Following is another way to do the same task

As for IPv6 transition phase, FlowLabel information is discarded for translation and tunneling. Here, we can use OPTION field plus take help from MPLS enable routers for flow base forwarding. So, this solution will work on MPLS enable routers. In this way, we may reduce the forwarding overheads. For such implementation, we may claim that for IPv6 transition phase, the FlowLabel information will not lost in case of translation and tunneling. 

Looking forward for your comments.

Regards
Sajjad (IPv6 project)
CoReNeT research group

On Thursday, February 13, 2014 3:06 AM, Fred Baker (fred) <fred@cisco.com> 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
>
>
>
>
>
>
>