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

Commentary: Merging per JiK ...
This document specifies Deterministic Networking data plane
encapsulation solutions.  The described data plane solutions is
applied over an IP Networks.
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows extremely low
packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in I-D.ietf-
detnet-architecture.
This document specifies the DetNet data plane and the on-wire
encapsulation of DetNet flows over an IP network.  The specified
encapsulation provides the building blocks to enable the DetNet
service layer functions and allow flow identification as described in
the DetNet Architecture.
The DetNet transport layer functionality that provides congestion
protection for DetNet flows is assumed to be in place in a DetNet
node.
Furthermore, this document also describes how DetNet flows are
identified, how a DetNet Relay/Edge/Transit nodes work, and how the
Packet Replication and Elimination function (PREF) is implemented
with the IP data plane solution(s).  [JiK] PROEF is possible within a
domain using domain specific means.  Across domain is outside of
scope of this document.
This document does not define the associated control plane functions,
or Operations, Administration, and Maintenance (OAM).  It also does
not specify traffic handling capabilities required to deliver
congestion protection and latency control for DetNet flows at the
DetNet transport layer.
This document uses the terminology established in the DetNet
architecture I-D.ietf-detnet-architecture and the DetNet Data Plane
Solution Alternatives I-D.ietf-detnet-dp-alt.
Attachment Circuit.
DetNet Control Word.
Layer 2 Virtual Private Network.
Label Switching Router.
Multiprotocol Label Switching - Transport Profile.
Multi-Segment PseudoWire (MS-PW).
This document specifies Deterministic Networking data plane operation
for IP encapsulated user data.
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows extremely low
packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in the DetNet
Architecture I-D.ietf-detnet-architecture.
This document specifies the DetNet data plane operation for IP hosts
and routers, which 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 as described in the DetNet
Architecture.  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.
The DetNet Architecture decomposes the DetNet related data plane
functions into two layers: a service layer and a transport layer.
The service layer is used to provide DetNet service protection and
reordering.  The transport layer is used to provides congestion
protection (low loss, assured latency, and limited reordering).  As
no DetNet specific headers are added to support IP DetNet flows, only
the transport layer functions are supported.  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.
This document does not define the associated control plane functions,
or Operations, Administration, and Maintenance (OAM).  Providing a
native IP solution for the DetNet service layer is out of scope of
this document.
This document uses the terminology and concepts established in the
DetNet architecture I-D.ietf-detnet-architecture the reader is
assumed to be familiar with that document.
PseudoWire.
Packet Replication, Ordering and Elimination Function.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
This document describes how to use IP to support a data plane method
of flow identification and packet forwarding over layer-3.  Two
different cases are covered: (i) the inter-connect scenario, in which
IEEE802.1 TSN is routed over a layer-3 network (i.e., to enlarge the
layer-2 domain), and (ii) native connectivity between DetNet-aware
end systems.
fig_ip_detnet illustrates how DetNet can provide services for a
possibly IEEE 802.1TSN aware IP end systems over a DetNet enabled
network.  The edge nodes insert and remove required DetNet data plane
encapsulation.  The 'X' in the edge and relay nodes represents a
potential DetNet flow packet replication and elimination point.  This
conceptually parallels L2VPN services, and could leverage existing
related solutions as discussed below.
Congestion protection and latency control: usage of allocated
resources (queuing, policing, shaping).
Explicit routes: select/apply the flow specific path.
Service protection: recognize DetNet compound and member flows
for replication an elimination.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
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.
fig_ip_detnet_simple illustrates a DetNet enabled IP network.  The
end systems originate IP encapsulated traffic that is identified as
DetNet flows, relay nodes understand the transport requirements of
the DetNet flow and ensure that node, interface and sub-network
resources are allocated to ensure DetNet service requirements.  IEEE
802.1 TSN is an example sub-network type which can provide support
for DetNet flows and service.  The mapping of IP DetNet flows to TSN
streams and TSN protection mechanisms is expected to be defined in a
future document.
fig_ip_detnet_simple illustrates a more complect DetNet enabled IP
network where an IP flow is mapped to one or more MPLS (TE) LSPs.
The end systems still originate IP encapsulated traffic that is
identified as DetNet flows.  The edge node follow procedures defined
in I-D.ietf-detnet-dp-sol-mpls to map each DetNet flow to MPLS LSPs.
While not shown, Edge nodes can provide service layer functions such
as PREF and PROEF over the MPLS transport layer.
DetNet IP flows are identified based on IP, both IPv4 RFC0791 and
IPv6 RFC2460, header information.  In particular, 6 header fields are
used and this set 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.
DetNet flow aggregation may also be enabled via the use of wildcards,
masks, prefixes and ranges may be used to support DetNet flow
aggregation.  In these cases, it is expected that DetNet aware
intermediate nodes will provide DetNet service assurance on the
aggregate through resource allocation and control.
Congestion protection and latency control: usage of allocated
resources (queuing, policing, shaping) to ensure that the
congestion-related loss and latency/jitter requirements of a
DetNet flow are met.
Explicit routes: a reservation that maps a flow to a specific
path, which also limits miss-ordering and jitter.  The
spreading of a single DetNet flow across multiple paths, e.g.,
via ECMP, also impacts ordering and end-to-end jitter, and as
such is for future study.
Service protection: which in the case of this document
translates to changing the explicit path after a failure is
detected.  Path changes, even in the case of failure recovery,
can lead to the out of order delivery of data.
On each DetNet node dealing with DetNet flows, an internal local-ID
is assumed to determine what local operation a packet goes through.
Therefore, local-IDs has to be unique on each edge and relay nodes.
Local-ID is unambiguously bound to the DetNet flow.
Discuss about 6-tuple and stuff..
DetNet service layer introduces packet replication and elimination
functionality (PREF) for use in DetNet edge and relay node and end
system packet processing.  PREF MAY be enabled in a DetNet node and
the required processing is only applied to packets with a positive
flow identification at the DetNet service layer.  PREF utilizes a
sequence number carried within a DetNet flow packets.
At a DetNet node level the output of the PREF elimination function is
always a single packet.  The output of the PREF replication function
at a DetNet node level is always one or more packets (i.e., 1:N
replication).  The replicated packets MUST share the same d-CW i.e.,
the sequence number is the same for each member flow of the compound
flow.  The location and mechanism on the packet processing pipeline
used for replication is implementation specific.
The complex part of the DetNet PREF processing is tracking the
history of received packets for multiple DetNet member flows.  These
ingress DetNet member flows (to a node) MUST have the same local-ID
if they belong to the same DetNet (compound) flow and share the same
sequence number counter and the history information.  The location of
the packet elimination on the packet processing pipeline is
implementation specific.
DetNet service layer introduces also packet reordering functionality
for use in DetNet edge and relay node and end system packet
processing.  The reordering functionality MAY be enabled in a DetNet
node.  The reordeing functionality relies on a presence of sequence
numbers in a DetNet (compound) flows.  The reordering processing is
only applied to packets with a positive flow identification at the
DetNet service layer.  [JiK] ECMP SHOULD NOT be used.
In case of an IP PSN the same tunneling concept can be used as for an
MPLS PSN, but the tunnel is constructed by a new IP header (and
possible upper layer fields).  The data-flow IP header MUST be
preserved as-is.
DetNet IP header contains the IP addresses of the ingress/egress PE
nodes of DetNet domain.  The End-system IP header contains the IP
addresses of the end-systems.  Therefore all DetNet specific
functions can be used.
DetNet flows transported via IP have more limited aggregation
options, due to the available traffic flow identification fields of
the IP solution.  One available approach is to manage the resources
associated with a DSCP identified traffic class and to map (remark)
individually controlled DetNet flows onto that traffic class.  This
approach also requires that nodes support aggregation ensure that
traffic from aggregated LSPs are placed (shaped/policed/enqueued) in
a fashion that ensures the required DetNet service is preserved.
SB> I am sure we can do better than this with SR, or the use of
routing techniques that map certain addresses to certain paths.
In both the MPLS and IP cases, additional details of the traffic
control capabilities needed at a DetNet-aware node may be covered in
the new service descriptions mentioned above or in separate future
documents.  Management and control plane mechanisms will also need to
ensure that the service required on the aggregate flow (H-LSP or
DSCP) are provided, which may include the discarding or remarking
mentioned in the previous sections.
IPv4 and IPv6 will move under Section 6.
PTP with on-path support: in this approach PTP packets are sent as
ordinary or as DetNet flows, and intermediate nodes take part in
the protocol as Transparent Clocks or Boundary Clocks [IEEE1588].
The on-path PTP support by intermediate nodes provides a higher
degree of accuracy than the previous approach.  The actual
accuracy depends on whether all intermediate nodes are PTP-
capable, or only a subset of them.
PTP with on-path support: in this approach PTP packets are sent as
ordinary or as DetNet flows, and intermediate nodes take part in
the protocol as Transparent Clocks or Boundary Clocks IEEE1588.
The on-path PTP support by intermediate nodes provides a higher
degree of accuracy than the previous approach.  The actual
accuracy depends on whether all intermediate nodes are PTP-
capable, or only a subset of them.
The security considerations of DetNet in general are discussed in I-
D.ietf-detnet-architecture and I-D.sdt-detnet-security.  Other
security considerations will be added in a future version of this
draft.
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.