Draft: draft-ietf-detnet-ip-over-tsn

Commentary: Reflecting the 9th September discussions .
Paragraph (version A):
This document specifies the Deterministic Networking IP data plane
when operating over a TSN network.
Paragraph (version A):
This document specifies the DetNet data plane operation for IP hosts
and routers that provide DetNet service to IP encapsulated data.  No
DetNet specific encapsulation is defined to support IP flows, rather
existing IP and higher layer protocol header information is used to
support flow identification and DetNet service delivery.
Paragraph (version A):
The DetNet Architecture decomposes the DetNet related data plane
functions into two sub-layers: a service sub-layer and a forwarding
sub-layer.  The service sub-layer is used to provide DetNet service
protection and reordering.  The forwarding sub-layer is used to
provides congestion protection (low loss, assured latency, and
limited reordering).  As no DetNet specific headers are added to
support DetNet IP flows, only the forwarding sub-layer functions are
supported using the DetNet IP defined by this document.  Service
protection can be provided on a per sub-net basis using technologies
such as MPLS I-D.ietf-detnet-dp-sol-mpls and IEEE802.1 TSN.
Paragraph (version B):
This document specifies the Deterministic Networking IP data plane
when operating over a TSN sub-network.
Paragraph (version B):
I-D.ietf-detnet-ip specifies the DetNet data plane operation for IP
hosts and routers that provide DetNet service to IP encapsulated
data.  This document focuses on the scenario where DetNet IP nodes
are interconnected by a TSN sub-network.
Paragraph (version B):
The DetNet Architecture decomposes the DetNet related data plane
functions into two sub-layers: a service sub-layer and a forwarding
sub-layer.  The service sub-layer is used to provide DetNet service
protection and reordering.  The forwarding sub-layer is used to
provides congestion protection (low loss, assured latency, and
limited reordering).  As described in I-D.ietf-detnet-ip no DetNet
specific headers are added to support DetNet IP flows, only the
forwarding sub-layer functions are supported inside the DetNet
domain.  Service protection can be provided on a per sub-network
basis as shown here for the IEEE802.1 TSN sub-network scenario.
Paragraph (version A):
Customer Edge equipment.
Paragraph (version A):
Class of Service.
Paragraph (version A):
Label-switched path.
Paragraph (version A):
Multiprotocol Label Switching.
Paragraph (version A):
Operations, Administration, and Maintenance.
Paragraph (version A):
Provider Edge.
Paragraph (version A):
Packet Switched Network.
Paragraph (version A):
Pseudowire.
Paragraph (version A):
Quality of Service.
Paragraph (version A):
Traffic Engineering.
Paragraph (version A):
This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, to identify DetNet flows and provide a DetNet service.
From a data plane perspective, an end-to-end IP model is followed.
As mentioned above, existing IP and higher layer protocol header
information is used to support flow identification and DetNet service
delivery.
Paragraph (version A):
DetNet uses "6-tuple" based flow identification, where "6-tuple"
refers to information carried in IP and higher layer protocol
headers.  General background on the use of IP headers, and
"5-tuples", to identify flows and support Quality of Service (QoS)
can be found in RFC3670.  RFC7657 also provides useful background on
the delivery differentiated services (DiffServ) and "6-tuple" based
flow identification.
Paragraph (version B):
I-D.ietf-detnet-ip describes how IP is used by DetNet nodes, i.e.,
hosts and routers, to identify DetNet flows and provide a DetNet
service.  From a data plane perspective, an end-to-end IP model is
followed.  DetNet uses "6-tuple" based flow identification, where
"6-tuple" refers to information carried in IP and higher layer
protocol headers.
Paragraph (version A):
fig_ip_detnet_simple illustrates a DetNet enabled IP network.  The
DetNet enabled end systems originate IP encapsulated traffic that is
identified as DetNet flows, relay nodes understand the forwarding
requirements of the DetNet flow and ensure that node, interface and
sub-network resources are allocated to ensure DetNet service
requirements.  The dotted line around the Service component of the
Relay Nodes indicates that the transit routers are DetNet service
aware but do not perform any DetNet service sub-layer function, e.g.,
PREOF.  IEEE 802.1 TSN is an example sub-network type which can
provide support for DetNet flows and service.  The mapping of DetNet
IP flows to TSN streams and TSN protection mechanisms is covered in
mapping-tsn.
Paragraph (version A):
Note: The sub-network can represent a TSN, MPLS or IP network
segment.
Paragraph (version A):
fig_ip_detnet illustrates a variant of fig_ip_detnet_simple, with an
MPLS based DetNet network as a sub-network between the relay nodes.
It shows a more complex DetNet enabled IP network where an IP flow is
mapped to one or more PWs and MPLS (TE) LSPs.  The end systems still
originate IP encapsulated traffic that is identified as DetNet flows.
The relay nodes follow procedures defined in RRR to map each DetNet
flow to MPLS LSPs.  While not shown, relay nodes can provide service
sub-layer functions such as PREOF using DetNet over MPLS, and this is
indicated by the solid line for the MPLS facing portion of the
Service component.  Note that the Transit node is MPLS (TE) LSP aware
and performs switching based on MPLS labels, and need not have any
specific knowledge of the DetNet service or the corresponding DetNet
flow identification.  See RRR for details on the mapping of IP flows
to MPLS, and I-D.ietf-detnet-dp-sol-mpls for general support of
DetNet services using MPLS.
Paragraph (version A):
fig_non_detnet_ip illustrates another variant of fig_ip_detnet_simple
where the end systems are not DetNet aware.  In this case, edge nodes
sit at the boundary of the DetNet domain and provide DetNet service
proxies for the end applications by initiating and terminating DetNet
service for the application's IP flows.  The existing header
information or an approach used for aggregation can be used to
support DetNet flow identification.
Paragraph (version A):
Non-DetNet and DetNet IP packets are identical on the wire.  From
data plane perspective, the only difference is that there is flow-
associated DetNet information on each DetNet node that defines the
flow related characteristics and required forwarding behavior.  As
shown above, edge nodes provide a Service Proxy function that
"associates" one or more IP flows with the appropriate DetNet flow-
specific information and ensures that the receives the proper traffic
treatment within the domain.
Paragraph (version A):
Note: The operation of IEEE802.1 TSN end systems over DetNet enabled
IP networks is not described in this document.  While TSN flows could
be encapsulated in IP packets by an IP End System or DetNet Edge Node
in order to produce DetNet IP flows, the details of such are out of
scope of this document.
Paragraph (version A):
Within a DetNet domain, the DetNet enabled IP Routers interconnect
links and sub-networks to support end-to-end delivery of DetNet
flows.  From a DetNet architecture perspective, these routers are
DetNet relays, as they must be DetNet service aware.  Such routers
identify DetNet flows based on the IP 6-tuple, and ensure that the
DetNet service required traffic treatment is provided both on the
node and on any attached sub-network.
Paragraph (version A):
This solution provides DetNet functions end to end, but does so on a
per link and sub-network basis.  Congestion protection and latency
control and the resource allocation (queuing, policing, shaping) are
supported using the underlying link / sub net specific mechanisms.
However, service protections (packet replication and packet
elimination functions) are not provided at the DetNet layer end to
end.  But such service protection can be provided on a per underlying
L2 link and sub-network basis.
Paragraph (version A):
The DetNet Service Flow is mapped to the link / sub-network specific
resources using an underlying system specific means.  This implies
each DetNet aware node on path looks into the forwarded DetNet
Service Flow packet and utilize e.g., a 5- (or 6-) tuple to find out
the required mapping within a node.
Paragraph (version A):
As noted earlier, the Service Protection is done within each link /
sub-network independently using the domain specific mechanisms (due
the lack of a unified end to end sequencing information that would be
available for intermediate nodes).  Therefore, service protection (if
any) cannot be provided end-to-end, only within sub-networks.  This
is shown for a three sub-network scenario in fig_pref_in_subnets,
where each sub-network can provide service protection between its
borders.
Paragraph (version A):
If end to end service protection is desired that can be implemented,
for example, by the DetNet end systems using Layer-4 (L4) transport
protocols or application protocols.  However, these are out of scope
of this document.
Paragraph (version A):
There are network scenarios, where the DetNet domain contains
multiple technology segments (IEEE 802.1 TSN, MPLS) and all those
segments are under the same administrative control (see
fig_pref_xcrs_segments).  Furthermore, DetNet nodes may be
interconnected via TSN segments.
Paragraph (version A):
DetNet routers ensure that detnet service requirements are met per
hop by allocating local resources, both receive and transmit, and by
mapping the service requirements of each flow to appropriate sub-
network mechanisms.  Such mapping is sub-network technology specific.
The mapping of DetNet IP Flows to MPLS is covered RRR .  The mapping
of IP DetNet Flows to IEEE 802.1 TSN is covered in mapping-tsn.
Paragraph (version A):
This section covers how DetNet IP flows operate over an IEEE 802.1
TSN sub-network.  fig_ip_detnet_to_tsn illustrates such a scenario,
where two IP (DetNet) nodes are interconnected by a TSN sub-network.
Node-1 is single homed and Node-2 is dual-homed.  IP nodes can be (1)
DetNet IP End System, (2) DetNet IP Edge or Relay node or (3) IP End
System.
Paragraph (version A):
The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
Working Group have defined (and are defining) a number of amendments
to IEEE8021Q that provide zero congestion loss and bounded latency in
bridged networks.  Furthermore IEEE8021CB defines frame replication
and elimination functions for reliability that should prove both
compatible with and useful to, DetNet networks.  All these functions
have to identify flows those require TSN treatment.
Paragraph (version A):
As is the case for DetNet, a Layer 2 network node such as a bridge
may need to identify the specific DetNet flow to which a packet
belongs in order to provide the TSN/DetNet QoS for that packet.  It
also may need additional marking, such as the priority field of an
IEEE Std 802.1Q VLAN tag, to give the packet proper service.
Paragraph (version A):
TSN capabilities of the TSN sub-network are made available for IP
(DetNet) flows via the protocol interworking function defined in
IEEE8021CB.  For example, applied on the TSN edge port connected to
the IP (DetNet) node it can convert an ingress unicast IP (DetNet)
flow to use a specific multicast destination MAC address and VLAN, in
order to direct the packet through a specific path inside the bridged
network.  A similar interworking pair at the other end of the TSN
sub-network would restore the packet to its original destination MAC
address and VLAN.
Paragraph (version B):
Congestion protection, latency control and the resource allocation
(queuing, policing, shaping) are supported using the underlying link
/ sub-net specific mechanisms.  Service protections (packet
replication and packet elimination functions) are not provided at the
DetNet layer end to end due the lack of a unified end to end
sequencing information that would be available for intermediate
nodes.  However, such service protection can be provided on a per
underlying L2 link and sub-network basis.
Paragraph (version B):
fig_ip_detnet_part illustrates an extract of a DetNet enabled IP
network, that uses a TSN sub-network as interconnection between two
DetNet Nodes.  In this figure, an Edge Node sits at the boundary of
the DetNet domain and provide DetNet service proxies for the end
applications by initiating and terminating DetNet service for the
application's IP flows.  Node and interface resources are allocated
to ensure DetNet service requirements.  Dotted lines around the
Service components of the Edge and Relay Nodes indicate that they are
DetNet service aware but do not perform any DetNet service sub-layer
function, e.g., PREOF (Packet Replication, Elimination, and Ordering
Functions).  In this example the Edge Node and the Transit Node are
interconnected by a TSN sub-network, being the primary focus of this
document.
Paragraph (version B):
DetNet routers ensure that detnet service requirements are met per
hop by allocating local resources, both receive and transmit, and by
mapping the service requirements of each flow to appropriate sub-
network mechanisms.  Such mappings are sub-network technology
specific.  The mapping of DetNet IP flows to TSN streams and TSN
protection mechanisms are covered in mapping-tsn.
Paragraph (version B):
This section covers how DetNet IP flows operate over an IEEE 802.1
TSN sub-network.  fig_ip_detnet_to_tsn illustrates such a scenario,
where two IP (DetNet) nodes are interconnected by a TSN sub-network.
Node-1 is single homed and Node-2 is dual-homed to the TSN sub-
network.
Paragraph (version B):
The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
Working Group have defined (and are defining) a number of amendments
to IEEE8021Q that provide zero congestion loss and bounded latency in
bridged networks.  Furthermore IEEE8021CB defines frame replication
and elimination functions for reliability that should prove both
compatible with and useful to DetNet networks.  All these functions
have to identify flows that require TSN treatment.
Paragraph (version B):
TSN capabilities of the TSN sub-network are made available for IP
(DetNet) flows via the protocol interworking function defined in
IEEE8021CB.  For example, applied on the TSN edge port it can convert
an ingress unicast IP (DetNet) flow to use a specific Layer-2
multicast destination MAC address and a VLAN, in order to direct the
packet through a specific path inside the bridged network.  A similar
interworking function pair at the other end of the TSN sub-network
would restore the packet to its original Layer-2 destination MAC
address and VLAN.
Paragraph (version A):
DetNet IP Flow and TSN Stream mapping is based on the active Stream
Identification function, that operates at the frame level.
IEEE8021CB defines an Active Destination MAC and VLAN Stream
identification function, what can replace some Ethernet header fields
namely (1) the destination MAC-address, (2) the VLAN-ID and (3)
priority parameters with alternate values.  Replacement is provided
for the frame passed down the stack from the upper layers or up the
stack from the lower layers.
Paragraph (version B):
Mapping of a DetNet IP flow to a TSN Stream is provided via the
combination of a passive and an active stream identification function
that operate at the frame level.  The passive stream identification
function is used to catch the 6-tuple of a DetNet IP flow and the
active stream identification function is used to modify the Ethernet
header according to ID of the mapped TSN Stream.
Paragraph (version B):
IEEE8021CB defines an IP Stream identification function that can be
used as a passive function for IP DetNet flows using UDP or TCP.
IEEEP8021CBdb defines a Mask-and-Match Stream identification function
that can be used as a passive function for any IP DetNet flows.
Paragraph (version B):
IEEE8021CB defines an Active Destination MAC and VLAN Stream
identification function, what can replace some Ethernet header fields
namely (1) the destination MAC-address, (2) the VLAN-ID and (3)
priority parameters with alternate values.  Replacement is provided
for the frame passed down the stack from the upper layers or up the
stack from the lower layers.
Paragraph (version A):
Active Destination MAC and VLAN Stream identification can be used
within a Talker to set flow identity or a Listener to recover the
original addressing information.  It can be used also in a TSN bridge
that is providing translation as a proxy service for an End System.
As a result IP (DetNet) flows can be mapped to use a particular {MAC-
address, VLAN} pair to match the Stream in the TSN sub-network.
Paragraph (version A):
From the TSN sub-network perspective DetNet IP nodes without any TSN
functions can be treated as TSN-unaware Talker or Listener.  In such
cases relay nodes in the TSN sub-network MUST modify the Ethernet
encapsulation of the DetNet IP flow (e.g., MAC translation, VLAN-ID
setting, Sequence number addition, etc.) to allow proper TSN specific
handling of the flow inside the sub-network.  This is illustrated in
fig_ip_without_tsn.
Paragraph (version A):
A Stream identification component MUST be able to instantiate the
following functions (1) Active Destination MAC and VLAN Stream
identification function, (2) IP Stream identification function and
(3) the related managed objects in Clause 9 of IEEE8021CB.  IP Stream
identification function provides a 6-tuple match.
Paragraph (version A):
TSN Streams supporting DetNet flows may use Frame Replication and
Elimination for Redundancy (FRER) [802.1CB] based on the loss service
requirements of the TSN Stream, which is derived from the DetNet
service requirements of the DetNet mapped flow.  The specific
operation of FRER is not modified by the use of DetNet and follows
IEEE8021CB.
Paragraph (version A):
FRER function and the provided service recovery is available only
within the TSN sub-network (as shown in fig_pref_in_subnets) as the
Stream-ID and the TSN sequence number are not valid outside the sub-
network.  An IP (DetNet) node represents a L3 border and as such it
terminates all related information elements encoded in the L2 frames.
Paragraph (version A):
This section provides DetNet IP data plane procedures to interwork
with a TSN underlay sub-network when the IP (DetNet) node acts as a
TSN-aware Talker or Listener (see fig_ip_with_tsn).  These procedures
have been divided into the following areas: flow identification,
mapping of a DetNet flow to a TSN Stream and ensure proper TSN
encapsulation.
Paragraph (version A):
Flow identification procedures are described in RRR .  A TSN-aware IP
(DetNet) node SHALL support the Stream Identification TSN components
as per IEEE8021CB.
Paragraph (version B):
Active Destination MAC and VLAN Stream identification can be used
within a Talker to set flow identity or a Listener to recover the
original addressing information.  It can be used also in a TSN bridge
that is providing translation as a proxy service for an End System.
Paragraph (version B):
This section covers required behavior of a TSN-aware DetNet node
using a TSN sub-network.
Paragraph (version B):
From the TSN sub-network perspective DetNet IP nodes are treated as
Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware.
Paragraph (version B):
In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within
the TSN sub-network must modify the Ethernet encapsulation of the
DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence
number addition, etc.) to allow proper TSN specific handling inside
the sub-network.  There are no requirements defined for TSN-unaware
IP DetNet nodes in this document.
Paragraph (version B):
IP (DetNet) nodes being TSN-aware can be treated as a combination of
a TSN-unaware Talker/Listener and a TSN-Relay, as shown in
fig_ip_with_tsn.  In such cases the IP (DetNet) node must provide the
TSN sub-network specific Ethernet encapsulation over the link(s)
towards the sub-network.
Paragraph (version B):
A TSN-aware IP (DetNet) node impementations MUST support the Stream
Identification TSN component for recognizing flows.
Paragraph (version B):
A Stream identification component MUST be able to instantiate the
following functions (1) Active Destination MAC and VLAN Stream
identification function, (2) IP Stream identification function, (3)
Mask-and-Match Stream identification function and (4) the related
managed objects in Clause 9 of IEEE8021CB and IEEEP8021CBdb.
Paragraph (version B):
A TSN-aware IP (DetNet) node implementations MUST support the
Sequencing function and the Sequence encode/decode function as
defined in IEEE8021CB if FRER is used inside the TSN sub-network.
Paragraph (version B):
A TSN-aware IP (DetNet) node implementations MUST support the Stream
splitting function and the Individual recovery function as defined in
IEEE8021CB when the node is a replication or elimination point for
FRER.
Paragraph (version B):
TSN Streams supporting DetNet flows may use Frame Replication and
Elimination for Redundancy (FRER) as defined in IEEE8021CB based on
the loss service requirements of the TSN Stream, which is derived
from the DetNet service requirements of the DetNet mapped flow.  The
specific operation of FRER is not modified by the use of DetNet and
follows IEEE8021CB.
Paragraph (version B):
FRER function and the provided service recovery is available only
within the TSN sub-network as the TSN Stream-ID and the TSN sequence
number are not valid outside the sub-network.  An IP (DetNet) node
represents a L3 border and as such it terminates all related
information elements encoded in the L2 frames.
Paragraph (version A):
For proper TSN encapsulation implementations of this document SHALL
support active Stream Identification function as defined in chapter
6.6 in IEEE8021CB.
Paragraph (version A):
A TSN-aware IP (DetNet) node SHALL support Ethernet encapsulation
with Redundancy tag (R-TAG) as per chapter 7.8 in IEEE8021CB.
Paragraph (version A):
Depending whether FRER functions are used in the TSN sub-network to
serve the mapped TSN Stream, a TSN-aware IP (DetNet) node SHALL
support Sequencing function and Sequence encode/decode function as
per chapter 7.4 and 7.6 in IEEE8021CB.  Furthermore when a TSN-aware
IP (DetNet) node acting as a replication or elimination point for
FRER it SHALL implement the Stream splitting function and the
Individual recovery function as per chapter 7.7 and 7.5 in
IEEE8021CB.
Paragraph (version A):
TSN-aware DetNet IP nodes are member of both the DetNet domain and
the TSN sub-network.  Within the TSN sub-network the TSN-aware IP
(DetNet) node has a TSM-aware Talker/Listener role, so TSN specific
management and control plane functionalities must be implemented.
There are many similarities in the management plane techniques used
in DetNet and TSN, but that is not the case for the control plane
protocols.  For example, RSVP-TE and MSRP behaves differently.
Therefore management and control plane design is an important aspect
of scenarios, where mapping between DetNet and TSN is required.
Paragraph (version B):
TSN-aware IP DetNet nodes are member of both the DetNet domain and
the TSN sub-network.  Within the TSN sub-network the TSN-aware IP
(DetNet) node has a TSN-aware Talker/Listener role, so TSN specific
management and control plane functionalities must be implemented.
There are many similarities in the management plane techniques used
in DetNet and TSN, but that is not the case for the control plane
protocols.  For example, RSVP-TE and MSRP behaves differently.
Therefore management and control plane design is an important aspect
of scenarios, where mapping between DetNet and TSN is required.
Paragraph (version A):
In order to use a TSN sub-network between DetNet nodes, DetNet
specific information must be converted to TSN sub-network specific
ones.  DetNet flow ID and flow related parameters/requirements must
be converted to a TSN Stream ID and stream related parameters/
requirements.  Note that, as the TSN sub-network is just a portion of
the end2end DetNet path (i.e., single hop from IP perspective), some
parameters (e.g., delay) may differ significantly.  Other parameters
(like bandwidth) also may have to be tuned due to the L2
encapsulation used in the TSN sub-network.
Paragraph (version A):
In some case it may be challenging to determine some TSN Stream
related information.  For example on a TSN-aware IP (DetNet) node
that acts as a Talker, it is quite obvious which DetNet node is the
Listener of the mapped TSN stream (i.e., the IP Next-Hop).  However
it may be not trivial to locate the point/interface where that
Listener is connected to the TSN sub-network.  Such attributes may
require interaction between control and management plane functions
and between DetNet and TSN domains.
Paragraph (version B):
In order to use a TSN sub-network between DetNet nodes, DetNet
specific information must be converted to TSN sub-network specific
ones.  DetNet flow ID and flow related parameters/requirements must
be converted to a TSN Stream ID and stream related parameters/
requirements.  Note that, as the TSN sub-network is just a portion of
the end2end DetNet path (i.e., single hop from IP perspective), some
parameters (e.g., delay) may differ significantly.  Other parameters
(like bandwidth) also may have to be tuned due to the L2
encapsulation used within the TSN sub-network.
Paragraph (version B):
In some case it may be challenging to determine some TSN Stream
related information.  For example, on a TSN-aware IP (DetNet) node
that acts as a Talker, it is quite obvious which DetNet node is the
Listener of the mapped TSN stream (i.e., the IP Next-Hop).  However
it may be not trivial to locate the point/interface where that
Listener is connected to the TSN sub-network.  Such attributes may
require interaction between control and management plane functions
and between DetNet and TSN domains.
Paragraph (version A):
Mapping between DetNet flow identifiers and TSN Stream identifiers,
if not provided explicitly, can be done by a TSN-aware IP (DetNet)
node locally based on information provided for configuration of the
TSN Stream identification functions (IP Stream identification and
active Stream identification function).
Paragraph (version B):
Mapping between DetNet flow identifiers and TSN Stream identifiers,
if not provided explicitly, can be done by a TSN-aware IP (DetNet)
node locally based on information provided for configuration of the
TSN Stream identification functions (IP Stream identification, Mask-
and-match Stream identification and active Stream identification
function).
Paragraph (version A):
Configuration of TSN specific functions (e.g., FRER) inside the TSN
sub-network is a TSN specific decision and may not be visible in the
DetNet domain.
Paragraph (version A):
The security considerations of DetNet in general are discussed in I-
D.ietf-detnet-architecture and I-D.ietf-detnet-security.  Other
security considerations will be added in a future version of this
draft.
Paragraph (version B):
Configuration of TSN specific functions (e.g., FRER) inside the TSN
sub-network is a TSN domain specific decision and may not be visible
in the DetNet domain.
Paragraph (version B):
The security considerations of DetNet in general are discussed in I-
D.ietf-detnet-architecture and I-D.ietf-detnet-security.  DetNet IP
data plane specific considerations are summarized in I-D.ietf-detnet-
ip.  Encryption may provided by an underlying sub-net using MACSec
IEEE802.1AE-2018 for DetNet IP over TSN flows.