draft-ietf-detnet-ip-01.txt   draft-ietf-detnet-ip-02.txt 
DetNet B. Varga, Ed. DetNet B. Varga, Ed.
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 2, 2020 L. Berger Expires: April 18, 2020 L. Berger
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
Independent
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
July 1, 2019 October 16, 2019
DetNet Data Plane: IP DetNet Data Plane: IP
draft-ietf-detnet-ip-01 draft-ietf-detnet-ip-02
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking data plane when
operating in an IP packet switched network. operating in an IP packet switched network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2020. This Internet-Draft will expire on April 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 24
2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4
4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6
4.1. End-System Specific Considerations . . . . . . . . . . . 7 4.1. End-System Specific Considerations . . . . . . . . . . . 7
4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7
4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 9 4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 9
4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9
4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10
4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 10 4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 10
4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 11 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 11
5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 11 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 12
5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12
5.1. DetNet IP Flow Identification Procedures . . . . . . . . 12 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 12
5.1.1. IP Header Information . . . . . . . . . . . . . . . . 12 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13
5.1.2. Other Protocol Header Information . . . . . . . . . . 13 5.1.2. Other Protocol Header Information . . . . . . . . . . 14
5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 14 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15
5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 15 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 15
6. Management and Control Information Summary . . . . . . . . . 15 6. Management and Control Information Summary . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative references . . . . . . . . . . . . . . . . . . 17 10.1. Normative references . . . . . . . . . . . . . . . . . . 18
10.2. Informative references . . . . . . . . . . . . . . . . . 19 10.2. Informative references . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Deterministic Networking (DetNet) is a service that can be offered by Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides these flows extremely low a network to DetNet flows. DetNet provides these flows extremely low
packet loss rates and assured maximum end-to-end delivery latency. packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in the DetNet General background and concepts of DetNet can be found in the DetNet
Architecture [I-D.ietf-detnet-architecture]. Architecture [I-D.ietf-detnet-architecture].
This document specifies the DetNet data plane operation for IP hosts This document specifies the DetNet data plane operation for IP hosts
skipping to change at page 3, line 50 skipping to change at page 4, line 4
CoS Class of Service. CoS Class of Service.
DetNet Deterministic Networking. DetNet Deterministic Networking.
DN DetNet. DN DetNet.
DiffServ Differentiated Services DiffServ Differentiated Services
DSCP Differentiated Services Code Point DSCP Differentiated Services Code Point
ECN Explicit Congestion Notification.
L2 Layer-2. L2 Layer-2.
L3 Layer-3. L3 Layer-3.
LSP Label-switched path. LSP Label-switched path.
MPLS Multiprotocol Label Switching. MPLS Multiprotocol Label Switching.
PREOF Packet Replication, Ordering and Elimination Function. PREOF Packet Replication, Ordering and Elimination Function.
skipping to change at page 4, line 37 skipping to change at page 4, line 40
This document describes how IP is used by DetNet nodes, i.e., hosts This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, identify DetNet flows and provide a DetNet service using 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 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 model is followed. As mentioned above, existing IP and higher layer
protocol header information is used to support flow identification protocol header information is used to support flow identification
and DetNet service delivery. Common data plane procedures and and DetNet service delivery. Common data plane procedures and
control information for all DetNet data planes can be found in the control information for all DetNet data planes can be found in the
[I-D.ietf-detnet-data-plane-framework]. [I-D.ietf-detnet-data-plane-framework].
The DetNet IP data plane uses "6-tuple" based flow identification, The DetNet IP data plane primarily uses "6-tuple" based flow
where 6-tuple refers to information carried in IP and higher layer identification, where 6-tuple refers to information carried in IP and
protocol headers. The 6-tuple referred to in this document is the higher layer protocol headers. The 6-tuple referred to in this
same as that defined in [RFC3290]. Specifically 6-tuple is document is the same as that defined in [RFC3290]. Specifically
(destination address, source address, IP protocol, source port, 6-tuple is (destination address, source address, IP protocol, source
destination port, and differentiated services (DiffServ) code point port, destination port, and differentiated services (DiffServ) code
(DSCP). General background on the use of IP headers, and 5-tuples, point (DSCP). General background on the use of IP headers, and
to identify flows and support Quality of Service (QoS) can be found 5-tuples, to identify flows and support Quality of Service (QoS) can
in [RFC3670]. [RFC7657] also provides useful background on the be found in [RFC3670]. [RFC7657] also provides useful background on
delivery of DiffServ and "tuple" based flow identification. the delivery of DiffServ and "tuple" based flow identification.
Referring to a 6-tuple allows DetNet nodes to forward packets with
the 6-tuple as is or remap the DSCP where required by the DetNet The DetNet IP data plane also allows for optional matching on two
service. additional data fields. The optional fields are the ECN Field, as in
[RFC3168], and the IPv6 flow label field, as defined in [RFC8200].
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.
DetNet flow aggregation may be enabled via the use of wildcards, DetNet flow aggregation may be enabled via the use of wildcards,
masks, prefixes and ranges. IP tunnels may also be used to support masks, lists, prefixes and ranges. IP tunnels may also be used to
flow aggregation. In these cases, it is expected that DetNet aware support flow aggregation. In these cases, it is expected that DetNet
intermediate nodes will provide DetNet service assurance on the aware intermediate nodes will provide DetNet service assurance on the
aggregate through resource allocation and congestion control aggregate through resource allocation and congestion control
mechanisms. mechanisms.
DetNet IP Relay Relay DetNet IP DetNet IP Relay Relay DetNet IP
End System Node Node End System End System Node Node End System
+----------+ +----------+ +----------+ +----------+
| Appl. |<------------ End to End Service ----------->| Appl. | | Appl. |<------------ End to End Service ----------->| Appl. |
+----------+ ............ ........... +----------+ +----------+ ............ ........... +----------+
| Service |<-: Service :-- DetNet flow --: Service :->| Service | | Service |<-: Service :-- DetNet flow --: Service :->| Service |
skipping to change at page 7, line 30 skipping to change at page 7, line 30
End systems need to ensure that DetNet service requirements are met End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow. When when processing packets associated with a DetNet flow. When
forwarding packets, this means that packets are appropriately shaped forwarding packets, this means that packets are appropriately shaped
on transmission and received appropriate traffic treatment on the on transmission and received appropriate traffic treatment on the
connected sub-network, see Section 4.3.2 and Section 4.2 for more connected sub-network, see Section 4.3.2 and Section 4.2 for more
details. When receiving packets, this means that there are details. When receiving packets, this means that there are
appropriate local node resources, e.g., buffers, to receive and appropriate local node resources, e.g., buffers, to receive and
process a DetNet flow packets. process a DetNet flow packets.
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.
4.2. DetNet Domain-Specific Considerations 4.2. DetNet Domain-Specific Considerations
As a general rule, DetNet IP domains need to be able to forward any 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 DetNet flow identified by the IP 6-tuple. Doing otherwise would
limit end system encapsulation format. From a practical standpoint limit end system encapsulation format. From a practical standpoint
this means that all nodes along the end-to-end path of DetNet flows 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 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 the transport protocols (e.g., TCP/UDP/IPsec) which can be used to
identify 6-tuple protocol ports. identify 6-tuple protocol ports.
skipping to change at page 9, line 33 skipping to change at page 9, line 35
+---+ +-----R------------+ +-----+ +---+ +-----R------------+ +-----+
Figure 4: Replication and elimination in sub-networks for DetNet IP Figure 4: Replication and elimination in sub-networks for DetNet IP
networks networks
If end to end service protection is desired, it can be implemented, If end to end service protection is desired, it can be implemented,
for example, by the DetNet end systems using Layer-4 (L4) transport for example, by the DetNet end systems using Layer-4 (L4) transport
protocols or application protocols. However, these protocols are out protocols or application protocols. However, these protocols are out
of scope of this document. of 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
reused at the edges of a DetNet network to prevent non-congestion
responsive DetNet traffic from escaping the DetNet domain.
4.3. Forwarding Sub-Layer Considerations 4.3. Forwarding Sub-Layer Considerations
4.3.1. Class of Service 4.3.1. Class of Service
Class of Service (CoS) for DetNet flows carried in IPv6 is provided Class of Service (CoS) for DetNet flows carried in IPv6 is provided
using the standard differentiated services code point (DSCP) field using the standard differentiated services code point (DSCP) field
[RFC2474] and related mechanisms. The 2-bit explicit congestion [RFC2474] and related mechanisms. The 2-bit explicit congestion
notification (ECN) [RFC3168] field MAY also be used. notification (ECN) [RFC3168] field MAY also be used.
One additional consideration for DetNet nodes which support CoS One additional consideration for DetNet nodes which support CoS
skipping to change at page 10, line 13 skipping to change at page 10, line 20
to TE LSPs via [RFC3473]. to TE LSPs via [RFC3473].
4.3.2. Quality of Service 4.3.2. Quality of Service
Quality of Service (QoS) for DetNet service flows carried in IP MUST Quality of Service (QoS) for DetNet service flows carried in IP MUST
be provided locally by the DetNet-aware hosts and routers supporting be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows. Such support leverages the underlying network layer DetNet flows. Such support leverages the underlying network layer
such as 802.1 TSN. The traffic control mechanisms used to deliver such as 802.1 TSN. The traffic control mechanisms used to deliver
QoS for IP encapsulated DetNet flows are expected to be defined in a QoS for IP encapsulated DetNet flows are expected to be defined in a
future document. From an encapsulation perspective, the combination future document. From an encapsulation perspective, the combination
of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP code, of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
uniquely identifies a DetNet service flow. previously mentioned two optional fields, uniquely identifies a
DetNet service flow.
Packets that are marked with a DetNet Class of Service value, but Packets that are marked with a DetNet Class of Service value, but
that have not been the subject of a completed reservation, can that have not been the subject of a completed reservation, can
disrupt the QoS offered to properly reserved DetNet flows by using disrupt the QoS offered to properly reserved DetNet flows by using
resources allocated to the reserved flows. Therefore, the network resources allocated to the reserved flows. Therefore, the network
nodes of a DetNet network must: nodes of a DetNet network must:
o Defend the DetNet QoS by discarding or remarking (to a non-DetNet o Defend the DetNet QoS by discarding or remarking (to a non-DetNet
CoS) packets received that are not the subject of a completed CoS) packets received that are not the subject of a completed
reservation. reservation.
o Not use a DetNet reserved resource, e.g. a queue or shaper o Not use a DetNet reserved resource, e.g. a queue or shaper
reserved for DetNet flows, for any packet that does not carry a reserved for DetNet flows, for any packet that does not carry a
DetNet Class of Service marker. DetNet Class of Service marker.
4.3.3. Path Selection
While path selection algorithms and mechanisms are out of 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 two additional
optional header fields. 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., [RFC5120], 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 [RFC7657], unexpected behavior can occur
when a single 5-tuple application flow experience 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 6-tuple is required. Again, this impacts path
selection for DetNet flows and this document only indirectly.
4.4. DetNet Flow Aggregation 4.4. DetNet Flow Aggregation
As described in [I-D.ietf-detnet-data-plane-framework], the ability As described in [I-D.ietf-detnet-data-plane-framework], the ability
to aggregate individual flows, and their associated resource control, to aggregate individual flows, and their associated resource control,
into a larger aggregate is an important technique for improving into a larger aggregate is an important technique for improving
scaling by reducing the state per hop. DetNet IP data plane scaling by reducing the state per hop. DetNet IP data plane
aggregation can take place within a single node, when that node aggregation can take place within a single node, when that node
maintains state about both the aggregated and individual flows. It maintains state about both the aggregated and individual flows. It
can also take place between nodes, where one node maintains state can also take place between nodes, where one node maintains state
about only flow aggregates while the other node maintains state on about only flow aggregates while the other node maintains state on
skipping to change at page 10, line 51 skipping to change at page 11, line 36
management or control function that provisions the aggregate flows management or control function that provisions the aggregate flows
must ensure that adequate resources are allocated and configured to must ensure that adequate resources are allocated and configured to
provide combined service requirements of the individual flows. As provide combined service requirements of the individual flows. As
DetNet is concerned about latency and jitter, more than just DetNet is concerned about latency and jitter, more than just
bandwidth needs to be considered. bandwidth needs to be considered.
From a single node perspective, the aggregation of IP flows impacts From a single node perspective, the aggregation of IP flows impacts
DetNet IP data plane flow identification and resource allocation. As DetNet IP data plane flow identification and resource allocation. As
discussed above, IP flow identification uses the IP "6-tuple" for discussed above, IP flow identification uses the IP "6-tuple" for
flow identification. DetNet IP flows can be aggregated using any of flow identification. DetNet IP flows can be aggregated using any of
the 6-tuple fields defined in Section 5.1. The use of prefixes, the 6-tuple, or two additional optional fields defined in
wildcards, bitmasks, and value ranges allows a DetNet node to Section 5.1. The use of prefixes, wildcards, lists, and value ranges
identify aggregate DetNet flows. From a resource allocation allows a DetNet node to identify aggregate DetNet flows. From a
perspective, DetNet nodes must provide service to a aggregate and not resource allocation perspective, DetNet nodes must provide service to
on a component flow basis. a aggregate and not on a component flow basis.
It is the responsibility of the DetNet controller plane to properly It is the responsibility of the DetNet controller plane to properly
provision the use of these aggregation mechanisms. This includes provision the use of these aggregation mechanisms. This includes
ensuring that aggregated flows have compatible e.g., the same or very ensuring that aggregated flows have compatible e.g., the same or very
similar QoS and/or CoS characteristics, see Section 4.3.2. It also similar QoS and/or CoS characteristics, see Section 4.3.2. It also
includes ensuring that per component-flow service requirements are includes ensuring that per component-flow service requirements are
satisfied by the aggregate, see Section 5.3. satisfied by the aggregate, see Section 5.3.
4.5. Bidirectional Traffic 4.5. Bidirectional Traffic
skipping to change at page 13, line 22 skipping to change at page 14, line 12
values, MUST be used for flow identification. Implementations SHOULD values, MUST be used for flow identification. Implementations SHOULD
allow for these fields to be ignored for a specific DetNet flow. allow for these fields to be ignored for a specific DetNet flow.
5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields
These fields are used to support Differentiated Services [RFC2474] These fields are used to support Differentiated Services [RFC2474]
and Explicit Congestion Notification [RFC3168]. Implementations of and Explicit Congestion Notification [RFC3168]. Implementations of
this document MUST support DetNet flow identification based on the this document MUST support DetNet flow identification based on the
IPv4 Type of Service field when processing IPv4 packets, and the IPv6 IPv4 Type of Service field when processing IPv4 packets, and the IPv6
Traffic Class Field when processing IPv6 packets. Implementations Traffic Class Field when processing IPv6 packets. Implementations
MUST support bitmask based matching, where bits set to one (1) in the MUST support list based matching of DSCP values, where the list is
bitmask indicate which subset of the bits in the field are to be used composed of possible field values that are to be considered when
in determining a match. Note that all bits set to zero (0) value as identifying a specific DetNet flow. Implementations SHOULD allow for
a bitmask effectively means that these fields are ignored. this field to be ignored for a specific DetNet flow.
Implementations of this document MUST allow the ECN field to be
ignored as part of DetNet flow identification. Additionally,
implementations SHOULD support identification of DetNet flows based
on the value carried in the ECN field. When this field is used to
identify a specific DetNet flow, implementations MUST support a list
of ECN values that match a specific slow.
5.1.1.5. IPv6 Flow Label Field 5.1.1.5. IPv6 Flow Label Field
Implementations of this document SHOULD support identification of Implementations of this document SHOULD support identification of
DetNet flows based on the IPv6 Flow Label field. Implementations DetNet flows based on the IPv6 Flow Label field. Implementations
that support matching based on this field MUST allow for this field that support matching based on this field MUST allow for this field
to be ignored for a specific DetNet flow. When this field is used to to be ignored for a specific DetNet flow. When this field is used to
identify a specific DetNet flow, implementations MAY exclude the IPv6 identify a specific DetNet flow, implementations MAY exclude the IPv6
Next Header field and next header information as part of DetNet flow Next Header field and next header information as part of DetNet flow
identification. identification.
skipping to change at page 15, line 45 skipping to change at page 16, line 37
effectively means that the address field is ignored. effectively means that the address field is ignored.
o IPv4 protocol field. A limited set of values is allowed, and the o IPv4 protocol field. A limited set of values is allowed, and the
ability to ignore this field, e.g., via configuration of the value ability to ignore this field, e.g., via configuration of the value
zero (0), is desirable. zero (0), is desirable.
o IPv6 next header field. A limited set of values is allowed, and o IPv6 next header field. A limited set of values is allowed, and
the ability to ignore this field, e.g., via configuration of the the ability to ignore this field, e.g., via configuration of the
value zero (0), is desirable. value zero (0), is desirable.
o IPv4 Type of Service and IPv6 Traffic Class Fields. o For the IPv4 Type of Service and IPv6 Traffic Class Fields:
o IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a * If the DSCP field is to be used in flow identification.
zero (0) effectively means that theses fields are ignored. Ignoring the DSCP filed is optional.
* When the DSCP field is used in flow identification, a list of
field values that may be used by a specific flow.
* If the ECN field is to be used in flow identification.
Matching based on ECN filed values is optional.
* When ECN field is used in flow identification, a list of field
values that may be used by a specific flow.
o IPv6 flow label field. This field can be optionally used for o IPv6 flow label field. This field can be optionally used for
matching. When used, can be exclusive of matching against the matching. When used, can be exclusive of matching against the
next header field. next header field.
o TCP and UDP Source Port. Exact and wildcard matching is required. o TCP and UDP Source Port. Exact and wildcard matching is required.
Port ranges can optionally be used. Port ranges can optionally be used.
o TCP and UDP Destination Port. Exact and wildcard matching is o TCP and UDP Destination Port. Exact and wildcard matching is
required. Port ranges can optionally be used. required. Port ranges can optionally be used.
skipping to change at page 19, line 20 skipping to change at page 20, line 20
10.2. Informative references 10.2. Informative references
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane Bryant, S., and J. Korhonen, "DetNet Data Plane
Framework", draft-ietf-detnet-data-plane-framework-00 Framework", draft-ietf-detnet-data-plane-framework-02
(work in progress), May 2019. (work in progress), September 2019.
[I-D.ietf-detnet-dp-sol-mpls] [I-D.ietf-detnet-dp-sol-mpls]
Korhonen, J. and B. Varga, "DetNet MPLS Data Plane Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D.
Flow Information Model", draft-ietf-detnet-flow- Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-
information-model-03 (work in progress), March 2019. flow-information-model-05 (work in progress), September
2019.
[I-D.ietf-detnet-ip-over-mpls] [I-D.ietf-detnet-ip-over-mpls]
Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft- Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over
ietf-detnet-ip-over-mpls-00 (work in progress), May 2019. MPLS", draft-ietf-detnet-ip-over-mpls-01 (work in
progress), July 2019.
[I-D.ietf-detnet-ip-over-tsn] [I-D.ietf-detnet-ip-over-tsn]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J. Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time
Sensitive Networking (TSN)", draft-ietf-detnet-ip-over- Sensitive Networking (TSN)", draft-ietf-detnet-ip-over-
tsn-00 (work in progress), May 2019. tsn-00 (work in progress), May 2019.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
J., Austad, H., Stanton, K., and N. Finn, "Deterministic J., Austad, H., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf- Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-04 (work in progress), March 2019. detnet-security-05 (work in progress), August 2019.
[I-D.ietf-detnet-tsn-vpn-over-mpls] [I-D.ietf-detnet-tsn-vpn-over-mpls]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J. Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive
Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- Networking over MPLS", draft-ietf-detnet-tsn-vpn-over-
mpls-00 (work in progress), May 2019. mpls-00 (work in progress), May 2019.
[I-D.ietf-detnet-yang] [I-D.ietf-detnet-yang]
Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic Geng, X., Chen, M., Ryoo, Y., Li, Z., and R. Rahman,
Networking (DetNet) Configuration YANG Model", draft-ietf- "Deterministic Networking (DetNet) Configuration YANG
detnet-yang-02 (work in progress), March 2019. Model", draft-ietf-detnet-yang-03 (work in progress), July
2019.
[IEEE802.1AE-2018] [IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018, Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>. <https://ieeexplore.ieee.org/document/8585421>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 20, line 36 skipping to change at page 21, line 37
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290, Informal Management Model for Diffserv Routers", RFC 3290,
DOI 10.17487/RFC3290, May 2002, DOI 10.17487/RFC3290, May 2002,
<https://www.rfc-editor.org/info/rfc3290>. <https://www.rfc-editor.org/info/rfc3290>.
[RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and
W. Weiss, "Information Model for Describing Network Device W. Weiss, "Information Model for Describing Network Device
QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670,
January 2004, <https://www.rfc-editor.org/info/rfc3670>. January 2004, <https://www.rfc-editor.org/info/rfc3670>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
Ed., and A. Lior, "Traffic Classification and Quality of Ed., and A. Lior, "Traffic Classification and Quality of
Service (QoS) Attributes for Diameter", RFC 5777, Service (QoS) Attributes for Diameter", RFC 5777,
DOI 10.17487/RFC5777, February 2010, DOI 10.17487/RFC5777, February 2010,
<https://www.rfc-editor.org/info/rfc5777>. <https://www.rfc-editor.org/info/rfc5777>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, DOI 10.17487/RFC6434, December Requirements", RFC 6434, DOI 10.17487/RFC6434, December
2011, <https://www.rfc-editor.org/info/rfc6434>. 2011, <https://www.rfc-editor.org/info/rfc6434>.
skipping to change at page 21, line 39 skipping to change at page 22, line 44
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Don Fedyk Don Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: dfedyk@labn.net Email: dfedyk@labn.net
Andrew G. Malis Andrew G. Malis
Futurewei Technologies Independent
Email: agmalis@gmail.com Email: agmalis@gmail.com
Stewart Bryant Stewart Bryant
Futurewei Technologies Futurewei Technologies
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Jouni Korhonen Jouni Korhonen
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 28 change blocks. 
62 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/