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

Commentary: TSN related documents are updated as follows : draft - ietf - detnet - ip - over - tsn AND draft - ietf - detnet - mpls - over - tsn type changed to informational overview shortened changing TSN related conformance language to informative text stating that mappings between DetNet and TSN management and control planes are out of scope of the document updating references draft - ietf - detnet - tsn - vpn - over - mpls overview shortened fixing 5.1 and 5.2 ( changing TSN related conformance language to informative text ) stating that mappings between DetNet and TSN management and control planes are out of scope of the document updating references
Paragraph (version A):
This document specifies the Deterministic Networking MPLS data plane
when operating over a TSN sub-network.
Paragraph (version B):
This document specifies the Deterministic Networking MPLS data plane
when operating over a TSN sub-network.  This document does not define
new procedures or processes.  Whenever this document makes
requirements statements or recommendations, these are taken from
normative text in the referenced RFCs.
Paragraph (version A):
fig_mpls_detnet_part illustrates an extract of a DetNet enabled MPLS
network.  Edge/relay nodes sit at MPLS LSP boundaries and transit
nodes are LSRs.  In this figure, two MPLS nodes (the edge node and
the transit node) are interconnected by a TSN sub-network.
Paragraph (version B):
MPLS (DetNet) nodes and transit nodes interconnected by a TSN sub-
network are the primary focus of this document.  The mapping of
DetNet MPLS flows to TSN streams and TSN protection mechanisms are
covered in mpls-over-tsn.
Paragraph (version A):
As described in the DetNet architecture RFC8655 and also illustrated
here in fig_mpls_detnet_part a sub-network provides from MPLS
perspective a single hop connection between MPLS (DetNet) nodes.
Functions used for resource allocation and explicit routes are
treated as domain internal functions and does not require function
interworking across the DetNet MPLS network and the TSN sub-network.
Paragraph (version B):
As described in the DetNet architecture RFC8655 a sub-network
provides from MPLS perspective a single hop connection between MPLS
(DetNet) nodes.  Functions used for resource allocation and explicit
routes are treated as domain internal functions and does not require
function interworking across the DetNet MPLS network and the TSN sub-
network.
Paragraph (version A):
When a PE receives a packet from a CE, on a given AC with DetNet
service, it MUST first check via Stream Identification (see Clause 6.
of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a
configured TSN Stream (i.e., App-flow from DetNet perspective).  If
no Stream ID is matched and no other (VPN) service is configured for
the AC then packet MUST be dropped.  If there is a matching TSN
Stream then the Stream-ID specific TSN functions MUST be executed
(e.g., ingress policing, header field manipulation in case of active
Stream Identification, FRER, etc.).  Source MAC lookup MAY also be
used for local MAC address learning.
Paragraph (version B):
When a PE receives a packet from a CE, on a given AC with DetNet
service, it first checks via Stream Identification (see Clause 6. of
IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a
configured TSN Stream (i.e., App-flow from DetNet perspective).  If
no Stream ID is matched and no other (VPN) service is configured for
the AC then packet MUST be dropped.  If there is a matching TSN
Stream then the Stream-ID specific TSN functions are executed (e.g.,
ingress policing, header field manipulation in case of active Stream
Identification, FRER, etc.).  Source MAC lookup may also be used for
local MAC address learning.
Paragraph (version A):
When a TSN entity of the PE receives a packet from the DetNet Service
Proxy, it MUST first check via Stream Identification (see Clause 6.
of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a
configured TSN Stream.  If no Stream ID is matched then packet MUST
be dropped.  If there is a matching TSN Stream then the Stream ID
specific TSN functions MUST be executed (e.g., header field
manipulation in case of active Stream Identification, FRER, etc.).
Source MAC lookup MAY also be used for local MAC address learning.
Paragraph (version A):
If the PE decides to forward the packet, the packet MUST be forwarded
according to the TSN Stream specific configuration to connected
CE(s).  If there are no TSN Stream specific forwarding configurations
the PE MUST flood the packet to locally attached CE(s).  If the
administrative policy on the PE does not allow flooding the PE MUST
drop the packet.
Paragraph (version B):
When a TSN entity of the PE receives a packet from the DetNet Service
Proxy, it first checks via Stream Identification (see Clause 6. of
IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a
configured TSN Stream.  If no Stream ID is matched then packet is
dropped.  If there is a matching TSN Stream then the Stream ID
specific TSN functions are executed (e.g., header field manipulation
in case of active Stream Identification, FRER, etc.).  Source MAC
lookup may also be used for local MAC address learning.
Paragraph (version B):
If the PE decides to forward the packet, the packet is forwarded
according to the TSN Stream specific configuration to connected
CE(s).  If there are no TSN Stream specific forwarding configurations
the PE floods the packet to locally attached CE(s).  If the
administrative policy on the PE does not allow flooding the PE drops
the packet.
Paragraph (version A):
App-Flow identification information to map received TSN Stream(s)
to the DetNet flow.  Parameters fo TSN stream identification are
defined in IEEE8021CB and IEEEP8021CBdb.
Paragraph (version B):
App-Flow identification information to map received TSN Stream(s)
to the DetNet flow.  Parameters of TSN stream identification are
defined in IEEE8021CB and IEEEP8021CBdb.
Paragraph (version A):
This document specifies the Deterministic Networking IP data plane
when operating over a TSN sub-network.
Paragraph (version B):
This document specifies the Deterministic Networking IP data plane
when operating over a TSN sub-network.  This document does not define
new procedures or processes.  Whenever this document makes
requirements statements or recommendations, these are taken from
normative text in the referenced RFCs.
Paragraph (version A):
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 A):
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 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 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 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 to the TSN sub-
network.
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
IP 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):
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.  DetNet nodes interconnected by a TSN sub-network are the
primary focus of this document.  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.
Dotted lines around the Service components of the IP (DetNet) Nodes
indicate that they are DetNet service aware but do not perform any
DetNet service sub-layer function.  Node-1 is single homed and Node-2
is dual-homed to the TSN sub-network.