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

Commentary: xml : cleanup some old IPv6 references and CoS / QoS language General alignment with architecture document … Terms : jitter , contention loss , controller plane Some cleanup related to S / T  Some cleanup related to control plane
The DetNet transport layer functionality that provides congestion
protection for DetNet flows is assumed to be in place in a DetNet
node.
The DetNet transport layer functionality that eliminates (or reduces)
contention loss for DetNet flows is assumed to be in place in a
DetNet node.
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 does not define the associated control plane functions,
or Operations, Administration, and Maintenance (OAM).  While
requiring implementations to control contention loss and jitter of
DetNet flows, this document does not specify the specific mechanisms
needed to eliminate contention loss or reduce jitter.
CoS for DetNet flows carried in IPv6 is provided using the standard
differentiated services code point (DSCP) field RFC2474 and related
mechanisms.  The 2-bit explicit congestion notification (ECN) RFC3168
field MAY also be used.
One additional consideration for DetNet nodes which support CoS
services is that they MUST ensure that the CoS service classes do not
impact the congestion protection and latency control mechanisms used
to provide DetNet QoS.  This requirement is similar to requirement
for MPLS LSRs to that CoS LSPs do not impact the resources allocated
to TE LSPs via RFC3473.
One additional consideration for DetNet nodes which support CoS
services is that they MUST ensure that the CoS service classes do not
impact the eliminating contention loss and jitter reduction
mechanisms used to provide DetNet QoS.  This requirement is similar
to requirement for MPLS LSRs to that CoS LSPs do not impact the
resources allocated to TE LSPs, e.g., via RFC3473.
In addition to explicit routes, and packet replication and
elimination, described in dn-dt-solution above, DetNet provides zero
congestion loss and bounded latency and jitter.  As described in I-
D.ietf-detnet-architecture, there are different mechanisms that maybe
used separately or in combination to deliver a zero congestion loss
service.  This includes Quality of Service (QoS) mechanisms at the
MPLS layer, that may be combined with the mechanisms defined by the
underlying network layer such as 802.1TSN.
In addition to explicit routes, and packet replication and
elimination, described in dn-dt-solution above, DetNet provides zero
congestion loss and bounded latency and jitter.  As described in I-
D.ietf-detnet-architecture, there are different mechanisms that maybe
used separately or in combination to deliver a zero congestion loss
service.  These mechanisms are provided by the either the MPLS or IP
layers, and may be combined with the mechanisms defined by the
underlying network layer such as 802.1TSN.
MUST defend the DetNet QoS by discarding or remarking (to a non-
DetNet CoS) packets received that are not the subject of a
completed reservation.
MUST NOT use a DetNet reserved resource, e.g. a queue or shaper
reserved for DetNet flows, for any packet that does not carry a
DetNet Class of Service marker.
MUST defend the DetNet QoS by discarding or remarking (to an
allocated DetNet flow or non-competing non-DetNet flow) packets
received that are not the subject of a completed resource
allocation.
MUST NOT use a DetNet allocated resource, e.g. a queue or shaper
reserved for DetNet flows, for any packet that does match the
corresponding DetNet flow.
Ensuring that the proper Ethernet VLAN tag priority and destination
MAC address are used on a DetNet/TSN packet may require further
clarification of the customary L2/L3 transformations carried out by
routers and edge label switches.  Edge nodes may also have to move
sequence number fields among Layer 2, PW, and IPv6 encapsulations.
Ensuring that the proper Ethernet VLAN tag priority and destination
MAC address are used on a DetNet/TSN packet may require further
clarification of the customary L2/L3 transformations carried out by
routers and edge label switches.  Edge nodes may also have to move
sequence number fields among Layer 2, PW, and IP encapsulations.
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.
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, and the DetNet architecture I-D.ietf-detnet-architecture
refers to these collectively as the 'Controller Plane'.  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 or any combination thereof.  Specific 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 MPLS 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 upstream DetNet service-aware peer nodes (e.g., a MPLS DetNet
End System as shown in fig_pw_detnet, or a DetNet Relay or Edge Node
as shown in fig_pw_detnet2).
As discussed in sec_dt_dp, The transport layer uses one or T-Labels
to transport DetNet packets between DetNet service-aware nodes along
explicitly defined routes at the DetNet layer and in the MPLS layer.
In the DetNet layer the explicit route consists of the set of Relay
Nodes that the DetNet flow must traverse.  In the MPLS layer the
explicit route consists of the set of LSRs, links, and possibly link
bundle members and queues that the DetNet packets of a flow must
traverse between nodes in the DetNet layer (i.e. between a specific
Edge Node and the next hop Relay Node, between specific Relay Nodes,
and between a specific Relay node and the egress Edge Node.  This
detailed steering is needed to ensure that packets are routed through
the resources that have been reserved for them, and hence provide the
DetNet application with the required performance.
Whether configuring, calculating and instantiating these routes is a
single-stage or multi-stage process is out of scope of this document.
A reasonable expectation is that explicitly setting up routes at the
DetNet layer will be through the use of a centralized management
controller.
The route could be explicitly set up by a centralized management
controller calculating the path and explicitly configuring each
node along that path.
The route could be set up using RSVP-TE signaling.
The path could be implemented using MPLS-based segment routing.
DetNet S-Labels (see flow-identification for their definition) are
similar to other MPLS service labels that denote the contents of the
MPLS packet payload 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 network (EVPN) service.
S-Labels are expected to be allocated in the same manner as any other
service labels.  S-Labels uniquely identify a particular DetNet flow,
and are local to the node on which the label is allocated.  In the
DetNet service layer the explicit route consists of the set of Relay
Nodes that the DetNet flow must traverse.  They can be used to
identify the DetNet 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 upstream DetNet service-aware peer nodes
(e.g., a MPLS DetNet End System as shown in fig_pw_detnet, or a
DetNet Relay or Edge Node as shown in fig_pw_detnet2) and interpreted
in the context of their received T-Label.
As discussed in sec_dt_dp, the transport layer uses one or more
T-Labels to transport DetNet packets between DetNet service-aware
nodes along explicitly defined routes at the DetNet Transport layer,
which in the context of this document is the MPLS layer.  In the
DetNet Transport (MPLS) layer the explicit route consists of the set
of DetNet nodes which are LSRs, links, and possibly link bundle
members and queues that the DetNet packets of a flow must traverse
between nodes in the DetNet service layer (i.e. between a specific
Edge Node and the next hop Relay Node, between specific Relay Nodes,
and between a specific Relay node and the egress Edge Node.  Resource
allocation corresponding to the set of Services supported over the
Transport layer, which may or may not include aggregation, is
required at this layer.  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.
Whether configuring, calculating and instantiating these routes is a
single-stage or multi-stage process, or in a centralized or
distributed manner, is out of scope of this document.
The path could be explicitly set up by a controller which
calculates the path and explicitly configures each node along that
path with the appropriate forwarding and resource allocation
information.
The path could be set up using RSVP-TE signaling.
The path could be implemented using MPLS-based segment routing
that is extended to support resource allocation.
Much like other MPLS labels, there are a number of alternatives
available for DetNet S-Label and T-label advertisement to an upstream
peer node.  These include distributed signaling protocols such as
RSVP-TE, centralized label distribution via a controller that manages
both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc.,
and hybrid combinations of the two, and could also make use of MPLS-
based segment routing.  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 control 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 may require enhancements to existing methods of establishing
explicit paths through a network.  There may be capabilities that can
be adopted from technologies like GMPLS end-to-end recovery RFC4872
and GMPLS segment recovery RFC4873.
As discussed in sec_intro, this document does not specify traffic
handling capabilities required to prevent contention loss and deliver
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.
Much like other MPLS labels, there are a number of alternatives
available for DetNet S-Label and T-label advertisement to an upstream
peer node.  These include distributed signaling protocols such as
RSVP-TE, centralized label distribution via a controller that manages
both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc.,
and hybrid combinations of the two.  The details of the controller
plane 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 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 are be capabilities that can
be used, or extended, for example GMPLS end-to-end recovery RFC4872
and GMPLS segment recovery RFC4873.
As discussed in sec_intro, this document does not specify the
mechanisms needed to eliminate contention loss or reduce jitter for
DetNet flows at the DetNet transport layer.  The ability to manage
node and link resources to be able to provide these functions will be
a necessary part of the DetNet controller plane.  It will also be
necessary to be able to control the required queuing mechanisms used
to provide these functions along a flow's path through the network.
See control-management-requirements for further discussion of these
requirements.
flows as well whether IPv6 or MPLS is used.
flows.
DetNet's use of PREOF increases the difficulty of using co-routing
bidirectional flows, since if PREOF is used, then the replication
points in one direction would have to match the elimination 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.
DetNet's use of PREOF may increase the complexity of using co-routing
bidirectional flows, since if PREOF is used, then the replication
points in one direction would have to match the elimination 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.
Control and management mechanisms will need to support bidirectional
flows, but the specification of such mechanisms are out of scope of
this document.  That said, it may be possible to take advantage of
signaling mechanisms that were originally developed for GMPLS (such
as RFC6387) and MPLS-TP (such as RFC6373).
Control and management mechanisms will need to support bidirectional
flows, but the specification of such mechanisms are out of scope of
this document.  Related control plan mechanisms have been defined in
RFC3473, RFC6387 and RFC7551.
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 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.
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 controller plane to be able to properly
provision the use of these mechanisms.  These requirements are
included in the next section.
While the definition of controller plane 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.