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

From: sajjad akbar <[email-masked]>
Date: Wed, 12 Feb 2014 06:42:56 -0800 (PST)

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.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 12 Feb 2014 07:38:18 -0800

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: sajjad akbar <[email-masked]>
Date: Wed, 12 Feb 2014 09:43:46 -0800 (PST)

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. 

looking forward for comments.

Regards
Sajjad 
Team Lead IPv6 Project
Pakistan

On Wednesday, February 12, 2014 8:38 PM, joel jaeggli <[email-masked]> wrote:

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 12 Feb 2014 22:06:28 +0000

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

> http://tools.ietf.org/html/rfc7126#section-3

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein

---

From: sajjad akbar <[email-masked]>
Date: Thu, 13 Feb 2014 04:09:52 -0800 (PST)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Feb 2014 07:52:20 +1300

There is already https://datatracker.ietf.org/doc/draft-dreibholz-ipv4-flowlabel/

However, RFC 6437 already makes it acceptable to apply a new flow
label at a suitable point such as the exit from a v4 to v6
translator.

Regards
   Brian

On 13/02/2014 11:06, Fred Baker (fred) wrote:
> ------------------------------------------------------------------------
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 14 Feb 2014 13:29:20 -0800

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.