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

Commentary: Fine with the changes . Ready to be merged .
The DetNet Architecture decomposes the DetNet related data plane
functions into two layers: a service layer and a transport layer.
The service layer is used to provide DetNet service protection and
reordering.  The transport layer is used to provides congestion
protection (low loss, assured latency, and limited reordering).  As
no DetNet specific headers are added to support IP DetNet flows, only
the transport layer functions are supported using the IP DetNet
defined by this document.  Service protection can be provided on a
per sub-net basis using technologies such as MPLS I-D.ietf-detnet-dp-
sol-mpls and IEEE802.1 TSN.
The DetNet Architecture decomposes the DetNet related data plane
functions into two layers: a service layer and a forwarding layer.
The service layer is used to provide DetNet service protection and
reordering.  The forwarding layer is used to provides congestion
protection (low loss, assured latency, and limited reordering).  As
no DetNet specific headers are added to support IP DetNet flows, only
the forwarding layer functions are supported using the IP DetNet
defined by this document.  Service protection can be provided on a
per sub-net basis using technologies such as MPLS I-D.ietf-detnet-dp-
sol-mpls and IEEE802.1 TSN.
This document uses the terminology and concepts established in the
DetNet architecture I-D.ietf-detnet-architecture the reader is
assumed to be familiar with that document.
This document uses the terminology and concepts established in the
DetNet architecture I-D.ietf-detnet-architecture and the reader is
assumed to be familiar with that document.
fig_ip_detnet_simple illustrates a DetNet enabled IP network.  The
DetNet enabled end systems originate IP encapsulated traffic that is
identified as DetNet flows, relay nodes understand the transport
requirements of the DetNet flow and ensure that node, interface and
sub-network resources are allocated to ensure DetNet service
requirements.  The dotted line around the Service component of the
Relay Nodes indicates that the transit routers are DetNet service
aware but do not perform any DetNet service layer function, e.g.,
PREOF.  IEEE 802.1 TSN is an example sub-network type which can
provide support for DetNet flows and service.  The mapping of IP
DetNet flows to TSN streams and TSN protection mechanisms is covered
in mapping-tsn.
fig_ip_detnet_simple illustrates a DetNet enabled IP network.  The
DetNet enabled end systems originate IP encapsulated traffic that is
identified as DetNet flows, relay nodes understand the forwarding
requirements of the DetNet flow and ensure that node, interface and
sub-network resources are allocated to ensure DetNet service
requirements.  The dotted line around the Service component of the
Relay Nodes indicates that the transit routers are DetNet service
aware but do not perform any DetNet service layer function, e.g.,
PREOF.  IEEE 802.1 TSN is an example sub-network type which can
provide support for DetNet flows and service.  The mapping of IP
DetNet flows to TSN streams and TSN protection mechanisms is covered
in mapping-tsn.
fig_ip_detnet illustrates a variant of fig_ip_detnet_simple, with an
MPLS based DetNet network as a sub-network between the relay nodes.
It shows a more complex DetNet enabled IP network where an IP flow is
mapped to one or more PWs and MPLS (TE) LSPs.  The end systems still
originate IP encapsulated traffic that is identified as DetNet flows.
The relay nodes follow procedures defined in I-D.ietf-detnet-dp-sol-
mpls to map each DetNet flow to MPLS LSPs.  While not shown, relay
nodes can provide service layer functions such as PREOF over the MPLS
transport layer, and this is indicated by the solid line for the MPLS
facing portion of the Service component.  Note that the Transit node
is MPLS (TE) LSP aware and performs switching based on MPLS labels,
and need not have any specific knowledge of the DetNet service or the
corresponding DetNet flow identification.  See I-D.ietf-detnet-dp-
sol-mpls for details on the mapping of IP flows to MPLS as well as
general support for DetNet services using MPLS.
fig_ip_detnet illustrates a variant of fig_ip_detnet_simple, with an
MPLS based DetNet network as a sub-network between the relay nodes.
It shows a more complex DetNet enabled IP network where an IP flow is
mapped to one or more PWs and MPLS (TE) LSPs.  The end systems still
originate IP encapsulated traffic that is identified as DetNet flows.
The relay nodes follow procedures defined in I-D.ietf-detnet-dp-sol-
mpls to map each DetNet flow to MPLS LSPs.  While not shown, relay
nodes can provide service layer functions such as PREOF using DetNet
over MPLS, and this is indicated by the solid line for the MPLS
facing portion of the Service component.  Note that the Transit node
is MPLS (TE) LSP aware and performs switching based on MPLS labels,
and need not have any specific knowledge of the DetNet service or the
corresponding DetNet flow identification.  See I-D.ietf-detnet-dp-
sol-mpls for details on the mapping of IP flows to MPLS as well as
general support for DetNet services using MPLS.
End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow.  When
transporting packets, this means that packets are appropriately
shaped on transmission and received appropriate traffic treatment on
the connected sub-network, see QoS and detrouting for more details.
When receiving packets, this means that there are appropriate local
node resources, e.g., buffers, to receive and process a DetNet flow
packets.
End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow.  When
forwarding packets, this means that packets are appropriately shaped
on transmission and received appropriate traffic treatment on the
connected sub-network, see QoS and detrouting for more details.  When
receiving packets, this means that there are appropriate local node
resources, e.g., buffers, to receive and process a DetNet flow
packets.
The DetNet Service Flow MUST be mapped to the link / sub-network
specific resources using an underlying system specific means.  This
implies each DetNet aware node on path MUST look into the transported
DetNet Service Flow packet and utilize e.g., a 5- (or 6-) tuple to
find out the required mapping within a node.
The DetNet Service Flow MUST be mapped to the link / sub-network
specific resources using an underlying system specific means.  This
implies each DetNet aware node on path MUST look into the forwarded
DetNet Service Flow packet and utilize e.g., a 5- (or 6-) tuple to
find out the required mapping within a node.
DetNet flows transported via IP have more limited aggregation
options, due to the available traffic flow identification fields of
the IP solution.  One available approach is to manage the resources
associated with a DSCP identified traffic class and to map (remark)
individually controlled DetNet flows onto that traffic class.  This
approach also requires that nodes support aggregation ensure that
traffic from aggregated LSPs are placed (shaped/policed/enqueued) in
a fashion that ensures the required DetNet service is preserved.
DetNet flows forwarded via IP have more limited aggregation options,
due to the available traffic flow identification fields of the IP
solution.  One available approach is to manage the resources
associated with a DSCP identified traffic class and to map (remark)
individually controlled DetNet flows onto that traffic class.  This
approach also requires that nodes support aggregation ensure that
traffic from aggregated LSPs are placed (shaped/policed/enqueued) in
a fashion that ensures the required DetNet service is preserved.