Draft: draft-ietf-detnet-dp-sol-ip-01

Commentary: Cleanup related changes
This document specifies the DetNet data plane operation for IP hosts
and routers that provide DetNet service to IP encapsulated data, so
dealing with TSN flows is out-of-scope in this document.  No DetNet
specific encapsulation is defined to support IP flows, rather
existing IP header information is used to support flow identification
and DetNet service delivery.  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.
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 header information is used to support flow identification
and DetNet service delivery.  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.
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 act as DetNet service
proxies for the end applications by initiating and terminating DetNet
service for the native IP flows.  The existing header information or
an approach such as described in aggregation can be used to support
DetNet flow identification.
Native IP and DetNet IP packets are identical on the wire.  From data
plane perspective the only differece is that DetNet IP packets have
on each DetNet node an associated DetNet specific data structure,
what defines flow related characteristics and required forwarding
functions.  Edge Nodes MUST provide a Service Proxy entity that
"associates" the DetNet flows and native flows at the edge of the
DetNet domain.  It ensures that the DN Flow is properly served at the
Edge node (and inside the domain).
Note: Serving TSN end systems over DetNet enabled IP networks is not
explicitly described in this document.  TSN flows can be encapsulated
in IP packets by an IP End System or by an IP DetNet End System, what
results in a corresponding native IP flow or DetNet flow.  Any
details of such encapsulations are out-of-scope here.
This section provides informative considerations related to providing
DetNet services via IP.
Explicit routes: a reservation that maps a flow to a specific
path, which also limits miss-ordering and jitter.
Which in the case of this document translates to changing the
explicit path after a failure is detected while maintaining the
required DetNet service characteristics.  Path changes, even in
the case of failure recovery, can lead to the out of order
delivery of data.
Load sharing is not recommended for packets of the same DetNet
flow.  The spreading of a single DetNet flow across multiple
paths, e.g., via ECMP or UCMP, also impacts ordering and end-
to-end jitter, and as such use of multiple paths for support of
a single DetNet flow is is out of scope this document.
For example, identify misbehaving flows.
For example, volume above threshold.
DetNet IP flows are identified based on IP, both IPv4 RFC0791 and
IPv6 RFC8200, header information.  6 header fields are used and this
set of fields is commonly referred to as the IP header "6-tuple".
The 6 fields include the IP source and destination address fields,
the next level protocol or header field, the next level protocol
(e.g.  TCP or UDP) source and destination ports, and the IPv4 Type of
Service or IPv6 Traffic Class field (i.e., DSCP).  As part of single
DetNet flow identification, any of the fields can be ignored
(wildcarded), and bit masks, prefix based longest match, and ranges
can also be used.
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 such as described in aggregation can be
used to support DetNet flow identification.
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.
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.
DetNet IP flows are identified based on IP, both IPv4 RFC0791 and
IPv6 RFC8200, header information.  Six (6) header fields are used and
this set of fields is commonly referred to as the IP header
"6-tuple".  The 6 fields include the IP source and destination
address fields, the next level protocol or header field, the next
level protocol (e.g.  TCP or UDP) source and destination ports, and
the IPv4 Type of Service or IPv6 Traffic Class field (i.e., DSCP).
As part of single DetNet flow identification, any of the fields can
be ignored (wildcarded), and bit masks, prefix based longest match,
and ranges can also be used.
Use of a specific path for a flow.  This limits miss-ordering and
latency.
Which in the case of this document translates to changing the
explicit path after a failure is detected in order to restore
delivery of the required DetNet service characteristics.  Path
changes, even in the case of failure recovery, can lead to the out
of order delivery of data.
Generally, distributing packets of the same DetNet flow over
multiple paths is not recommended.  Such load sharing, e.g., via
ECMP or UCMP, impacts ordering and end-to-end jitter.
For example, to support identification of misbehaving flows.
For example, unexpected loss.
CoS for DetNet flows carried in PWs and MPLS is provided using the
existing MPLS Differentiated Services (DiffServ) architecture
RFC3270.  Both E-LSP and L-LSP MPLS DiffServ modes MAY be used to
support DetNet flows.  The Traffic Class field (formerly the EXP
field) of an MPLS label follows the definition of RFC5462 and
RFC3270.  The Uniform, Pipe, and Short Pipe DiffServ tunneling and
TTL processing models are described in RFC3270 and RFC3443 and MAY be
used for MPLS LSPs supporting DetNet flows.  MPLS ECN MAY also be
used as defined in ECN RFC5129 and updated by RFC5462.