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

Commentary: Updates from today 's meeting plus a bit of cleanup - references - spelling - addressing some clarifications from  
 I have checked all the diffs and they look good .
Paragraph (version A):
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.  DetNet provides these flows 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):
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 A):
The DetNet forwarding sub-layer may be directly provided by the
DetNet service layer, for example by IP, MPLS or IEEE 802.1 TSN
IEEE802.1TSNTG.  Alternatively an overlay approach may be used in
which the packet is natively carried between key nodes within the
DetNet network (say between PREOF nodes) and a sublayer is used to
provide the information needed to reach the next hop in the overlay.
Paragraph (version A):
This forwarding layer provides the quality underpin needed by the
DetNet Service layer.  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 layer provides additional support beyond the connectivity
function of the forwarding layer.  An example of this is Packet
Replication, Elimination, and Ordering (PREOF) function see PREOF.
Paragraph (version B):
The DetNet forwarding sub-layer may be directly provided by the
DetNet service sub-layer, for example by IP or MPLS.  Alternatively
an overlay approach may be used in which the packet is natively
carried between key nodes within the DetNet network (say between
PREOF nodes) and a sub-layer is used to provide the information
needed to reach the next hop in the overlay.
Paragraph (version B):
This forwarding sub-layer provides the quality underpin needed by the
DetNet Service sub-layer.  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 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)
function see PREOF.
Paragraph (version A):
Whether the DetNet flows are carried in there native form across
the DetNet network, or whether they are encapsulated.  dn_svcs and
dn_svc_encaps contrast native services and the encapsulation of
services.
Paragraph (version A):
Whether or not the DetNet data plane includes the facility to
carry additional information (metadata) that can be used to
provide an enhanced service to the DetNet packet.
Paragraph (version A):
The encapsulation of the DetNet flows allows them to be sent over a
data plane of a type other than their native type.  Encapsulation is
essential if, for example, it is required to send Ethernet DetNet
flows over a data plane such as MPLS.  dn_svc_encaps illustrates some
encapsulation combinations.
Paragraph (version B):
How the data plane is constructed: The DetNet service sub-layer
provides 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 standardized technologies e.g.  dn_svc_encaps.
Paragraph (version B):
Extensibility of that Data Plane: Whether or not the DetNet data
plane includes the facility to carry additional information
(metadata) that can be used to provide an enhanced service to the
DetNet packet.
Paragraph (version B):
The encapsulation of the DetNet flows allows them to be sent over a
data plane of a type 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 encapsulation combinations.
Paragraph (version A):
Encapsulation is also needed if the DetNet flow or aggregate flow is
not easily recognised from from its native encapsulation.
Paragraph (version B):
Encapsulation is also needed if the DetNet flow or aggregate flow is
not easily recognised from its encapsulation.
Paragraph (version A):
Implicit metadata can be included through the use of the network
programming paradigm I-D.spring-srv6-network-programming in which the
suffix of an IPv6 address is used to encode additional information
for use by the network of the receiving host.  Examples of such
information include the sequence number for use by the PREOF
function, or even all the essential information being deigned into
the DetNet over MPLS label stack (the DetNet Control Word and the
DetNet Service label).
Paragraph (version B):
Implicit metadata can be included through the use of the network
programming paradigm I-D.spring-srv6-network-programming in which the
suffix of an IPv6 address is used to encode additional information
for use by the network of the receiving host.  Examples of such
information include the sequence number for use by the PREOF
function, or even all the essential information being included into
the DetNet over MPLS label stack (the DetNet Control Word and the
DetNet Service label).
Paragraph (version A):
MPLS provides the ability to forward traffic over implicit and
explicit paths to the point in the network where the next DetNet
service layer action needs to take place.  It does this through the
use of a stack of one or more labels with various forwarding
semantics.
Paragraph (version B):
MPLS provides the ability to forward traffic over implicit and
explicit paths to the point in the network where the next DetNet
service sub-layer action needs to take place.  It does this through
the use of a stack of one or more labels with various forwarding
semantics.
Paragraph (version A):
In cases where metadata is needed to process an MPLS encapsulated
packet at the service layer, this has been been provided through the
use of a shim layer also called a control word (CW) RFC4385.
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 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, this has been been provided through
the use of a shim layer also called a control word (CW) RFC4385.
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):
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.
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 A):
Use of network coding to improve a network's throughput,
efficiency, latency, and scalability, as well as resilience to
partition, attacks, and eavesdropping, as compared to traditional
methods.  Network coding is another technique that uses multiple
paths typically with very similar delays and capacity.  Network
coding is often applied in wireless networks.
Paragraph (version A):
Use of packet by packet distribution of the same DetNet flow over
multiple paths is not recommended.  Such load sharing, e.g., via
ECMP or UCMP, impacts ordering and possibly jitter.
Paragraph (version A):
For example, to support identification of misbehaving flows.
Paragraph (version A):
For example, increase counters.
Paragraph (version A):
For example, unexpected loss.
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):
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 B):
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 B):
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):
IP aggreggation has both data plane and controller plane aspects.
For the dataplane flows may be aggregated for treatment based on
shared charateristice such as 5-tuple.  Alternatively, an IP
encapsualtion may be used to tunnel an aggregate number of DetNet
Flows between relay nodes.
Paragraph (version A):
MPLS aggragation similarly has data plane and controller plane
aspects.  In the case of MPLS flows are often tunneled in a
forwarding sublayer and reservation is associated with that MPLS
tunnel.
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 5-tuple.  Alternatively, an IP encapsulation
may be used to tunnel an aggregate number of DetNet Flows between
relay nodes.
Paragraph (version B):
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):
Any of the DetNet native service types may be transported by another
DetNet service.  MPLS nodes may interconnected by different sub-
network technologies, which may include point-to-point links.  Each
of these sub-network technologies 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 I-D.mpls-over-tsn.  UDP/IP represents the encapsulation
used on a DetNet IP PSN, as described in I-D.mpls-over-udp-ip.
Paragraph (version B):
Any of the DetNet service types may be transported by another DetNet
service.  MPLS nodes may interconnected by different sub-network
technologies, which may include point-to-point links.  Each of these
sub-network technologies 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 I-D.mpls-over-tsn.  UDP/IP represents the encapsulation
used on a DetNet IP PSN, as described in I-D.mpls-over-udp-ip.
Paragraph (version A):
In the abstract, the results of either distributed signaling or
centralized provisioning are equivalent from a DetNet data plane
perspective - flows are instantiated, explicit routes are determined,
resources are reserved, and packets are forwarded through the domain
using the DetNet native data plane.
Paragraph (version B):
In the abstract, the results of either distributed signaling or
centralized provisioning are equivalent from a DetNet data plane
perspective - flows are instantiated, explicit routes are determined,
resources are reserved, and packets are forwarded through the domain
using the DetNet data plane.
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, both of which aggregate multiple DetNet flows into a single new
DetNet flow.  It can also be grouping of IP flows that share 5-tuple
of 6-tuple attributes or flow identifiers at the DetNet layer.
Paragraph (version B):
Flow aggregation includes aggregation accomplished through the use of
hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and
TSN, both of which aggregate multiple DetNet flows into a single new
DetNet flow.  It can also be grouping of IP flows that share 5-tuple
of 6-tuple attributes or flow identifiers at the DetNet sub-layer.
Paragraph (version A):
When DetNet services are provisioned or requested one or more
paths meeting the requirements are selected and the resources
verified and if successful recorded in the databases.
Paragraph (version A):
The assignment of resources depends on the technology and it
includes assignment of specific links and coordination of the
queuing and other traffic management capabilities.
Paragraph (version A):
Depending on the specific technology the assigned resources are
updated in the databases preventing oversubscription.
Paragraph (version B):
When DetNet services are provisioned or requested one or more
paths meeting the requirements are selected and the resources
verified and recorded.
Paragraph (version B):
The assignment of resources along the path depends on the
technology and it includes assignment of specific links and
coordination of the queuing and other traffic management
capabilities.
Paragraph (version B):
Depending on the specific technology the assigned resources are
updated and distributed in the databases preventing over
subscription.
Paragraph (version A):
Explicit routes are used to ensure that packets are routed through
the resources that have been reserved for them, and hence provide the
DetNet application with the required service.  A requirement for the
DetNet Controller Plane will be the ability to assign a particular
identified DetNet IP flow to a path through the DetNet domain that
has been assigned the required nodal resources.  This provides the
appropriate traffic treatment for the flow and also includes
particular links as a part of the path that are able to support the
DetNet flow.  For example, by using IEEE 802.1 TSN links (as
discussed in XXX ) DetNet parameters can be maintained.  Further
considerations and requirements for the DetNet Controller Plane are
discussed in control-management-requirements.
Paragraph (version B):
Explicit routes are used to ensure that packets are routed through
the resources that have been reserved for them, and hence provide the
DetNet application with the required service.  A requirement for the
DetNet Controller Plane will be the ability to assign a particular
identified DetNet IP flow to a path through the DetNet domain that
has been assigned the required nodal resources.  This provides the
appropriate traffic treatment for the flow and also includes
particular links as a part of the path that are able to support the
DetNet flow.  For example, by using IEEE 802.1 TSN links (as
discussed in I-D.mpls-over-tsn ) DetNet parameters can be maintained.
Further considerations and requirements for the DetNet Controller
Plane are discussed in control-management-requirements.
Paragraph (version A):
As discussed in sec_intro, this document does not specify the
mechanisms needed to eliminate packet contention, packet loss or
reduce jitter for DetNet flows at the DetNet forwarding sub-layer.
The ability to manage node and link resources to be able to provide
these functions is a necessary part of the DetNet controller plane.
It is also necessary to be able to control the required queuing
mechanisms used to provide these functions along a flow's path
through the network.  See XXX and control-management-requirements for
further discussion of these requirements.
Paragraph (version B):
As discussed in sec_intro, this document does not specify the
mechanisms needed to eliminate packet contention, packet loss or
reduce jitter for DetNet flows at the DetNet forwarding sub-layer.
The ability to manage node and link resources to be able to provide
these functions is a necessary part of the DetNet controller plane.
It is also necessary to be able to control the required queuing
mechanisms used to provide these functions along a flow's path
through the network.  See I-D.ietf-detnet-ip --> and control-
management-requirements for further discussion of these requirements.
Paragraph (version A):
sec_dt_dp discussed the use of the IP "6-tuple" for flow
identification, and goes on to discuss how identified flows use
specific QoS mechanisms for flow-specific traffic treatment,
including path control and resource allocation.  XXX contains
detailed DetNet IP flow identification procedures.  Flow
identification will play an important role for the DetNet controller
plane.
Paragraph (version A):
aggregation and ip-agg discuss the use of flow aggregation in DetNet.
Flow aggregation can be accomplished using any of the 6-tuple fields
defined in XXX , using a DSCP identified traffic class or other
field.  It will be the responsibility of the DetNet controller plane
to be able to properly provision the use of these aggregation
mechanisms.  These requirements are included in control-management-
requirements.
Paragraph (version A):
This section covers MPLS data plane specific control plane
considerations.  This section needs generallizing.
Paragraph (version A):
DetNet S-Labels (see XXX for their definition) are similar to other
MPLS service labels that denote the contents of the MPLS packet
payload such as a layer 2 pseudowire, an IP packet that is routed in
a VPN context with a private address, or an Ethernet virtual private
network (EVPN) service.
Paragraph (version B):
sec_dt_dp discussed the use of the IP "6-tuple" for flow
identification, and goes on to discuss how identified flows use
specific QoS mechanisms for flow-specific traffic treatment,
including path control and resource allocation.  I-D.ietf-detnet-ip
contains detailed DetNet IP flow identification procedures.  Flow
identification will play an important role for the DetNet controller
plane.
Paragraph (version B):
aggregation and ip-agg discuss the use of flow aggregation in DetNet.
Flow aggregation can be accomplished using any of the 6-tuple fields
defined in I-D.ietf-detnet-ip , using a DSCP identified traffic class
or other field.  It will be the responsibility of the DetNet
controller plane to be able to properly provision the use of these
aggregation mechanisms.  These requirements are included in control-
management-requirements.
Paragraph (version B):
This section covers MPLS data plane specific control plane
considerations.  This section needs generalizing.
Paragraph (version B):
DetNet S-Labels I-D.ietf-detnet-mpls for their definition) are
similar to other MPLS service labels that denote the contents of the
MPLS packet payload such as a layer 2 pseudowire, an IP packet that
is routed in a VPN context with a private address, or an Ethernet
virtual private network (EVPN) service.
Paragraph (version A):
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 XXX , or a DetNet Relay
or Edge Node as shown in XXX ) and interpreted in the context of
their received F-Label.
Paragraph (version A):
As discussed in sec_dt_dp, the forwarding sub-layer uses one or more
F-Labels to forward DetNet packets between DetNet service-aware nodes
along explicitly defined routes at the DetNet forwarding sub-layer,
which in the context of this document is the MPLS layer.  F-Labels
can also provide context for an S-Label.  In the DetNet Forwarding
(MPLS) sub-layer the explicit route consists of the set of DetNet
nodes which are LSRs, links, and possibly link bundle members and
queues that the DetNet packets of a flow must traverse between nodes
in the DetNet service sub-layer (i.e. between a specific Edge Node
and the next hop Relay Node, between specific Relay Nodes, and
between a specific Relay node and the egress Edge Node.  Resource
allocation corresponding to the set of Services supported over the
forwarding sub-layer, which may or may not include aggregation, is
required at this sub-layer.  Explicit routes are used to ensure that
packets are routed through the resources that have been reserved for
them, and hence provide the DetNet application with the required
service.  Multiple F-Labels may be pushed after an S-Label and there
is no requirement for all F-Labels to be controlled via the same
controller mechanisms.  For example in EVPN, some labels are
distributed using BGP while others are distributed using LDP or RSVP.
Paragraph (version B):
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 or a DetNet Relay or Edge Node and
interpreted in the context of their received F-Label.
Paragraph (version B):
As discussed in sec_dt_dp, the forwarding sub-layer uses one or more
F-Labels to forward DetNet packets between DetNet service-aware nodes
along explicitly defined routes at the DetNet forwarding sub-layer,
which in the context of this document is MPLS.  F-Labels can also
provide context for an S-Label.  In the DetNet Forwarding (MPLS) sub-
layer the explicit route consists of the set of DetNet nodes which
are LSRs, links, and possibly link bundle members and queues that the
DetNet packets of a flow must traverse between nodes in the DetNet
service sub-layer (i.e. between a specific Edge Node and the next hop
Relay Node, between specific Relay Nodes, and between a specific
Relay node and the egress Edge Node.  Resource allocation
corresponding to the set of Services supported over the forwarding
sub-layer, which may or may not include aggregation, is required at
this sub-layer.  Explicit routes are used to ensure that packets are
routed through the resources that have been reserved for them, and
hence provide the DetNet application with the required service.
Multiple F-Labels may be pushed after an S-Label and there is no
requirement for all F-Labels to be controlled via the same controller
mechanisms.  For example in EVPN, some labels are distributed using
BGP while others are distributed using LDP or RSVP.