Draft: draft-ietf-detnet-mpls

Commentary: All comments were replied and fixed as per 8:00pm CET , 09 - 09 - 2020
Paragraph (version A):
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows with
extremely low packet loss rates and assured maximum end-to-end
delivery latency.  General background and concepts of DetNet can be
found in RFC8655.
Paragraph (version B):
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides a capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low data loss rates and bounded latency within a
network domain.  General background and concepts of DetNet can be
found in the DetNet Architecture RFC8655.
Paragraph (version A):
This document specifies the DetNet data plane operation and the on-
wire encapsulation of DetNet flows over an MPLS-based Packet Switched
Network (PSN) using the service reference model.  MPLS encapsulation
already provides a solid foundation of building blocks to enable the
DetNet service and forwarding sub-layer functions.  MPLS encapsulated
DetNet can be carried over a variety of different network
technologies that can provide the DetNet required level of service.
However, the specific details of how DetNet MPLS is carried over
different network technologies is out of scope of this document.
Paragraph (version B):
This document specifies the DetNet data plane operation and the on-
wire encapsulation of DetNet flows over an MPLS-based Packet Switched
Network (PSN) using the service reference model.  MPLS encapsulation
already provides a solid foundation of building blocks to enable the
DetNet service and forwarding sub-layer functions.  MPLS encapsulated
DetNet can be carried over a variety of different network
technologies that can provide the DetNet required level of service.
However, the specific details of how DetNet MPLS is carried over
different network technologies are out of scope of this document.
Paragraph (version A):
A DetNet "service" label that is used between DetNet nodes that
implement also the DetNet service sub-layer functions.  An S-Label
is also used to identify a DetNet flow at DetNet service sub-layer
at a receiving DetNet node.
Paragraph (version B):
A DetNet "service" label that is used between DetNet nodes that
implement the DetNet service sub-layer functions.  An S-Label is
used to identify a DetNet flow at DetNet service sub-layer at a
receiving DetNet node.
Paragraph (version A):
A DetNet control word (d-CW) conforms to the Generic PW MPLS Control
Word (PWMCW) defined in RFC4385.  The d-CW formatted as shown in
fig_detnet_cw MUST be present in all DetNet packets containing app-
flow data.  This format of the d-CW was created in order (1) to allow
larger S/N space to avoid S/N rollover frequency in some applications
and (2) to allow sequence numbering systems that include the value
zero as a valid sequence number, which simplifies implementation.
Paragraph (version B):
A DetNet control word (d-CW) conforms to the Generic PW MPLS Control
Word (PWMCW) defined in RFC4385.  The d-CW formatted as shown in
fig_detnet_cw MUST be present in all DetNet packets containing app-
flow data.  This format of the d-CW was created in order (1) to allow
larger sequence number space to avoid sequence number rollover
frequency in some applications and (2) to allow sequence numbering
systems that include the value zero as a valid sequence number, which
simplifies implementation.
Paragraph (version A):
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) RFC6790
MAY be carried below the S-Label in the label stack in networks where
DetNet flows would otherwise received ECMP treatment.  When ELs are
used, the same EL value SHOULD be used for all of the packets sent
using a specific S-Label to force the flow to follow the same path.
However, as outlined in I-D.ietf-detnet-data-plane-framework the use
of ECMP for DetNet flows is NOT RECOMMENDED.  ECMP MAY be used for
non-DetNet flows within a DetNet domain.
Paragraph (version B):
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) RFC6790
MAY be carried below the S-Label in the label stack in networks where
DetNet flows would otherwise receive ECMP treatment.  When ELs are
used, the same EL value SHOULD be used for all of the packets sent
using a specific S-Label to force the flow to follow the same path.
However, as outlined in I-D.ietf-detnet-data-plane-framework the use
of ECMP for DetNet flows is NOT RECOMMENDED.  ECMP MAY be used for
non-DetNet flows within a DetNet domain.
Paragraph (version A):
When receiving a DetNet MPLS packet, an implementation MUST identify
the DetNet service associated with the incoming packet based on the
S-Label.  When a node is using platform labels for S-Labels, no
additional information is needed as the S-label uniquely identifies
the DetNet service.  In the case where platform labels are not used,
zero or more F-Labels and optionally, the incoming interface,
proceeding the S-Label MUST be used together with the S-Label to
uniquely identify the DetNet service associated with a received
packet.  The incoming interface MAY also be used together with any
present F-Label(s) and the S-Label to uniquely identify an incoming
DetNet service, for example, in the case where PHP is used.  Note
that choice to use platform label space for S-Label or S-Label plus
one or more F-Labels to identify DetNet services is a local
implementation choice, with one caveat.  When one or more F-labels,
or incoming interface, is needed together with an S-Label to uniquely
identify a service, the controller plane must ensure that incoming
DetNet MPLS packets arrive with the needed information (F-label(s)
and/or incoming interface) and provision the needed information.  The
provisioned information MUST then be used to identify incoming DetNet
service based on the combination of S-Label and F-Label(s) or
incoming interface.
Paragraph (version B):
When receiving a DetNet MPLS packet, an implementation MUST identify
the DetNet service associated with the incoming packet based on the
S-Label.  When a node is using platform labels for S-Labels, no
additional information is needed as the S-label uniquely identifies
the DetNet service.  In the case where platform labels are not used,
zero or more F-Labels proceeding the S-Label MUST be used together
with the S-Label to uniquely identify the DetNet service associated
with a received packet.  The incoming interface MAY also be used
together with any present F-Label(s) and the S-Label to uniquely
identify an incoming DetNet service, for example, in the case where
PHP is used.  Note that choice to use platform label space for
S-Label or S-Label plus one or more F-Labels to identify DetNet
services is a local implementation choice, with one caveat.  When one
or more F-labels, or incoming interface, is needed together with an
S-Label to uniquely identify a service, the controller plane must
ensure that incoming DetNet MPLS packets arrive with the needed
information (F-label(s) and/or incoming interface) and provision the
needed information.  The provisioned information MUST then be used to
identify incoming DetNet service based on the combination of S-Label
and F-Label(s) or incoming interface.
Paragraph (version A):
After a DetNet service is identified for a received DetNet MPLS
packet, as described above, an implementation MUST check if PEF is
configured for that DetNet service.  When configured, the
implementation MUST track the sequence number contained in received
d-CWs and MUST ensure that duplicate (replicated) instances of a
particular sequence number are discarded.  The specific mechanisms
used for an implementation to identify which received packets are
duplicates and which are new is an implementation choice.  Note that
per dn-sn the sequence number field length may be 16 or 28 bits, and
the field value can wrap.  PEF MUST NOT be used with DetNet flows
configured with a d-CW sequence number field length of 0 bits.
Paragraph (version A):
Note that an implementation MAY wish to constrain the maximum number
of sequence numbers that are tracked, on platform-wide or per flow
basis.  Some implementations MAY support the provisioning of the
maximum number of sequence numbers that are tracked on either a
platform-wide or per flow basis.
Paragraph (version B):
After a DetNet service is identified for a received DetNet MPLS
packet, as described above, if PEF is configured for that DetNet
service, duplicate (replicated) instances of a particular sequence
number MUST be discarded.  The specific mechanisms used for an
implementation to identify which received packets are duplicates and
which are new is an implementation choice.  Note that per dn-sn the
sequence number field length may be 16 or 28 bits, and the field
value can wrap.  PEF MUST NOT be used with DetNet flows configured
with a d-CW sequence number field length of 0 bits.
Paragraph (version B):
An implementation MAY constrain the maximum number of sequence
numbers that are tracked on either a platform-wide or per flow basis.
Some implementations MAY support the provisioning of the maximum
number of sequence numbers that are tracked on either a platform-wide
or per flow basis.
Paragraph (version A):
A function that is related to in-order delivery is the Packet
Ordering Function (POF).  Implementations MAY support POF.  When
supported, use of the POF for a particular DetNet service MUST be
provisioned via configuration, e.g., via the controller plane
described by I-D.ietf-detnet-data-plane-framework.  Implementations
MAY required that PEF and POF be used in combination.  There is no
requirement related to the order of execution of the Packet
Elimination and Ordering Functions in an implementation.
Paragraph (version A):
After a DetNet service is identified for a received DetNet MPLS
packet, as described above, an implementation MUST check if POF is
configured for that DetNet service.  When configured, the
implementation MUST track the sequence number contained in received
d-CWs and MUST ensure that packets are processed in the order
indicated in the received d-CW sequence number field, which may not
be in the order the packets are received.  As defined in dn-sn the
sequence number field length may be 16 or 28 bits, is incremented by
one (1) for each new MPLS packet sent for a particular DetNet
service, and the field value can wrap.  The specific mechanisms used
for an implementation to identify the order of received packets is an
implementation choice.
Paragraph (version A):
Note that an implementation MAY wish to constrain the maximum number
of out of order packets that can be processed, on platform-wide or
per flow basis.  Some implementations MAY support the provisioning of
this number on either a platform-wide or per flow basis.  The number
of out of order packets that can be processed also impacts the
latency of a flow.
Paragraph (version B):
A function that is related to in-order delivery is the Packet
Ordering Function (POF).  Implementations MAY support POF.  When
supported, use of the POF for a particular DetNet service MUST be
provisioned via configuration, e.g., via the controller plane
described by I-D.ietf-detnet-data-plane-framework.  Implementations
MAY require that PEF and POF be used in combination.  There is no
requirement related to the order of execution of the Packet
Elimination and Ordering Functions in an implementation.
Paragraph (version B):
After a DetNet service is identified for a received DetNet MPLS
packet, as described above, if POF is configured for that DetNet
service, packets MUST be processed in the order indicated in the
received d-CW sequence number field, which may not be in the order
the packets are received.  As defined in dn-sn the sequence number
field length may be 16 or 28 bits, is incremented by one (1) for each
new MPLS packet sent for a particular DetNet service, and the field
value can wrap.  The specific mechanisms used for an implementation
to identify the order of received packets is an implementation
choice.
Paragraph (version B):
An implementation MAY constrain the maximum number of out of order
packets that can be processed, on either a platform-wide or per flow
basis.  The number of out of order packets that can be processed also
impacts the latency of a flow.
Paragraph (version A):
When multiple sets of outgoing F-Labels or interfaces are provisioned
for a particular DetNet service, a copy of the outgoing packet,
including the pushed member flow-specific S-Label, MUST be made per
F-label set and outgoing interface.  Each set of provisioned F-Labels
are then pushed onto a copy of the packet.  Each copy is then
forwarded as described below in f-labels-all.
Paragraph (version B):
When multiple sets of outgoing F-Labels or interfaces are provisioned
for a particular DetNet service (i.e., for PRF), a copy of the
outgoing packet, including the pushed member flow-specific S-Label,
MUST be made per F-label set and outgoing interface.  Each set of
provisioned F-Labels are then pushed onto a copy of the packet.  Each
copy is then forwarded as described below in f-labels-all.
Paragraph (version A):
DetNet flows forwarded via MPLS can leverage MPLS-TE's existing
support for hierarchical LSPs (H-LSPs), see RFC4206.  H-LSPs are
typically used to aggregate control and resources, they may also be
used to provide OAM or protection for the aggregated LSPs.  Arbitrary
levels of aggregation naturally falls out of the definition for
hierarchy and the MPLS label stack RFC3032.  DetNet nodes which
support aggregation (LSP hierarchy) map one or more LSPs (labels)
into and from an H-LSP.  Both carried LSPs and H-LSPs may or may not
use the TC field, i.e., L-LSPs or E-LSPs.  Such nodes will need to
ensure that individual LSPs and H-LSPs receive the traffic treatment
required to ensure the required DetNet service is preserved.
Paragraph (version B):
DetNet flows forwarded via MPLS can leverage MPLS-TE's existing
support for hierarchical LSPs (H-LSPs), see RFC4206.  H-LSPs are
typically used to aggregate control and resources, they may also be
used to provide OAM or protection for the aggregated LSPs.  Arbitrary
levels of aggregation naturally falls out of the definition for
hierarchy and the MPLS label stack RFC3032.  DetNet nodes which
support aggregation (LSP hierarchy) map one or more LSPs (labels)
into and from an H-LSP.  Both carried LSPs and H-LSPs may or may not
use the TC field, i.e., L-LSPs or E-LSPs RFC3270.  Such nodes will
need to ensure that individual LSPs and H-LSPs receive the traffic
treatment required to ensure the required DetNet service is
preserved.
Paragraph (version A):
The sequence number length to be used for the service.  Valid
values included 0, 16 and 28 bits. 0 bits cannot be used when PEF
or POF is configured for the service.
Paragraph (version B):
The sequence number length to be used for the service.  Valid
values include 0, 16 and 28 bits. 0 bits cannot be used when PEF
or POF is configured for the service.
Paragraph (version A):
The traffic parameters associated with a specific label in the
stack.  Note that there may be multiple sets of traffic paramters
associated with specific labels in the stack, e.g., when H-LSPs
are used.
Paragraph (version B):
The traffic parameters associated with a specific label in the
stack.  Note that there may be multiple sets of traffic parameters
associated with specific labels in the stack, e.g., when H-LSPs
are used.
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.  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 A):
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.  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 A):
From a data plane perspective this document does not add or modify
any header information.
Paragraph (version B):
Security aspects which are unique to DetNet are those whose aim is to
protect the support of 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):
An additional consideration for the DetNet 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 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.  MPLS doesn't
provide any native security services to account for confidentiality
and integrity.
Paragraph (version B):
From a data plane perspective this document does not add or modify
any application header information.
Paragraph (version A):
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 is prevented or mitigated through the use of
existing mechanisms, for example by policing and shaping incoming
traffic.  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.
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 is prevented or mitigated through the use of
existing mechanisms, for example by policing and shaping incoming
traffic.  To prevent DetNet packets from being delayed by an entity
external to a DetNet domain, DetNet technology definition can allow
for the mitigation of on-path attackers, for example through use of
authentication and authorization of devices within the DetNet domain.