Draft: draft-ietf-detnet-ip

Commentary: -- please approve and merge -- I 've uploaded this version ...
Paragraph (version A):
This document specifies the Deterministic Networking data plane when
operating in an IP packet switched network.
Paragraph (version B):
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; instead
the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery.  This
document builds on the DetNet Architecture and Data Plane Framework.
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, instead
the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery.  Common
data plane procedures and control information for all DetNet data
planes can be found in the I-D.ietf-detnet-data-plane-framework.
Paragraph (version B):
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; instead
the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery.  Common
data plane procedures and control information for all DetNet data
planes can be found in I-D.ietf-detnet-data-plane-framework.
Paragraph (version A):
This document provides an overview of the DetNet IP data plane in
sec_dt_dp, considerations that apply to providing DetNet services via
the DetNet IP data plane in dn-gen-encap-solution. ip-procs provides
the procedures for hosts and routers that support IP-based DetNet
services. ip-flow-id-info summarizes the set of information that is
needed to identify an individual DetNet flow.
Paragraph (version B):
This document provides an overview of the DetNet IP data plane in
sec_dt_dp, and considerations that apply to providing DetNet services
via the DetNet IP data plane in dn-gen-encap-solution. ip-procs
provides the procedures for hosts and routers that support IP-based
DetNet services. ip-flow-id-info summarizes the set of information
that is needed to identify an individual DetNet flow.
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
using an IP data plane.  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.  Common data plane
procedures and control information for all DetNet data planes can be
found in the I-D.ietf-detnet-data-plane-framework.
Paragraph (version A):
The DetNet IP data plane primarily uses "6-tuple" based flow
identification, where 6-tuple refers to information carried in IP and
higher layer protocol headers.  The 6-tuple referred to in this
document is the same as that defined in RFC3290.  Specifically
6-tuple is (destination address, source address, IP protocol, source
port, destination port, and differentiated services (DiffServ) code
point (DSCP).  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 of DiffServ and "tuple" based flow identification.  Note
that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP
component.
Paragraph (version B):
This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, to identify DetNet flows and provide a DetNet service
using an IP data plane.  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.  Common data plane
procedures and control information for all DetNet data planes can be
found in I-D.ietf-detnet-data-plane-framework.
Paragraph (version B):
The DetNet IP data plane primarily uses 6-tuple based flow
identification, where "6-tuple" refers to information carried in IP
and higher layer protocol headers.  The 6-tuple referred to in this
document is the same as that defined in RFC3290.  Specifically
6-tuple is destination address, source address, IP protocol, source
port, destination port, and differentiated services (DiffServ) code
point (DSCP).  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 of DiffServ and "tuple" based flow identification.  Note
that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP
component.
Paragraph (version A):
For some of the protocols 5-tuples and 6-tuples cannot be used
because the port information is not available (e.g., ICMP, IPSec
ESP).  Same can be valid for flow aggregates.  In such cases using
smaller tuples are appropriate, e.g., a 3-tuple (2 IP addresses, IP
protocol) or even a 2-tuple (all IP traffic between two IP
addresses).
Paragraph (version A):
Non-DetNet and DetNet IP packets are identical on the wire.
Generally the fields used in flow identification are forwarded
unmodified, however modification of these fields is allowed, for
example changing the DSCP value, when required by the DetNet service.
Paragraph (version B):
For some of the protocols 5-tuples and 6-tuples cannot be used
because the port information is not available (e.g., ICMP, IPSec
ESP).  This is also the case for flow aggregates.  In such cases,
using fewer fields is appropriate, e.g., a 3-tuple (2 IP addresses,
IP protocol) or even a 2-tuple (all IP traffic between two IP
addresses).
Paragraph (version B):
Non-DetNet and DetNet IP packets have the same protocol header format
on the wire.  Generally the fields used in flow identification are
forwarded unmodified.  However, standard modification of the DSCP
field RFC2474 is not precluded.
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 within the DetNet domain 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 (Packet Replication,
Elimination and Ordering Function).
Paragraph (version B):
The specific procedures that are required to be implemented by a
DetNet node supporting this document can be found in ip-procs.  The
DetNet controller plane, as defined in RFC8655, is responsible for
providing each node with the information needed to identify and
handle each DetNet flow.
Paragraph (version B):
fig_ip_detnet_simple illustrates a DetNet enabled IP network.  The
DetNet enabled end systems originate IP encapsulated traffic that is
identified within the DetNet domain as DetNet flows based on IP
header information.  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 (Packet Replication, Elimination and Ordering Function).
Paragraph (version A):
Note, that fig_ip_detnet_simple and fig_non_detnet_ip can be
collapsed, so IP DetNet End Systems can communicate over DetNet IP
network with IP End System.
Paragraph (version A):
As 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 flow 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.  TSN over MPLS is
discribed in I-D.ietf-detnet-tsn-vpn-over-mpls.
Paragraph (version A):
This section provides informative considerations related to providing
DetNet service to flows which are identified based on their header
information.
Paragraph (version B):
Note that fig_ip_detnet_simple and fig_non_detnet_ip can be
collapsed, so IP DetNet End Systems can communicate over a DetNet IP
network with IP End Systems.
Paragraph (version B):
As non-DetNet and DetNet IP packets have the same protocol header
format on the wire, from a 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
flow receives the proper traffic treatment within the domain.
Paragraph (version B):
Note: The operation of IEEE802.1 TSN end systems over DetNet enabled
IP networks is not described in this document.  TSN over MPLS is
described in I-D.ietf-detnet-tsn-vpn-over-mpls.
Paragraph (version B):
This section provides considerations related to providing DetNet
service to flows which are identified based on their header
information.
Paragraph (version A):
Data-flows requiring DetNet service are generated and terminated on
end systems.  This document deals only with IP end systems.  The
protocols used by an IP end system are specific to an application,
and end systems peer with other end systems.  DetNet's use of 6-tuple
IP flow identification means that DetNet must be aware of not only
the format of the IP header, but also of the next protocol carried
within an IP packet (see nxt-proto-field).
Paragraph (version A):
When IP end systems are DetNet-aware, no application-level or
service-level proxy functions are needed inside the DetNet domain.
For DetNet unaware IP end systems service-level proxy functions are
needed inside the DetNet domain.
Paragraph (version A):
End systems need to ensure that DetNet service requirements are met
when processing packets associated to a DetNet flow.  When forwarding
packets, this means that packets are appropriately shaped on
transmission and receive appropriate traffic treatment on the
connected sub-network, see QoS and dn_dom_spec_cons for more details.
When receiving packets, this means that there are appropriate local
node resources, e.g., buffers, to receive and process the packets of
that DetNet flow.
Paragraph (version B):
Data-flows requiring DetNet service are generated and terminated on
end systems.  This document deals only with IP end systems.  The
protocols used by an IP end system are specific to an application,
and end systems peer with other end systems.  DetNet's use of 6-tuple
IP flow identification means that DetNet must be aware of not only
the format of the IP header, but also of the next protocol value
carried within an IP packet (see nxt-proto-field).
Paragraph (version B):
For DetNet unaware IP end systems service-level proxy functions are
needed inside the DetNet domain.
Paragraph (version B):
When IP end systems are DetNet-aware, no application-level or
service-level proxy functions are needed inside the DetNet domain.
End systems need to ensure that DetNet service requirements are met
when processing packets associated to a DetNet flow.  When sending
packets, this means that packets are appropriately shaped on
transmission and receive appropriate traffic treatment on the
connected sub-network; see QoS and dn_dom_spec_cons for more details.
When receiving packets, this means that there are appropriate local
node resources, e.g., buffers, to receive and process the packets of
that DetNet flow.
Paragraph (version B):
An important additional consideration for DetNet-aware end systems is
avoiding IP fragmentation.  Full 6-tuple flow identification is not
possible on IP fragments as fragments don't include the transport
headers or their port information.  As such, it is important that
applications and/or end-systems use an IP packet size that will avoid
fragmentation within the network when sending DetNet flows.  The
maximum size can be learned via path MTU discovery, RFC1192 and
RFC8201, or via the controller plane.  Note that path MTU discovery
relies on ICMP, which may not follow the same path as an individual
DetNet flow.
Paragraph (version A):
As a general rule, DetNet IP domains need to be able to forward any
DetNet flow identified by the IP 6-tuple.  Doing otherwise would
limit the number of 6-tuple flow ID combinations that could be used
by the end systems.  From a practical standpoint this means that all
nodes along the end-to-end path of DetNet flows need to agree on what
fields are used for flow identification.
Paragraph (version B):
As a general rule, DetNet IP domains need to be able to forward any
DetNet flow identified by the IP 6-tuple.  Doing otherwise would
limit the number of 6-tuple flow ID combinations that could be used
by the end systems.  From a practical standpoint this means that all
nodes along the end-to-end path of DetNet flows need to agree on what
fields are used for flow identification.  Possible consequences of
not having such an agreement include some flows interfering with
other flows, and the traffic treatment expected for a service not
being provided.
Paragraph (version A):
L3 (IP) end systems may use any of these connection types.  A DetNet
domain allows communication between any end-systems using the same
encapsulation format, independent of their connection type and DetNet
capability.  DN attached end systems have no knowledge about the
DetNet domain and its encapsulation format.  See fig_es_con_types for
L3 end system connection examples.
Paragraph (version B):
L3 (IP) end systems may use any of these connection types.  A DetNet
domain allows communication between any end systems using the same
encapsulation format, independent of their connection type and DetNet
capability.  DN attached end systems have no knowledge about the
DetNet domain and its encapsulation format.  See fig_es_con_types for
L3 end system connection examples.
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 protection (packet replication and packet
elimination functions) is not provided at the DetNet layer end to
end.  Instead 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 6-tuple to find out the
required mapping within a node.
Paragraph (version A):
As noted earlier, service protection must be implemented within each
link / sub-network independently, using the domain specific
mechanisms.  This is due to the lack of unified end-to-end sequencing
information that could be used by the intermediate nodes.  Therefore,
service protection (if enabled) 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.  "R" and "E" denotes replication and
elimination points within the sub-network.
Paragraph (version A):
If end to end service protection is desired, it can be implemented,
for example, by the DetNet end systems using Layer-4 (L4) transport
protocols or application protocols.  However, these protocols are out
of scope of this document.
Paragraph (version B):
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-network specific mechanisms.
However, service protection (packet replication and packet
elimination functions) is not provided at the DetNet layer end-to-
end.  Instead service protection can be provided on a per underlying
L2 link and sub-network basis.
Paragraph (version B):
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 6-tuple to find out the
required mapping within a node.
Paragraph (version B):
As noted earlier, service protection must be implemented within each
link/sub-network independently, using the domain specific mechanisms.
This is due to the lack of unified end-to-end sequencing information
that could be used by the intermediate nodes.  Therefore, service
protection (if enabled) 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.  "R" and "E" denote replication and
elimination points within the sub-network.
Paragraph (version B):
If end-to-end service protection is desired, it can be implemented,
for example, by the DetNet end systems using Layer-4 (L4) transport
protocols or application protocols.  However, these protocols are out
of scope of this document.
Paragraph (version A):
Quality of Service (QoS) for DetNet service flows carried in IP MUST
be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows.  Such support leverages the underlying network layer
such as 802.1 TSN.  The traffic control mechanisms used to deliver
QoS for IP encapsulated DetNet flows are expected to be defined in a
future document.  From an encapsulation perspective, the combination
of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
previously mentioned optional field (i.e., flow label), uniquely
identifies a DetNet IP flow.
Paragraph (version B):
Quality of Service (QoS) for DetNet service flows carried in IP must
be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows.  Such support leverages the underlying network layer
such as 802.1 TSN.  The node-internal traffic control mechanisms used
to deliver QoS for IP encapsulated DetNet flows are outside the scope
of this document.  From an encapsulation perspective, the combination
of the 6-tuple (the typical 5-tuple enhanced with the DSCP) and
optionally the flow label uniquely identifies a DetNet IP flow.
Paragraph (version A):
Remarking packets associated with an incomplete reservation.
Remarking can be accomplished by changing the value of the DSCP
field to a value that results in the packet no longer matching any
other reserved DetNet IP flow.
Paragraph (version B):
Re-marking packets associated with an incomplete reservation.  Re-
marking can be accomplished by changing the value of the DSCP
field to a value that results in the packet no longer matching any
other reserved DetNet IP flow.
Paragraph (version A):
While path selection algorithms and mechanisms are out of scope of
the DetNet data plane definition, it is important to highlight the
implications of DetNet IP flow identification on path selection and
next hops.  As mentioned above, the DetNet IP data plane identifies
flows using "6-tuple" header information as well as the additional
optional header field.  DetNet generally allows for both flow-
specific traffic treatment and flow-specific next-hops.
Paragraph (version B):
While path selection algorithms and mechanisms are out of scope of
the DetNet data plane definition, it is important to highlight the
implications of DetNet IP flow identification on path selection and
next hops.  As mentioned above, the DetNet IP data plane identifies
flows using "6-tuple" header information as well as the optional
(flow label) header field.  DetNet generally allows for both flow-
specific traffic treatment and flow-specific next-hops.
Paragraph (version A):
Care should be taken when using different next hops for the same
5-tuple.  As discussed in RFC7657, unexpected behavior can occur when
a single 5-tuple application flow experience reordering due to being
split across multiple next hops.  Understanding of the application
and transport protocol impact of using different next hops for the
same 6-tuple is required.  Again, this impacts path selection for
DetNet flows and this document only indirectly.
Paragraph (version B):
Care should be taken when using different next hops for the same
5-tuple.  As discussed in RFC7657, unexpected behavior can occur when
a single 5-tuple application flow experiences reordering due to being
split across multiple next hops.  Understanding of the application
and transport protocol impact of using different next hops for the
same 5-tuple is required.  Again, this impacts path selection for
DetNet flows and this document only indirectly.
Paragraph (version A):
From a single node perspective, the aggregation of IP flows impacts
DetNet IP data plane flow identification and resource allocation.  As
discussed above, IP flow identification uses the IP "6-tuple" for
flow identification.  DetNet IP flows can be aggregated using any of
the 6-tuple, and an additional optional field (i.e., flow label).
The use of prefixes, wildcards, lists, and value ranges allows a
DetNet node to identify aggregate DetNet flows.  From a resource
allocation perspective, DetNet nodes ought to provide service to an
aggregate rather than on a component flow basis.
Paragraph (version A):
It is the responsibility of the DetNet controller plane to properly
provision the use of these aggregation mechanisms.  This includes
ensuring that aggregated flows have compatible e.g., the same or very
similar QoS and/or CoS characteristics, see QoS.  It also includes
ensuring that per component-flow service requirements are satisfied
by the aggregate, see ip-svc.
Paragraph (version A):
While the DetNet IP data plane must support bidirectional DetNet
flows, there are no special bidirectional features with respect to
the data plane other than the need for the two directions of a co-
routed bidirectional flow to take the same path.  That is to say that
bidirectional DetNet flows are solely represented at the management
and control plane levels, without specific support or knowledge
within the DetNet data plane.  Fate sharing and associated or co-
routed bidirectional flows can be managed at the control level.
Paragraph (version B):
From a single node perspective, the aggregation of IP flows impacts
DetNet IP data plane flow identification and resource allocation.  As
discussed above, IP flow identification uses the IP "6-tuple" for
flow identification.  DetNet IP flows can be aggregated using any of
the 6-tuple fields and optionally also by the flow label.  The use of
prefixes, wildcards, lists, and value ranges allows a DetNet node to
identify aggregate DetNet flows.  From a resource allocation
perspective, DetNet nodes ought to provide service to an aggregate
rather than on a component flow basis.
Paragraph (version B):
It is the responsibility of the DetNet controller plane to properly
provision the use of these aggregation mechanisms.  This includes
ensuring that aggregated flows have compatible (e.g., the same or
very similar) QoS and/or CoS characteristics, see QoS.  It also
includes ensuring that per component-flow service requirements are
satisfied by the aggregate, see ip-svc.
Paragraph (version B):
The DetNet controller plane MUST ensure that non-congestion-
responsive DetNet traffic is not forwarded outside a DetNet domain.
Paragraph (version B):
While the DetNet IP data plane must support bidirectional DetNet
flows, there are no special bidirectional features within the data
plane.  The special case of co-routed bidirectional DetNet flows are
solely represented at the management and control plane levels,
without specific support or knowledge within the DetNet data plane.
Fate sharing and associated or co-routed bidirectional flows can be
managed at the control level.
Paragraph (version A):
This section provides DetNet IP data plane procedures.  These
procedures have been divided into the following areas: flow
identification, forwarding and traffic treatment.  Flow
identification includes those procedures related to matching IP and
higher layer protocol header information to DetNet flow (state)
information and service requirements.  Flow identification is also
sometimes called Traffic classification, for example see RFC5777.
Forwarding includes those procedures related to next hop selection
and delivery.  Traffic treatment includes those procedures related to
providing an identified flow with the required DetNet service.
Paragraph (version B):
This section provides DetNet IP data plane procedures.  These
procedures have been divided into the following areas: flow
identification, forwarding and traffic treatment.  Flow
identification includes those procedures related to matching IP and
higher layer protocol header information to DetNet flow (state)
information and service requirements.  Flow identification is also
sometimes called Traffic classification; for example see RFC5777.
Forwarding includes those procedures related to next hop selection
and delivery.  Traffic treatment includes those procedures related to
providing an identified flow with the required DetNet service.
Paragraph (version A):
IP and higher layer protocol header information is used to identify
DetNet flows.  All DetNet implementations that support this document
MUST identify individual DetNet flows based on the set of information
identified in this section.  Note, that additional flow
identification requirements, e.g., to support other higher layer
protocols, may be defined in the future.
Paragraph (version B):
IP and higher layer protocol header information is used to identify
DetNet flows.  All DetNet implementations that support this document
MUST identify individual DetNet flows based on the set of information
identified in this section.  Note that additional flow identification
requirements, e.g., to support other higher layer protocols, may be
defined in the future.
Paragraph (version A):
Implementations of this document MUST support DetNet flow
identification based on the Source Address field of an IP packet.
Implementations SHOULD support longest prefix matching for this
field, see RFC1812 and RFC7608.  Note that a prefix length of zero
(0) effectively means that the field is ignored.
Paragraph (version A):
Implementations of this document MUST support DetNet flow
identification based on the Destination Address field of an IP
packet.  Implementations SHOULD support longest prefix matching for
this field, see RFC1812 and RFC7608.  Note that a prefix length of
zero (0) effectively means that the field is ignored.
Paragraph (version B):
Implementations of this document MUST support DetNet flow
identification based on the Source Address field of an IP packet.
Implementations SHOULD support longest prefix matching for this field
(see RFC1812 and RFC7608.)  Note that a prefix length of zero (0)
effectively means that the field is ignored.
Paragraph (version B):
Implementations of this document MUST support DetNet flow
identification based on the Destination Address field of an IP
packet.  Implementations SHOULD support longest prefix matching for
this field (see RFC1812 and RFC7608.)  Note that a prefix length of
zero (0) effectively means that the field is ignored.
Paragraph (version A):
Implementations of this document MUST support DetNet flow
identification based on the IPv4 Protocol field when processing IPv4
packets, and the IPv6 Next Header Field when processing IPv6 packets.
An implementation MUST support flow identification based on the next
protocol values defined in nxt-proto.  Other, non-zero values, MUST
be used for flow identification.  Implementations SHOULD allow for
these fields to be ignored for a specific DetNet flow.
Paragraph (version B):
Implementations of this document MUST support DetNet flow
identification based on the IPv4 Protocol field when processing IPv4
packets, and the IPv6 Next Header Field when processing IPv6 packets.
This includes the next protocol values defined in nxt-proto and any
other value, including zero.  Implementations SHOULD allow for these
fields to be ignored for a specific DetNet flow.
Paragraph (version A):
These fields are used to support Differentiated Services RFC2474
RFC2475.  Implementations of this document MUST support DetNet flow
identification based on the DSCP field in the IPv4 Type of Service
field when processing IPv4 packets, and the DSCP field in the IPv6
Traffic Class Field when processing IPv6 packets.  Implementations
MUST support list based matching of DSCP values, where the list is
composed of possible field values that are to be considered when
identifying a specific DetNet flow.  Implementations SHOULD allow for
this field to be ignored for a specific DetNet flow.
Paragraph (version B):
These fields are used to support Differentiated Services RFC2474
RFC2475.  Implementations of this document MUST support DetNet flow
identification based on the DSCP field in the IPv4 Type of Service
field when processing IPv4 packets, and the DSCP field in the IPv6
Traffic Class Field when processing IPv6 packets.  Implementations
MUST support list-based matching of DSCP values, where the list is
composed of possible field values that are to be considered when
identifying a specific DetNet flow.  Implementations SHOULD allow for
this field to be ignored for a specific DetNet flow.
Paragraph (version A):
Implementations of this document SHOULD support identification of
DetNet flows based on the IPv6 Flow Label field.  Implementations
that support matching based on this field MUST allow for this field
to be ignored for a specific DetNet flow.  When this field is used to
identify a specific DetNet flow, implementations MAY exclude the IPv6
Next Header field and next header information as part of DetNet flow
identification.
Paragraph (version B):
Implementations of this document SHOULD support identification of
DetNet flows based on the IPv6 Flow Label field.  Implementations
that support matching based on this field MUST allow for it to be
ignored for a specific DetNet flow.  When this field is used to
identify a specific DetNet flow, implementations MAY exclude the IPv6
Next Header field and next header information as part of DetNet flow
identification.
Paragraph (version A):
DetNet flow identification for ICMP is achieved based on the
protocol's header.  Note that ICMP type is not included in the flow
definition.
Paragraph (version B):
DetNet flow identification for ICMP RFC0792 is achieved based on the
protocol number in the IP header.  Note that ICMP type is not
included in the flow definition.
Paragraph (version A):
General requirements for IP nodes are defined in RFC1122, RFC1812 and
RFC8504, and are not modified by this document.  The typical next-hop
selection process is impacted by DetNet.  Specifically,
implementations of this document SHALL use management and control
information to select the one or more outgoing interfaces and next
hops to be used for a packet associated with a DetNet flow.
Paragraph (version B):
General requirements for IP nodes are defined in RFC1122, RFC1812 and
RFC8504, and are not modified by this document.  The typical next-hop
selection process is impacted by DetNet.  Specifically,
implementations of this document SHALL use management and control
information to select the one or more outgoing interfaces and next
hops to be used for a packet associated with a DetNet flow.  Specific
management and control information will be defined in future
documents, e.g., I-D.ietf-detnet-yang.
Paragraph (version A):
Implementations of this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via I-D.ietf-detnet-
yang.  General information on DetNet service can be found in I-
D.ietf-detnet-flow-information-model.  Typical mechanisms used to
provide different treatment to different flows includes the
allocation of system resources (such as queues and buffers) and
provisioning or related parameters (such as shaping, and policing).
Support can also be provided via an underlying network technology
such as MPLS I-D.ietf-detnet-ip-over-mpls or IEEE802.1 TSN I-D.ietf-
detnet-ip-over-tsn.  Other mechanisms than the ones used in the TSN
case are outside the scope of this document.
Paragraph (version B):
Implementations of this document must ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via I-D.ietf-detnet-
yang.  General information on DetNet service can be found in I-
D.ietf-detnet-flow-information-model.  Typical mechanisms used to
provide different treatment to different flows includes the
allocation of system resources (such as queues and buffers) and
provisioning of related parameters (such as shaping, and policing).
Support can also be provided via an underlying network technology
such as MPLS I-D.ietf-detnet-ip-over-mpls or IEEE802.1 TSN I-D.ietf-
detnet-ip-over-tsn.  Other mechanisms than the ones used in the TSN
case are outside the scope of this document.
Paragraph (version A):
IPv4 protocol field.  A limited set of values is allowed, and the
ability to ignore this field, e.g., via configuration of the value
zero (0), is desirable.
Paragraph (version A):
IPv6 next header field.  A limited set of values is allowed, and
the ability to ignore this field, e.g., via configuration of the
value zero (0), is desirable.
Paragraph (version B):
IPv4 protocol field.  A limited set of values is allowed, and the
ability to ignore this field is desirable.
Paragraph (version B):
IPv6 next header field.  A limited set of values is allowed, and
the ability to ignore this field is desirable.
Paragraph (version A):
IPv6 flow label field.  This field can be optionally used for
matching.  When used, can be used instead of matching against the
Next Header field.
Paragraph (version A):
TCP and UDP Source Port.  Exact and wildcard matching is required.
Port ranges can optionally be used.
Paragraph (version A):
TCP and UDP Destination Port.  Exact and wildcard matching is
required.  Port ranges can optionally be used.
Paragraph (version B):
IPv6 flow label field.  This field can be optionally used for
matching.  When used, this field can be used instead of matching
against the Next Header field.
Paragraph (version B):
TCP and UDP Source Port.  Support for both exact and wildcard
matching is required.  Port ranges can optionally be used.
Paragraph (version B):
TCP and UDP Destination Port.  Support for both exact and wildcard
matching is required.  Port ranges can optionally be used.
Paragraph (version B):
For end systems, an optional maximum IP packet size that should be
used for that outgoing DetNet IP flow.
Paragraph (version B):
An implementation MUST support ordering of the set of information
information used to identify an individual DetNet flow.  This can,
for example, be used to provide a DetNet service for a specific UDP
flow, with unique Source and Destination Port field values, while
providing a different service for the aggregate of all other flows
with that same UDP Destination Port value.
Paragraph (version A):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.  This section considers exclusively security
considerations which are specific to the DetNet IP data plane.
Paragraph (version B):
Detailed security considerations for DetNet are cataloged in I-
D.ietf-detnet-security, and more general security considerations are
described in RFC8655.  This section considers exclusively security
considerations which are specific to the DetNet IP data plane.
Paragraph (version B):
Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.  Achieving such loss rates
and bounded latency may not be possible in the face of a highly
capable adversary, such as the one envisioned by the Internet Threat
Model of BCP 72 that can arbitrarily drop or delay any or all
traffic.  In order to present meaningful security considerations, we
consider a somewhat weaker attacker who does not control the physical
links of the DetNet domain, but may have the ability to control a
network node within the boundary of the DetNet domain.
Paragraph (version B):
The primary consideration for the DetNet data plane is to maintain
integrity of data and delivery of the associated DetNet service
traversing the DetNet network.  Since no DetNet-specific fields are
available in the DetNet IP data plane, the integrity and
confidentiality of application flows can be protected through
whatever means are provided by the underlying technology.  For
example, encryption may be used, such as that provided by IPSec
RFC4301 for IP flows and/or by an underlying sub-net using MACSec
IEEE802.1AE-2018 for IP over Ethernet (Layer-2) flows.
Paragraph (version B):
To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks.  To
protect against DOS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated, for example
through the use of existing mechanism such as policing and shaping
applied at the input of a DetNet domain or within an edge IEEE802.1
TSN domain.  To prevent DetNet packets from being delayed by an
entity external to a DetNet domain, DetNet technology definition can
allow for the mitigation of Man-In-The-Middle attacks, for example
through use of authentication and authorization of devices within the
DetNet domain.