Deterministic Networking (DetNet) Data Plane: IPEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comLabN Consulting, L.L.C.lberger@labn.netLabN Consulting, L.L.C.dfedyk@labn.netFuturewei Technologiessb@stewartbryant.comDetNetApplicationEndpointService Sub-layerForwarding Sub-layer
This document specifies the Deterministic Networking (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-layer and
higher-layer protocol header information is used to support flow
identification and DetNet service delivery. This document builds on
the DetNet architecture (RFC 8655) and data plane framework
(RFC 8938).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Terminology
. Terms Used in This Document
. Abbreviations
. Requirements Language
. Overview of the DetNet IP Data Plane
. DetNet IP Data Plane Considerations
. End-System-Specific Considerations
. DetNet Domain-Specific Considerations
. Forwarding Sub-Layer Considerations
. Class of Service
. Quality of Service
. Path Selection
. DetNet Flow Aggregation
. Bidirectional Traffic
. DetNet IP Data Plane Procedures
. DetNet IP Flow Identification Procedures
. IP Header Information
. Other Protocol Header Information
. Forwarding Procedures
. DetNet IP Traffic Treatment Procedures
. Management and Control Information Summary
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Contributors
Authors' Addresses
Introduction
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows.
DetNet provides these flows with extremely low packet loss rates and
assured maximum end-to-end
delivery latency. General background and concepts of DetNet can
be found in the DetNet architecture .
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-layer 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 DetNet architecture models the DetNet-related data plane functions
as 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 the Packet Replication Function (PRF) and Packet Elimination
Function (PEF)) and reordering. The forwarding sub-layer is used to
provide congestion protection (low loss, assured latency, and limited
out-of-order delivery). The service sub-layer generally requires
additional header fields to provide its service; for example, see
. 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-network basis using technologies such as MPLS and Ethernet,
as specified by the IEEE 802.1 TSN (Time-Sensitive Networking) task
group (referred to in this document simply as "IEEE 802.1 TSN").
See .
This document provides an overview of the DetNet IP data plane in
and considerations that
apply to providing
DetNet services via the DetNet IP data plane in .
provides the procedures for hosts and routers that support IP-based
DetNet services. summarizes the set of
information that is needed to identify an individual DetNet flow.
TerminologyTerms Used in This Document
This document uses the terminology and concepts established in
the DetNet architecture ,
and it is assumed that the reader is
familiar with that document and its terminology.
Abbreviations
The following abbreviations are used in this document:
CoS
Class of Service
DetNet
Deterministic Networking
DN
DetNet
Diffserv
Differentiated Services
DSCP
Differentiated Services Code Point
L2
Layer 2
L3
Layer 3
LSP
Label Switched Path
MPLS
Multiprotocol Label Switching
PEF
Packet Elimination Function
PREOF
Packet Replication, Elimination, and Ordering Functions
PRF
Packet Replication Function
QoS
Quality of Service
TSN
Time-Sensitive Networking. TSN is a task group of the IEEE
802.1 Working Group.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Overview of the DetNet IP Data Plane
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-layer 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 DetNet IP data plane primarily uses 6-tuple-based flow identification, where
"6-tuple" refers to information carried in IP-layer and higher-layer protocol
headers. The 6-tuple referred to in this document is the same as
that defined in . Specifically, the 6-tuple is
destination address, source address, IP protocol, source port,
destination port, and
DSCP. General background on the use of IP headers and 5-tuples
to identify flows and support Quality of Service (QoS) can be found in
. also provides
useful background on the delivery of Diffserv and tuple-based flow
identification. Note that a 6-tuple is composed of a 5-tuple
plus the addition of a DSCP component.
For some of the protocols, 5-tuples and 6-tuples cannot be used, because
the port information is not available (e.g., ICMP, IPsec, and
Encapsulating Security Payload (ESP)). This is
also the case for flow aggregates. In such cases, using
fewer fields is appropriate, such as a 3-tuple (2 IP
addresses, IP protocol) or even a
2-tuple (all IP traffic between two IP addresses).
The DetNet IP data plane also allows for optional matching on
the IPv6 Flow Label field,
as defined in .
Non-DetNet and DetNet IP packets have the same protocol
header format on the wire.
Generally, the fields used in flow identification are forwarded
unmodified. However, standard modification of the
DSCP field is not precluded.
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.
The specific procedures that are required to be implemented by a
DetNet node supporting this document can be found in . The DetNet Controller Plane, as defined in
, is responsible for providing each node
with the information needed to identify and handle each DetNet flow.
illustrates a
DetNet-enabled IP
network. The DetNet-enabled end systems originate IP-encapsulated
traffic that is identified within the DetNet domain as DetNet
flows based on IP header information.
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.
illustrates a variant of where the end systems are not DetNet
aware. In this case, edge nodes sit at the boundary of the DetNet
domain and provide DetNet service proxies for the end applications by
initiating and terminating DetNet service for the application's IP
flows. The existing header information or an approach such as described
in can be used to support DetNet flow
identification.
Note that Figures and can be collapsed,
so IP DetNet
end systems can communicate over a DetNet IP network with IP end systems.
As non-DetNet and DetNet IP packets have the same protocol header
format on the wire, from
a 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 flow receives the proper traffic treatment within the domain.
DetNet IP Data Plane Considerations
This section provides considerations related to
providing DetNet service to flows that are identified
based on their header information.
End-System-Specific Considerations
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 value carried
within an IP packet (see ).
For DetNet-unaware IP end systems, service-level proxy functions are
needed inside the DetNet domain.
When IP end systems are DetNet aware, no application-level or
service-level proxy functions are needed inside the DetNet domain.
End systems need to ensure that DetNet service requirements are met
when processing packets associated to a DetNet flow. When
sending packets, this means that packets are
appropriately shaped on transmission and receive appropriate traffic
treatment on the connected sub-network; see Sections and 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.
An important additional consideration for DetNet-aware end
systems is avoiding IP fragmentation. Full 6-tuple flow
identification is not possible on IP fragments, as fragments
don't include the transport headers or their port
information. As such, it is important that applications and/or
end systems use an IP packet size that will avoid
fragmentation within the network when sending DetNet flows.
The maximum size can be learned via Path MTU Discovery or via the Controller Plane. Note that Path MTU
Discovery relies on
ICMP, which may not follow the same path as an individual
DetNet flow.
In order to maximize reuse of existing mechanisms,
DetNet-aware applications and end systems SHOULD NOT mix
DetNet and non-DetNet traffic within a single 5-tuple.
DetNet Domain-Specific Considerations
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.
Possible consequences of not having such an agreement include
some flows interfering with other flows, and
the traffic treatment expected for a service not being
provided.
From a connection-type perspective, two scenarios are identified:
DN attached: the end system is directly connected to an edge
node or the end system is behind a sub-network. (See ES1 and
ES2 in .)
DN integrated: the end system is part of the DetNet domain. (See ES3
in .)
L3 (IP) end systems may use any of these connection types. A DetNet
domain allows communication between any end systems using the
same encapsulation format, independent of their connection type and
DetNet capability. DN-attached end systems have no knowledge about
the DetNet domain and its encapsulation format. See for L3 end system connection examples.
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 traffic treatment required by the DetNet service is
provided on both the node and any attached sub-network.
This solution provides DetNet functions end to end, but it does so
on a per-link and per-sub-network basis. Congestion protection, latency
control,
and resource allocation (queuing, policing,
shaping) are supported using the underlying
link/sub-network-specific mechanisms. However, service protection
(PRF and PEF) is not
provided end to end at the DetNet layer.
Instead, service protection can be
provided on a per-link (underlying
L2 link) and per-sub-network basis.
The DetNet service flow is mapped to the
link/sub-network-specific resources using an underlying
system-specific
means. This implies that each DetNet-aware node on the path looks
into the forwarded DetNet service flow packet and utilizes,
for example, a 6-tuple to find out the required mapping within
a node.
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 scenario
with three sub-networks in ,
where each sub-network can provide service protection between
its borders. "R" and "E" denote replication and elimination
points within the sub-network.
If end-to-end service protection is desired, it can be
implemented -- for example, by the DetNet end systems using
Layer 4
(L4) transport protocols or application protocols. However, these
protocols are out of the scope of this document.
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 reused) at the edges of a DetNet
network to prevent non-congestion-responsive DetNet
traffic from escaping the DetNet
domain.
Forwarding Sub-Layer ConsiderationsClass of Service
Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6
is provided using the standard
DSCP field and related mechanisms.
One additional consideration for DetNet nodes that 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 Label Switching Routers (LSRs) that CoS LSPs
cannot impact the resources allocated to TE
LSPs .
Quality of Service
Quality of Service (QoS) for DetNet service flows carried in IP must be provided locally by
the DetNet-aware hosts and routers supporting DetNet flows. Such
support leverages the underlying network layer such as
802.1 TSN. The node-internal traffic control mechanisms used to
deliver QoS for
IP-encapsulated DetNet flows are outside the scope of this
document. From an encapsulation perspective, the combination of the 6-tuple
(the typical 5-tuple enhanced with the DSCP) and optionally
the flow label uniquely identifies a DetNet IP flow.
Packets that are identified as part of a DetNet IP flow
but that have not been the subject of a completed reservation
can disrupt the QoS offered to properly reserved DetNet flows
by using resources allocated to the reserved flows.
Therefore, the network nodes of a DetNet network MUST ensure
that no DetNet-allocated resource, e.g., queue or shaper, is
used by such flows.
There are multiple methods that may be
used by an implementation to defend service delivery to
reserved DetNet flows, including but not limited to:
Treating packets associated with an incomplete reservation
as non-DetNet traffic.
Discarding packets associated with an incomplete
reservation.
Re-marking packets associated with an incomplete
reservation. Re-marking can be accomplished by changing
the value of the DSCP field to a value that
results in the packet no longer matching any other
reserved DetNet IP flow.
Path Selection
While path selection algorithms and mechanisms are out of the
scope of the DetNet data plane definition, it is important to
highlight the implications of DetNet IP flow identification on
path selection and next hops. As mentioned above, the DetNet
IP data plane identifies flows using 6-tuple header
information as well as the optional (flow label) header
field. DetNet generally allows for both flow-specific traffic
treatment and flow-specific next hops.
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., ), for a particular 6-tuple.
Using different
next hops for different 5-tuples does not take any special
consideration for DetNet-aware applications.
Care should be taken when using different next hops for the
same 5-tuple. As discussed in ,
unexpected behavior can occur when a single 5-tuple
application flow experiences reordering due to being split
across multiple next hops. Understanding of the application
and transport protocol impact of using different next hops for
the same 5-tuple is required. Again, this only indirectly impacts path
selection for DetNet flows and this document.
DetNet Flow Aggregation
As described in , the ability to
aggregate individual flows and their associated resource
control into a larger aggregate is an important technique for
improving scaling by reducing the state per hop. DetNet IP
data plane aggregation can take place within a single node,
when that node maintains state about both the aggregated and
individual flows. It can also take place between nodes, when
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 the combined
service requirements of the individual flows. As DetNet is
concerned about latency and jitter, more than just bandwidth
needs to be considered.
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 fields and optionally also by
the flow label. 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 ought to provide service to an
aggregate rather than on a component flow basis.
It is the responsibility of the DetNet Controller Plane to
properly provision the use of these aggregation mechanisms.
This includes ensuring that aggregated flows have compatible
(e.g., the same or very similar) QoS and/or CoS characteristics;
see . It also includes
ensuring that per-component-flow service requirements are satisfied
by the aggregate; see .
The DetNet Controller Plane MUST ensure that
non-congestion-responsive DetNet traffic is not forwarded
outside a DetNet domain.
Bidirectional Traffic
While the DetNet IP data plane must support bidirectional
DetNet flows, there are no special bidirectional features within
the data plane. The special case of co-routed bidirectional
DetNet flows is
solely represented at the management and control plane levels,
without specific support or knowledge within the DetNet data
plane. Fate sharing and associated or co-routed
bidirectional flows can be managed at the control level.
Control and management mechanisms need to support
bidirectional flows, but the specification of such mechanisms
is out of the scope of this document. An example control plane
solution for MPLS can be found in .
DetNet IP Data Plane Procedures
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-layer
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 . 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 establishment and operational procedures
also have requirements on the control and management systems
for DetNet flows, and these are referred to in this section.
Specifically, this section identifies a
number of information elements that 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 requirements for management- and
control-related information is included. Conformance
language is not used in the summary, since it applies to future
mechanisms such as those that may be provided in YANG models
.
DetNet IP Flow Identification Procedures
IP-layer 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
requirements for flow identification, e.g., to support
other higher-layer protocols, may be defined in the future.
The configuration and control information used to identify an
individual DetNet flow MUST be ordered by an 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 when the implementation is acting as a
DetNet end system, a relay node, or an edge node.
IP Header Information
Implementations of this document MUST support DetNet flow
identification based on IP header information. The IPv4
header is defined in , and the IPv6
is defined in .
Source Address Field
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 and
). Note that a prefix length of
zero (0) effectively means that the field is ignored.
Destination Address Field
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 and
). Note that a prefix length of
zero (0) effectively means that the field is ignored.
IPv4 Protocol and IPv6 Next Header Fields
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. This includes
the next protocol
values defined in and any other
value, including zero.
Implementations SHOULD allow for these fields to be
ignored for a specific DetNet flow.
IPv4 Type of Service and IPv6 Traffic Class Fields
These fields are used to support differentiated services
.
Implementations of this document MUST support DetNet flow
identification based on the DSCP field in the IPv4 Type of
Service field when processing IPv4 packets and the DSCP
field in the IPv6 Traffic Class field when processing IPv6
packets. Implementations MUST support list-based matching
of DSCP values, where the list is composed of possible
field values that are to be considered when identifying a
specific DetNet flow. Implementations SHOULD allow for
this field to be ignored for a specific DetNet flow.
IPv6 Flow Label Field
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 it
to be ignored for a specific DetNet flow. When this field
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.
Other Protocol Header Information
Implementations of this document MUST support DetNet flow
identification based on header information identified in this
section. Support for TCP, UDP, ICMP, and IPsec flows is defined.
Future documents are expected to define support for other
protocols.
TCP and UDP
DetNet flow identification for TCP and UDP is
achieved 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.
The rules defined in this section only apply when the
IPv4 Protocol or IPv6 Next Header field contains the
IANA-defined value for UDP or TCP.
Source Port Field
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 value. Implementations SHOULD support
range-based port matching. Implementation MUST also allow
for the field to be ignored for a specific DetNet flow.
Destination Port Field
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 value. Implementations SHOULD support
range-based port matching. Implementation MUST also allow
for the field to be ignored for a specific DetNet flow.
ICMP
DetNet flow identification for ICMP is achieved based on the
protocol number in the IP header. Note that ICMP type is not included in the
flow definition.
IPsec AH and ESP
IPsec Authentication Header (AH)
and Encapsulating Security Payload (ESP) 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 value. Implementations
SHOULD
also allow for the field to be ignored for a specific
DetNet flow.
The rules defined in this section only apply when the
IPv4 Protocol or IPv6 Next Header field contains the
IANA-defined value for AH or ESP.
Forwarding Procedures
General requirements for IP nodes are defined in , , and
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. Specific management and control
information will be defined in future documents, e.g., .
The use of multiple paths or links, e.g., ECMP, to support a
single DetNet flow is NOT RECOMMENDED. ECMP MAY be used for
non-DetNet flows within a DetNet domain.
The above implies that management and control functions will
be defined to support this requirement, e.g., see .
DetNet IP Traffic Treatment Procedures
Implementations of 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 .
General information on DetNet service can be found in . Typical
mechanisms used to provide different treatment to different flows
include the allocation of system resources (such as queues and
buffers) and provisioning of related parameters (such as shaping and
policing). Support can also be provided via an underlying network
technology such as MPLS or
IEEE 802.1 TSN .
Other mechanisms than the ones used in the TSN case are outside the
scope of this document.
Management and Control Information Summary
The following summarizes the set of information that is needed to
identify individual and aggregated DetNet flows:
IPv4 and IPv6 Source Address field.
IPv4 and IPv6 source address prefix length, where a zero
(0) value effectively means that the Source Address field is
ignored.
IPv4 and IPv6 Destination Address field.
IPv4 and IPv6 destination address prefix length, where a
zero (0) value effectively means that the Destination Address field is
ignored.
IPv4 Protocol field. A limited set of values is allowed,
and the ability to ignore this field is desirable.
IPv6 Next Header field. A limited set of values is allowed,
and the ability to ignore this field is desirable.
For the IPv4 Type of Service and IPv6 Traffic Class fields:
Whether or not the DSCP field is used in flow identification.
Use of the DSCP field for flow identification is optional.
If the DSCP field is used to identify a flow, then the flow
identification information (for that flow) includes a list of
DSCPs used by that flow.
IPv6 Flow Label field. This field can be optionally used
for matching. When used, this field can be used instead of matching against
the Next Header field.
TCP and UDP Source Port. Support for both exact and wildcard matching is
required. Port ranges can optionally be used.
TCP and UDP Destination Port. Support for both exact and wildcard matching is
required. Port ranges can optionally be used.
IPsec Header SPI field. Exact matching is
required. Support for wildcard matching is
recommended.
For end systems, an optional maximum IP packet size
that should be used for that outgoing DetNet IP flow.
This information MUST be provisioned per DetNet flow via
configuration, e.g., via the Controller Plane or the management plane.
An implementation MUST support ordering of the
set of information used to identify an
individual DetNet flow. 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 the aggregate of all other
flows with that same UDP Destination Port value.
It is the responsibility of the DetNet Controller Plane to
properly provision both flow identification information and
the flow-specific resources needed to provide the traffic
treatment needed to meet each flow's service requirements.
This applies for aggregated and individual flows.
Security Considerations
Detailed security considerations for DetNet are cataloged in
, and more general security considerations
are described in . This section
exclusively considers security considerations that are specific to the DetNet
IP data plane.
Security aspects that are unique to DetNet are those whose aim is to
provide the specific QoS aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
Achieving such loss rates and bounded latency may not be possible
in the face of a highly capable adversary, such as the one
envisioned by the Internet Threat Model of BCP 72 that can
arbitrarily drop or delay any or all traffic. In order to
present meaningful security considerations, we consider a
somewhat weaker attacker who does not control the physical links
of the DetNet domain but may have the ability to control a
network node within the boundary of the DetNet domain.
The primary consideration for the DetNet data plane is to maintain
integrity of data and delivery of the associated DetNet service traversing
the DetNet network.
Since no DetNet-specific fields are available in the DetNet IP
data plane,
the integrity and confidentiality of application flows can be protected through whatever means are
provided by the underlying technology. For example, encryption may be
used, such as that provided by IPsec for IP
flows and/or by an underlying sub-network using
MACsec
for IP over
Ethernet (Layer 2) flows.
From a data plane perspective, this document does not add or modify any
header information.
At the management and control level, DetNet flows are identified on a
per-flow basis, which may provide Controller Plane
attackers with additional information about the data flows (when
compared to Controller Planes that do not include per-flow identification).
This is an inherent property of DetNet that has security
implications that should be considered when determining if DetNet is
a suitable technology for any given use case.
To provide uninterrupted availability of the DetNet service,
provisions can be made against DoS attacks and delay attacks. To
protect against DoS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated -- for example,
through the use of existing mechanisms such as policing and shaping
applied at the input of a DetNet domain or within an edge IEEE 802.1
TSN domain. To prevent DetNet packets from being delayed by an entity
external to a DetNet domain, DetNet technology definitions can allow
for the mitigation of man-in-the-middle attacks -- for example,
through the use of authentication and authorization of devices within the
DetNet domain.
IANA Considerations
This document has no IANA actions.
ReferencesNormative ReferencesUser Datagram ProtocolInternet ProtocolInternet Control Message ProtocolTransmission Control ProtocolRequirements for IP Version 4 RoutersThis memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 HeadersThis document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]Security Architecture for the Internet ProtocolThis document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]IP Authentication HeaderThis document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]IP Encapsulating Security Payload (ESP)This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]IPv6 Prefix Length Recommendation for ForwardingIPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Internet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.Deterministic Networking ArchitectureThis document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.Deterministic Networking (DetNet) Data Plane FrameworkInformative ReferencesDetNet Flow Information ModelThis document describes flow and service information model for Deterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planesWork in ProgressDetNet Data Plane: IP over MPLSWork in ProgressDetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)Work in ProgressDetNet Data Plane: MPLSWork in ProgressDeterministic Networking (DetNet) Security ConsiderationsWork in ProgressDetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLSWork in ProgressDeterministic Networking (DetNet) Configuration YANG ModelThis document contains the specification for Deterministic Networking flow configuration YANG Model. The model allows for provisioning of end-to-end DetNet service along the path without dependency on any signaling protocol. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA).Work in ProgressIEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) SecurityIEEETime-Sensitive Networking (TSN) Task GroupIEEERequirements for Internet Hosts - Communication LayersThis RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]Path MTU discoveryThis memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]An Architecture for Differentiated ServicesThis document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.An Informal Management Model for Diffserv RoutersThis document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community.Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) ExtensionsThis document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]Guidelines for Writing RFC Text on Security ConsiderationsAll RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Information Model for Describing Network Device QoS Datapath MechanismsThe purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repositoryM-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]Traffic Classification and Quality of Service (QoS) Attributes for DiameterThis document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy. [STANDARDS-TRACK]RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.Differentiated Services (Diffserv) and Real-Time CommunicationThis memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC.Path MTU Discovery for IP version 6This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981.IPv6 Node RequirementsThis document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.This document obsoletes RFC 6434, and in turn RFC 4294.Acknowledgements
The authors wish to thank , , , ,
, , , , ,
, , and for their
various contributions to this work. served as
technical advisor to the DetNet working group during the
development of this document and provided many valuable
comments. IESG comments were provided by ,
, , , , and
.
Contributors
The editor of this document wishes to thank and acknowledge the following
people who contributed substantially to the content of this document and
should be considered coauthors:
jouni.nospam@gmail.comMalis Consultingagmalis@gmail.comAuthors' AddressesEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comLabN Consulting, L.L.C.lberger@labn.netLabN Consulting, L.L.C.dfedyk@labn.netFuturewei Technologiessb@stewartbryant.com