Draft: draft-ietf-detnet-dp-sol-mpls-02

Commentary: New section 7 text
DetNet flow identification at a DetNet service layer is realized by
an S-label.  The S-label is allocated from the platform label space
RFC3031 which means that the DetNet flow is correctly identified and
matched to the flow parameters, including the flow history,
regardless of which input interface the packet arrives on.  The
S-label MUST be at the bottom label of the label stack for a DetNet-
s- or DetNet-st-flow and MUST precede the d-CW.
DetNet flow identification at a DetNet service layer is realized by
an S-label.  The S-label is allocated from the platform label space
RFC3031 which means that the DetNet flow is correctly identified and
matched to the flow parameters, including the flow history,
regardless of which input interface the packet arrives on.
While the S-Label will usually be at the bottom of the label stack,
immediately preceding the d-DW, there may be cases where there are
additional label stack entries beneath it.  For example, when an OAM
Associated Channel Header (ACH) RFC4385 is carried that applies to
the S-Label, a GAL RFC5586 will be in the label stack below the
S-Label.
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) RFC6790
may be carried below the S-Label in the label stack in order to
control or prevent ECMP treatment for packets in a DetNet flow (the
use of the same EL for all of the packets in a flow forces the flow
to follow the same path when otherwise ECMP is in use in a network).
However, as previously stated in dn-gen-encap-solution, the use of
ECMP in a DetNet domain is not recommended.
While management plane and control planes are traditionally
considered separately, from the Data Plane perspective there is no
practical difference based on the origin of flow provisioning
information.  This document therefore does not distinguish between
information provided by a control plane protocol, e.g., RSVP-TE
RFC3209 and RFC3473, or by a network management mechanisms, e.g.,
RestConf RFC8040 and YANG RFC7950.
The DetNet S-Label distribution follows the same mechanisms specified
for XYZ . The details of the control plane protocol solution required
for the label distribution and the management of the label number
space are out of scope of this document.
While management plane and control planes are traditionally
considered separately, from the Data Plane perspective there is no
practical difference based on the origin of flow provisioning
information.  This document therefore does not distinguish between
information provided by distributed control plane protocols, e.g.,
RSVP-TE RFC3209 and RFC3473, or by centralized network management
mechanisms, e.g., RestConf RFC8040, YANG RFC7950, and the Path
Computation Element Communication Protocol (PCEP) I-D.ietf-pce-pcep-
extension-for-pce-controller.  That said, there are particular
considerations and requirements for DetNet that are discussed in
control-management-requirements.
DetNet S-Labels (see flow-identification for their definition) are
similar to other service labels that denote the contents of the MPLS
packet payload being other than a normal routed IP packet, such as a
layer 2 pseudowire, an IP packet that is routed in a VPN context with
a private address, or an Ethernet virtual private wire service.
Like other service labels, they are allocated by the downstream
receiver of DetNet packets from its platform label space.  S-Labels
uniquely identify a particular DetNet flow, and are local to the node
on which the label is allocated.  They are used to identify the flow
that a packet belongs to as it traverses a particular node in a
DetNet domain.  Because labels are local to each node rather than
being a global identifier within a domain, they must be advertised to
their direct upstream peer nodes.
Much like other MPLS labels, there are a number of alternatives
available for DetNet S-Label advertisement to a DetNet node's
upstream peers.  These include distributed signaling protocols such
as targeted LDP and RSVP-TE and centralized label distribution via a
controller that manages both the sender and the receiver using
NETCONF/YANG, BGP, PCEP, etc.  The details of the control plane
protocol solution required for the label distribution and the
management of the label number space are out of scope of this
document, but as mentioned above, there are particular DetNet
considerations and requirements that are discussed in control-
management-requirements.
The path can be implemented using segment routing.
Where the DetNet traffic is carried over IP detnet-data-plane-
encapsulation-for-ip-transport-networks explicit paths may need to be
provided in the IP layer.  This is for further study.
The control plane protocol solution required for managing the PREOF
processing is outside the scope of this document.
The path can be implemented using MPLS-based segment routing.
See control-management-requirements for further discussion of these
alternatives.
When DetNet traffic is carried over IP (see detnet-data-plane-
encapsulation-for-ip-transport-networks) explicit paths may need to
be provided in the IP layer.  This is for further study.
The control plane protocol solution required for managing the PREOF
processing is outside the scope of this document.  That said, it must
be noted that the ability to determine, for a particular flow, packet
replication and recombination points in the DetNet domain is going to
require enhancements to existing methods of establishing explicit
paths through a network.  There may be capabilities that can be
adopted from technologies like MPLS point-to-multipoint traffic
engineering RFC4875.
As stated in the Introduction, this document does not specify traffic
handling capabilities required to deliver congestion protection and
latency control for DetNet flows at the DetNet transport layer.
However, the ability to manage node and link resources to be able to
provide these functions will be a necessary part of the DetNet
control and management planes.  It will also be necessary to be able
to signal or provision the required queuing disciplines needed to
provide these functions along a flow's path through the network.  See
control-management-requirements for further discussion of these
requirements.
While the IPv6 and MPLS data planes must support bidirectional DetNet
flows, there are no special bidirectional features with respect to
the data plane other than need for the two directions take the same
paths.  Fate sharing and associated vs co-routed bidirectional flows
can be managed at the control level.  Note, that there is no stated
requirement for bidirectional DetNet flows to be supported using the
same IPv6 Flow Labels or MPLS Labels in each direction.  Control
mechanisms will need to support such bidirectional flows for both
IPv6 and MPLS, but such mechanisms are out of scope of this document.
An example control plane solution for MPLS can be found in RFC7551.
While the IPv6 and MPLS data planes must support bidirectional DetNet
flows, there are no special bidirectional features with respect to
the data plane other than need for the two directions take the same
paths.  Fate sharing and associated vs co-routed bidirectional flows
can be managed at the control level.  Note, that there is no stated
requirement for bidirectional DetNet flows to be supported using the
same IPv6 Flow Labels or MPLS Labels in each direction.
DetNet's use of PREOF increases the difficulty of using co-routing
bidirectional flows, since the replication points in one direction
would have to match the recombination points in the other direction,
and vice versa, and the optimal points for these functions in one
direction may not match the optimal points in the other.  The ability
to use co-routed bidirectional flows alongside PREOF is for future
study.
Control and management mechanisms will need to support bidirectional
flows for both IPv6 and MPLS, but the specification of such
mechanisms are out of scope of this document.  This is further
discussed in control-management-requirements.
FAG discusses the use of flow aggregation in DetNet.  It includes
flow aggregation accomplished through the use of hierarchical LSPs,
aggregating multiple DetNet flows into a single new DetNet flow, and
simple aggregation at the DetNet layer.  It will be the
responsibility of the DetNet control and management plane to be able
to properly signal and/or provision the use of these mechanisms.
These requirements are included in the next section.
While the definition of control and management planes for DetNet is
out of the scope of this document, there are particular
considerations and requirements for such that result from the unique
characteristics of the DetNet architecture I-D.ietf-detnet-
architecture and data plane as defined herein.
These requirements, as stated earlier, could be satisfied using
distributed control protocol signaling (such as RSVP-TE) or
centralized network management provisioning mechanisms.  When using
the latter, the path could be implemented via MPLS-based segment
routing.
In the abstract, the results of either distributed signaling or
centralized provisioning are equivalent from a DetNet data plane
perspective - flows are instantiated, explicit routes are determined,
resources are reserved, and packets are forwarded through the domain
using the MPLS data plane.
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.