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

Commentary: I mean operation as in behavior , not OAM .
This document specifies Deterministic Networking data plane
encapsulation solutions.  The described data plane solutions is
applied over an MPLS Packet Switched Networks.
This document specifies the Deterministic Networking data plane when
operating over an MPLS Packet Switched Networks.
This document specifies the DetNet data plane and the on-wire
encapsulation of DetNet flows over an MPLS-based Packet Switched
Network (PSN).  The specified encapsulation provides the building
blocks to enable the DetNet service layer functions and allow flow
identification as described in the DetNet Architecture.
The DetNet transport layer functionality that eliminates (or reduces)
contention loss for DetNet flows is assumed to be in place in a
DetNet node.
Furthermore, this document also describes how DetNet flows are
identified, and how a DetNet Relay/Edge/Transit nodes works.  It also
describes the function and operation of the Packet Replication (PRF)
Packet Elimination (PEF) and Packet Ordering (POF) functions in the
MPLS data plane.
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.
This document uses the terminology established in the DetNet
architecture I-D.ietf-detnet-architecture and the DetNet Data Plane
Solution Alternatives I-D.ietf-detnet-dp-alt.
A label used to identify the LSP used to transport a DetNet flow
across an MPLS PSN, e.g., a hop-by-hop label used between label
switching routers (LSR).
A DetNet "service" label that is used between DetNet nodes that
implement also the DetNet service layer functions.  An S-Label is
also used to identify a DetNet flow at DetNet service layer.
A Packet Elimination Function (PEF) eliminates duplicate copies of
packets received by an edge or a relay node to prevent excess
packets flooding the network, or to prevent duplicate packets
being sent out of the DetNet domain.
A Packet Replication Function (PRF) replicates DetNet flow packets
and forwards them to one or more next hops in the DetNet domain.
The number of packet copies sent to each next hop is a DetNet flow
specific parameter at the node doing the replication.  PRF can be
implemented by an edge node, a relay node, or an end system.
A Packet Ordering Function (POF) re-orders packets within a DetNet
flow that are received out of order.  This function can be
implemented by an edge node, a relay node, or an end system.
Collective name for Packet Replication, Elimination, and Ordering
Functions.
A DetNet Control Word (d-CW) is used for sequencing and
identifying duplicate packets of a DetNet flow at the DetNet
service layer.
The DetNet Architecture decomposes the DetNet related data plane
functions 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 is used to
provides congestion protection (low loss, assured latency, and
limited reordering) leveraging MPLS Traffic Engineering mechanisms.
This document specifies the DetNet data plane operation and the on-
wire encapsulation of DetNet flows over an MPLS-based Packet Switched
Network (PSN).  The specified encapsulation provides the building
blocks to enable the DetNet service and forwarding sub-layer
functions and supports flow identification as described in the DetNet
Architecture.  As part of the service sub-layer functions, this
document describes the and how a DetNet Relay/Edge/Transit nodes
works.  It also describes the function and operation of the Packet
Replication (PRF) Packet Elimination (PEF) and Packet Ordering (POF)
functions with an MPLS data plane.  It also describes an MPLS-based
DetNet forwarding sub-layer that eliminates (or reduces) contention
loss and provides bounded latency for DetNet flows.
This document does not define, but does allow for, associated
controller plane and Operations, Administration, and Maintenance
(OAM) functions.
This document uses the terminology established in the DetNet
architecture I-D.ietf-detnet-architecture, and the reader is assumed
to be familiar with that document and its terminology.
A Detnet "forwarding" label that identifies the LSP used to
forward a DetNet flow across an MPLS PSN, e.g., a hop-by-hop label
used between label switching routers (LSR).
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.
A DetNet Control Word (d-CW) is used for sequencing and
identifying duplicate packets of a DetNet flow at the DetNet
service sub-layer.
DetNet Control Word.
This document describes how DetNet flows are carried over MPLS
networks.  The DetNet Architecture, I-D.ietf-detnet-architecture,
decomposes the DetNet data plane into two layers: a service layer and
a transport layer.  The basic approach defined in this document
supports the DetNet service layer based on existing pseudowire (PW)
encapsulations and mechanisms, and supports the DetNet transport
layer based on existing MPLS Traffic Engineering encapsulations and
mechanisms.  Background on PWs can be found in RFC3985 and RFC3031.
The MPLS DetNet data plane approach defined in this document is shown
in dn_mpls_dp_approach.  The service layer is supported by a DetNet
control word (d-CW) which conforms to the Generic PW MPLS Control
Word (PWMCW) defined in RFC4385.  A d-CW identifying service label
(S-Label) is also used.  The transport layer is supported by one or
labels (T-Labels).
A node operating on a DetNet flow in the Detnet layer, i.e. a node
processing a DetNet packet which has the S-label as top of stack uses
the local context associated with that S-label to determine what
local operation(s) are applied to that packet.  The S-label has to be
unique on each edge and relay node, which is achieved by using a
label taken from the platform label space RFC3031.
This document describes how DetNet flows are carried over MPLS
networks.  The DetNet Architecture, I-D.ietf-detnet-architecture,
decomposes the DetNet data plane into two sub-layers: a service sub-
layer and a forwarding sub-layer.  The basic approach defined in this
document supports the DetNet service sub-layer based on existing
pseudowire (PW) encapsulations and mechanisms, and supports the
DetNet forwarding sub-layer based on existing MPLS Traffic
Engineering encapsulations and mechanisms.  Background on PWs can be
found in RFC3985 and RFC3031.  Background on MPLS Traffic Engineering
can be found in RFC3272 and RFC3209.
The MPLS DetNet data plane approach defined in this document is shown
in dn_mpls_dp_approach.  The service sub-layer is supported by a
DetNet control word (d-CW) which conforms to the Generic PW MPLS
Control Word (PWMCW) defined in RFC4385.  A d-CW identifying service
label (S-Label) is also used.  The forwarding sub-layer is supported
by one or forwarding labels (F-Labels).
A node operating on a DetNet flow in the Detnet service sub-layer,
i.e. a node processing a DetNet packet which has the S-Label as top
of stack uses the local context associated with that S-Label, for
example a received F-Label, to determine what local DetNet
operation(s) are applied to that packet.  An S-Label generally is
unique on each edge and relay node, which can be achieved by using a
label taken from the platform label space RFC3031.
Transit nodes are normal MPLS Label Switching Routers (LSRs).  They
are generally unaware of the special requirements of DetNet flows,
although they need to provide traffic engineering services and proper
QoS to the LSPs associated with DetNet flows to enhance the prospect
of the LSPs meeting the DetNet service requirements.  Some
implementations of transit nodes may be DetNet aware, but such nodes
just support the DetNet transport layer.
The MPLS LSP may be provided by any MPLS method (provisioned, RSVP-
TE, MPLS- TP, or MPLS Segment Routing (SR)).
Transit nodes may be non-DetNet aware MPLS Label Switching Routers
(LSRs).  In this case, they would be unaware of the special
requirements of DetNet service information, although they need to
provide traffic engineering services and proper QoS to the LSPs
associated with DetNet flows to ensure the LSPs meet the DetNet
service requirements.  Some implementations of transit nodes may be
DetNet aware, but such nodes just support the DetNet forwarding sub-
layer.
The MPLS LSP may be provided by any MPLS method (provisioned, RSVP-
TE, MPLS-TP, or MPLS Segment Routing (SR) when extended to support
resource allocation).
fig_8021_detnet illustrates how DetNet can provide services for IEEE
802.1TSN end systems, CE1 and CE2, over a DetNet enabled network.
The edge nodes, E1 and E2, insert and remove required DetNet data
plane encapsulation.  The 'X' in the edge nodes and relay node, R1,
represent a potential DetNet flow packet replication and elimination
point.  This conceptually parallels L2VPN services, and could
leverage existing related solutions as discussed below.
fig_8021_detnet illustrates how DetNet can provide services for IEEE
802.1TSN end systems, CE1 and CE2, over a DetNet enabled network.
The edge nodes, E1 and E2, insert and remove required DetNet data
plane encapsulation.  The 'X' in the edge nodes and relay node, R1,
represent a potential DetNet compound flow packet replication and
elimination point.  This conceptually parallels L2VPN services, and
could leverage existing related solutions as discussed below.
fig_pw_detnet illustrates how an end to end MPLS-based DetNet service
is provided in a more detail.  In this case, the end systems, CE1 and
CE2, are able to send and receive DetNet flows, and R1 and R2 are
relay nodes as they sit in the middle of a DetNet network.  For
example, an end system sends data encapsulated in MPLS.  The 'X' in
the end systems, and relay nodes represents potential DetNet flow
packet replication and elimination points.  In this figure, the relay
nodes may change the underlying transport, for example tunneling MPLS
over IP detnet-data-plane-encapsulation-for-ip-transport-networks, or
simply interconnect network segments.
fig_pw_detnet illustrates how an end to end MPLS-based DetNet service
is provided in a more detail.  In this case, the end systems, CE1 and
CE2, are able to send and receive DetNet flows, and R1 and R2 are
relay nodes as they sit in the middle of a DetNet network.  For
example, an end system sends data encapsulated in MPLS.  The 'X' in
the end systems, and relay nodes represents potential DetNet compound
flow packet replication and elimination points.  In this figure, the
relay nodes may change the underlying forwarding sub-layer, for
example tunneling MPLS over IP detnet-data-plane-encapsulation-for-
ip-transport-networks, or simply interconnect network segments.
The above is of course illustrative of many network scenarios that
can be configured.  Between a pair of relay nodes there may be one or
more transport nodes that simply forward the DetNet traffic, but
these are omitted for clarity.
The above is of course illustrative of many network scenarios that
can be configured.  Between a pair of relay nodes there may be one or
more transit nodes that simply forward the DetNet traffic, but these
are omitted for clarity.
Usage of allocated resources (queuing, policing, shaping) to
ensure that the congestion-related loss and latency/jitter
requirements of a DetNet flow are met.
Use of a specific path for a flow.  This limits miss-ordering and
latency.
Use of allocated resources (queuing, policing, shaping) to ensure
that the congestion-related loss and latency/jitter requirements
of a DetNet flow are met.
Use of a specific path for a flow.  This limits misordering and
bounds latency.
Generally, distributing packets of the same DetNet flow over
multiple paths is not recommended.  Such load sharing, e.g., via
ECMP or UCMP, impacts ordering and end-to-end jitter.
Generally, distributing packets of the same DetNet flow over
multiple paths is not recommended.  Such load sharing, e.g., via
ECMP or UCMP, impacts ordering and possibly jitter.
In this design an MPLS service label (the S-Label), similar to a
pseudowire (PW) label RFC3985, is used to identify both the DetNet
flow identity and the payload MPLS payload type satisfying (1) and
(2) in the list above.  OAM traffic discrimination happens through
the use of the Associated Channel method described in RFC4385.  The
sequence number is carried in the DetNet Control word which carries
the Data/OAM discriminator.  The LSP used to transport the DetNet
packet may be of any type (MPLS-LDP, MPLS-TE, MPLS-TP RFC5921, or
MPLS-SR I-D.ietf-spring-segment-routing-mpls).  The LSP (T-Label)
label and/or the S-Label may be used to indicate the queue processing
as well as the forwarding parameters.
In this design an MPLS service label (the S-Label), similar to a
pseudowire (PW) label RFC3985, is used to identify both the DetNet
flow identity and the payload MPLS payload type satisfying (1) and
(2) in the list above.  OAM traffic discrimination happens through
the use of the Associated Channel method described in RFC4385.  The
sequence number is carried in the DetNet Control word which carries
the Data/OAM discriminator.  The LSP used to forward the DetNet
packet may be of any type (MPLS-LDP, MPLS-TE, MPLS-TP RFC5921, or
MPLS-SR I-D.ietf-spring-segment-routing-mpls).  The LSP (F-Label)
label and/or the S-Label may be used to indicate the queue processing
as well as the forwarding parameters.
Zero or more MPLS transport LSP label(s) (T-label) used to direct
the packet along the label switched path (LSP) to the next peer
node along the path.  When Penultimate Hop Popping is in use there
may be no label T-label in the protocol stack on the final hop.
Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to
direct the packet along the label switched path (LSP) to the next
peer node along the path.  When Penultimate Hop Popping is in use
there may be no label F-Label in the protocol stack on the final
hop.
A further method of using SR to perform aggregation is for further
study.
Simple-aggregation-at-the-detnet-layer: is this not the same as
H-LSP?  The A-label can be treated just as an additional T-label.
End of review comment.
Simple-aggregation-at-the-detnet-layer: is this not the same as
H-LSP?  The A-label can be treated just as an additional F-Label.
Another approach would be not to include a d-CW for the aggregated
flow.  This would be functionally similar to aggregation at the
transport layer using H-LSPs, but would confine knowledge of the
aggregation to the DetNet layer.  Such an approach shares the
disadvantage that PREOF operations would not be possible.  OAM
operation in this mode is for further study.
Another approach would be not to include a d-CW for the aggregated
flow.  This would be functionally similar to aggregation at the
forwarding sub-layer using H-LSPs, but would confine knowledge of the
aggregation to the DetNet layer.  Such an approach shares the
disadvantage that PREOF operations would not be possible.  OAM
operation in this mode is for further study.
A DetNet Relay node operates in the DetNet transport layer . This
processing is done within an extended forwarder function.  Whether an
ingress DetNet member flow receives DetNet specific processing
depends on how the forwarding is programmed.  Some relay nodes may be
DetNet service aware, while others may be unmodified LSRs that only
understand how to swicth MPLS-TE LSPs.
A DetNet Relay node operates in the DetNet forwarding sub-layer .
This processing is done within an extended forwarder function.
Whether an ingress DetNet member flow receives DetNet specific
processing depends on how the forwarding is programmed.  Some relay
nodes may be DetNet service aware, while others may be unmodified
LSRs that only understand how to swicth MPLS-TE LSPs.
DetNet flows transported via IP have more limited aggregation
options, due to the available traffic flow identification fields of
the IP solution.  One available approach is to manage the resources
associated with a DSCP identified traffic class and to map (remark)
individually controlled DetNet flows onto that traffic class.  This
approach also requires that nodes support aggregation ensure that
traffic from aggregated LSPs are placed (shaped/policed/enqueued) in
a fashion that ensures the required DetNet service is preserved.
In both the MPLS and IP cases, additional details of the traffic
control capabilities needed at a DetNet-aware node may be covered in
the new service descriptions mentioned above or in separate future
documents.  Management and control plane mechanisms will also need to
ensure that the service required on the aggregate flow (H-LSP or
DSCP) are provided, which may include the discarding or remarking
mentioned in the previous sections.
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.
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 sub-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 F-Label.
As discussed in sec_dt_dp, the forwarding sub-layer uses one or more
F-Labels to forward DetNet packets between DetNet service-aware nodes
along explicitly defined routes at the DetNet forwarding sub-layer,
which in the context of this document is the MPLS layer.  In the
DetNet Forwarding (MPLS) sub-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 sub-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 forwarding sub-layer, which may or may not include
aggregation, is required at this sub-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.
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.  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 path could be implemented using MPLS-based segment routing
when extended to support resource allocation.
Much like other MPLS labels, there are a number of alternatives
available for DetNet S-Label and F-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.
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.
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 forwarding sub-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.
This section specifies the DetNet encapsulation over an IP transport
network.  The approach is modeled on the operation of MPLS and
PseudoWires (PW) over an IP Packet Switched Network (PSN) RFC7510.
It is also based on the MPLS data plane encapsulation described in
pwSolution.
This section specifies the DetNet encapsulation over an IP network.
The approach is modeled on the operation of MPLS and PseudoWires (PW)
over an IP Packet Switched Network (PSN) RFC7510.  It is also based
on the MPLS data plane encapsulation described in pwSolution.