1. DetNet Data Plane Discussion
Jouni Korhonen
IETF 97 – Seoul, Korea

2. Background
In IETF 94 there was a “teaser” presentation of a PW-based data plane for DetNet.
See slides-94-detnet-4.pdf
Design Team looked into a number of DetNet Data Plane Protocol and Solution Alternatives.
See Draft-ietf-detnet-dp-alt-00
This presentation looks into a possible data plane solution based on the current Design Team input.

3. Background from IETF #96 Currently outside the scope of the draft.
PseudoWire
PseudoWire
RTP/UDP
Options:
MPLS LSPs
IPv[46]
IPv[46] A B C
Currently outside the scope of the draft.
Options:
Select 1
Pro: Only one solution to worry about
Con: May not be well suited to all use cases
Select 2 – One for L2 Interconnect (L2VPN) – One for DetNet End Stations (hosts)
Pro: Can optimize for routers and simple hosts
Con: More than one solution, complicates interworking
Select 3 or more

4. Assumptions We have QoS mechanisms on both L2 and L3..
They need to work together.
Sufficient queuing and scheduling mechanisms are in place in underlying links & sub-networks.

5. Remember the simple DetNet enabled network example
TSN              Edge          Transit        Relay        DetNet  End System       Node            Node         Node         End System                                         |  Appl.  |<---:Svc Proxy:-- End to End Service >|  Appl.  |                              |   TSN   |    |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service |                   |Transport|    |Trp| |Trp|    |Transport|    |Trp| |Trp|   |Transport|                           :  Link  :    /  ,  \   :  Link  :    /  ,  \              +-[  Sub  ]-+       +-[  Sub  ]-+                          [Network]                     [Network]                           `-----'                       `-----'

6. What services we need to look into?
DetNet End-to-end (case #1)
E.g. RTP end to end..
TSN interconnect (case #2)
Connecting two L2 TSN islands..
Service translation (case #3)
From L2 TSN to DetNet and vice versa.
Service interworking (case #4)
Connecting TSN end systems to DetNet end systems

7. Case #1 - End to end DetNet
DetNet           Relay         Transit        Relay        DetNet  End System       Node            Node         Node         End System                                         |  Appl.  |< End to End Service >|  Appl.  |                              | Service |<---: Service :--- DetNet flow ---: Service :-->| Service |                   |Transport|    |Trp| |Trp|    |Transport|    |Trp| |Trp|   |Transport|                           :  Link  :    /  ,  \   :  Link  :    /  ,  \              +-[  Sub  ]-+       +-[  Sub  ]-+                          [Network]                     [Network]                           `-----'                       `-----'

8. Case #2 - TSN interconnect
< Single L2 TSN Domain >
TSN              Edge          Transit        Edge        TSN  End System       Node            Node         Node         End System                             |  Appl.  |< End to End Service >|  Appl.  |                              |   TSN   |    |TSN| |VPN|<-- DetNet flow -->|VPN| |TSN| | TSN |                   |Transport|    |Trp| |Trp|    |Transport|    |Trp| |Trp|   |Transport|                           :  Link  :    /  ,  \   :  Link  :    /  ,  \              +-[  Sub  ]-+       +-[  Sub  ]-+                          [Network]                     [Network]                           `-----'                       `-----'
Equivalent e.g., to TSN over EVPN’

9. Case #3 - TSN Service translation
<-TSN Domain1 ->< transport domain ><- TSN domain2 ->
TSN              Edge          Transit        Edge        TSN  End System       Node            Node         Node         End System                               |  Appl.  |<---:Svc Proxy:-- E2End Service --:Svc Proxy:-->|  Appl.  |                              |   TSN   |    |TSN| |Svc|<-- DetNet flow -->:Svc| |TSN:-->| TSN |                   |Transport|    |Trp| |Trp|    |Transport|    |Trp| |Trp|   |Transport|                           :  Link  :    /  ,  \   :  Link  :    /  ,  \              +-[  Sub  ]-+       +-[  Sub  ]-+                          [Network]                     [Network]                           `-----'                       `-----'
From TSN to DetNet and back to TSN

10. Case #4 - Service interworking
TSN              Edge          Transit        Relay        DetNet  End System       Node            Node         Node         End System                                         |  Appl.  |<---:Svc Proxy:-- End to End Service >|  Appl.  |                              |   TSN   |    |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service |                   |Transport|    |Trp| |Trp|    |Transport|    |Trp| |Trp|   |Transport|                           :  Link  :    /  ,  \   :  Link  :    /  ,  \              +-[  Sub  ]-+       +-[  Sub  ]-+                          [Network]                     [Network]                           `-----'                       `-----'
E.g. between TSN and DetNet enabled end systems

11. Recap of some key features DetNet data plane needs to support..
Flow identification:
Identify specific deterministic flows.
Reliability:
Flow duplication and merging.
Packet sequencing and duplicate elimination.
Zero congestion loss and bounded latecy:
DetNet packets are not discarded due to congestion at any point in a DetNet aware network..

12. Things to care about when it comes data plane encapsulation
Flow Identification:
IEEE 802.1CB does w.g., MAC+VLAN and Octuple for flow identification.
In DetNet this should would ideally be transport independent.
Sequencing:
IEEE 802.1CB defines an R-TAG with a 16 bit sequence number, which is “compatible” with HSR, PRP, RTP and surprise with PW CW.
In DetNet this should ideally be transport independent.
Timing:
Basically carrying service related timing information as part of the encapsulation.

13. Prior work..
Draft-ietf-detnet-dp-alt already identified that MS-PWE is close:
Edge nodes => T-PE, Relay nodes => S-PE.
PW for transporting Ethernet payload.
Packet PW for transporting “any” packet over PW.
Sequencing and duplicate elimination using CW sequence numbering.
Fixed RTP header already defined for PW Encapsulation Layer. Similar to TDMoIP (RFC5087), SAToP (RFC4553), and aligned with Sections 5.2.2, and of [RFC3985].
Flow identification i.e., PW multiplexing using PW label.
PWE PSN transport can be either MPLS or IP.
Redundancy & protection could use:
PW level solution and be independent of PSN
In some cases use PWE NSP..

14. Assuming a PW-based DetNet data plane solution
Packet formats.. a lot already there.
Service level semantics need work:
E.g., service recreation (end TSN, create PW).
E.g., how to do IEEE P802.1CB Frame Replication and Elimination for Redundancy?

15. How packet formats would look like TSN over DetNet?
| Application Payload | >| Application Payload |
/=====================\
H Payload Convergence H >| Ethernet header (RFC6658,4448) |
H H |
H Timing H >| RTP (optional??) (RFC5087) |
H Sequencing H >| CW & Sequence Number (RFC4448) |
\=====================/ |
| PW Demultiplexer | >|PW Label for flow identification| |
| PSN Convergence | >| Outer Label or MPLS-in-IP | |
| PSN |-----+
| Data-Link |
| Physical |
Transport independent
For MPLS PSN, use TE LSPs (controlled via whatever)
For IP PSN, maybe use IP over TE-LSPs?
Or just IP over TSN when available..

16. More about packet formats.. example
Observations
| Application payload | m
| Ethernet | 14
| Header | |
| |
| Optional RTP SSRC Identifier | 4
| Optional RTP Timestamp | 4
| Optional RTP flags & SeqNum | 4
| PW Control Word and SeqNum | 4
| PW Label (flow identifier) | 4
| 0 or more MPLS Tunnel Labels | n*4
| PSN (MPLS or IP) | k
Overhead is obvious.
Think RTP/UDP/IPv6 payload..
Optional fields are not good in general.
Assumes encapsulation for all application payloads.
Suboptimal when end systems are DetNet aware.

17. DetNet native format Observations DetNet headers are unmodified..
| Application payload | m
| ???? | x
| Optional RTP SSRC Identifier | 4
| Optional RTP Timestamp | 4
| Optional RTP flags & SeqNum | 4
| PW Control Word and SeqNum | 4
| PW Label (flow identifier) | 4
| 0 or more MPLS Tunnel Labels | n*4
| PSN (MPLS or IP) | k
DetNet headers are unmodified..
IP transport header is TBD..
TCP? QUIC? RTP? ..

18. Handling of services First priority: Second priority (case #3 and #4):
DetNet End-to-end (case #1)
Can use the same building blocks shown previously..
TSN interconnect (case #2)
Not much to do.. mostly a “normal” EVPN’
TSN aware nodes/end systems take care of stuff ;)
Second priority (case #3 and #4):
Service translation and Service interworking
Need a bit more work. See next slides.

19. Cases #3/4 - Service translation and Service interworking
Are TSN sequence numbers and DetNet sequence numbers the same or managed separately?
Assumption they are managed separately.
Assuming minimal impact to existing PW logic.
How are MAC addresses & VLAN etc managed/created in DetNet Edge Nodes?
Assumption they are not encapsulated into PW headers.
Similar approach to packet PWs?
Certain information can be in multiple layers?
E.g., an RTP/UDP/IPv6 flow would already have everything needed from a DetNet flow (identification, seqnums, etc).
Is that an issue?

20. PWE specific issues Encapsulation should be rather straight forward.
Control plane is a bigger “more work” topic.
Harder issue is how to do flow duplication and merging for hitless or lossless 1+1 protection:
Could be done in PW NSP? Would rule out “packet services” but be transparent to PWE.
Could be done as a new function in PW Instance?
What about DetNet Relays (i.e., S-PEs)? They would need to do more than just label switching..
Should be independent of the PSN.
slides-94-detnet-4.pdf discussed these in more detail..

21. Straw-man proposals? MS-PW based approach.. Encapsulation:
Either MPLS or IP PSNs (MPLS-in-IP).
Model DetNet nodes after T-PEs, S-PEs and LSRs.
Encapsulation:
CWs for sequencing.
PW labels for flow identification.
Study when RTP is needed.
Service protection:
Replication & merging at PSN layer (e.g., 1+1 LSP).
Duplicate elimination at PW Multiplexer layer.
PseudoWire
MPLS LSPs
PseudoWire
IPv[46]

22. Discussion and next steps
Reinitiate the data plane Design Team to come up with the data plane solution?