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

Commentary: please review and merge
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, rather
existing IP header information is used to support flow identification
and DetNet service delivery.  General background on the use of IP
headers, and "5-tuples", to identify flows and support Quality of
Service (QoS) can be found in RFC3670.  RFC7657 also provides useful
background on the delivery differentiated services (DiffServ) and
"6-tuple" based flow identification.
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, rather
existing IP and higher layer protocol header information is used to
support flow identification and DetNet service delivery.
This document provides an overview of the DetNet IP data plane in
sec_dt_dp, considerations that apply to providing DetNet services via
the DetNet IP data plane in dn-gen-encap-solution and m-cp-
considerations. ip-encap provides the requirements for hosts and
routers that support IP-based DetNet services.  Finally, mapping-tsn
provides rules for mapping IP-based DetNet flows to IEEE 802.1 TSN
streams.
This document provides an overview of the DetNet IP data plane in
sec_dt_dp, considerations that apply to providing DetNet services via
the DetNet IP data plane in dn-gen-encap-solution and m-cp-
considerations. ip-procs provides the procedures for hosts and
routers that support IP-based DetNet services.  Finally, mapping-tsn
provides rules for mapping IP-based DetNet flows to IEEE 802.1 TSN
streams.
This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, to identify DetNet flows and provide a DetNet service.
From a data plane perspective, an end-to-end IP model is followed.
This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, to identify DetNet flows and provide a DetNet service.
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.
DetNet uses "6-tuple" based flow identification, where "6-tuple"
refers to information carried in IP and higher layer protocol
headers.  General background on the use of IP headers, and
"5-tuples", to identify flows and support Quality of Service (QoS)
can be found in RFC3670.  RFC7657 also provides useful background on
the delivery differentiated services (DiffServ) and "6-tuple" based
flow identification.
DetNet IP flows are identified based on IP, both IPv4 RFC0791 and
IPv6 RFC8200, header information.  Six (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.
Note: using IP multicast destination address is also allowed within
the 6-tuple.
Use of a specific path for a flow.  This limits miss-ordering and
latency.
Use of a specific path for a flow.  This limits miss-ordering and
can improve delivery of deterministic latency.
This section provides DetNet IP data plane procedures.  These
procedures have been divided into the following areas: flow
identification, forwarding and traffic treatment.  Flow
identification includes those procedures related to matching IP and
higher layer protocol header information to DetNet flow (state)
information and service requirements.  Flow identification is also
sometimes called Traffic classification, for example see RFC5777.
Forwarding includes those procedures related to next hop selection
and delivery.  Traffic treatment includes those procedures related to
providing an identified flow with the required DetNet service.
DetNet IP data plane procedures also have implications on the control
and management of DetNet flows and these are also covered in this
section.  Specifically this section identifies a number of
information elements that will require support via the management and
control interfaces supported by a DetNet node.  The specific
mechanism used for such support is out of the scope of this document.
A summary of the management and control related information
requirements is included.  Conformance language is not used in the
summary as it applies to future mechanisms such as those that may be
provided in YANG models [YANG-REF-TBD].
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.
The configuration and control information used to identify an
individual DetNet flow MUST be ordered by and implementation.
Implementations MUST support a fixed order when identifying flows,
and MUST identify a DetNet flow by the first set of matching flow
information.
Implementations of this document MUST support DetNet flow
identification MUST when the implementation is acting as a DetNet end
systems, a relay node or as an edge node.
Implementations of this document MUST support DetNet flow
identification based on IP header information.  The IPv4 header is
defined in RFC0791 and the IPv6 is defined in RFC8200.
Implementations of this document MUST support DetNet flow
identification based on the Source Address field of an IP packet.
Implementations SHOULD support longest prefix matching for this
field, see RFC1812 and RFC7608.  Note that a prefix length of zero
(0) effectively means that the field is ignored.
Implementations of this document MUST support DetNet flow
identification based on the Destination Address field of an IP
packet.  Implementations SHOULD support longest prefix matching for
this field, see RFC1812 and RFC7608.  Note that a prefix length of
zero (0) effectively means that the field is ignored.
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,
SHOULD be used for flow identification.  Implementations SHOULD allow
for these fields to be ignored for a specific DetNet flow.
These fields are used to support Differentiated Services RFC2474 and
Explicit Congestion Notification RFC3168.  Implementations of this
document MUST support DetNet flow identification based on the IPv4
Type of Service field when processing IPv4 packets, and the IPv6
Traffic Class Field when processing IPv6 packets.  Implementations
MUST support bimask based matching, where one (1) values in the
bitmask indicate which subset of the bits in the field are to be used
in determining a match.  Note that a zero (0) value as a bitmask
effectively means that these fields are ignored.
Implementations of this document SHOULD support identification of
DetNet flows based on the IPv6 Flow Label field.  Implementations
that support matching based on this field MUST allow for this fields
to be ignored for a specific DetNet flow.  When this fields is used
to identify a specific DetNet flow, implementations MAY exclude the
IPv6 Next Header field and next header information as part of DetNet
flow identification.
Implementations of this document MUST support DetNet flow
identification based on header information identified in this
section.  Support for TCP, UDP and IPsec flows are defined.  Future
documents are expected to define support for other protocols.
DetNet flow identification for TCP RFC0793 and UDP RFC0768 is done
based on the Source and Destination Port fields carried in each
protocol's header.  These fields share a common format and common
DetNet flow identification procedures.
Implementations of this document MUST support DetNet flow
identification based on the Source Port field of a TCP or UDP packet.
Implementations MUST support flow identification based on a
particular value carried in the field, i.e., an exact.
Implementations SHOULD support range-based port matching.
Implementation MUST also allow for the field to be ignored for a
specific DetNet flow.
Implementations of this document MUST support DetNet flow
identification based on the Destination Port field of a TCP or UDP
packet.  Implementations MUST support flow identification based on a
particular value carried in the field, i.e., an exact.
Implementations SHOULD support range-based port matching.
Implementation MUST also allow for the field to be ignored for a
specific DetNet flow.
IPsec Authentication Header (AH) RFC4302 and Encapsulating Security
Payload (ESP) RFC4303 share a common format for the Security
Parameters Index (SPI) field.  Implementations MUST support flow
identification based on a particular value carried in the field,
i.e., an exact.  Implementation SHOULD also allow for the field to be
ignored for a specific DetNet flow.
IPv4 and IPv6 source address field.
IPv4 and IPv6 source address prefix length, where a zero (0) value
effectively means that the address field is ignored.
IPv4 and IPv6 destination address field.
IPv4 and IPv6 destination address prefix length, where a zero (0)
effectively means that the address field is ignored.
IPv4 protocol field.  A limited set of values is allowed, and the
ability to ignore this field, e.g., via configuration of the value
zero (0), is desirable.
IPv6 next header field.  A limited set of values is allowed, and
the ability to ignore this field, e.g., via configuration of the
value zero (0), is desirable.
IPv4 Type of Service and IPv6 Traffic Class Fields.
IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a
zero (0) effectively means that theses fields are ignored.
IPv6 flow label field.  This field can be optionally used for
matching.  When used, can be exclusive of matching against the
next header field.
TCP and UDP Source Port.  Exact and wildcard matching is required.
Port ranges can optionally be used.
TCP and UDP Destination Port.  Exact and wildcard matching is
required.  Port ranges can optionally be used.
Information identifying a DetNet flow is ordered and implementations
use the first match.  This can, for example, be used to provide a
DetNet service for a specific UDP flow, with unique Source and
Destination Port field values, while providing a different service
for all other flows with that same UDP Destination Port value.
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.
The use of multiple paths or links, e.g., ECMP, to support a single
DetNet flow will generally be avoided in order to meet DetNet service
requirements.
The above implies that management and control functions will be
defined to support this requirement, e.g., see [YANG-REF-TBD].
Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
management and control functions, e.g., via [YANG-REF-TBD].  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-dp-sol-mpls and IEEE802.1 TSN mapping-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.
The use of prefixes, wildcards, bimasks, and port ranges allows a
DetNet node to aggregate DetNet flows.  This aggregation can take
place within a single node, when that node maintains state about both
the aggregated and component flows.  It can also take place between
nodes, where one node maintains state about only flow aggregates
while the other node maintains state on all or a portion of the
component flows.  In either case, the management or control function
that provisions the aggregate flows must ensure that adequate
resources are allocated and configured to provide combined service
requirements of the component flows.  As DetNet is concerned about
latency and jitter, more than just bandwidth needs to be considered.
As is the case for DetNet, a Layer 2 network node such as a bridge
may need to identify the specific DetNet flow to which a packet
belongs in order to provide the TSN/DetNet QoS for that packet.  It
also may need a CoS marking, such as the priority field of an IEEE
Std 802.1Q VLAN tag, to give the packet proper service.
TSN capabilities of the TSN sub-network is made available for IP
(DetNet) flows via the protocol interworking function defined in
IEEE8021CB.  For example, applied on the TSN edge port connected to
the IP (DetNet) node it can convert an ingress unicast IP (DetNet)
flow to use a specific multicast destination MAC address and VLAN, in
order to direct the packet through a specific path inside the bridged
network.  A similar interworking pair at the other end of the TSN
sub-network would restore the packet to its original destination MAC
address and VLAN.
As is the case for DetNet, a Layer 2 network node such as a bridge
may need to identify the specific DetNet flow to which a packet
belongs in order to provide the TSN/DetNet QoS for that packet.  It
also may need additional marking, such as the priority field of an
IEEE Std 802.1Q VLAN tag, to give the packet proper service.
TSN capabilities of the TSN sub-network are made available for IP
(DetNet) flows via the protocol interworking function defined in
IEEE8021CB.  For example, applied on the TSN edge port connected to
the IP (DetNet) node it can convert an ingress unicast IP (DetNet)
flow to use a specific multicast destination MAC address and VLAN, in
order to direct the packet through a specific path inside the bridged
network.  A similar interworking pair at the other end of the TSN
sub-network would restore the packet to its original destination MAC
address and VLAN.
TBD.
RFC7322 limits the number of authors listed on the front page of a
draft to a maximum of 5, far fewer than the 20 individuals below who
made important contributions to this draft.  The editor wishes to
thank and acknowledge each of the following authors for contributing
text to this draft.  See also acks.
The author(s) ACK and NACK.