Draft: draft-ietf-detnet-data-plane-framework

Commentary: All comments received before 04 - 27 are resolved
Paragraph (version A):
This document provides an overall framework for the DetNet data
plane.  It covers concepts and considerations that are generally
common to any Deterministic Networking data plane specification.
Paragraph (version B):
This document provides an overall framework for the DetNet data
plane.  It covers concepts and considerations that are generally
common to any Deterministic Networking data plane specification.  It
describes related controller plane considerations as well.
Paragraph (version A):
The DetNet Architecture models the DetNet related data plane
functions decomposed 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
leverages Traffic Engineering mechanisms and provides congestion
protection (low loss, assured latency, and limited out-of-order
delivery).  A particular forwarding sub-layer may have capabilities
that are not available on other forwarding-sub layers.  DetNet makes
use of the existing forwarding sub-layers with their respective
capabilities and does not require 1:1 equivalence between different
forwarding sub-layer capabilities.
Paragraph (version B):
The DetNet Architecture models the DetNet related data plane
functions as being decomposed 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 leverages Traffic Engineering mechanisms and provides
congestion protection (low loss, assured latency, and limited out-of-
order delivery).  A particular forwarding sub-layer may have
capabilities that are not available on other forwarding-sub layers.
DetNet makes use of the existing forwarding sub-layers with their
respective capabilities and does not require 1:1 equivalence between
different forwarding sub-layer capabilities.
Paragraph (version A):
As defined in RFC8655, DetNet flows may be carried over network
technologies that can provide the DetNet required service
characteristics.  For example, DetNet MPLS flows can be carried over
IEEE 802.1 Time Sensitive Network (TSN) IEEE802.1TSNTG sub-networks.
However, IEEE 802.1 TSN support is not required in DetNet.  TSN frame
preemption is an example of a forwarding layer capability that is
typically not replicated in other forwarding technologies.  Most of
DetNet benefits can be gained by running over a data link layer that
has not been specifically enhanced to support all TSN capabilities
but for certain networks and traffic mixes delay and jitter
performance may vary due to the forwarding sub-layer intrinsic
properties.
Paragraph (version B):
As defined in RFC8655, DetNet flows may be carried over network
technologies that can provide the DetNet required service
characteristics.  For example, DetNet MPLS flows can be carried over
IEEE 802.1 Time Sensitive Network (TSN) IEEE802.1TSNTG sub-networks.
However, IEEE 802.1 TSN support is not required in DetNet.  TSN frame
preemption is an example of a forwarding layer capability that is
typically not replicated in other forwarding technologies.  Most of
DetNet benefits can be gained by running over a data link layer that
has not been specifically enhanced to support all TSN capabilities
but for such networks and traffic mixes delay and jitter performance
may vary due to the forwarding sub-layer intrinsic properties.
Paragraph (version A):
The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer.  An example of
this is Packet Replication, Elimination, and Ordering functions see
PREOF.  The ordering function (POF) uses sequence numbers added to
packets enabling a range of packet order protection from simple
ordering and dropping out-of-order packets to more complex reordering
of a fixed number of out-of-order, minimally delayed packets.
Reordering requires buffer resources and has impact on the delay and
jitter of packets in the DetNet flow.
Paragraph (version A):
The method of instantiating each of the layers is specific to the
particular DetNet data plane method, and more than one approach may
be applicable to a given bearer network type.
Paragraph (version B):
The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer.  See PREOF as an
example for Packet Replication, Elimination, and Ordering functions.
The ordering function (POF) uses sequence numbers added to packets
enabling a range of packet order protection from simple ordering and
dropping out-of-order packets to more complex reordering of a fixed
number of out-of-order, minimally delayed packets.  Reordering
requires buffer resources and has impact on the delay and jitter of
packets in the DetNet flow.
Paragraph (version B):
The method of instantiating each of the layers is specific to the
particular DetNet data plane method, and more than one approach may
be applicable to a given network type.
Paragraph (version A):
The DetNet data plane is provided by the DetNet service and
forwarding sub layers.  The DetNet service sub-layer generally
provides its functions for the DetNet application flows by using or
applying existing standardized headers and/or encapsulations.  The
Detnet forwarding sub-layer may provide capabilities leveraging that
same header or encapsulation technology (e.g., DN IP or DN MPLS) or
it may be achieved by other technologies (e.g., dn_svc_encaps).
DetNet is currently defined for operation over packet-switched (IP)
networks or label-switched (MPLS) networks.
Paragraph (version B):
The DetNet data plane is provided by the DetNet service and
forwarding sub layers.  The DetNet service sub-layer generally
provides its functions for the DetNet application flows by using or
applying existing standardized headers and/or encapsulations.  The
Detnet forwarding sub-layer may provide capabilities leveraging that
same header or encapsulation technology (e.g., DN IP or DN MPLS) or
it may be achieved by other technologies as shown in dn_svc_encaps.
DetNet is currently defined for operation over packet-switched (IP)
networks or label-switched (MPLS) networks.
Paragraph (version A):
DetNet encodes specific flow attributes (flow identity and sequence
number) in packets.  For example, in DetNet IP, zero encapsulation is
used and no sequence number is available, and in DetNet MPLS, DetNet-
specific information may be added explicitly to the packets in the
format of S-label and d-CW I-D.ietf-detnet-mpls .
Paragraph (version B):
DetNet encodes specific flow attributes (flow identity and sequence
number) in packets.  For example, in DetNet IP, zero encapsulation is
used and no sequence number is available, and in DetNet MPLS, DetNet-
specific information may be added explicitly to the packets in the
form of S-label and d-CW I-D.ietf-detnet-mpls .
Paragraph (version A):
The DetNet data plane framework supports a Flow-ID (for
identification of the flow or aggregate flow) and/or a Sequence
Number (for PREOF) for each DetNet flow.  The DetNet Service sub-
layer requires both; the DetNet forwarding sub-layer requires only
Flow-ID.  Metadata can also be used for OAM indications and
instrumentation of DetNet data plane operation.
Paragraph (version B):
The DetNet data plane framework supports a Flow-ID (for
identification of the flow or aggregate flow) and/or a Sequence
Number (for PREOF) for each DetNet flow.  The Flow-ID is used by both
the service and forwarding sub-layers, but the sequence number is
only used by the service layer.  Metadata can also be used for OAM
indications and instrumentation of DetNet data plane operation.
Paragraph (version A):
Some MPLS examples of implicit metadata include the sequence number
for use by the PREOF function, or even all the essential information
being included into the DetNet over MPLS label stack (the DetNet
Control Word and the DetNet Service label).
Paragraph (version B):
An MPLS example of explicit metadata is the sequence number used by
the PREOF function, or even the case where all the essential
information being included into the DetNet over MPLS label stack (the
DetNet Control Word and the DetNet Service label).
Paragraph (version A):
Use of packet-by-packet distribution of the same DetNet flow over
multiple paths is not recommended except for the cases listed above
where PREOF is utilized to improve protection of traffic and maintain
order.  Packet by packet load sharing, e.g., via ECMP or UCMP,
impacts ordering and possibly jitter.
Paragraph (version B):
Use of packet-by-packet load sharing of the same DetNet flow over
multiple paths is not recommended except for the cases listed above
where PREOF is utilized to improve protection of traffic and maintain
order.  Packet-by-packet load sharing, e.g., via ECMP or UCMP,
impacts ordering and possibly jitter.
Paragraph (version A):
IP aggregation has both data plane and controller plane aspects.  For
the data plane, flows may be aggregated for treatment based on shared
characteristics such as 6-tuple.  Alternatively, an IP encapsulation
may be used to tunnel an aggregate number of DetNet Flows between
relay nodes.
Paragraph (version B):
IP aggregation has both data plane and controller plane aspects.  For
the data plane, flows may be aggregated for treatment based on shared
characteristics such as 6-tuple I-D.ietf-detnet-ip.  Alternatively,
an IP encapsulation may be used to tunnel an aggregate number of
DetNet Flows between relay nodes.
Paragraph (version A):
However, from a practical and implementation standpoint, they are not
equivalent at all.  Some approaches are more scalable than others in
terms of signaling load on the network.  Some can take advantage of
global tracking of resources in the DetNet domain for better overall
network resource optimization.  Some are more resilient than others
if link, node, or management equipment failures occur.  While a
detailed analysis of the control plane alternatives is out of the
scope of this document, the requirements from this document can be
used as the basis of a later analysis of the alternatives.
Paragraph (version B):
However, from a practical and implementation standpoint, controller
plane alternatives are not equivalent at all.  Some approaches are
more scalable than others in terms of signaling load on the network.
Some alternatives can take advantage of global tracking of resources
in the DetNet domain for better overall network resource
optimization.  Some solutions are more resilient than others if link,
node, or management equipment failures occur.  While a detailed
analysis of the control plane alternatives is out of the scope of
this document, the requirements from this document can be used as the
basis of a later analysis of the alternatives.
Paragraph (version A):
Explicit routes are used to ensure that packets are routed through
the resources that have been reserved for them, and hence provide the
DetNet application with the required service.  A requirement for the
DetNet Controller Plane will be the ability to assign a particular
identified DetNet IP flow to a path through the DetNet domain that
has been assigned the required nodal resources.  This provides the
appropriate traffic treatment for the flow and also includes
particular links as a part of the path that are able to support the
DetNet flow.  For example, by using IEEE 802.1 TSN links (as
discussed in I-D.ietf-detnet-mpls-over-tsn ) DetNet parameters can be
maintained.  Further considerations and requirements for the DetNet
Controller Plane are discussed in control-management-requirements.
Paragraph (version B):
Explicit routes are used to ensure that packets are routed through
the resources that have been reserved for them, and hence provide the
DetNet application with the required service.  A requirement for the
DetNet Controller Plane will be the ability to assign a particular
identified DetNet IP flow to a path through the DetNet domain that
has been assigned the required per-node resources.  This provides the
appropriate traffic treatment for the flow and also includes
particular links as a part of the path that are able to support the
DetNet flow.  For example, by using IEEE 802.1 TSN links (as
discussed in I-D.ietf-detnet-mpls-over-tsn ) DetNet parameters can be
maintained.  Further considerations and requirements for the DetNet
Controller Plane are discussed in control-management-requirements.
Paragraph (version A):
See control-management-requirements for further discussion of these
alternatives.  In addition, RFC2386 contains useful background
information on QoS-based routing, and RFC5575 discusses a specific
mechanism used by BGP for traffic flow specification and policy-based
routing.
Paragraph (version B):
See control-management-requirements for further discussion of these
alternatives.  In addition, RFC2386 contains useful background
information on QoS-based routing, and RFC5575 (being updated by I-
D.ietf-idr-rfc5575bis) discusses a specific mechanism used by BGP for
traffic flow specification and policy-based routing.
Paragraph (version A):
The controller plane protocol solution required for managing the
PREOF processing is outside the scope of this document.  That said,
it should be noted that the ability to determine, for a particular
flow, optimal packet replication and elimination points in the DetNet
domain requires explicit support.  There may be capabilities that can
be used, or extended, for example GMPLS end-to-end recovery RFC4872
and GMPLS segment recovery RFC4873.
Paragraph (version A):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations for DetNet
architecture are described in RFC8655.  This section considers
general security considerations applicable to all data planes.
Paragraph (version A):
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.
Paragraph (version A):
The primary consideration for the data plane is to maintain integrity
of data and delivery of the associated DetNet service traversing the
DetNet network.  Application flows can be protected through whatever
means is 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 Ethernet (Layer-2) flows.
Paragraph (version B):
The controller plane protocol solution required for managing the
PREOF processing is outside the scope of this document.  That said,
it should be noted that the ability to determine, for a particular
flow, optimal packet replication and elimination points in the DetNet
domain requires explicit support.  There may be existing capabilities
that can be used, or extended, for example GMPLS end-to-end recovery
RFC4872 and GMPLS segment recovery RFC4873.
Paragraph (version B):
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations for DetNet
architecture are described in RFC8655.  This section considers
architecture-level DetNet security considerations applicable to all
data planes.
Paragraph (version B):
Part of what makes DetNet unique is its ability to provide specific
and reliable quality of service (delivering data flows with extremely
low packet loss rates and bounded end-to-end delivery latency), and
the security-related aspects of protecting that quality of service
are similarly unique.
Paragraph (version B):
As for all communications protocols, the primary consideration for
the data plane is to maintain integrity of data and delivery of the
associated DetNet service traversing the DetNet network.  Application
flows can be protected through whatever means is 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 Ethernet (Layer-2) flows.