Re: [Softwires] ECN [4rd-U complement - e2e transparency to IPv4 TOS]

[Rémi Després <[e-mail]>]

Le 18 oct. 2011 à 22:01, Brian E Carpenter a écrit :

> On 2011-10-18 19:55, Rémi Després wrote:
>> Le 17 oct. 2011 à 22:17, Brian E Carpenter a écrit :
>> 
>>> On 2011-10-18 01:36, Rémi Després wrote:
>>>> Hi Satoru-san,
>>>> 
>>>> Thank you for identifying a limitation of the 4rd-U  
>>>> You are right, as currently specified, "it doesn't support diff-serv tunneling model, pipe and short-pipe".
>>>> All these need e2e transparency to the IPv4 Type of Service.
>>>> 
>>>> Fortunately, this is easy to fix:
>> 
>> *
>>>> in the Identification field of the IPv6 Fragment header, copy not only the DF bits but also the IPv4 TOS.
>> *
>> 
>>> Will this cause any difficulties for ECN, if ECN is supported on the IPv6
>>> leg of the journey?
>> 
>> Not in my understanding.
>> Since the IPv4 TOS is copied in the Identification field of the IPv6 Fragment header, it will be restored at exit of the IPv6 leg independently of any MPLS and ECN that may be used in that leg.
> 
> That's my problem. If the IPv6 leg supports ECN, any change to the ECN bits
> during the IPv6 journey will be lost, so the end systems will not be informed
> about congestion. I think the ECN bits need to be copied to and from the IPv6
> Traffic Class.

Thanks for the clarification.
Whether ECN is deployed or not is beyond my current knowledge, but I now understand that this issue exists, and is applicable to 4rd-U as it is to encapsulation. 

>>> Apart from that, please remember that the DSCP part of the DS Field is not an
>>> end-to-end field; it is mutable.
>> 
>>> I advise applying the relevant considerations
>>> from Sections 4.1 and 5.1 of RFC 6145.
>> 
>> This isn't necessary because RFC 6145 is about Translation, while 4rd-U, with the above between asterisks, precisely avoids translations between IPv4 TOS and IPv6 Traffic. 
>> In this respect, is more like 4rd Encapsulation than like 4rd Translation.
> 
> Firstly, that means that any diffserv treatment specified for the IPv4 packet is
> missed during the IPv6 journey. So as for ECN, the IPv4 DSCP value should probably
> be copied into the the IPv6 traffic class.

Using the same field for ECN and for QoS differentiation seems to me a source of difficulty.
A minimal approach seems to be treating IPv6-domain traversal as just one link traversal.   


> Second, as discussed in RFC 6145 section 5.1,
> the diffserv code point might be rewritten at the exit from IPv6.

> Please also see the extensive discussion about diffserv and tunnels in RFC 2983.
> Actually the treatment in RFC 6145 was supposed to be roughly equivalent to RFC 2983.

Thanks for the reference.

Regards,
RD