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

Commentary: also includes / builds on 
 I 'm confused by this . I thought an app flow always mapped to a single s label and that s label may map to multiple member flows using different f labels . Are you saying a single app flow may use multiple s labels ? If so , under what conditions ? 
 Sorry I think this is a bad cut and paste oh , probably node processing should just be dropped . 
 Sure .... 
 Agreed . But the maximum number of sequence numbers that are tracked may be per platform or per flow . 
 Thanks ! Will do . 
 Okay . I 'll clarify . 
 I agree it can be independent . The in addition was just transition text , it can be dropped if it is confusing .  
 I think this is a subtlety that can be left to the new l2 over mpls document 
 Okay 
 Simply that how outflows are mapped to mpls are out of scope of the document . I 'm working on the DetNet IP over mpls section for the IP solution document . I should have something out late today on that . 
 It 's included in the f - label section , we can make it a subsection if you want . 
 Yes - to the IP solution document ( hope to have that tonight ) and a new l2 / tsn over DetNet mpls draft ...  
 Yes . 
 no - there is explicit text on this in the subsequent section .
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 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 DetNet node data plane operation.  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.
MPLS encapsulated DetNet flows can be carried over network
technologies that can provide the DetNet required level of service.
This document defines examples of such, specifically carrying DetNet
MPLS flows over IEEE 802.1 TSN sub-networks, and over DetNet IP PSN.
The intent is for this document to support different traffic types
being mapped over DetNet MPLS, but this is out side the scope of this
document.  An example of such can be found in I-D.ietf-detnet-dp-sol-
ip.  This document also allows for, but does not define, associated
controller plane and Operations, Administration, and Maintenance
(OAM) functions.
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.
fig_tsn_mpls_detnet shows several node types defined in I-D.ietf-
detnet-architecture.  DetNet Edge Nodes sit at the boundary of a
DetNet domain.  They are responsible for mapping non-DetNet aware
traffic to DetNet services.  They also support the imposition and
disposition of the required DetNet encapsulation.  These are
functionally similar to pseudowire (PW) Terminating Provider Edge
(T-PE) nodes which use MPLS-TE LSPs.
Native TSN flow and DetNet MPLS flow differ not only by the
additional MPLS specific encapsulation, but DetNet MPLS flows have on
each DetNet node an associated DetNet specific data structure, what
defines flow related characteristics and required forwarding
functions.  Edge Nodes MUST provide a Service Proxy entity that
"associates" the DetNet flows and native flows at the edge of the
DetNet domain.  It ensures that the DN Flow is properly served at the
Edge node (and inside the domain).
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_ip_mpls_detnet and fig_8021_detnet, show different cases where
relay nodes may be used.  Relay nodes are similar to edge nodes in
that both are aware of the needs of particular DetNet flows and take
care to process them in accordance with the required performance
needs.  They differ in that relay nodes sit within a DetNet domain
while edge nodes always sit at DetNet domain boundaries.  Both node
types can enhance the reliability of delivery by enabling the
replication of packets so that multiple copies, possibly over
multiple paths are forwarded through the DetNet domain.  They also
reduce the impact of replication by eliminating surplus copies of
DetNet packets.  Relay nodes may sit the boundary of an MPLS domain
when the non-MPLS domain is DetNet aware.  Relay nodes are
functionally similar to PW S-PEs or, when at the edge of an MPLS
network, T-PEs RFC6073.
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 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.
fig_pw_detnet2 illustrates how an end to end MPLS-based DetNet
service is provided where the end systems are not able to send and
receive DetNet flows.  In this example, the nodes labeled CE1 and CE2
could be non-DetNet aware IP routers or hosts.  Note that E1 and E2
are edge nodes as they sit boundaries of the DetNet enabled domain.
fig_ip_pw_detnet illustrates how end to end DetNet service is
provided where the end systems are able to send and receive IP DetNet
flows, e.g., per I-D.ietf-detnet-dp-sol-ip, and the MPLS nodes
optionally provide service protection.  In this case R1 and R3 are
T-PEs and R2 is an S-PE and the DetNet service is end-to-end.
An example MPLS DetNet network fragment and packet flow is
illustrated in fig_mpls_example.
The DetNet MPLS 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.
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 may be unique
when taken from the platform label space RFC3031, which would enable
correct DetNet flow identification regardless of which input
interface or LSP the packet arrives on.
The DetNet MPLS data plane builds on MPLS Traffic Engineering
encapsulations and mechanisms to provide a forwarding sub-layer that
is responsible for providing resource allocation and explicit routes.
The forwarding sub-layer is supported by one or more forwarding
labels (F-Labels).
fig_dn_mpls_detnet illustrates a hypothetical DetNet MPLS-only
network composed of DetNet aware MPLS enabled end systems, operating
over a DetNet aware MPLS network.  In this figure, relay nodes sit at
MPLS LSP boundaries and transit nodes are LSRs.
DetNet end system and relay nodes are DetNet service sub-layer aware,
understand the particular needs of DetNet flows and provide both
DetNet service and forwarding sub-layer functions.  They add, remove
and process d-CWs, S-Labels and F-labels as needed.  MPLS enabled end
system and relay nodes can enhance the reliability of delivery by
enabling the replication of packets where multiple copies, possibly
over multiple paths, are forwarded through the DetNet domain.  They
can also eliminate surplus previously replicated copies of DetNet
packets.  DetNet MPLS nodes provide functionality similar to T-PEs
when they sit at the edge of an MPLS domain, and functionality
similar to S-PEs when they are in the middle of an MPLS domain, see
RFC6073.  End system and relay nodes also include DetNet forwarding
sub-layer functions, support for notably explicit routes, and
resources allocation to eliminate (or reduce) congestion loss and
jitter.
DetNet transit nodes reside wholly within a DetNet domain, and also
provide DetNet forwarding sub-layer functions in accordance with the
performance required by a DetNet flow carried over an LSP.  Unlike
other DetNet node types, transit nodes provide no service sub-layer
processing.  In a DetNet MPLS network, transit nodes may be DetNet
service aware or may be DetNet unaware MPLS Label Switching Routers
(LSRs).  In this latter case, such LSRs would be unaware of the
special requirements of the DetNet service sub-layer, but would still
provide traffic engineering services and the QoS need to ensure that
the (TE) LSPs meet the service requirements of the carried DetNet
flows.
The LSPs may be provided by any MPLS controller method.  For example
they may be provisioned via a management plane, RSVP-TE, MPLS-TP, or
MPLS Segment Routing (when extended to support resource allocation).
fig_pw_detnet illustrates how an end to end MPLS-based DetNet service
is provided in a more detail.  In this figure, the end systems, CE1
and CE2, are able to send and receive MPLS encapsulated DetNet flows,
and R1, R2 and R3 are relay nodes as they sit in the middle of a
DetNet network.  The 'X' in the end systems, and relay nodes
represents potential DetNet compound flow packet replication and
elimination points.  In this example, service protection is supported
over four DetNet member flows and TE LSPs.  For a unidirectional
flow, R1 supports PRF, R2 supports PREOF and R3 supports PEF and POF.
Note that the relay nodes may change the underlying forwarding sub-
layer, for example tunneling MPLS over IEEE 802.1 TSN mpls-over-tsn,
or simply over interconnect network links.
As previously mentioned, this document specifies how MPLS is used to
support DetNet flows using an MPLS data plane as well as how such can
be mapped to IEEE 802.1 TSN and IP DetNet PSNs.  In the remainder of
this section, sample uses of DetNet MPLS are shown for illustrative
purposes.  These uses are an IP DetNet, where the end nodes support
I-D.ietf-detnet-dp-sol-ip, and an L2VPN service, where the L2 is
itself an IEEE 802.1 TSN.
fig_dn_ip_mpls_detnet illustrates DetNet enabled End Systems (hosts),
connected to DetNet (DN) enabled IP networks, operating over a DetNet
aware MPLS network.  In this figure, Relay nodes sit at the boundary
of the MPLS domain since the non-MPLS domain is DetNet aware.  This
figure is very similar to fig_dn_mpls_detnet.  The primary difference
is that the Relay nodes are at the edges of the MPLS domain and
therefore function as T-PEs, and that service sub-layer functions are
not provided over the DetNet IP network.  There is no difference in
transit node function.
fig_ip_pw_detnet illustrates how relay nodes can provide service
protection over the MPLS domain.  In this case, CE1 and CE2 are IP
DetNet end systems which are interconnected via a MPLS domain such as
previously shown in fig_pw_detnet.  Note that R1 and R3 sit at the
edges of an MPLS domain and therefore are similar to T-PEs, while R2
sits in the middle of the domain and is therefore similar to an S-PE.
fig_ip_mpls_detnet illustrates non-DetNet enabled End Systems
(hosts), connected to DetNet (DN) enabled MPLS network.  It differs
from fig_dn_ip_mpls_detnet in that the hosts and edge IP networks are
not DetNet aware.  In this case, edge nodes sit at the boundary of
the MPLS domain since it is also a DetNet domain boundary.  The edge
nodes provide DetNet service proxies for the end applications by
initiating and terminating DetNet service for the application's IP
flows.  See I-D.ietf-detnet-dp-sol-ip for more information.
fig_pw_detnet2 illustrates how it is still possible to provided
DetNet service protection for non-DetNet aware end systems.  This
figures is basically the same as fig_ip_pw_detnet, with the exception
that CE1 and CE2 are non-DetNet aware end systems and E1 and E3 are
edge nodes that replace the relay nodes R1 and R3.
fig_tsn_mpls_detnet shows IEEE 802.1 TSN end stations operating over
a TSN aware DetNet service running over an MPLS network.  DetNet Edge
Nodes sit at the boundary of a DetNet domain.  They are responsible
for mapping non-DetNet aware L2 traffic to DetNet services.  They
also support the imposition and disposition of the required DetNet
encapsulation.  These are functionally similar to pseudowire (PW)
Terminating Provider Edge (T-PE) nodes which use MPLS-TE LSPs.  In
this example they understand and support IEEE 802.1 TSN and are able
to map TSN flows into DetNet flows.  The specific of this operation
are discussed in [TBD-TSN-OVER-DETNET].
Native TSN flow and DetNet MPLS flow differ not only by the
additional MPLS specific encapsulation, but DetNet MPLS flows have on
each DetNet node an associated DetNet specific data structure, what
defines flow related characteristics and required forwarding
functions.  In this example, edge Nodes provide a service proxy
function that "associates" the DetNet flows and native flows at the
edge of the DetNet domain.  This ensures that the DN Flow is properly
served at the Edge node (and inside the domain).
fig_8021_detnet illustrates how DetNet can provide services for IEEE
802.1TSN end systems, CE1 and CE2, over a DetNet enabled MPLS
network.  Similar to fig_ip_mpls_detnet, 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.
An example DetNet MPLS network fragment and packet flow is
illustrated in fig_mpls_example.
The DetNet data plane also allows for the aggregation of DetNet
flows, e.g., via MPLS hierarchical LSPs, to improved scaling.  When
DetNet flows are aggregated, transit nodes may have limited ability
to provide service on per-flow DetNet identifiers.  Therefore,
identifying each individual DetNet flow on a transit node may not be
achieved in some network scenarios, but DetNet service can still be
assured in these scenarios through resource allocation and control.
Data-flows requiring DetNet service are generated and terminated on
end-systems.  Encapsulation depends on application and its
preferences.  In a DetNet (or even a TSN) domain the DN (TSN)
functions use at most two flow parameters, namely Flow-ID and
Sequence Number.  However, an application may exchange further flow
related parameters (e.g., time-stamp), which are not considered by DN
functions.
L2 (Ethernet) end-system: application directly over L2.
L3 (IP) end-system: application over L3.
Note: An MPLS DetNet end system (as shown in fig_pw_detnet) can be
treated as a combination of an L3 (IP) end-system and an MPLS DetNet
edge node.
In case of Ethernet end-systems the application data is encapsulated
directly in L2.  From the DN domain perspective no upper layer
protocols are visible.  The Data-flow uses only Ethernet tag(s) and
further flow specific parameters (if needed) are hidden inside the
protocol data unit (PDU).
The IP end-system scenario is different.  In this case, data-flows
are encapsulated directly in IP and, typically, other higher layer
protocols such as UDP and Real-time Transport Protocol (RTP).  Many
valid combinations exist and it is up to applications to select
specific headers to be used.  Details on support for DetNet IP data
flows can be found in I-D.ietf-detnet-dp-sol-ip.
As a general rule, DetNet domains MUST be capable of forwarding any
Data-flows and the DetNet domain MUST NOT mandate the end-system
encapsulation format.
L3 end-systems peer with L3 end-systems.
Directly attached: end-system is directly connected to an edge
node.
Indirectly attached: end-system is behind a (L2-TSN / L3-DetNet)
sub-network.
DN integrated: end-system is part of the DetNet domain.
L3 end-systems may use any of these connection types, however L2 end-
systems may use only the first two (directly or indirectly attached).
DetNet domain MUST allow communication between any end-systems of the
same type (L2-L2, L3-L3), independent of their connection type and
DetNet capability.  However directly attached and indirectly attached
end-systems have no knowledge about the DetNet domain and its
encapsulation format at all.  See fig_es_con_types for L3 end-system
scenarios.
The simplest DetNet service is to provide tunneling for layer two,
where the connected hosts are in the same broadcast (BC) domain.
Forwarding over the DetNet domain is based on L2 (MAC) addresses
(i.e. dst-MAC), or on received interface RFC3985.  In both cases the
L2 headers MUST either be kept, or provision must be made for their
reconstruction at egress from the DetNet domain.
As shown in fig_encap_DN_bridging both L2 and L3 end-systems can be
served by such a DetNet L2 encapsulation service.  This encapsulation
service may be carried over MPLS natively pwSolution, or over MPLS
over IP detnet-data-plane-encapsulation-for-ip-transport-networks.
IP traffic and IP DetNet flows, see I-D.ietf-detnet-dp-sol-ip, can be
carried over a DetNet MPLS domain.  In such cases, the IP headers are
modified per standard router behavior, e.g., TTL handling.
fig_mpls_DN_routing shows the encapsulation of an IP flow over MPLS
as well as when MPLS is carried over an IP PSN, see detnet-data-
plane-encapsulation-for-ip-transport-networks.
There are networking scenarios, where the DetNet domain contains
multiple technology segments (IP, MPLS, ..) and all those segments
are under the same administrative control (see
fig_pref_xcrs_segments).  Furthermore, DetNet nodes may be
interconnected via TSN segments.
An important aspect of DetNet network design is the placement of
DetNet functions across the domain.  Designs based on segment-by-
segment optimization can provide only sub-optimal solutions.  In
order to achieve global optimized Inter-Working Functions (DN-IWF)
can be placed at segment edge nodes, which stitch together DetNet
flows across connected segments.
DN-IWF may ensure that flow attributes are correlated across segment
edges.  For example, there are two DetNet functions which require
Sequence Numbers: (1) PEF: removes duplications from flows and (2)
POF: ensures in-order-delivery of packet in a flow.  Stitching flows
together and correlating attributes means for example that
replication of packets can happen in one segment and elimination of
duplicates in a different one.
The goal of DN-IWF is to (1) match and (2) translate segment specific
flow attributes.  The DN-IWF ensures that segment specific attributes
comprise per domain unique attributes for the whole DetNet domain.
This characteristic can ensure that DetNet functions can be based on
per domain attributes and not per segment attributes.
For the Flow-ID the DN-IWF can implement a static mapping.  The
situation is more complicated for Sequence Number as it is different
packet-by-packet, so it may need more sophisticated translation
unless its format is exactly the same in the two technology segments.
In this later case the DN-IWF can simple copy the Sequence Number
field between the tunneling encapsulation of the two technology
segments.
In case of three technology segments (IP, MPLS and TSN) three DN-IWF
functions can be specified.  In the rest of this section the focus is
on the (1) IP - MPLS network scenario.  Note: the use-cases are out-
of-scope for (2) TSN - IP, (3) TSN - MPLS.
Simplest implementation of DN-IWF is provided if the flow attributes
have the same format.  Such a common denominator of the tunnel
encapsulation format is the pseudowire encapsulation over both IP and
MPLS.
The DetNet data plane also allows for the aggregation of DetNet
flows, e.g., via MPLS hierarchical LSPs, to improved scaling.  When
DetNet flows are aggregated, transit nodes provide service to the
aggregate and not on a per-DetNet flow basis.  In this case, nodes
performing aggregation will ensure that per-flow service requirements
are achieved.
Data-flows requiring DetNet service are generated and terminated on
end-systems.  Encapsulation depends on application and its
preferences.  In a DetNet MPLS domain the DN functions use the d-CWs,
S-Labels and F-Labels to provide DetNet services.  However, an
application may exchange further flow related parameters (e.g., time-
stamp), which are not provided by DN functions.
Specifics related to non-MPLS DetNet end station behavior are out
side the scope of this document.  For example, details on support for
DetNet IP data flows can be found in I-D.ietf-detnet-dp-sol-ip.  This
document is also useful for end stations that map IP flows to DetNet
flows.
As a general rule, DetNet MPLS domains are capable of forwarding any
DetNet MPLS flows and the DetNet domain does not mandate the end-
system or edge system encapsulation format.  Unless there is a proxy
of some form present, end-systems peer with similar end-systems using
the same application encapsulation format.  For example, as shown in
fig_es_connect, IP applications peer with IP applications and
Ethernet L2VPN applications peer with Ethernet L2VPN applications.
As shown in fig_dn_mpls_detnet, MPLS nodes are interconnected by
different sub-network technologies, which may include point-to-point
links.  Each of these need to provide appropriate service to DetNet
flows.  In some cases, e.g., on dedicated point-to-point links or TDM
technologies, all that is required is for a DetNet node to
appropriately queue its output traffic.  In other cases, DetNet nodes
will need to map DetNet flows to the flow semantics (i.e.,
identifiers) and mechanisms used by an underlying sub-network
technology.  fig_dn_mpls_sn_ex shows several examples of header
formats that can be used to carry DetNet MPLS flows over different
sub-network technologies.  L2 represent a generic layer-2
encapsulation that might be used on a point-to-point link.  TSN
represents the encapsulation used on an IEEE 802.1 TSN network, as
described in mpls-over-tsn.  UDP/IP represents the encapsulation used
on a DetNet IP PSN, as described in mpls-over-ip .
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.
To simplify implementation and to maximize interoperability two
sequence number sizes are supported: a 16 bit sequence number and a
28 bit sequence number.  The 16 bit sequence number is needed to
support some types of legacy clients.  The 28 bit sequence number is
used in situations where it is necessary ensure that in high speed
networks the sequence number space does not wrap whilst packets are
in flight.  In addition it must be possible to send a packet with a
zero length sequence number, to support the case where sequence
numbers are not required by a particular DetNet flow.
Note that the concept of a zero length sequence number is not to be
confused with a sequence number of zero.  For example, were the
sequence number size is 16 bits, the sequence will contain: 65535, 0,
1.  In this case zero is an ordinary sequence number.  Unlike RFC4448
a sequence number of zero does not indicate that no sequence number
is in use.  Where sequence numbers are not in use, and thus a zero
length sequence number is in used, the sequence number field in the
packet is sent as zero.  The DetNet packet forwarder knows which of
these cases applies through configuration parameters associated with
each specific DetNet flow.
Note that when the network consists only of DetNet enabled nodes with
no aggregation, Penultimate Hop Popping (PHP) means that the only
label in the label stack may be the S-Label.
fig_pw_mpls illustrates a DetNet data plane MPLS encapsulation.  The
MPLS-based encapsulation of the DetNet flows is a good fit for the
Layer-2 interconnect deployment cases (see fig_8021_detnet).
Furthermore, end to end DetNet service i.e., native DetNet deployment
(see fig_pw_detnet) is also possible if DetNet end systems are
capable of initiating and termination MPLS encapsulated packets.
DetNet control word (d-CW) containing sequencing information for
packet replication and duplicate elimination purposes, and the OAM
indicator.  There MUST be a separate sequence number space for
each DetNet flow.
DetNet service Label (S-Label) that identifies a DetNet flow to
the peer node that is to process it.  The S-Label is allocated
from the platform label space RFC3031.
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 DetNet control word (d-CW) conforms to the Generic PW MPLS Control
Word (PWMCW) defined in RFC4385 and is illustrated in fig_detnet_cw.
The upper nibble of the d-CW MUST be set to zero (0).  Two sequence
number sizes are supported: 16 bits and 28 bits.  The sequence number
size in use for the d-CW associated with a DetNet flow (S-Label) is
configured either by a control plane or manually for each DetNet
flow.  The sequence number is aligned to the right (least significant
bits) and unused bits MUST be set to zero (0).  Each DetNet flow MUST
have its own sequence number counter.  The sequence number is
incremented by one for each new packet.
As discussed in dn-dt-solution, zero is an ordinary sequence number
with no special meaning.  Also as discussed therein, where no
sequence number is used by a particular DetNet flow, the sequence
number field in the d-CW is set to zero.
The d-CW MUST always be present in a packet.  In a case where the
sequence number is not used (e.g., for DetNet-t-flows) a zero length
sequence number is used and the sequence number MUST be set to zero
(0).
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 Generic Associated Channel Label (GAL) will be in the
label stack below the S-Label, followed by the ACH RFC5586.
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.
The S-Label for a specific DetNet flow is unique to that DetNet flow
on a specific node, but is not required to be identical with the
S-Label for that DetNet flow in any other node within the DetNet
domain.  Thus the S-Label can only be used to identify the DetNet
flow at the intended receiving node.
The only nodes that needs to know the payload type of a flow are the
DetNet ingress node and the DetNet egress nodes.  The ingress node
has to know how to process the packet it receives from the ingress AC
or IP flow, and the egress edge node has to know how to prepare the
packet for transmission to the next hop.
On ingress a DetNet edge node has to classify the packets into those
that are for transmission as Detnet packets and those that are for
transmission as "normal" packets at one of more lower priorities.
The packet type is indicated to the egress edge node through the
value of the S-Label.  Thus, when the egress edge node looks up the
S-Label one of the parameters returned is the packet type which in
turn tells the egress edge node how to prepare the packet for
transmission to a next hop.
The consequence of this approach is that if multiple packet
encapsulations are processed on a node pair, each encapsulation will
need its own S-Label.  That is not generally a problems, since it is
anticipated that only one encapsulation type will be present for each
DetNet flow.  Of course, if for some reason the multiple
encapsulations are needed to support a single DetNet service,
multiple S-Labels will be required for that service.  Note that in
the unlikely case that Ipv4 and IPv6 will map to the same DetNet
flow, different S-Labels will be needed to differentiate between the
versions of IP.
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
DetNet sequence number is carried in the DetNet Control word which
carries the Data/OAM discriminator.  To simplify implementation and
to maximize interoperability two sequence number sizes are supported:
a 16 bit sequence number and a 28 bit sequence number.  The 16 bit
sequence number is needed to support some types of legacy clients.
The 28 bit sequence number is used in situations where it is
necessary ensure that in high speed networks the sequence number
space does not wrap whilst packets are in flight.
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.  Note that the possible use of Penultimate Hop Popping
(PHP) means that the only label in a received label stack may be the
S-Label.
fig_pw_mpls illustrates a DetNet data plane MPLS encapsulation.  The
MPLS-based encapsulation of the DetNet flows is a good fit for the
scenarios described in sec_ip_mpls_dt_dp_scen and
sec_tsn_mpls_dt_dp_scen.  Furthermore, end to end DetNet service
i.e., native DetNet deployment (see sec_mpls_dt_dp_scen) is also
possible if DetNet end systems are capable of initiating and
termination MPLS encapsulated packets.
DetNet control word (d-CW) containing sequencing information for
packet replication and duplicate elimination purposes, and the OAM
indicator.
DetNet service Label (S-Label) that identifies a DetNet flow at
the receiving DetNet service sub-layer processing node.
Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to
direct the packet along the label switched path (LSP) to the next
service sub-layer processing 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 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.
Per RFC4385, MUST be set to zero (0).
An unsigned value implementing the DetNet sequence number.
The sequence number length MUST be provisioned (configured) on a per
app-flow basis via configuration, e.g., the controller plane
described in cp_considerations.
A 0 bit sequence number field length indicates that there is no
DetNet sequence number used for the flow.  When the length is zero,
the sequence number field MUST be set to zero (0) on all packets sent
for the flow.
When the sequence number field length is 16 or 28 bits for a flow,
the sequence number MUST be incremented by one for each new app-flow
packet sent.  When the field length is 16 bits, d-CW bits 4 to 15
MUST be set to zero (0).  This values carried in this field can wrap
and it is important to note that zero (0) is a valid field value.
For example, were the sequence number size is 16 bits, the sequence
will contain: 65535, 0, 1.  In this case, zero (0) is an ordinary
sequence number.  This differs from RFC4448 where a sequence number
of zero (0) does not indicate that no sequence number field value is
in use.
The sequence number is optionally used during receive processing as
described below in pef-requirements and pof-requirements.
App-flow identification at a DetNet service sub-layer is realized by
an S-Label.  Each app-flow MUST be sent by the node that adds a d-CW
with a single specific S-Label value.  MPLS-aware DetNet end systems
and edge nodes, which are by definition MPLS ingress and egress
nodes, MUST add and remove the d-CW and S-Label.  Relay nodes MAY
swap S-Label values when processing an app-flow.
The S-Label value MUST be provisioned per app-flow via configuration,
e.g., via the controller plane described in cp_considerations.  Note
that S-Labels provide app-flow identification at the downstream
DetNet service sub-layer receiver, not the sender.  As such, S-Labels
MUST be allocated by the entity that controls the service sub-layer
receiving node's label space, and MAY be allocated from the platform
label space RFC3031.
The S-Label will normally be at the bottom of the label stack,
immediately preceding the d-CW.  To support service sub-layer level
OAM, an OAM Associated Channel Header (ACH) RFC4385 together with a
Generic Associated Channel Label (GAL) RFC5586 MAY be used in place
of a d-CW.
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 previously stated in dn-gen-encap-solution, the use of
ECMP for DetNet flows is NOT RECOMMENDED.  ECMP MAY be used for non-
DetNet flows within a DetNet domain.
When receiving a DetNet MPLS flow, an implementation MUST identify
the app-flow 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 app-flow.  In the case where platform labels are not used, one or
more F-Labels proceeding the S-Label MUST be used together with the
S-Label to uniquely identify the incoming app-flows.  When PHP is
used, the incoming interface MAY also be used to together with any
present F-Label(s) and the S-Label to uniquely identify an incoming
app-flows.  Note that choice to use platform label space for S-Label
or S-Label plus one or more F-Labels to identify app flows 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, the controller plane MUST ensure that incoming DetNet MPLS
packets arrive with the needed information (F-label(s) and/or
incoming interface); the details of such are outside the scope of
this document.
While NOT REQUIRED, the use of platform labels for S-Labels matches
other pseudowire encapsulations.  This implementation choice also
impacts PEF and POF processing as described in the next section.
Implementations MAY support the Packet Elimination Function (PEF) for
received DetNet MPLS flows.  When supported, use of the PEF for a
particular app-flow MUST be provisioned via configuration, e.g., via
the controller plane described in cp_considerations.
After an app-flow is identified for a received DetNet MPLS packet, as
described above, an implementation MUST check if PEF is configured
for that app-flow.  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.
Note that an implementation MAY wish to constrain the maximum number
sequence numbers that are tracked, on platform-wide or per flow
basis.  Some implementations MAY support the provisioning of the
maximum number sequence numbers that are tracked number on either a
platform-wide or per flow basis.
A function that is related to PEF is the Packet Ordering Function
(POF).  Implementations MAY support POF.  When supported, use of the
POF for a particular app-flow MUST be provisioned via configuration,
e.g., via the controller plane described by cp_considerations.
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.
After an app-flow is identified for a received DetNet MPLS packet, as
described above, an implementation MUST check if POF is configured
for that app-flow.  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 incremened by one (1) for each new app-flow
packet sent, and the field value can wrap.  The specific mechanisms
used for an implementation to identify the order of received packets
is an implementation choice.
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.
F-Labels are support the DetNet forwarding sub-layer.  F-Labels are
used to provide LSP-based connectivity between DetNet service sub-
layer processing nodes.
DetNet MPLS end systems, edge nodes and relay nodes may operate at
the DetNet service sub-layer with understand of app-flows and their
requirements.  As mentioned above, when operating at this layer such
nodes can push, pop or swap (pop then push) S-Labels.  In all cases,
the F-Labels used for the app-flow are always replaced and this
section applies.
When sending a DetNet flow, Zero or more F-Labels MAY be added on top
of an S-Label by the node pushing an S-Label.  The F-Labels to be
pushed when sending a particular app-flow MUST be provisioned per
app-flow via configuration, e.g., via the controller plane discussed
in cp_considerations.  To allow for the omission of F-Labels, an
implementation SHOULD also allow an outgoing interface to be
provisioned.
The Packet Replication Function (PRF) function MAY be supported by an
implementation for outgoing DetNet flows.  When supported, the same
app-flow data will be sent over multiple outgoing forwarding sub-
layer LSPs.  To support PRF an implementation MUST support the
setting of different sets of F-Labels.  Hereto, to allow for the
omission of F-Labels, an implementation SHOULD also allow multiple
outgoing interfaces to be provisioned.  PRF MUST NOT be used with
app-flows configured with a d-CW sequence number field length of 0
bits.
When a single set of F-Labels is provisioned for a particular
outgoing app-flow, that set of F-labels MUST be pushed after the
S-Label is pushed.  The outgoing packet is then forwarded as
described below in f-labels-all.  When a single outgoing interface is
provisioned, the outgoing packet is then forwarded as described below
in f-labels-all.
When multiple sets of F-Labels or interfaces are provisioned for a
particular outgoing app-flow, a copy of the outgoing packet,
including the pushed 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.
As described in the previous section, when receiving a DetNet MPLS
flow, an implementation identifies the app-flow associated with the
incoming packet based on the S-Label.  When a node is using platform
labels for S-Labels, any F-Labels can be popped and the S-label
uniquely identifies the app-flow.  In the case where platform labels
are not used, F-Label(s) MUST also be provisioned for incoming app-
flows.  When PHP is used, incoming interface MUST be provisioned.
The provisioned information MUST then be used to identify incoming
app-flows based on the combination of S-Label and F-Label(s) or
incoming interface.
All DetNet aware MPLS nodes process F-Labels as needed to meet the
service requirements of the DetNet flow or flows carried in the LSPs
represented by the F-Labels.  This includes normal push, pop and swap
operations.  Such processing is essentially the same type of
processing enabled for TE LSPs, although the specific service
parameters, or traffic specification, can differ.  When the DetNet
service parameters of the app-flow or flows carried in an LSP
represented by an F-Label can be met by an exiting TE mechanism, the
forwarding sub-layer processing node MAY be a DetNet unaware, i.e.,
standard, MPLS LSR.  Such TE LSPs may provide LSP forwarding service
as defined in, but not limited to, RFC3209, RFC3270, RFC3272,
RFC3473, RFC4875, RFC5440, and RFC6006.
More specifically, as mentioned above, the DetNet forwarding sub-
layer provides explicit routes and allocated resources, and F-Labels
are used to map to each.  Explicit routes are supported based on the
topmost (outermost) F-Label that is pushed or swapped and the LSP
that corresponds to this label.  This topmost (outgoing) label MUST
be associated with a provisioned outgoing interface and, for non-
point-to-point outgoing interfaces, a next hop LSR.  Note that this
information MUST be provisioned via configuration or the controller
plane.  In the previously mentioned special case where there is no
added F-labels and the outgoing interface is not a point-to-point
interface, the outgoing interface MUST also be associated with a next
hop LSR.
Resources may be allocated in a hierarchical fashion per LSP that is
represented by each F-Label.  Each LSP MAY be provisioned with a
service parameters that dictates the specific traffic treatment to be
received by the traffic carried over that LSP.  Implementations of
this document MUST ensure that traffic carried over each LSP
represented by an F-Label receives the traffic treatment provisioned
for that LSP.  Typical mechanisms used to provide different treatment
to different flows includes the allocation of system resources (such
as queues and buffers) and provisioning or related parameters (such
as shaping, and policing).  Support can also be provided via an
underlying network technology such IEEE802.1 TSN mpls-over-tsn.
Other than in the TSN case, the specific mechanisms used by a DetNet
node to ensure DetNet service delivery requirements are met for
supported DetNet flows is outside the scope of this document.
MUST ensure a QoS flow does not exceed its allocated resources or
provisioned service level,
MUST ensure a CoS flow or service class does not impact the
service delivered to other flows.  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.
Subsequent sections provide additional considerations related to CoS
(CoS), QoS (QoS) and aggregation (Aggregation).
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.
requirements for DetNet that are discussed in control-management-
requirements.
requirements for the DetNet Controller Plane are discussed in
control-management-requirements.
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.
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 DetNet MPLS 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.
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.
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 of a co-routed
bidirectional flow to take the same path.  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.
This section covers how MPLS DetNet flows operate over an IEEE 802.1
TSN sub-network.  fig_mpls_detnet_to_tsn illustrates such a scenario,
where two MPLS (DetNet) nodes are interconnected by a TSN sub-
network.  Node-1 is single homed and Node-2 is dual-homed.  MPLS
nodes can be (1) MPLS DetNet End System, (2) MPLS DetNet Edge or
Relay node or (3) MPLS Transit node.
Note: in case of MPLS Transit node there is no DetNet Service sub-
layer.
This section covers how DetNet MPLS flows operate over an IEEE 802.1
TSN sub-network.  fig_mpls_detnet_to_tsn illustrates such a scenario,
where two MPLS (DetNet) nodes are interconnected by a TSN sub-
network.  Node-1 is single homed and Node-2 is dual-homed.  MPLS
nodes can be (1) DetNet MPLS End System, (2) DetNet MPLS Edge or
Relay node or (3) MPLS Transit node.
Note: in case of MPLS Transit node there is no DetNet Service sub-
layer processing.
As protocol interworking function defined in IEEE8021CB does not work
for MPLS labeled flows, the MPLS DetNet nodes MUST ensure proper TSN
sub-network specific Ethernet encapsulation of the MPLS DetNet
packets.  For a given TSN Stream (i.e., DetNet flow) an MPLS (DetNet)
node MUST behave as a TSN-aware Talker or a Listener inside the TSN
sub-network.
As protocol interworking function defined in IEEE8021CB does not work
for MPLS labeled flows, the DetNet MPLS nodes MUST ensure proper TSN
sub-network specific Ethernet encapsulation of the DetNet MPLS
packets.  For a given TSN Stream (i.e., DetNet flow) an MPLS (DetNet)
node MUST behave as a TSN-aware Talker or a Listener inside the TSN
sub-network.
Stream Identification MUST pair MPLS flows and TSN Streams and encode
that in data plane formats as well.  The packet's stream_handle
subparameter (see IEEE8021CB) inside the Talker/Listener is defined
based on the Flow-ID used in the upper MPLS DetNet layer.  Stream
Identification function MUST encode Ethernet header fields namely (1)
the destination MAC-address, (2) the VLAN-ID and (3) priority
parameters with TSN sub-network specific values.  Encoding is
provided for the frame passed down the stack from the upper layers.
Stream Identification MUST pair MPLS flows and TSN Streams and encode
that in data plane formats as well.  The packet's stream_handle
subparameter (see IEEE8021CB) inside the Talker/Listener is defined
based on the Flow-ID used in the upper DetNet MPLS layer.  Stream
Identification function MUST encode Ethernet header fields namely (1)
the destination MAC-address, (2) the VLAN-ID and (3) priority
parameters with TSN sub-network specific values.  Encoding is
provided for the frame passed down the stack from the upper layers.
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.
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 maps the MPLS
data plane encapsulation described in pwSolution to the DetNet IP
data plane define in I-D.ietf-detnet-dp-sol-ip.
Where the UDP header is used as defined in Section 3 of RFC7510.
As in pwSolution, the S-Label is used to identify a DetNet flow to
the peer node that processes it, in this case the node addressed by
the IP Header in IP-encap-dn.  The S-Label is allocated from the
receiving node?s platform label space RFC3031.
In ingress Edge Nodes, the encapsulation in IP-encap-dn will be
imposed on Detnet Flow Payload Packets as received from DetNet End
Systems, and the encapsulation will be removed in egress Edge Nodes
as they transmit the Payload Packets to the End Systems.
Again, the UDP header is used as defined in Section 3 of RFC7510.
Note that if required in both the case of IP Encapsulation of DetNet
IP-encap-dn, and of IP Encapsulation of DetNet with MPLS-SR IP-encap-
dn-sr, it is possible to omit the UDP header if required.  Operation
of MPLS directly over IP is described in RFC4023.  In this case
DetNet Service can be provided on a per IP flow basis as described in
I-D.ietf-detnet-dp-sol-ip.
This document builds on the the specification of MPLS over UDP and IP
defined in RFC7510.  It replaces the the F-Label(s) used in
pwSolution with UDP and IP headers.  The UDP and IP header
information is used to identify DetNet flows, including member flows,
per I-D.ietf-detnet-dp-sol-ip.  The resulting encapsulation is shown
in IP-encap-dn.
d-CW and and S-Labels are used as defined in pwSolution and are not
modified by this section.
To support outgoing DetNet MPLS over IP, an implementation MUST
support the provisioning of IP/UDP header information in place of
sets of F-Labels.  Note that multiple sets of F-Labels can be
provisioned to support PRF on transmitted DetNet flows and therefore,
when PRF is supported, multiple IP/UDP headers MAY be provisioned.
When multiple IP/UDP headers are provisioned for a particular
outgoing app-flow, a copy of the outgoing packet, including the
pushed S-Label, MUST be made for each.  The headers for each outgoing
packet MUST be based on the configuration information and as defined
in RFC7510, with one exception.  The one exceptions is that the UDP
Source Port value MUST be set to uniquely identify the DetNet
(forwarding sub-layer) flow.  The packet MUST then be handed as a
DetNet IP packet, per I-D.ietf-detnet-dp-sol-ip.
To support receive processing an implementation MUST also support the
provisioning of received IP/UDP header information.  When S-Labels
are taken from platform label space, all that is required is to
provision that receiving IP/UDP encapsulated DetNet MPLS packets is
permitted.  Once the IP/UDP header is stripped, the S-label uniquely
identifies the app-flow.  When S-Labels are not taken from platform
label space, IP/UDP header information MUST be provisioned.  The
provisioned information MUST then be used to identify incoming app-
flows based on the combination of S-Label and incoming IP/UDP header.
Normal receive processing, including PEOF can then take place.
This document makes no IANA requests.