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

Commentary: ip - over - tsn ( nits ) mpls - over - tsn ( nits ) tsn - vpn - over - mpls ( nits , ch5.2 , ch5.3 )
Paragraph (version A):
This document uses the terminology and concepts established in the
DetNet architecture RFC8655 and I-D.ietf-detnet-data-plane-framework,
and I-D.ietf-detnet-mpls.  The reader is assumed to be familiar with
these documents and their terminology.
Paragraph (version B):
This document uses the terminology and concepts established in the
DetNet architecture RFC8655 and RFC8938, and I-D.ietf-detnet-mpls.
The reader is assumed to be familiar with these documents and their
terminology.
Paragraph (version A):
A MPLS DetNet flow is configured to carry any number of TSN flows.
The DetNet flow specific bandwidth profile SHOULD match the required
bandwidth of the App-flow aggregate.
Paragraph (version A):
The LSP used to forward the DetNet packet may be of any type (MPLS-
LDP, MPLS-TE, MPLS-TP RFC5921, or MPLS-SR RFC8660).  The LSP
(F-Label) label and/or the S-Label may be used to indicate the queue
processing as well as the forwarding parameters.
Paragraph (version A):
When a PE receives a packet from the Service Proxy function it MUST
add to the packet the DetNet flow-ID specific S-label and create a
d-CW.  The PE MUST forward the packet according to the configured
DetNet Service and Forwarding sub-layer rules to other PE nodes.
Paragraph (version B):
When a PE receives a packet from the Service Proxy function it MUST
handle the packet as defined in I-D.ietf-detnet-mpls.
Paragraph (version A):
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 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 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 B):
RFC8939 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 RFC8939 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):
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 B):
RFC8939 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):
DetNet IP related configuration information according to the
DetNet role of the DetNet IP node, as per I-D.ietf-detnet-ip.
Paragraph (version A):
Mapping between DetNet IP flow(s) (as flow identification defined
in I-D.ietf-detnet-ip, it is summarized in Section 5.1 of that
document, and includes all wildcards, port ranges and the ability
to ignore specific IP fields) and TSN Stream(s) (as stream
identification information defined in IEEE8021CB and
IEEEP8021CBdb).  Note, that managed objects for TSN Stream
identification can be found in IEEEP8021CBcv.
Paragraph (version B):
DetNet IP related configuration information according to the
DetNet role of the DetNet IP node, as per RFC8939.
Paragraph (version B):
Mapping between DetNet IP flow(s) (as flow identification defined
in RFC8939, it is summarized in Section 5.1 of that document, and
includes all wildcards, port ranges and the ability to ignore
specific IP fields) and TSN Stream(s) (as stream identification
information defined in IEEE8021CB and IEEEP8021CBdb).  Note, that
managed objects for TSN Stream identification can be found in
IEEEP8021CBcv.
Paragraph (version A):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.  DetNet IP data plane specific considerations
are summarized in I-D.ietf-detnet-ip.  This section considers
exclusively security considerations which are specific to the DetNet
IP over TSN sub-network scenario.
Paragraph (version B):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.  DetNet IP data plane specific considerations
are summarized in RFC8939.  This section considers exclusively
security considerations which are specific to the DetNet IP over TSN
sub-network scenario.