Draft: draft-ietf-detnet-ip

Commentary: As discussed in Nov 28 call
Paragraph (version A):
This document specifies the DetNet data plane operation for IP hosts
and routers that provide DetNet service to IP encapsulated data.  No
DetNet specific encapsulation is defined to support IP flows, instead
the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery.  Common
data plane procedures and control information for all DetNet data
planes can be found in the I-D.ietf-detnet-data-plane-framework.
Paragraph (version A):
The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: 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 out-of-order
delivery).  Since 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 Ethernet as specified in
the IEEE 802.1 TSN task group(referred to in this document simply as
IEEE802.1 TSN).
Paragraph (version B):
This document specifies the DetNet data plane operation for IP hosts
and routers that provide DetNet service to IP encapsulated data.  No
DetNet-specific encapsulation is defined to support IP flows, instead
the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery.  Common
data plane procedures and control information for all DetNet data
planes can be found in the I-D.ietf-detnet-data-plane-framework.
Paragraph (version B):
The DetNet Architecture models the DetNet related data plane
functions as two sub-layers: 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 (e.g., by packet replication and
packet elimination functions) and reordering.  The forwarding sub-
layer is used to provides congestion protection (low loss, assured
latency, and limited out-of-order delivery).  The service sub-layer
generally requires additional fields to provide its service; for
example see I-D.ietf-detnet-mpls.  Since no DetNet-specific fields
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 Ethernet as
specified in the IEEE 802.1 TSN task group(referred to in this
document simply as IEEE802.1 TSN).
Paragraph (version A):
Packet Replication, Ordering and Elimination Function.
Paragraph (version B):
Packet Replication, Elimination and Ordering Function.
Paragraph (version A):
This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, identify DetNet flows and provide a DetNet service using
an IP data plane.  From a data plane perspective, an end-to-end IP
model is followed.  As mentioned above, existing IP and higher layer
protocol header information is used to support flow identification
and DetNet service delivery.  Common data plane procedures and
control information for all DetNet data planes can be found in the I-
D.ietf-detnet-data-plane-framework.
Paragraph (version B):
This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, to identify DetNet flows and provide a DetNet service
using an IP data plane.  From a data plane perspective, an end-to-end
IP model is followed.  As mentioned above, existing IP and higher
layer protocol header information is used to support flow
identification and DetNet service delivery.  Common data plane
procedures and control information for all DetNet data planes can be
found in the I-D.ietf-detnet-data-plane-framework.
Paragraph (version A):
Generally the fields used in flow identification are forward
unmodified but modification is allowed, for example to a DSCP value,
when required by the DetNet service.
Paragraph (version A):
DetNet flow aggregation may be enabled via the use of wildcards,
masks, lists, 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.
Paragraph (version A):
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.
Paragraph (version B):
Non-DetNet and DetNet IP packets are identical on the wire.
Generally the fields used in flow identification are forwarded
unmodified, however modification of these fields is allowed, for
example to a DSCP value, when required by the DetNet service.
Paragraph (version B):
DetNet flow aggregation may be enabled via the use of wildcards,
masks, lists, 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 on the
aggregate through resource allocation and congestion control
mechanisms.
Paragraph (version B):
fig_ip_detnet_simple illustrates a DetNet enabled IP network.  The
DetNet enabled end systems originate IP encapsulated traffic those
are identified within the DetNet domain 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.
Paragraph (version A):
Note, that fig_ip_detnet_simple and fig_non_detnet_ip can be
combined, so IP DetNet End Systems can communicate over DetNet IP
network with IP End System.
Paragraph (version A):
Non-DetNet and DetNet IP packets are identical on the wire.  From
data plane perspective, the only difference is that there is flow-
associated DetNet information on each DetNet node that defines the
flow related characteristics and required forwarding behavior.  As
shown above, edge nodes provide a Service Proxy function that
"associates" one or more IP flows with the appropriate DetNet flow-
specific information and ensures that the receives the proper traffic
treatment within the domain.
Paragraph (version B):
Note, that fig_ip_detnet_simple and fig_non_detnet_ip can be
collapsed, so IP DetNet End Systems can communicate over DetNet IP
network with IP End System.
Paragraph (version B):
As non-DetNet and DetNet IP packets are identical on the wire, from
data plane perspective, the only difference is that there is flow-
associated DetNet information on each DetNet node that defines the
flow related characteristics and required forwarding behavior.  As
shown above, edge nodes provide a Service Proxy function that
"associates" one or more IP flows with the appropriate DetNet flow-
specific information and ensures that the receives the proper traffic
treatment within the domain.
Paragraph (version A):
Data-flows requiring DetNet service are generated and terminated on
end systems.  This document deals only with IP end systems.  The
protocols used by an IP end system are specific to an application and
end systems peer with end systems using the same application
encapsulation format.  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.
Paragraph (version A):
When IP end systems are DetNet aware, no application-level or
service-level proxy functions are needed inside the DetNet domain.
For DetNet unaware IP end systems service-level proxy functions are
needed inside the DetNet domain.
Paragraph (version A):
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 dn_dom_spec_cons 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.
Paragraph (version A):
In order to maximize reuse of 5-tuple based mechanisms, e.g,
traceroute, DetNet aware applications and end systems SHOULD NOT mix
DetNet and non-DetNet traffic within a single 5-tuple.
Paragraph (version A):
As a general rule, DetNet IP 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 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.
Paragraph (version B):
Data-flows requiring DetNet service are generated and terminated on
end systems.  This document deals only with IP end systems.  The
protocols used by an IP end system are specific to an application,
and end systems peer with other end systems.  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 (see nxt-proto-field).
Paragraph (version B):
When IP end systems are DetNet-aware, no application-level or
service-level proxy functions are needed inside the DetNet domain.
For DetNet unaware IP end systems service-level proxy functions are
needed inside the DetNet domain.
Paragraph (version B):
End systems need to ensure that DetNet service requirements are met
when processing packets associated to a DetNet flow.  When forwarding
packets, this means that packets are appropriately shaped on
transmission and receive appropriate traffic treatment on the
connected sub-network, see QoS and dn_dom_spec_cons for more details.
When receiving packets, this means that there are appropriate local
node resources, e.g., buffers, to receive and process the packets of
that DetNet flow.
Paragraph (version B):
In order to maximize reuse of 5-tuple based mechanisms, e.g,
traceroute, DetNet-aware applications and end systems SHOULD NOT mix
DetNet and non-DetNet traffic within a single 5-tuple.
Paragraph (version B):
As a general rule, DetNet IP domains need to be able to forward any
DetNet flow identified by the IP 6-tuple.  Doing otherwise would
limit the number of 6-tuple flow ID combinations that could be used
by the end systems.  From a practical standpoint this means that all
nodes along the end-to-end path of 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.
Paragraph (version A):
Within a DetNet domain, the DetNet enabled IP Routers are
interconnected by links and sub-networks 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.
Paragraph (version B):
Within a DetNet domain, the DetNet-enabled IP Routers are
interconnected by links and sub-networks 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.
Paragraph (version A):
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
elimination functions) are not provided at the DetNet layer end to
end.  Instead service protection can be provided on a per underlying
L2 link and sub-network basis.
Paragraph (version A):
The DetNet Service Flow is mapped to the link / sub-network specific
resources using an underlying system specific means.  This implies
each DetNet aware node on path looks into the forwarded DetNet
Service Flow packet and utilize e.g., a 6-tuple to find out the
required mapping within a node.
Paragraph (version A):
As noted earlier, the Service Protection is done within each link /
sub-network independently using the domain specific mechanisms (due
the lack of a unified end to end sequencing information that would be
available for intermediate nodes).  Therefore, service protection (if
enabled) cannot be provided end-to-end, only within sub-networks.
This is shown for a three sub-network scenario in
fig_pref_in_subnets, where each sub-network can provide service
protection between its borders.  "R" and "E" denotes replication and
elimination points within the sub-network.
Paragraph (version B):
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 protection (packet replication and packet
elimination functions) is not provided at the DetNet layer end to
end.  Instead service protection can be provided on a per underlying
L2 link and sub-network basis.
Paragraph (version B):
The DetNet Service Flow is mapped to the link / sub-network specific
resources using an underlying system-specific means.  This implies
each DetNet-aware node on path looks into the forwarded DetNet
Service Flow packet and utilize e.g., a 6-tuple to find out the
required mapping within a node.
Paragraph (version B):
As noted earlier, service protection must be implemented within each
link / sub-network independently, using the domain specific
mechanisms.  This is due to the lack of unified end-to-end sequencing
information that could be used by the intermediate nodes.  Therefore,
service protection (if enabled) cannot be provided end-to-end, only
within sub-networks.  This is shown for a three sub-network scenario
in fig_pref_in_subnets, where each sub-network can provide service
protection between its borders.  "R" and "E" denotes replication and
elimination points within the sub-network.
Paragraph (version A):
Note that not mixing DetNet and non-DetNet traffic within a single
5-tuple, as described above, enables simpler 5-tuple filters to be
reused at the edges of a DetNet network to prevent non-congestion
responsive DetNet traffic from escaping the DetNet domain.
Paragraph (version B):
Note that not mixing DetNet and non-DetNet traffic within a single
5-tuple, as described above, enables simpler 5-tuple filters to be
used (or re-used) at the edges of a DetNet network to prevent non-
congestion-responsive DetNet traffic from escaping the DetNet domain.
Paragraph (version A):
One additional consideration for DetNet nodes which support CoS
services is that they MUST ensure that the CoS service classes do not
impact the congestion protection and latency control mechanisms used
to provide DetNet QoS.  This requirement is similar to requirement
for MPLS LSRs to that CoS LSPs do not impact the resources allocated
to TE LSPs via RFC3473.
Paragraph (version B):
One additional consideration for DetNet nodes which support CoS
services is that they MUST ensure that the CoS service classes do not
impact the congestion protection and latency control mechanisms used
to provide DetNet QoS.  This requirement is similar to the
requirement for MPLS LSRs that CoS LSPs cannot impact the resources
allocated to TE LSPs RFC3473.
Paragraph (version A):
In non-DetNet IP forwarding, it is generally assumed that the same
series of next hops, i.e., the same path, will be used for a
particular 5-tuple or, in some cases, e.g., RFC5120, for a particular
6-tuple.  Using different next hops for different 5-tuples does not
take any special consideration for DetNet aware applications.
Paragraph (version B):
In non-DetNet IP forwarding, it is generally assumed that the same
series of next hops, i.e., the same path, will be used for a
particular 5-tuple or, in some cases, e.g., RFC5120, for a particular
6-tuple.  Using different next hops for different 5-tuples does not
take any special consideration for DetNet-aware applications.
Paragraph (version A):
From a single node perspective, the aggregation of IP flows impacts
DetNet IP data plane flow identification and resource allocation.  As
discussed above, IP flow identification uses the IP "6-tuple" for
flow identification.  DetNet IP flows can be aggregated using any of
the 6-tuple, and an additional optional field defined in ip-flow-id.
The use of prefixes, wildcards, lists, and value ranges allows a
DetNet node to identify aggregate DetNet flows.  From a resource
allocation perspective, DetNet nodes must provide service to a
aggregate and not on a component flow basis.
Paragraph (version B):
From a single node perspective, the aggregation of IP flows impacts
DetNet IP data plane flow identification and resource allocation.  As
discussed above, IP flow identification uses the IP "6-tuple" for
flow identification.  DetNet IP flows can be aggregated using any of
the 6-tuple, and an additional optional field defined in ip-flow-id.
The use of prefixes, wildcards, lists, and value ranges allows a
DetNet node to identify aggregate DetNet flows.  From a resource
allocation perspective, DetNet nodes must provide service to an
aggregate and not on a component flow basis.
Paragraph (version A):
IP and higher layer protocol header information is used to identify
DetNet flows.  All DetNet implementations that support this document
MUST identify individual DetNet flows based on the set of information
identified in this section.  Note, that additional flow
identification requirements, e.g., to support other higher layer
protocols, may be defined in future.
Paragraph (version B):
IP and higher layer protocol header information is used to identify
DetNet flows.  All DetNet implementations that support this document
MUST identify individual DetNet flows based on the set of information
identified in this section.  Note, that additional flow
identification requirements, e.g., to support other higher layer
protocols, may be defined in the future.
Paragraph (version A):
Implementations of this document MUST support DetNet flow
identification when the implementation is acting as a DetNet end
systems, a relay node or as an edge node.
Paragraph (version B):
Implementations of this document MUST support DetNet flow
identification when the implementation is acting as a DetNet end
systems, a relay node, or as an edge node.
Paragraph (version A):
Implementations of this document MUST support DetNet flow
identification based on the IPv4 Protocol field when processing IPv4
packets, and the IPv6 Next Header Field when processing IPv6 packets.
An implementation MUST support flow identification based based the
next protocol values defined in nxt-proto.  Other, non-zero values,
MUST be used for flow identification.  Implementations SHOULD allow
for these fields to be ignored for a specific DetNet flow.
Paragraph (version B):
Implementations of this document MUST support DetNet flow
identification based on the IPv4 Protocol field when processing IPv4
packets, and the IPv6 Next Header Field when processing IPv6 packets.
An implementation MUST support flow identification based on the next
protocol values defined in nxt-proto.  Other, non-zero values, MUST
be used for flow identification.  Implementations SHOULD allow for
these fields to be ignored for a specific DetNet flow.
Paragraph (version A):
General requirements for IP nodes are defined in RFC1122, RFC1812 and
RFC6434, and are not modified by this document.  The typical next-hop
selection process is impacted by DetNet.  Specifically,
implementations of this document SHALL use management and control
information to select the one or more outgoing interfaces and next
hops to be used for a packet belonging to a DetNet flow.
Paragraph (version B):
General requirements for IP nodes are defined in RFC1122, RFC1812 and
RFC6434, and are not modified by this document.  The typical next-hop
selection process is impacted by DetNet.  Specifically,
implementations of this document SHALL use management and control
information to select the one or more outgoing interfaces and next
hops to be used for a packet associated with a DetNet flow.
Paragraph (version A):
Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via I-D.ietf-detnet-
yang.  General information on DetNet service can be found in I-
D.ietf-detnet-flow-information-model.  Typical mechanisms used to
provide different treatment to different flows includes the
allocation of system resources (such as queues and buffers) and
provisioning or related parameters (such as shaping, and policing).
Support can also be provided via an underlying network technology
such as MPLS I-D.ietf-detnet-ip-over-mpls.  and IEEE802.1 TSN I-
D.ietf-detnet-ip-over-tsn.  Other than in the TSN case, the specific
mechanisms used by a DetNet node to ensure DetNet service delivery
requirements are met for supported DetNet flows is outside the scope
of this document.
Paragraph (version B):
Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via I-D.ietf-detnet-
yang.  General information on DetNet service can be found in I-
D.ietf-detnet-flow-information-model.  Typical mechanisms used to
provide different treatment to different flows includes the
allocation of system resources (such as queues and buffers) and
provisioning or related parameters (such as shaping, and policing).
Support can also be provided via an underlying network technology
such as MPLS I-D.ietf-detnet-ip-over-mpls or IEEE802.1 TSN I-D.ietf-
detnet-ip-over-tsn.  Other than in the TSN case, the specific
mechanisms used by a DetNet node to ensure DetNet service delivery
requirements are met for supported DetNet flows is outside the scope
of this document.
Paragraph (version A):
IPv6 flow label field.  This field can be optionally used for
matching.  When used, can be exclusive of matching against the
next header field.
Paragraph (version B):
IPv6 flow label field.  This field can be optionally used for
matching.  When used, can be used instead of matching against the
Next Header field.