Draft: draft-ietf-detnet-data-plane-framework

Commentary: Update based on the comments of   ( 01.10 ) and   ( 04.10 ) . 
 I agree with  , it 's a well - known and deployed example . I 'm not sure why it was removed . Cheers ,  
 comments have been resolved
Paragraph (version A):
This document provides an overall framework for the Deterministic
Networking data plane.  It covers concepts and considerations that
are generally common to any Deterministic Networking data plane
specification.
Paragraph (version A):
Deterministic Networking (DetNet) provides a capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end
delivery latency.  A description of the general background and
concepts of DetNet can be found in I-D.ietf-detnet-architecture.
Paragraph (version B):
This document provides an overall framework for the DetNet data
plane.  It covers concepts and considerations that are generally
common to any Deterministic Networking data plane specification.
Paragraph (version B):
DetNet (Deterministic Networking) provides a capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end
delivery latency.  A description of the general background and
concepts of DetNet can be found in I-D.ietf-detnet-architecture.
Paragraph (version A):
The DetNet Architecture models the DetNet related data plane
functions decomposed 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 provide congestion protection (low loss, assured latency,
and limited out-of-order delivery) and leverages Traffic Engineering
mechanisms.
Paragraph (version A):
As part of the service sub-layer functions, this document describes
typical DetNet node data plane operation.  It describes the function
and operation of the Packet Replication (PRF) Packet Elimination
(PEF) and the Packet Ordering (POF) functions within the service sub-
layer.  It also describes the forwarding sub-layer that is used to
eliminate (or reduce) contention loss and provide bounded latency for
DetNet flows.
Paragraph (version B):
The DetNet Architecture models the DetNet related data plane
functions decomposed 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
leverages Traffic Engineering mechanisms and provides congestion
protection (low loss, assured latency, and limited out-of-order
delivery).
Paragraph (version B):
As part of the service sub-layer functions, this document describes
typical DetNet node data plane operation.  It describes the function
and operation of the Packet Replication (PRF) Packet Elimination
(PEF) and the Packet Ordering (POF) functions within the service sub-
layer.  Furthermore, it also describes the forwarding sub-layer.
Paragraph (version A):
Different traffic types, or application flows, can be mapped on top
of DetNet.  DetNet can optionally reuse header information provided
by, or shared with, applications.  An example of shared header fields
can be found in I-D.ietf-detnet-ip.
Paragraph (version A):
This document also covers concepts related to the controller plane
and Operations, Administration, and Maintenance (OAM) functions
related to the control plane.  Data plane OAM specifics are out of
scope for this docuement.
Paragraph (version B):
Different application flows (e.g., Ethernet, IP, etc.), can be mapped
on top of DetNet.  DetNet can optionally reuse header information
provided by, or shared with, applications.  An example of shared
header fields can be found in I-D.ietf-detnet-ip.
Paragraph (version B):
This document also covers basic concepts related to the controller
plane and Operations, Administration, and Maintenance (OAM).  Data
plane OAM specifics are out of scope for this docuement.
Paragraph (version B):
DetNet Control Word.
Paragraph (version B):
DetNet.
Paragraph (version B):
DetNet "service" label.
Paragraph (version B):
Time-Division Multiplexing.
Paragraph (version A):
This document describes how application flows, or app-flows, are
carried over DetNet networks.  The DetNet Architecture, I-D.ietf-
detnet-architecture, models the DetNet related data plane functions
decomposed into two sub-layers: a service sub-layer and a forwarding
sub-layer.
Paragraph (version B):
This document describes how application flows, or app-flows, are
carried over DetNet networks.  The DetNet Architecture, I-D.ietf-
detnet-architecture, models the DetNet related data plane functions
as decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer.
Paragraph (version A):
The forwarding sub-layer provides the quality underpin needed by the
DetNet flow.  It may do this directly through the use of queuing
techniques and traffic engineering methods, or it may do this through
the assistance of its underlying connectivity.  For example it may
call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN
IEEE802.1TSNTG.
Paragraph (version B):
The forwarding sub-layer provides the QoS related functions needed by
the DetNet flow.  It may do this directly through the use of queuing
techniques and traffic engineering methods, or it may do this through
the assistance of its underlying connectivity.  For example it may
call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN
IEEE802.1TSNTG.
Paragraph (version A):
The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer.  An example of
this is Packet Replication, Elimination, and Ordering (PREOF)
functions see PREOF.
Paragraph (version A):
The method of instantiating each of the layers is specific to the
particular DetNet data plane method.  There may be more than one
approach that is applicable to a given bearer network type.
Paragraph (version A):
Data plane technology: The DetNet data plane is provided by the
DetNet service and forwarding sub layers.  The DetNet service sub-
layer generally provides its functions for the DetNet application
flows by using or applying existing standardized headers and/or
encapsulations.  The Detnet forwarding sub-layer may provide
capabilities leveraging that same header or encapsulation
technology e.g. dn_svcs or it may be achieved by other
technologies e.g.  dn_svc_encaps.  DetNet is currently defined for
operation over packet switched (IP) networks or label switched
(MPLS) networks.
Paragraph (version A):
Encapsulation format: DetNet encodes specific flow attributes
(namely flow identity and sequence number) in packets.  For
example, in DetNet IP, zero encapsulation may be used and no
sequence number is available, and in DetNet MPLS, DetNet specific
information may be added explicitly to the packets in the format
of S-label and d-CW.
Paragraph (version A):
The encapsulation of the DetNet flows allows them to be sent over a
data plane technology other than their native type.  Encapsulation is
essential if, for example, it is required to send Ethernet TSN stream
as a DetNet Application over a data plane such as MPLS.
dn_svc_encaps illustrates some relationships between the components.
Paragraph (version A):
The use of encapsulation is also required if additional information
(meta-data) is needed by the DetNet data plane and there is either no
ability to include it in the client data packet, or the specification
of the client data plane does not permit the modification of the
packet to include additional data.  An example of such meta-data is
the inclusion of a sequence number required by the PREOF function.
Paragraph (version B):
The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer.  An example of
this is Packet Replication, Elimination, and Ordering functions see
PREOF.
Paragraph (version B):
The method of instantiating each of the layers is specific to the
particular DetNet data plane method, and more than one approach may
be applicable to a given bearer network type.
Paragraph (version B):
There are two major characteristics to the data plane: the technology
and the encapsulation, as discussed below.
Paragraph (version B):
The DetNet data plane is provided by the DetNet service and
forwarding sub layers.  The DetNet service sub-layer generally
provides its functions for the DetNet application flows by using or
applying existing standardized headers and/or encapsulations.  The
Detnet forwarding sub-layer may provide capabilities leveraging that
same header or encapsulation technology (e.g., DN IP or DN MPLS) or
it may be achieved by other technologies (e.g., dn_svc_encaps).
DetNet is currently defined for operation over packet switched (IP)
networks or label switched (MPLS) networks.
Paragraph (version B):
DetNet encodes specific flow attributes (flow identity and sequence
number) in packets.  For example, in DetNet IP, zero encapsulation is
used and no sequence number is available, and in DetNet MPLS, DetNet
specific information may be added explicitly to the packets in the
format of S-label and d-CW.
Paragraph (version B):
The encapsulation of a DetNet flow allows it to be sent over a data
plane technology other than its native type.  DetNet uses header
information to perform traffic classification, i.e., identify DetNet
flows, and provide DetNet service and forwarding functions.  As
mentioned above, DetNet may add headers, as is the case for DN MPLS,
or may use headers that are already present, as is the case in DN IP.
dn_svc_encaps illustrates some relationships between the components.
Paragraph (version B):
The use of encapsulation is also required if additional information
(metadata) is needed by the DetNet data plane and there is either no
ability to include it in the client data packet, or the specification
of the client data plane does not permit the modification of the
packet to include additional data.  An example of such metadata is
the inclusion of a sequence number required by the PREOF function.
Paragraph (version A):
Both of these metadata are required for DetNet service sub-layer
specific functions (e.g., PREOF).  DetNet forwarding sub-layer
related functions require only Flow-ID.
Paragraph (version A):
Metadata can be a useful way of identifying packets that need to be
treated as a flow or flow aggregate.  It is also useful as a way of
including a sequence number the packet for use by the PREOF function
or as a place to carry OAM indications or OAM information to
instrument DetNet data plane operation.
Paragraph (version B):
The DetNet data plane framework supports a Flow-ID (for
identification of the flow or aggregate flow) and/or a Sequence
Number (for PREOF) for each DetNet flow.  The DetNet Service sub-
layer requires both; the DetNet forwarding sub-layer requires only
Flow-ID.  Metadata can also be used for OAM indications and
instrumentation of DetNet data plane operation.
Paragraph (version B):
Metadata can be included implicit or explicit.  Explicit means that a
dedicated header field is used to include metadata in a DetNet
packet.  In case of implicit method a part of an already existing
header field is used to encode the metadata.
Paragraph (version A):
An IP data plane may operate natively or through the use of an
encapsulation.  Many types of IP encapsulation can satisfy DetNet
requirements and it is anticipated that more than one encapsulation
may be deployed for example GRE, IPSec etc.
Paragraph (version A):
One method of operating an IP DetNet data plane without encapsulation
is to use "6-tuple" based flow identification, where "6-tuple" refers
to information carried in IP and higher layer protocol headers.
General background on the use of IP headers, and "6-tuples", to
identify flows and support Quality of Service (QoS) can be found in
RFC3670.  RFC7657 also provides useful background on the delivery
differentiated services (DiffServ) and "tuple" based flow
identification.  DetNet flow aggregation may be enabled via the use
of wildcards, masks, prefixes and ranges.  The operation of this
method is described in detail in I-D.ietf-detnet-ip.
Paragraph (version B):
An IP data plane may operate natively or through the use of an
encapsulation.  Many types of IP encapsulation can satisfy DetNet
requirements and it is anticipated that more than one encapsulation
may be deployed, for example GRE, IPSec etc.
Paragraph (version B):
One method of operating an IP DetNet data plane without encapsulation
is to use "6-tuple" based flow identification, where "6-tuple" refers
to information carried in IP and higher layer protocol headers.
General background on the use of IP headers, and "6-tuples", to
identify flows and support Quality of Service (QoS) can be found in
RFC3670.  RFC7657 provides useful background on differentiated
services (DiffServ) and "tuple" based flow identification.  DetNet
flow aggregation may be enabled via the use of wildcards, masks,
prefixes and ranges.  The operation of this method is described in
detail in I-D.ietf-detnet-ip.
Paragraph (version A):
In cases where metadata is needed to process an MPLS encapsulated
packet at the service sub-layer, a shim layer also called a control
word (CW) RFC4385 can be used.  Although such CWs are frequently 32
bits long, there is no architectural constraint on its size of this
structure, only the requirement that it is fully understood by all
parties operating on it in the DetNet service sub-layer.  The
operation of this method is described in detail in I-D.ietf-detnet-
mpls.
Paragraph (version B):
In cases where metadata is needed to process an MPLS encapsulated
packet at the service sub-layer, a shim layer called a control word
(CW) RFC4385 can be used.  Although such CWs are frequently 32 bits
long, there is no architectural constraint on its size of this
structure, only the requirement that it is fully understood by all
parties operating on it in the DetNet service sub-layer.  The
operation of this method is described in detail in I-D.ietf-detnet-
mpls.
Paragraph (version A):
Reservation of resources can allocate resources to specific DetNet
flows.  This can eliminate packet contention and loss for DetNet
traffic.  This also can reduce jitter for the DetNet traffic.
DetNet flows are assumed to behave with respect to the reserved
traffic profile.  If other traffic shares the link resources, the
use of (queuing, policing, shaping) policies can be used to ensure
that the allocation of resources reserved for DetNet is met.
Queuing and shaping of DetNet traffic could be required to ensure
that DetNet traffic does not exceed its reserved profile but this
would impact the DetNet service characteristics.
Paragraph (version A):
Use of a specific path for a flow.  This allows control of the
network delay by steering the packet with the ability to influence
the physical path.  Explicit routes complement reservation by
ensuring that a consistent path can be associated with its
resources for the duration of that path.  Coupled with the traffic
mechanism, this limits misordering and bounds latency.  Explicit
route computation can encompass a wide set of constraints and
optimize the path for a certain characteristic e.g. highest
bandwidth or lowest jitter.  In these cases the "best" path for
any set of characteristics may not be a shortest path.  The
selection of path can take into account multiple network metrics.
Some of these metrics are measured and distributed by the routing
system as traffic engineering metrics.
Paragraph (version A):
Use of multiple packet streams using multiple paths, for example
1+1 or 1:1 linear protection.  For DetNet this primarily relates
to packet replication and elimination capabilities.  MPLS offers a
number of protection schemes.  MPLS hitless protection can be used
to switch traffic to an already established path in order to
restore delivery rapidly after a failure.  Path changes, even in
the case of failure recovery, can lead to the out of order
delivery of data requiring packet ordering functions either within
the DetNet service or at a high layer in the application traffic.
Establishment of new paths after a failure is out of scope for
DetNet services.
Paragraph (version A):
Network Coding, not to be confused with network programming,
comprises several techniques where multiple data flows are
encoded.  These resulting flows can then be sent on different
paths.  The encoding operation can combine flows and error
recovery information.  When the encoded flows are decoded and
recombined the original flows can be recovered.  Note that Network
coding uses an alternative to packet by packet PREOF.  Therefore,
for certain network topologies and traffic loads, Network Coding
can be used to improve a network's throughput, efficiency,
latency, and scalability, as well as resilience to partition,
attacks, and eavesdropping, as compared to traditional methods.
DetNet could utilized Network coding as an alternative to other
protection means.  Network coding is often applied in wireless
networks and is being explored for other network types.
Paragraph (version A):
Use of packet by packet distribution of the same DetNet flow over
multiple paths is not recommended except for the cases listed
above where PREOF is utilized to improve protection of traffic and
maintain order.  Packet by packet load sharing, e.g., via ECMP or
UCMP, impacts ordering and possibly jitter.
Paragraph (version A):
Since Detnet leverages many different forwarding sub-layers, those
technologies also support a number of tools to troubleshoot
connectivity for example, to support identification of misbehaving
flows.  At the service layer again there are existing mechanisms
to troubleshoot or monitor flows.  Many of these mechanisms exist
for IP and MPLS networks.  A client of a DetNet service can
introduce any monitoring applications which can detect and monitor
delay and loss.
Paragraph (version A):
To a large degree this follows the logic in the previous section.
Analytics can be inherited from the two sub-layers.  At the DetNet
service edge packet and bit counters e.g. sent, received, dropped,
and out of sequence are maintained.
Paragraph (version A):
The provider of a DetNet service may allow other capabilities to
monitor flows such as more detail loss statistics and time
stamping of events.  The details of these capabilities are
currently out of scope for this document.
Paragraph (version A):
Several of these capabilities are expanded upon in more detail below.
Paragraph (version A):
Service protection allow DetNet services to increase reliability and
maintain a DetNet Service Assurance in the case of network congestion
or some failures.  Detnet relies on the underlying technology
capabilities for various protection schemes.  Protection schemes
enable partial or complete coverage of the network paths and active
protection with combinations of PRF, PRE, and POF.
Paragraph (version B):
This section provides informative considerations related to providing
DetNet service to flows which are identified based on their header
information.
Paragraph (version B):
At a high level, the following functions are provided on a per flow
basis.
Paragraph (version B):
Reservation of resources can allocate resources to specific DetNet
flows.  This can eliminate packet contention and packet loss for
DetNet traffic.  This also can reduce jitter for DetNet traffic.
Resources allocated to a DetNet flow protect it from other traffic
flows.  On the other hand, DetNet flows are assumed to behave with
respect to the reserved traffic profile.  Misbehaving DetNet flows
must be detected and it have to be ensured that they do not
compromise QoS of other flows.  The use of (queuing, policing,
shaping) policies can be used to ensure that the allocation of
resources reserved for DetNet is met.
Paragraph (version B):
Use of a specific path for a flow.  This allows control of the
network delay by steering the packet with the ability to influence
the physical path.  Explicit routes complement reservation by
ensuring that a consistent path can be associated with its resources
for the duration of that path.  Coupled with the traffic mechanism,
this limits misordering and bounds latency.  Explicit route
computation can encompass a wide set of constraints and optimize the
path for a certain characteristic e.g. highest bandwidth or lowest
jitter.  In these cases the "best" path for any set of
characteristics may not be a shortest path.  The selection of path
can take into account multiple network metrics.  Some of these
metrics are measured and distributed by the routing system as traffic
engineering metrics.
Paragraph (version B):
Use of multiple packet streams using multiple paths, for example 1+1
or 1:1 linear protection.  For DetNet this primarily relates to
packet replication and elimination capabilities.  MPLS offers a
number of protection schemes.  MPLS hitless protection can be used to
switch traffic to an already established path in order to restore
delivery rapidly after a failure.  Path changes, even in the case of
failure recovery, can lead to the out of order delivery of data
requiring packet ordering functions either within the DetNet service
or at a high layer in the application traffic.  Establishment of new
paths after a failure is out of scope for DetNet services.
Paragraph (version B):
Network Coding, not to be confused with network programming,
comprises several techniques where multiple data flows are encoded.
These resulting flows can then be sent on different paths.  The
encoding operation can combine flows and error recovery information.
When the encoded flows are decoded and recombined the original flows
can be recovered.  Note that Network coding uses an alternative to
packet by packet PREOF.  Therefore, for certain network topologies
and traffic loads, Network Coding can be used to improve a network's
throughput, efficiency, latency, and scalability, as well as
resilience to partition, attacks, and eavesdropping, as compared to
traditional methods.  DetNet could utilized Network coding as an
alternative to other protection means.  Network coding is often
applied in wireless networks and is being explored for other network
types.
Paragraph (version B):
Use of packet-by-packet distribution of the same DetNet flow over
multiple paths is not recommended except for the cases listed above
where PREOF is utilized to improve protection of traffic and maintain
order.  Packet by packet load sharing, e.g., via ECMP or UCMP,
impacts ordering and possibly jitter.
Paragraph (version B):
Detnet leverages many different forwarding sub-layers, each of which
supports various tools to troubleshoot connectivity, for example
identification of misbehaving flows.  The DetNet Service layer can
leverage existing mechanisms to troubleshoot or monitor flows, such
as those in use by IP and MPLS networks.  At the Application layer a
client of a DetNet service can use existing techniques to detect and
monitor delay and loss.
Paragraph (version B):
Network analytics can be inherited from the technologies of the
Service and Forwarding sub-layers.  At the DetNet service edge,
packet and bit counters (e.g. sent, received, dropped, and out-of-
sequence) can be maintained.
Paragraph (version B):
The provider of a DetNet service may provide other capabilities to
monitor flows, such as more detailed loss statistics and time
stamping of events.  The details of these capabilities are currently
out of scope for this document.
Paragraph (version B):
Service protection allow DetNet services to increase reliability and
maintain a DetNet Service Assurance in the case of network congestion
or network failure.  Detnet relies on the underlying technology
capabilities for various protection schemes.  Protection schemes
enable partial or complete coverage of the network paths and active
protection with combinations of PRF, PEF, and POF.
Paragraph (version A):
This example also illustrates 1:1 protection scheme meaning there is
traffic and path for each segment of the end to end path.  Local
DetNet relay nodes determine which packets are eliminated and which
packets are forwarded.  A 1+1 scheme where only one path is used for
traffic at a time, could use the same topology.  In this case there
is no PRF function and traffic is switched upon detection of failure.
An OAM scheme that monitors the paths detects the loss of path or
traffic is required to initiate the switch.  A POF may still be used
in this case to prevent misordering of packets.  In both cases the
protection paths are established and maintained for the duration of
the DetNet service.
Paragraph (version A):
The DetNet data plane also allows for the aggregation of DetNet
flows, to improved scaling by reducing the state per hop.  How this
is accomplished is data plane or control plane dependent.  When
DetNet flows are aggregated, transit nodes provide service to the
aggregate and not on a per-DetNet flow basis.  When aggregating
DetNet flows the flows should be compatible i.e. the same or very
similar QoS and CoS characteristics.  In this case, nodes performing
aggregation will ensure that per-flow service requirements are
achieved.
Paragraph (version A):
If bandwidth reservations are used, the sum of the reservations
should be the sum of all the individual reservations, in other words,
the reservations should not create an over subscription of bandwidth
reservation.  If maximum delay bounds are used the system should
ensure that the aggregate does not exceed the delay bounds of the
individual flows.
Paragraph (version A):
DetNet encapsulation is a data plane mechanism that can be used to
aggregate traffic.  Encapsulation can either be in the same service
type or in a different service type see dn_svc_encaps for example.
When an encapsulation is used the choice of reserving a maximum
resource level and then tracking the services in the aggregated
service or adjusting the aggregated resources as the services are
added is implementation and technology specific.
Paragraph (version B):
This example also illustrates 1:1 protection scheme meaning there is
traffic over each segment of the end to end path.  Local DetNet relay
nodes determine which packets are eliminated and which packets are
forwarded.  A 1+1 scheme where only one path is used for traffic at a
time, could use the same topology.  In this case there is no PRF
function and traffic is switched upon detection of failure.  An OAM
scheme that monitors the paths detects the loss of path or traffic is
required to initiate the switch.  A POF may still be used in this
case to prevent misordering of packets.  In both cases the protection
paths are established and maintained for the duration of the DetNet
service.
Paragraph (version B):
The DetNet data plane also allows for the aggregation of DetNet
flows, which can improve scalability by reducing the per-hop state.
How this is accomplished is data plane or control plane dependent.
When DetNet flows are aggregated, transit nodes provide service to
the aggregate and not on a per-DetNet flow basis.  When aggregating
DetNet flows the flows should be compatible i.e. the same or very
similar QoS and CoS characteristics.  In this case, nodes performing
aggregation will ensure that per-flow service requirements are
achieved.
Paragraph (version B):
If bandwidth reservations are used, the sum of the reservations
should be the sum of all the individual reservations; in other words,
the reservations should not add up to an over-subscription of
bandwidth reservation.  If maximum delay bounds are used, the system
should ensure that the aggregate does not exceed the delay bounds of
the individual flows.
Paragraph (version B):
When an encapsulation is used the choice of reserving a maximum
resource level and then tracking the services in the aggregated
service or adjusting the aggregated resources as the services are
added is implementation and technology specific.
Paragraph (version A):
DetNet flows at edges must be able to handle rejection to an
aggregation group due to lack of resources as well as conditions
where general requirements are not satisfied.
Paragraph (version A):
IP aggregation has both data plane and controller plane aspects.  For
the data plane flows may be aggregated for treatment based on shared
characteristics such as 6-tuple.  Alternatively, an IP encapsulation
may be used to tunnel an aggregate number of DetNet Flows between
relay nodes.
Paragraph (version A):
MPLS aggregation similarly has data plane and controller plane
aspects.  In the case of MPLS flows are often tunneled in a
forwarding sub-layer and reservation is associated with that MPLS
tunnel.
Paragraph (version A):
Data-flows requiring DetNet service are generated and terminated on
end-systems.  Encapsulation depends on the application and its
preferences.  For example, 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.
Paragraph (version A):
As a general rule, DetNet domains are capable of forwarding any
DetNet 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 applications peer with Ethernet applications.
Paragraph (version B):
DetNet flows at edges must be able to handle rejection to an
aggregation group due to lack of resources as well as conditions
where requirements are not satisfied.
Paragraph (version B):
IP aggregation has both data plane and controller plane aspects.  For
the data plane, flows may be aggregated for treatment based on shared
characteristics such as 6-tuple.  Alternatively, an IP encapsulation
may be used to tunnel an aggregate number of DetNet Flows between
relay nodes.
Paragraph (version B):
MPLS aggregation also has data plane and controller plane aspects.
MPLS flows are often tunneled in a forwarding sub-layer, under the
reservation associated with that MPLS tunnel.
Paragraph (version B):
Data-flows requiring DetNet service are generated and terminated on
end-systems.  Encapsulation depends on the application and its
preferences.  For example, in a DetNet MPLS domain the sub-layer
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 DetNet
functions.
Paragraph (version B):
As a general rule, DetNet domains are capable of forwarding any
DetNet flows and the DetNet domain does not mandate the end-system or
edge node 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 applications peer with Ethernet applications.
Paragraph (version A):
Flow aggregation includes aggregation accomplished through the use of
hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and
TSN, all of which aggregate multiple DetNet flows into a single new
DetNet flow.  Aggregation can also be grouping of IP flows that share
6-tuple attributes or flow identifiers at the DetNet sub-layer.
Paragraph (version B):
Flow aggregation means that multiple App-flows are served by a single
new DetNet flow.  There are many techniques to achieve aggregation,
for example in case of IP, it can be grouping of IP flows that share
6-tuple attributes or flow identifiers at the DetNet sub-layer.
Another example includes aggregation accomplished through the use of
hierarchical LSPs in MPLS and tunnels.
Paragraph (version A):
Depending on the specific technology the assigned resources are
updated and distributed in the databases preventing over
subscription.
Paragraph (version B):
Depending on the specific technology, the assigned resources
are updated and distributed in the databases, preventing over-
subscription.
Paragraph (version A):
DetNet's use of PREOF may increase the complexity of using co-routing
bidirectional flows, since if PREOF is used, then the replication
points in one direction would have to match the elimination points in
the other direction, and vice versa, and the optimal points for these
functions in one direction may not match the optimal points in the
other subsequent to the network and traffic constraints.
Furthermore, due to the per packet service protection nature,
bidirectional forwarding per packet may not be ensured.  The first
packet of received member flows is selected by the elimination
function independently of which path it has taken through the
network.
Paragraph (version B):
DetNet's use of PREOF may increase the complexity of using co-routing
bidirectional flows, since if PREOF is used, then the replication
points in one direction would have to match the elimination points in
the other direction, and vice versa.  In such cases the optimal
points for these functions in one direction may not match the optimal
points in the other, due to network and traffic constraints.
Furthermore, due to the per packet service protection nature,
bidirectional forwarding per packet may not be ensured.  The first
packet of received member flows is selected by the elimination
function independently of which path it has taken through the
network.
Paragraph (version A):
From a data plane perspective DetNet does not add or modify any
header information.
Paragraph (version B):
In order to prevent or mitigate DetNet attacks on other networks via
flow escape, edge devices can for example use existing mechanism such
as policing and shaping applied at the output of a DetNet domain.