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

Commentary: New section 5 , and capitalized headings . 
  , Yes , I 'll make that change . Cheers ,  
 And done . 
 Thanks ....   you might want to turn off line wrap in your editor ... 
  , I just checked the settings and I do n't believe it 's doing any hard wrapping . What are you seeing ? Cheers ,  
 right - it 's best to use hard wrapping for maximum editor independence as well as   .    , This is similar to the text in the MPLS document , but that document references SR - MPLS . In the IP case , I figured that SR - MPLS was off the table , so I changed the reference to SRv6 . The earlier part of the sentence already references control plane signaling , centralized management , and hybrid solutions . In addition to those , I wanted to include the fact that SRv6 is also a valid solution here . If there 's anything else that you would like to include , we can certainly add that . Cheers ,
Quality of Service (QoS) mechanisms for flow specific traffic
treatment typically includes a guarantee/agreement for the service,
and allocation of resources to support the service.  Example QoS
mechanisms include discrete resource allocation, admission control,
flow identification and isolation, and sometimes path control,
traffic protection, shaping, policing and remarking.  Example
protocols that support QoS control include RFC2205 (RSVP) and RSVP-TE
RFC3209 and RFC3473.  The existing MPLS mechanisms defined to support
CoS RFC3270 can also be used to reserve resources for specific
traffic classes.
Quality of Service (QoS) mechanisms for flow-specific traffic
treatment typically includes a guarantee/agreement for the service,
and allocation of resources to support the service.  Example QoS
mechanisms include discrete resource allocation, admission control,
flow identification and isolation, and sometimes path control,
traffic protection, shaping, policing and remarking.  Example
protocols that support QoS control include RFC2205 (RSVP) and RSVP-TE
RFC3209 and RFC3473.  The existing MPLS mechanisms defined to support
CoS RFC3270 can also be used to reserve resources for specific
traffic classes.
While management plane and control plane are traditionally considered
separately, from the Data Plane perspective there is no practical
difference based on the origin of flow provisioning information.
This document therefore does not distinguish between information
provided by a control plane protocol, e.g., RSVP-TE RFC3209 and
RFC3473, or by a network management mechanisms, e.g., RestConf
RFC8040 and YANG RFC7950.
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.
While management plane and control planes are traditionally
considered separately, from the Data Plane perspective there is no
practical difference based on the origin of flow provisioning
information, and the DetNet architecture I-D.ietf-detnet-architecture
refers to these collectively as the 'Controller Plane'.  This
document therefore does not distinguish between information provided
by distributed control plane protocols, e.g., IGP routing protocols,
or by centralized network management mechanisms, e.g., RestConf
RFC8040, YANG RFC7950, and the Path Computation Element Communication
Protocol (PCEP) RFC8283 I-D.ietf-teas-pce-native-ip or any
combination thereof.  Specific considerations and requirements for
the DetNet Controller Plane are discussed in control-management-
requirements.
sec_dt_dp introduces the use of the IP "6-tuple" for flow
identification, and QoS goes on to discuss how identified flows use
specific QoS mechanisms for flow-specific traffic treatment,
including path control and resource allocation. ip-flow-id contains
detailed DetNet IP flow identification procedures.  Flow
identification will play an important role for the DetNet controller
plane.
aggregation and agg-con discuss the use of flow aggregation in
DetNet.  Flow aggregation can be accomplished using any of the
6-tuple fields defined in ip-flow-id, 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.
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 to provide the
appropriate traffic treatment for the flow, and also to include
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 mapping-tsn).  Further considerations and requirements for the
DetNet Controller Plane are discussed in control-management-
requirements.
Whether configuring, calculating and instantiating these routes is a
single-stage or multi-stage process, or in a centralized or
distributed manner, is out of scope of this document.
The path could be explicitly set up by a controller which
calculates the path and explicitly configures each node along that
path with the appropriate forwarding and resource allocation
information.
The path could be implemented using IPv6-based segment routing
when extended to support resource allocation.
See control-management-requirements for further discussion of these
alternatives.  In addition, RFC2386 contains useful background
information on QoS-based routing, and RFC5575 discusses a specific
mechanism used by BGP for traffic flow specification and policy-based
routing.
As discussed in sec_intro, this document does not specify the
mechanisms needed to eliminate contention 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
will be a necessary part of the DetNet controller plane.  It will
also be necessary to be able to control the required queuing
mechanisms used to provide these functions along a flow's path
through the network.  See ip-svc and control-management-requirements
for further discussion of these requirements.
Some DetNet applications generate bidirectional traffic.  Although
this document discusses the DetNet IP data plane, MPLS definitions
RFC5654 are useful to illustrate terms such as 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 forwarding path.  This is analogous to standard IP
routing.  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 reservations may differ in each
direction.  The concepts of associated bidirectional flows and co-
routed bidirectional flows can also be applied to DetNet IP flows.
While the DetNet IP data plane must support bidirectional DetNet
flows, there are no special bidirectional features with respect to
the data plane other than the need for the two directions of a co-
routed bidirectional flow to take the same path.  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.
Control and management mechanisms will need to support bidirectional
flows, but the specification of such mechanisms are out of scope of
this document.  An example control plane solution for MPLS can be
found in RFC7551.
This is further discussed in control-management-requirements.
While the definition of controller plane for DetNet is out of the
scope of this document, there are particular considerations and
requirements for such that result from the unique characteristics of
the DetNet architecture I-D.ietf-detnet-architecture and data plane
as defined herein.
Instantiate DetNet flows in a DetNet domain (which may include
some or all of explicit path determination, link bandwidth
reservations, restricting flows to IEEE 802.1 TSN links, node
buffer and other resource reservations, specification of required
queuing disciplines along the path, ability to manage
bidirectional flows, etc.) as needed for a flow.
Provision flow identification information at each of the nodes
along the path, and it may differ depending on the location in the
network and the DetNet functionality.
These requirements, as stated earlier, could be satisfied using
distributed control protocol signaling, centralized network
management provisioning mechanisms, or hybrid combinations of the
two, and could also make use of IPv6-based segment routing.
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 IP data plane.
However, from a practical and implementation standpoint, they are not
equivalent at all.  Some approaches are more scalable than others in
terms of signaling load on the network.  Some can take advantage of
global tracking of resources in the DetNet domain for better overall
network resource optimization.  Some are more resilient than others
if link, node, or management equipment failures occur.  While a
detailed analysis of the control plane alternatives is out of the
scope of this document, the requirements from this document can be
used as the basis of a later analysis of the alternatives.