Re: [Detnet] IPv6 encapsulation in dataplane doc

["Jouni" <[e-mail]>]

Hi Pascal,

 

Thanks for good input (again) and I agree in most parts – I do have
reservations for L4 solution since it would be per L4 protocol. One
clarification to my ”first point”. In my example the not-mentioned
assumption was that the edge node is the first node doing duplication &
elimination at the subnet/transport layer. If that DetNet subnet/transport
layer can extended all way to end systems (like with current TSN in 802.1
space) then some of the issues are relaxed.

 

 

-          Jouni

 

From: Pascal Thubert (pthubert) [mailto:[e-mail]] 
Sent: Thursday, February 8, 2018 12:46 PM
To: Jouni <[e-mail]>; 'Lou Berger' <[e-mail]>;
[e-mail]
Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc

 

I fully agree, Jouni ;

 

For your first point: In the case of wireless, PRP (a form of PREF) is a
critical feature for industrial deployments; this is shipping and deployed
today. The link that needs protection the most is the first hop (the UNI
from/to the device) since it is over Wi-Fi. If the PREF starts at the
network edge (say the controller), then most of the benefit is lost. So
DetNet must enable E2E Services, in particular over IPv4 which is dominant
in industrial use cases. What DetNet could bring to the art could that a
single wireless transmission received by 2 APs end up on 2 parallel
end-to-end paths.

 

For your second point: there are a number of potential issues if the
sequencing is not done by the source end point. If a packet is received at
one edge and not at another, then the sequences will differ over the 2 paths
and reconciliation will be impossible. Packets received out of order at the
ingress will be delivered out of order at the egress meaning that whatever
support for in-order-delivery (IOD) is defeated.

 

My conclusion is that the end points must contribute to the effort. They
must stream the data at a reasonable pace, and if Service Layer functions
are expected from the network,  they really should indicate the flow ID and
the sequence number from their perspective.

 

Now what can we expect from current end points? 

 

-          Existing industrial devices can claim a rough need for a given
rate but were not necessarily designed to provide guarantees for burstiness
in DetNet terms. Failure to comply to DetNet terms may cause
loss/reclassification by ingress filtering in the edge router, which would
defeat one purpose of DetNet for reliability. For a close-to-acceptable
sources, one can imagine a jitter absorption feature at the DetNet ingress
edge router. But that also mean an additional latency, which may defeat
another purpose of DetNet of in-time-delivery.

-          TCP is adverse to DetNet, and will not maintain the optimal rate;
in any case, the sense of sequence that can be inferred from the offset can
be defeated by retries.  In order to support TCP endpoints, one would
probably need to devise a L4-proxy function (ala DLSW) that terminates TCP
at the ingress edge and maps it into something more DetNet friendly.

-          UDP does not provide sequencing information - this is probably
the use case for the DetNet Destination Option in the inner header.

-          Arguably RTP can signal both flow and sequence, but does not have
network coding, does not expect multipath, and I’m not sure if the rate
control work has gone beyond the research papers. Then again, packets may be
lost or reclassified at the ingress edge.

-          This leaves rate control (e.g. adaptive bitrate streaming) to the
application layer (typically over HTTP), meaning that each application as to
cover for the network deficiencies in its own ways. Which is sad because it
adds complexity to each and every application, a complexity that is not the
core business of the app and could be handled in common at a lower layer. 

 

DetNet has the power to simplify the application, remove jitter recovery
buffers and the like, by transporting the near-perfect rate in near-perfect
time.  It would be better that the end points contribution happens without
impacting each and every time sensitive application, by providing DetNet
Service Layer functionality at the L4 transport.

 

Flow identification (by port), IOD and duplicate elimination are classical
L4-transport features (e.g. TCP). MP-TCP already distributes packets over
different paths. It is not a gigantic conceptual step to place DetNet
Service Layer features in a L4 transport. If a DetNet friendly transport -to
be designed- adds DetNet Service Layer capabilities like PREF and/or network
coding in the end points, 2 parallel DetNet Transport Layer circuits based
on the discussion at the interim would enable the end-to-end service without
knowing it. So ‘d say that the proposal is still useful, but depends on L4
transport capabilities that would be fully transparent to the DetNet
signaling and would not use the Destination Option. 

 

Alternatively, say we want DetNet to provide the S-level functions, e.g.
PREF. Considering that we expect that an edge router can read the ports,
then it can figure what the L4 transport can be recognized and that for some
transports, e.g. RTP and the suggested new transport, the edge router can
derive a sequence from the transport header in a non-ambiguous way. 

 

All the best,

 

Pascal

 

From: Jouni [mailto:[e-mail]] 
Sent: jeudi 8 février 2018 10:08
To: 'Lou Berger' <[e-mail] <mailto:[e-mail]> >; Pascal
Thubert (pthubert) <[e-mail] <mailto:[e-mail]> >;
[e-mail] <mailto:[e-mail]> 
Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc

 

Hi,

 

Yes, we discussed this to an extent in the last call. I’ve been thinking
this a bit more lately (cross country skiing conditions have been great thus
you got a lot of time while on the skiing tracks ;) Few concerns/points to
think I see here are:

* End systems cannot participate to DetNet service layer packet elimination
& duplication business. If they still do e.g. using DetNet DstOpt that is
separate from subnet/transport layer provided service.

* Different subnet/transport layer segments in the DetNet domain are likely
to use their own sequencing and duplication & elimination solutions. I am
not sure how independent those will be e.g., is the sequence numbering
unified across or only per segment. The former is not IMO easy and the
latter easily reduces to single points between segments to handle number
book keeping properly.  

 

Regardless the above I am keen to explore this alternative approach..

 

-          Jouni

 

 

From: detnet [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: Wednesday, February 7, 2018 17:00 PM
To: Pascal Thubert (pthubert) <[e-mail]
<mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc

 

Pascal/all,

At the last interim a proposal was made to simplify IP processing, at least
for the initial detnet solution, by leaving PREF to the subnet/transport
layers (i.e., TSN and MPLS) and providing DetNet flow identification based
on typical IP 5-tuple perhaps + dscp. This approach has several benefits
beyond simplification, notably it will work for both ipv4 and IPv6, and
doesn't require any modification to encapsulation / formats.

It would be really valuable to get feedback from the whole working group if
this simplification is acceptable or has unacceptable limitations.

Lou

On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)"
<[e-mail] <mailto:[e-mail]> > wrote:

Dear all

 

This is about the IPv6 encapsulation and more precisely

 

                        Therefore, if a DetNet-aware end system only
   inserted the DetNet Destination Option into the IPv6 but e.g., a
   DetNet Edge node is configured to enforce an explicit route for the
   IPv6 packet using a source routing header, then it has no other
   possibility than add an outer tunneling IPv6 header with required
   extension headers in it.  The processing of IPv6 packets in a DetNet
   Edge node is discussed further in Section 6.4.1
<https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01#section-6.4.1> .

 

 

With the current spec, a source sends a DetNet packet as

 

                    +---------------------------------+

                    |                                 |

                    |           DetNet Flow           |

                    |             Payload             |

                    |                                 |

                    /---------------------------------\

                    H   Optional DetNet DstOpt Hdr    H

                    \---------------------------------/

                    |          IPv6 header            |

                    |     (with set Flow label)       |

                    +---------------------------------+

 

And then the ingress node needs to re-encapsulate as

 
                    +---------------------------------+
                    |                                 |
                    |           DetNet Flow           |
                    |             Payload             |
                    |                                 |
                    /---------------------------------\
                    H        DetNet DstOpt Hdr        H

                    \---------------------------------/

                    |          IPv6 header            |

                    |     (with set Flow label)       |

                    +=================================+

                    |          Routing header         |
                    /---------------------------------\
                    H        DetNet DstOpt Hdr        H
                    \---------------------------------/
                    |          IPv6 header            |
                    |     (with set Flow label)       |
                    +---------------------------------+

 

This creates a duplication of the DetNet Destination Option.

 

There are alternatives 

 

a)  whereby the packet is tunneled from the source to the detnet ingress,
and based on its state the DetNet ingress accepts the packet, processes it
and then resends it. The tunneled version of this could be:

 

                    +---------------------------------+

                    |                                 |

                    |           DetNet Flow           |

                    |             Payload             |

                    |                                 |

                    +---------------------------------+

                    |          IPv6 header            |

                    |   (dest = final destination)    |

                    /=================================\

                    H   Optional DetNet DstOpt Hdr    H

                    \---------------------------------/

                    |          IPv6 header            |

                    |   (dest = DetNet ingress edge)  |

                    |     (with set Flow label)       |

                    +---------------------------------+

 

Which allows the ingress to tunnel to the egress as follows:

                    +---------------------------------+

                    |                                 |

                    |           DetNet Flow           |

                    |             Payload             |

                    |                                 |

                    +---------------------------------+

                    |          IPv6 header            |

                    |      (to final destination)     |

                    +=================================+

                    |          Routing header         |
                    /---------------------------------\

                    H   Optional DetNet DstOpt Hdr    H

                    \---------------------------------/

                    |          IPv6 header            |

                    |   (dest = DetNet egress edge)   |

                    |     (with set Flow label)       |

                    +---------------------------------+

 

 

b)  whereby the PREF is done by the end nodes and the tunnel is transport
only, meaning that there are 2 tunnels A and B and that the source sends
twice a packet like this:

 

                    +---------------------------------+

                    |                                 |

                    |           DetNet Flow           |

                    |             Payload             |

                    |                                 |

                    /---------------------------------\

                    H   Optional DetNet DstOpt Hdr    H

                    \---------------------------------/

                    |          IPv6 header            |

                    |   (dest = DetNet ingress edge X)|

                    |     (with set Flow label)       |

                    +---------------------------------+

 

And then the ingress node needs to re-encapsulate as

 
                    +---------------------------------+
                    |                                 |
                    |           DetNet Flow           |
                    |             Payload             |
                    |                                 |
                    /---------------------------------\
                    H        DetNet DstOpt Hdr        H

                    \---------------------------------/

                    |          IPv6 header            |

                    |   (dest = final destination)    |

                    |     (with set Flow label)       |

                    +=================================+

                    |          Routing header         |
                    +---------------------------------+
                    |          IPv6 header            |
                    |   (dest = DetNet egress edge X) |
                    |     (with set Flow label)       |
                    +---------------------------------+

 

Cheers,

 

Pascal

_______________________________________________
detnet mailing list
[e-mail] <mailto:detnet%40ietf.org> 
https://www.ietf.org/mailman/listinfo/detnet