Draft: draft-ietf-detnet-ip-over-mpls

Commentary: mpls - over - ip : minor tweaks ipOmpls : Section 6 , Management and Control Information Summary mpls : editorial changes , refactoring of section 5 for clarity and completeness white space cleanup ( remove tabs and trailing spaces )
Paragraph (version A):
A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a
DetNet MPLS network MUST map that single DetNet IP flow into a single
MPLS DetNet flow and MUST process it in accordance to the procedures
defined in I-D.ietf-detnet-mpls Section 6.1.  PRF MAY be supported
for DetNet IP flows sent over an DetNet MPLS network.  Aggregation
MAY be supported as defined in I-D.ietf-detnet-mpls Section 5.4.
Aggregation considerations in I-D.ietf-detnet-ip MAY be used to
identify an individual DetNet IP flow.  The provisioning of the
mapping of DetNet IP flows to DetNet MPLS flows MUST be supported via
configuration, e.g., via the controller plane.
Paragraph (version B):
A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a
DetNet MPLS network MUST map a DetNet IP flow, as identified in I-
D.ietf-detnet-ip into a single MPLS DetNet flow and MUST process it
in accordance to the procedures defined in I-D.ietf-detnet-mpls
Section 6.1.  PRF MAY be supported at the MPLS level for DetNet IP
flows sent over an DetNet MPLS network.  Aggregation MAY be supported
as defined in I-D.ietf-detnet-mpls Section 5.4.  Aggregation
considerations in I-D.ietf-detnet-ip MAY be used to identify an
individual DetNet IP flow.  The provisioning of the mapping of DetNet
IP flows to DetNet MPLS flows MUST be supported via configuration,
e.g., via the controller plane.
Paragraph (version A):
A DetNet relay node (egress T-PE) MAY be provisioned to handle
packets received via the DetNet MPLS data plane as DetNet IP flows.
A single incoming DetNet MPLS flow MAY be treated as a single DetNet
IP flow, without examination of IP headers.  Alternatively, packets
received via the DetNet MPLS data plane MAY follow the normal DetNet
IP flow identification procedures defined in I-D.ietf-detnet-ip
Section 7.1.  An implementation MUST support the provisioning for
handling any received DetNet MPLS data plane as DetNet IP flows via
configuration.  Note that such configuration MAY include support from
PEOF on the incoming DetNet MPLS flow.
Paragraph (version B):
A DetNet relay node (egress T-PE) MAY be provisioned to handle
packets received via the DetNet MPLS data plane as DetNet IP flows.
A single incoming DetNet MPLS flow MAY be treated as a single DetNet
IP flow, without examination of IP headers.  Alternatively, packets
received via the DetNet MPLS data plane MAY follow the normal DetNet
IP flow identification procedures defined in I-D.ietf-detnet-ip
Section 7.1.
Paragraph (version B):
An implementation MUST support the provisioning for handling any
received DetNet MPLS data plane as DetNet IP flows via configuration.
Note that such configuration MAY include support from PEOF on the
incoming DetNet MPLS flow.
Paragraph (version B):
Each MPLS App-Flow is identified using the IP flow identification
information as defined in I-D.ietf-detnet-ip.  The information is
summarized in Section 6 of that document, and includes all
wildcards, port ranges and ability to ignore specific IP fields.
Paragraph (version B):
The DetNet MPLS service that is to be used to send the matching IP
traffic.  Logically this is a pointer to the information provided
in I-D.ietf-detnet-mpls Section 5.1, and includes both service and
traffic delivery information.
Paragraph (version B):
S-Label values that are carrying MPLS over IP encapsulated
traffic.
Paragraph (version B):
For each S-Label, how the received traffic is to be handled.  The
traffic may be processed according as any other DetNet IP traffic
as defined in this document or in I-D.ietf-detnet-ip, or the
traffic may be directly treated as an MPLS App-flow for additional
processing according to I-D.ietf-detnet-mpls.
Paragraph (version A):
This document specifies the MPLS Deterministic Networking data plane
operation and encapsulation over an IP network.  The approach is
modeled on the operation of MPLS and PseudoWires (PW) over IP.
Paragraph (version B):
This document specifies the MPLS Deterministic Networking data plane
operation and encapsulation over an IP network.  The approach is
modeled on the operation of MPLS and over UDP/IP packet switched
networks.
Paragraph (version A):
This document specifies use of the MPLS 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 I-D.ietf-
detnet-mpls to the DetNet IP data plane defined in I-D.ietf-detnet-
ip.
Paragraph (version B):
This document specifies use of the MPLS DetNet encapsulation over an
IP network.  The approach is modeled on the operation of MPLS over an
IP Packet Switched Network (PSN) RFC7510.  It maps the MPLS data
plane encapsulation described in I-D.ietf-detnet-mpls to the DetNet
IP data plane defined in I-D.ietf-detnet-ip.
Paragraph (version A):
PseudoWire.
Paragraph (version A):
d-CW and and S-Labels are used as defined in I-D.ietf-detnet-mpls and
are not modified by this document.  In case of aggregates the A-Label
is treated as an S-Label and it is not modified as well.
Paragraph (version A):
To support outgoing DetNet MPLS over UDP/IP, an implementation MUST
support the provisioning of UDP/IP header information in addition or
in place of F-Label(s).  The headers for each outgoing packet MUST be
based on the configuration information and as defined in RFC7510,
with one exception.  The one exception is that the UDP Source Port
value MUST be set to uniquely identify the DetNet flow.  The packet
MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip.
Paragraph (version A):
To support receive processing an implementation MUST also support the
provisioning of received UDP/IP header information.  The provisioned
information MUST be used to identify incoming app-flows based on the
combination of S-Label and incoming IP/UDP header.  Normal receive
processing, including PEF and POF can then take place.
Paragraph (version B):
d-CW, S-Labels and zero or more F-Labels are used as defined in I-
D.ietf-detnet-mpls and are not modified by this document.  In case of
aggregates the A-Label is treated as an S-Label and it too is not
modified.
Paragraph (version B):
To support outgoing DetNet MPLS over UDP/IP encapsulation, an
implementation MUST support the provisioning of UDP and IP header
information in addition or in place of F-Label(s).  Note, when PRF is
performed at the MPLS service sub-layer, there will be multiple
member flows, and each member flow will require the provisioning of
their own UDP and IP header information.  The headers for each
outgoing packet MUST be formatted on the configuration information
and as defined in RFC7510, with one exception.  Note that the UDP
Source Port value MUST be set to uniquely identify the DetNet flow.
The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-
detnet-ip.  This includes QoS related traffic treatment.
Paragraph (version B):
To support receive processing an implementation MUST also support the
provisioning of received UDP and IP header information.  The
provisioned information MUST be used to identify incoming app-flows
based on the combination of S-Label and incoming encapsulation header
information.  Normal receive processing as defined in I-D.ietf-
detnet-mpls, including PEF and POF, can then take place.
Paragraph (version A):
Label information (S-label or F-label) to be mapped to UDP/IP
flow.
Paragraph (version A):
IPv4 protocol field.  Only UDP is allowed.
Paragraph (version A):
IPv6 next header field.  Only UDP is allowed.
Paragraph (version B):
Label information (S-label or F-label) to be mapped to UDP/IP
flow.  Note that a single S-Label can map to multiple sets of UPD/
IP information when PREOF is used.
Paragraph (version A):
A special case of an S-Label, whose properties are known only at
the aggregation and deaggregation end-points.
Paragraph (version B):
A special case of an S-Label, whose aggregation properties are
known only at the aggregation and deaggregation end-points.
Paragraph (version A):
DetNet end system and relay nodes understand the particular needs of
DetNet flows and provide both DetNet service and forwarding sub-layer
functions.  In the case of MPLS, DetNet nodes add, remove and process
d-CWs, S-Labels and F-labels as needed.  DetNet MPLS nodes provide
functionality analogous to T-PEs when they sit at the edge of an MPLS
domain, and S-PEs when they are in the middle of an MPLS domain, see
RFC6073.
Paragraph (version B):
DetNet end system and relay nodes understand the particular needs of
DetNet flows and provide both DetNet service and forwarding sub-layer
functions.  In the case of MPLS, DetNet service-aware nodes add,
remove and process d-CWs, S-Labels and F-labels as needed.  DetNet
MPLS nodes provide functionality analogous to T-PEs when they sit at
the edge of an MPLS domain, and S-PEs when they are in the middle of
an MPLS domain, see RFC6073.
Paragraph (version A):
The sequence number length MUST be provisioned (configured) on a per
app-flow basis via configuration, e.g., the controller plane
described in I-D.ietf-detnet-data-plane-framework.
Paragraph (version B):
The sequence number length MUST be provisioned on a per app-flow
basis via configuration, i.e., via the controller plane described in
I-D.ietf-detnet-data-plane-framework.
Paragraph (version A):
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.
Paragraph (version B):
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).  The 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, where zero (0) is an ordinary sequence
number.
Paragraph (version B):
It is important to note that this document differs from RFC4448 where
a sequence number of zero (0) is used to indicate that the sequence
number check algorithm is not used.
Paragraph (version A):
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.
Paragraph (version B):
App-flow identification at a DetNet service sub-layer is realized by
an S-Label.  MPLS-aware DetNet end systems and edge nodes, which are
by definition MPLS ingress and egress nodes, MUST add and remove an
app-flow specific d-CW and S-Label.  Relay nodes MAY swap S-Label
values when processing an app-flow.
Paragraph (version A):
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.
Paragraph (version B):
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, zero
or more F-Labels and optionally, the incoming interface, proceeding
the S-Label MUST be used together with the S-Label to uniquely
identify the app-flows associated with a received packet.  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, for example, to in the case where PHP is used.  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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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 incremented 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.
Paragraph (version B):
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 incremented 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.
Paragraph (version A):
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 I-D.ietf-detnet-data-plane-framework.  F-Labels can also provide
context for an S-Label.  To allow for the omission of F-Labels, an
implementation SHOULD also allow an outgoing interface to be
provisioned.
Paragraph (version A):
The Packet Replication Function (PRF) function MAY be supported by an
implementation for outgoing DetNet flows.  When replication is
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.  Therefore, 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.
Paragraph (version B):
When sending a DetNet flow, zero or more F-Labels MAY be pushed 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 I-D.ietf-detnet-data-plane-framework.  F-Labels can also provide
context for an S-Label.  To allow for the omission of F-Labels, an
implementation SHOULD also allow an outgoing interface to be used.
Paragraph (version B):
The Packet Replication Function (PRF) function MAY be supported by an
implementation for outgoing DetNet flows.  When replication is
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.  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.
Paragraph (version A):
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.
Paragraph (version B):
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) and, optionally, the incoming interface MUST
also be provisioned for incoming app-flows.  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.
Paragraph (version A):
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.
Paragraph (version B):
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 provided 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.
Paragraph (version A):
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.
Paragraph (version B):
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 are 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.
Paragraph (version A):
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 I-D.ietf-detnet-
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.
Paragraph (version B):
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 one or more F-Labels 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
I-D.ietf-detnet-mpls-over-tsn.  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.
Paragraph (version A):
The resource control and management aspects of aggregation (including
the configuration of queuing, shaping, and policing) are the
responsibility of the DetNet controller plane and will be covered in
other documents.  It is also the responsibility of the controller
plane to ensure that consistent aggregation methods are used.
Paragraph (version B):
The resource control and management aspects of aggregation (including
the configuration of queuing, shaping, and policing) are the
responsibility of the DetNet controller plane and is out of scope of
this documents.  It is also the responsibility of the controller
plane to ensure that consistent aggregation methods are used.
Paragraph (version A):
Both the aggregation label, or A-Label, and the individual flow's
S-Label have their MPLS S bit set indicating bottom of stack, and the
d-CW allows the PREOF to work.  An A-Label is a special case of an
S-Label, whose properties are known only at the aggregation and
deaggregation end-points.
Paragraph (version B):
Both the aggregation label, which is referred to as an A-Label, and
the individual flow's S-Label have their MPLS S bit set indicating
bottom of stack, and the d-CW allows the PREOF to work.  An A-Label
is a special case of an S-Label, whose properties are known only at
the aggregation and deaggregation end-points.
Paragraph (version A):
It is important that the DetNet layer is configured such that a
DetNet node never receives its own replicated packets.  If it were to
receive such packets the replication function would make the loop
more destructive of bandwidth than a conventional unicast loop.
Ultimately the TTL in the S-Label will cause the packet to die during
a transient loop, but given the sensitivity of applications to packet
latency the impact on the DetNet application would be severe.
Paragraph (version B):
It is important that the DetNet layer is configured such that a
DetNet node never receives its own replicated packets.  If it were to
receive such packets the replication function would make the loop
more destructive of bandwidth than a conventional unicast loop.
Ultimately the TTL in the S-Label will cause the packet to die during
a transient loop, but given the sensitivity of applications to packet
latency the impact on the DetNet application would be severe.  To
avoid the problem of a transient forwarding loop, changes to an LSP
supporting DetNet MUST be loop-free.
Paragraph (version A):
Each flow's service parameters and S-Label.
Paragraph (version A):
The PREOF functions to be supported for each S-Label.
Paragraph (version A):
The mapping of each S-Label to an F-Label stack.
Paragraph (version A):
S-Labels to A-Label mappings.
Paragraph (version A):
A-Label values and service parameters.
Paragraph (version A):
Each DetNet F-Label value and associated traffic parameters.
Paragraph (version A):
F-Label to H-LSP mappings.
Paragraph (version A):
H-LSP label values and associated parameters.
Paragraph (version A):
Outgoing interface, next hop, and sub-network parameters on a
technology specific basis.
Paragraph (version A):
The path could be explicitly set up by a controller which
calculates the path and explicitly configures each node along that
path with the appropriate forwarding and resource allocation
information.
Paragraph (version A):
The path could be set up using RSVP-TE signaling.
Paragraph (version A):
The path could be implemented using MPLS-based segment routing
when extended to support resource allocation.
Paragraph (version B):
The specific information needed for the processing of each DetNet
service depends on the DetNet node type and the functions being
provided on the node.  This section summarizes based on the DetNet
sub-layer and if the DetNet traffic is being sent or received.  All
DetNet node types are DetNet forwarding sub-layer aware, while all
but transit nodes are service sub-layer aware.  This is shown in
fig_dn_mpls_detnet.
Paragraph (version B):
App-Flow identification information, e.g., an incoming service on
a relay node or IP information as defined in I-D.ietf-detnet-ip-
over-mpls.
Paragraph (version B):
The sequence number length to be used for the service.  Valid
values included 0, 16 and 28 bits. 0 bits cannot be used when PRF
is configured for the service.
Paragraph (version B):
The S-Label for the service.
Paragraph (version B):
If PRF is to be provided for the service.
Paragraph (version B):
The forwarding sub-layer information associated with the output of
the service sub-layer.  Note that when the PRF function is
provisioned, this information is per DetNet member flow.
Logically this is a pointer to details provided below for
transmission of Detnet flows at the forwarding sub-layer.
Paragraph (version B):
The forwarding sub-layer information associated with the input of
the service sub-layer.  Note that when the PEF function is
provisioned, this information is per DetNet member flow.
Logically this is a pointer to details provided below related to
the reception of Detnet flows at the forwarding sub-layer or
A-Label.
Paragraph (version B):
The S-Label for the received service.
Paragraph (version B):
If PEF or POF is to be provided for the service.
Paragraph (version B):
The sequence number length to be used for the service.  Valid
values included 0, 16 and 28 bits. 0 bits cannot be used when PEF
or POF are configured for the service.
Paragraph (version B):
Nodes performing aggregation using A-Labels, per Section aggregating-
detnet-flows-as-a-new-detnet-flow, require the additional information
summarized in this section.
Paragraph (version B):
The S-Labels or F-Labels that are to be carried over each
aggregated service.
Paragraph (version B):
The A-Label associated with each aggregated service.
Paragraph (version B):
The other S-Label information summarized above.
Paragraph (version B):
On the receiving node, the A-Label provides the forwarding context of
an incoming interface or an F-Label and is used in subsequent service
or forwarding sub-layer receive processing, as appropriated.  The
related addition configuration that may be provided discussed
elsewhere in this section.
Paragraph (version B):
The outgoing F-Label stack to be pushed.  The stack may include
H-LSP labels.
Paragraph (version B):
The traffic parameters associated with a specific label in the
stack.  Note that there may be multiple sets of traffic paramters
associated with specific labels in the stack, e.g., when H-LSPs
are used.
Paragraph (version B):
Outgoing interface and, for unicast traffic, the next hop
information.
Paragraph (version B):
Sub-network specific parameters on a technology specific basis.
For example, see I-D.ietf-detnet-mpls-over-tsn.
Paragraph (version B):
The incoming interface.  For some implementations and deployment
scenarios, this information may not be needed.
Paragraph (version B):
The incoming F-Label stack to be popped.  The stack may include
H-LSP labels.
Paragraph (version B):
How the incoming forwarding sub-layer flow is to be handled, i.e.,
forwarded as a transit node, or provided to the service sub-layer.