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

Commentary: Changes resulting from last week 's review call . 
 Chapter 7 . updates by
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.
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 Generic Associated Channel Label (GAL) will be in the
label stack below the S-Label, followed by the ACH RFC5586.
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.
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 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.
It is necessary to consider explicit routes both 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 this is a multi-
stage process, or a single stage process is out of scope of this
document.
The one method of explicitly setting up the explicit path at the
DetNet layer is through the use of the management controller.
The path can be explicitly set up by the management controller
calculating the path and explicitly configuring each node along
that path.
The LSP can be set up using RSVP-TE.  Such an approach confines
the packet to the explicit path.
The path can be implemented using MPLS-based segment routing.
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.
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.
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.
fate.  In both types of bidirectional LSPs, resource allocations may
differ in each direction.  The concepts of associated bidirectional
flows and co-routed bidirectional flows can be applied to DetNet
flows as well whether IPv6 or MPLS is used.
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.
fate.  In both types of bidirectional LSPs, resource reservations may
differ in each direction.  The concepts of associated bidirectional
flows and co-routed bidirectional flows can be applied to DetNet
flows as well whether IPv6 or MPLS is used.
While the MPLS 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 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 MPLS Labels in each direction.
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.
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).
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.
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.
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.
Instantiate DetNet flows in a DetNet domain (which may include
some or all of explicit path and PREOF replication and elimination
node determination, link bandwidth reservations, node buffer and
other resource reservations, specification of required queuing
disciplines along the path, ability to manage bidirectional flows,
etc.) as needed for a flow.
Provision flow identification information at each of the nodes
along the path, and it may differ depending on the location in the
network and the DetNet functionality (e.g. transit node vs. relay
node).
These requirements, as stated earlier, could be satisfied using
distributed control protocol signaling (such as RSVP-TE), centralized
network management provisioning mechanisms (such as BGP, PCEP, YANG
I-D.ietf-detnet-flow-information-model, etc.) or hybrid combinations
of the two, and could also make use of MPLS-based segment routing.