Download +---------+ +---------+ +---------+ +---------+ | TSN

DetNet Data Plane
Discussion
Jouni Korhonen
IETF 97 – Seoul, Korea
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.
Background from IETF #96
Options:
PseudoWire
PseudoWire
RTP/UDP
MPLS LSPs
IPv[46]
IPv[46]
• 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
3
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.
Remember the simple DetNet enabled
network example
TSN
End System
Edge
Node
Transit
Node
Relay
Node
DetNet
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]
`-----'
`-----'
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
Case #1 - End to end DetNet
DetNet
End System
Relay
Node
Transit
Node
Relay
Node
DetNet
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]
`-----'
`-----'
Case #2 - TSN interconnect
<------------- Single L2 TSN Domain --------------------------------->
TSN
End System
Edge
Node
Transit
Node
Edge
Node
TSN
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’
Case #3 - TSN Service translation
<-TSN Domain1 -><------ transport domain -------------><- TSN domain2 ->
TSN
End System
Edge
Node
Transit
Node
Edge
Node
TSN
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
Case #4 - Service interworking
TSN
End System
Edge
Node
Transit
Node
Relay
Node
DetNet
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
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..
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.
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, 5.4.1
and 5.4.2 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..
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?
How packet formats would look like
TSN over DetNet?
Transport independent
+---------------------+
+--------------------------------+
| Application Payload |--------->| Application Payload
|
/=====================\
+--------------------------------+
H Payload Convergence H--+ ---->| Ethernet header (RFC6658,4448) |
H---------------------H |
+--------------------------------+
H
Timing
H--------->| RTP (optional??) (RFC5087)
|
H---------------------H |
+--------------------------------+
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
|
For MPLS PSN, use TE LSPs (controlled via whatever)
+---------------------+
For IP PSN, maybe use IP over TE-LSPs?
|
Physical
|
+---------------------+
Or just IP over TSN when available..
More about packet formats.. example
+------------------------------+
| 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
+------------------------------+
Observations
• 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.
DetNet native format
+------------------------------+
| Application payload
|
+------------------------------+
|
????
|
+---------------+--------------+
| Optional RTP SSRC Identifier |
+------------------------------+
| Optional RTP Timestamp
|
+------------------------------+
| Optional RTP flags & SeqNum |
+------------------------------+
| PW Control Word and SeqNum
|
+------------------------------+
| PW Label (flow identifier)
|
+------------------------------+
| 0 or more MPLS Tunnel Labels |
+------------------------------+
| PSN (MPLS or IP)
|
+------------------------------+
m
x
4
4
4
4
4
n*4
k
Observations
• DetNet headers are
unmodified..
• IP transport header is TBD..
– TCP? QUIC? RTP? ..
Handling of services
• First priority:
– 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.
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?
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..
Straw-man proposals?
• MS-PW based approach..
– 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]
Discussion and next steps
• Reinitiate the data plane Design Team to come
up with the data plane solution?