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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 13 February 2014 18:52 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8741A03E4 for <v6ops@ietfa.amsl.com>; Thu, 13 Feb 2014 10:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv5PxPMJvgxW for <v6ops@ietfa.amsl.com>; Thu, 13 Feb 2014 10:52:18 -0800 (PST)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B8AB21A03FA for <v6ops@ietf.org>; Thu, 13 Feb 2014 10:52:15 -0800 (PST)
Received: by mail-pa0-f53.google.com with SMTP id lj1so11092156pab.26 for <v6ops@ietf.org>; Thu, 13 Feb 2014 10:52:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RFBpBkQ4+2EERBJIzvEgExWDv2ssTItXZUZkKbPLbhY=; b=ZfmvCa33HZfmmcwNjiGB4KdrN7Y245QrWimgl9JL8RegtFqOHa+nAupc4RBCe7KMd5 D+t0Bk8Pjn3GE33b30d7hI+jg+o1s2PVXbQvBO2UlT32uKro0o5gFd2INtrDBQDirwpp OLyJ3zRbH7ZrYBfzySEcM42rl+a1iosJlJPWVZuTO4T3y2u/V9X51d4XuratA36BW3b4 Exp2XLPVU6pFdF42VM0yPKDrCn5gnZw6bc6j/+66uSwqG3OiYh1ih0z9v4xvMqQJbAg9 YTUizBel144IzljhU/RdzOnMJqGFhvfr3o6lrZ5jb4BpiciKbcgjhIWlrJOYvXEM7OOT IXWQ==
X-Received: by 10.66.179.143 with SMTP id dg15mr3714914pac.52.1392317534644; Thu, 13 Feb 2014 10:52:14 -0800 (PST)
Received: from [192.168.1.115] (222-154-169-111.jetstream.xtra.co.nz. [222.154.169.111]) by mx.google.com with ESMTPSA id vf7sm9060160pbc.5.2014.02.13.10.52.11 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 10:52:13 -0800 (PST)
Message-ID: <52FD1464.2010803@gmail.com>
Date: Fri, 14 Feb 2014 07:52:20 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
References: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> <52FB956A.8010402@bogus.com> <1392227026.8043.YahooMailNeo@web125106.mail.ne1.yahoo.com> <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com>
In-Reply-To: <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4IIpXEfUm4qPacfcW0Wius3mlrI
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 18:52:20 -0000

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