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

Commentary: PR for changes since last meeting , formatted rev can be found here :
DetNet IP flows are identified based on IP, both IPv4 RFC0791 and
IPv6 RFC2460, header information.  In particular, 6 header fields are
used and this set is commonly referred to as the IP header "6-tuple".
The 6 fields include the IP source and destination address fields,
the next level protocol or header field, the next level protocol
(e.g.  TCP or UDP) source and destination ports, and the IPv4 Type of
Service or IPv6 Traffic Class field (i.e., DSCP).  As part of single
DetNet flow identification, any of the fields can be ignored
(wildcarded), and bit masks, prefix based longest match, and ranges
can also be used.
fig_non_detnet_ip illustrates a variant of fig_ip_detnet_simple where
the end systems are not DetNet aware.  In this case, edge nodes sit
at the boundary of the DetNet domain and act as proxies for the end
application by initiating and terminating DetNet service for the non-
DetNet aware IP flows.  The existing header information or an
approach such as described in aggregation can be used to support
DetNet flow identification.
DetNet IP flows are identified based on IP, both IPv4 RFC0791 and
IPv6 RFC2460, header information.  6 header fields are used and this
set of fields is commonly referred to as the IP header "6-tuple".
The 6 fields include the IP source and destination address fields,
the next level protocol or header field, the next level protocol
(e.g.  TCP or UDP) source and destination ports, and the IPv4 Type of
Service or IPv6 Traffic Class field (i.e., DSCP).  As part of single
DetNet flow identification, any of the fields can be ignored
(wildcarded), and bit masks, prefix based longest match, and ranges
can also be used.
DetNet flow aggregation may also be enabled via the use of wildcards,
masks, prefixes and ranges.  In these cases, it is expected that
DetNet aware intermediate nodes will provide DetNet service assurance
on the aggregate through resource allocation and mechanisms such as
queuing.
DetNet flow aggregation may be enabled via the use of wildcards,
masks, prefixes and ranges.  IP tunnels may also be used to support
flow aggregation.  In these cases, it is expected that DetNet aware
intermediate nodes will provide DetNet service assurance on the
aggregate through resource allocation and congestion control
mechanisms.
In case of Ethernet end-systems the application data is encapsulated
directly in L2.  From the DN domain perspective no upper layer
protocols are visible.  The Data-flow uses only Ethernet tag(s) and
further flow specific parameters (if needed) are hidden inside the
PDU.
The IP end-system scenario is different.  Data-flows are encapsulated
directly in L3 (i.e., IP) and the application may use further upper
layer protocols (e.g., RTP).  Many valid combinations exist, and it
may be application specific how the IP header fields are used.  Also,
usage of further upper layer protocols depends on application
requirements (e.g., time-stamp).  Some examples for encoding of Flow-
ID or Sequence Number attributes: IP address, IPv6-Flow-label, L4
ports, RTP-header, etc.
As a general rule, DetNet domains MUST be capable to forward any
Data-flows and the DetNet domain MUST NOT intend to mandate end-
system encapsulation format.
L3 end-systems peer with L3 end-systems.
This section provides informative considerations related to providing
DetNet services via IP.
Data-flows requiring DetNet service are generated and terminated on
end-systems.  The specific protocols used by an end system are
specific to an application.  This said, DetNet's use of 6-tuple IP
flow identification means that DetNet must be aware of not only the
format of the IP header, but also of the next protocol carried within
an IP packet.
When IP end stations are DetNet aware, no application-level or
service-level proxy functions are needed inside the DetNet domain, so
end-systems peer with end-systems using the same application
encapsulation format (see figure below).
End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow.  When sending
packets, this generally means that packets 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 generally means that there are appropriate
local node resources, e.g., buffers, to receive and process a DetNet
flow.
As a general rule, DetNet domains need to be able to forward any
DetNet flow identified by the IP 6-tuple.  Doing otherwise would
limit end-system encapsulation format.  From a practical standpoint
this means that all nodes along the end-to-end path of a DetNet flows
need to agree on what fields are used for flow identification, and
the transport protocols (e.g., TCP/UDP/IPsec) which can be used to
identify 6-tuple protocol ports.
DetNet Routing service provides routing, therefore available only for
L3 hosts that are in different BC domains.  Forwarding over the
DetNet domain is based on L3 (IP) addresses (i.e. dst-IP).
One may consider avoiding the additional IP encapsulation defined in
the previous sub-chapter.  In this case there is no "DetNet service
specific tunneling", but the DetNet Service flows are mapped to each
link / sub net using its technology specific methods.  No DetNet IP
header is used.  The data-flow IP header MUST be preserved and it is
used as-is when crossing the DetNet domain.
This solution provides some DetNet functions end to end, but some
DetNet functions are segmented.  Congestion protection and latency
control and the resource allocation (queuing, policing, shaping) done
using the underlying link / sub net specific mechanisms and they are
provided end to end.  However, service protections (packet
replication and packet emilination functions) are not provided end to
end, but per underlying layer-2 link / sub net.
Within a DetNet domain, the DetNet enabled IP Routers interconnect
links and sub-nets to support end-to-end delivery of DetNet flows.
From a DetNet architecture perspective, these routers are DetNet
relays, as they must be DetNet service aware.  Such routers identify
DetNet flows based on the IP 6-tuple, and ensure that the DetNet
service required traffic treatment is provided both on the node and
on any attached sub-network.
This solution provides DetNet functions end to end, but does so on a
per link and sub-network basis.  Congestion protection and latency
control and the resource allocation (queuing, policing, shaping) are
supported using the underlying link / sub net specific mechanisms.
However, service protections (packet replication and packet
emilination functions) are not provided at the DetNet layer end to
end.  But such service protection can be provided on a per underlying
layer-2 link and sub-network basis.
There are network scenarios, where the DetNet domain contains
multiple technology segments (IP, MPLS) and all those segments are
under the same administrative control (see fig_pref_xcrs_segments).
Furthermore, DetNet nodes may be interconnected via TSN segments.
There are network scenarios, where the DetNet domain contains
multiple technology segments (IEEE 802.1 TSN, MPLS) and all those
segments are under the same administrative control (see
fig_pref_xcrs_segments).  Furthermore, DetNet nodes may be
interconnected via TSN segments.
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 I-D.ietf-detnet-dp-
sol-mpls.  The mapping of IP DetNet Flows to IEEE 802.1 TSN is
covered in mapping-tsn.
The control plane protocol solution required for managing the PREF
processing is outside the scope of this document.
Some DetNet applications generate bidirectional traffic.  Using MPLS
definitions RFC5654 there are associated bidirectional flows, and co-
routed bidirectional flows.  MPLS defines a point-to-point associated
bidirectional LSP as consisting of two unidirectional point-to-point
LSPs, one from A to B and the other from B to A, which are regarded
as providing a single logical bidirectional transport path.  This
would be analogous of standard IP routing, or PWs running over two
reciprocal unidirection LSPs.  MPLS defines a point-to-point co-
routed bidirectional LSP as an associated bidirectional LSP which
satisfies the additional constraint that its two unidirectional
component LSPs follow the same path (in terms of both nodes and
links) in both directions.  An important property of co-routed
bidirectional LSPs is that their unidirectional component LSPs share
fate.  In both types of bidirectional LSPs, resource allocations may
differ in each direction.  The concepts of associated bidirectional
flows and co-routed bidirectional flows can be applied to DetNet
flows as well whether IPv6 or MPLS is used.
While the IPv6 and MPLS data planes must support bidirectional DetNet
flows, there are no special bidirectional features with respect to
the data plane other than need for the two directions take the same
paths.  Fate sharing and associated vs co-routed bidirectional flows
can be managed at the control level.  Note, that there is no stated
requirement for bidirectional DetNet flows to be supported using the
same IPv6 Flow Labels or MPLS Labels in each direction.  Control
mechanisms will need to support such bidirectional flows for both
IPv6 and MPLS, but such mechanisms are out of scope of this document.
An example control plane solution for MPLS can be found in RFC7551.
Some DetNet applications generate bidirectional traffic.  While the
DetNet data plane must support bidirectional DetNet flows, there are
no special bidirectional features with respect to the data plane
other than need for the two directions take the same paths.  That is
to say that bidirectional DetNet flows are solely represented at the
management and control plane levels, without specific support or
knowledge within the DetNet data plane.  Fate sharing and associated
vs co-routed bidirectional flows can be managed at the control level.
Note, that there is no stated requirement for bidirectional DetNet
flows to be supported using the same 6-tuple in each direction.
Control mechanisms will need to support such bidirectional flows but
such mechanisms are out of scope of this document.  An example
control plane solution for MPLS can be found in RFC7551.