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

Commentary: whitespace + changes from mar 5 meeting
The DetNet Architecture decomposes the DetNet related data plane
functions 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
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 sub-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 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
provides congestion protection (low loss, assured latency, and
limited reordering).  As no DetNet specific headers are added to
support DetNet IP flows, only the forwarding sub-layer functions are
supported using the DetNet IP 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.
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 sub-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 sub-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 DetNet
IP flows to TSN streams and TSN protection mechanisms is covered in
mapping-tsn.
DetNet routers ensure that detnet service requirements are met per
hop by allocating local resources, both receive and transmit, and by
mapping the service requirements of each flow to appropriate sub-
network mechanisms.  Such mapping is sub-network technology specific.
The mapping of IP DetNet Flows to MPLS is covered ip-over-mpls.  The
mapping of IP DetNet Flows to IEEE 802.1 TSN is covered in mapping-
tsn.
DetNet routers ensure that detnet service requirements are met per
hop by allocating local resources, both receive and transmit, and by
mapping the service requirements of each flow to appropriate sub-
network mechanisms.  Such mapping is sub-network technology specific.
The mapping of DetNet IP Flows to MPLS is covered ip-over-mpls.  The
mapping of IP DetNet Flows to IEEE 802.1 TSN is covered in mapping-
tsn.
This section defines how IP encapsulated DetNet flows are carried
over a DetNet MPLS data plane as defined in I-D.ietf-detnet-dp-sol-
mpls.  The basic encapsulation approach is to treat a DetNet IP flow
as an app flow from the DetNet MPLS app perspective.  The
corresponding example DetNet Sub-Network format is shown in
fig_dn_ip_mpls_sn_ex.
This section defines how IP encapsulated DetNet flows are carried
over a DetNet MPLS data plane as defined in I-D.ietf-detnet-dp-sol-
mpls.  The basic encapsulation approach is to treat a DetNet IP flow
as an app-flow from the DetNet MPLS app perspective.  The
corresponding example DetNet Sub-Network format is shown in
fig_dn_ip_mpls_sn_ex.
A relay node that sends a DetNet IP flows over a DetNet MPLS network
MUST map a single DetNet IP flow into a single app-flow and MUST
process that app-flow in accordance to the procedures defined in I-
D.ietf-detnet-dp-sol-mpls Section 6.2.  PRF MAY be supported for
DetNet IP flows sent over an DetNet MPLS network.  Aggregation as
defined in ip-agg MAY be used to identify an individual DetNet IP
flow.  The provisioning of the mapping of DetNet IP flows to DetNet
MPLS app flow information MUST be supported via configuration and the
controller plane, see m-cp-considerations.
A relay node MAY be provisioned to handle packets received via the
DetNet MPLS data plane as DetNet IP flows.  A single incoming MPLS
app 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 ip-flow-id.  An implementation
MUST support the provisioning of handling of received DetNet MPLS
data plane as DetNet IP flows via configuration and the controller
plane, see m-cp-considerations.  Note that such configuration MAY
include support from PEOF on the incoming DetNet MPLS flow.
A relay node that sends a DetNet IP flows over a DetNet MPLS network
MUST map a single DetNet IP flow into a single app-flow and MUST
process that app-flow in accordance to the procedures defined in I-
D.ietf-detnet-dp-sol-mpls Section 6.2.  PRF MAY be supported for
DetNet IP flows sent over an DetNet MPLS network.  Aggregation as
defined in ip-agg MAY be used to identify an individual DetNet IP
flow.  The provisioning of the mapping of DetNet IP flows to DetNet
MPLS app-flow information MUST be supported via configuration and the
controller plane, see m-cp-considerations.
A relay node MAY be provisioned to handle packets received via the
DetNet MPLS data plane as DetNet IP flows.  A single incoming MPLS
app-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 ip-flow-id.  An implementation
MUST support the provisioning of handling of received DetNet MPLS
data plane as DetNet IP flows via configuration and the controller
plane, see m-cp-considerations.  Note that such configuration MAY
include support from PEOF on the incoming DetNet MPLS flow.
This section covers how IP DetNet flows operate over an IEEE 802.1
TSN sub-network.  fig_ip_detnet_to_tsn illustrates such a scenario,
where two IP (DetNet) nodes are interconnected by a TSN sub-network.
Node-1 is single homed and Node-2 is dual-homed.  IP nodes can be (1)
IP DetNet End System, (2) IP DetNet Edge or Relay node or (3) IP End
System.
This section covers how DetNet IP flows operate over an IEEE 802.1
TSN sub-network.  fig_ip_detnet_to_tsn illustrates such a scenario,
where two IP (DetNet) nodes are interconnected by a TSN sub-network.
Node-1 is single homed and Node-2 is dual-homed.  IP nodes can be (1)
DetNet IP End System, (2) DetNet IP Edge or Relay node or (3) IP End
System.
IP DetNet Flow and TSN Stream mapping is based on the active Stream
Identification function, that operates at the frame level.
IEEE8021CB defines an Active Destination MAC and VLAN Stream
identification function, what can replace some Ethernet header fields
namely (1) the destination MAC-address, (2) the VLAN-ID and (3)
priority parameters with alternate values.  Replacement is provided
for the frame passed down the stack from the upper layers or up the
stack from the lower layers.
DetNet IP Flow and TSN Stream mapping is based on the active Stream
Identification function, that operates at the frame level.
IEEE8021CB defines an Active Destination MAC and VLAN Stream
identification function, what can replace some Ethernet header fields
namely (1) the destination MAC-address, (2) the VLAN-ID and (3)
priority parameters with alternate values.  Replacement is provided
for the frame passed down the stack from the upper layers or up the
stack from the lower layers.
From the TSN sub-network perspective IP DetNet nodes without any TSN
functions can be treated as TSN-unaware Talker or Listener.  In such
cases relay nodes in the TSN sub-network MUST modify the Ethernet
encapsulation of the IP DetNet flow (e.g., MAC translation, VLAN-ID
setting, Sequence number addition, etc.) to allow proper TSN specific
handling of the flow inside the sub-network.  This is illustrated in
fig_ip_without_tsn.
From the TSN sub-network perspective DetNet IP nodes without any TSN
functions can be treated as TSN-unaware Talker or Listener.  In such
cases relay nodes in the TSN sub-network MUST modify the Ethernet
encapsulation of the DetNet IP flow (e.g., MAC translation, VLAN-ID
setting, Sequence number addition, etc.) to allow proper TSN specific
handling of the flow inside the sub-network.  This is illustrated in
fig_ip_without_tsn.
TSN-aware IP DetNet nodes are member of both the DetNet domain and
the TSN sub-network.  Within the TSN sub-network the TSN-aware IP
(DetNet) node has a TSM-aware Talker/Listener role, so TSN specific
management and control plane functionalities must be implemented.
There are many similarities in the management plane techniques used
in DetNet and TSN, but that is not the case for the control plane
protocols.  For example, RSVP-TE and MSRP behaves differently.
Therefore management and control plane design is an important aspect
of scenarios, where mapping between DetNet and TSN is required.
TSN-aware DetNet IP nodes are member of both the DetNet domain and
the TSN sub-network.  Within the TSN sub-network the TSN-aware IP
(DetNet) node has a TSM-aware Talker/Listener role, so TSN specific
management and control plane functionalities must be implemented.
There are many similarities in the management plane techniques used
in DetNet and TSN, but that is not the case for the control plane
protocols.  For example, RSVP-TE and MSRP behaves differently.
Therefore management and control plane design is an important aspect
of scenarios, where mapping between DetNet and TSN is required.