< draft-ietf-detnet-mpls-11.txt   draft-ietf-detnet-mpls-12.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: February 17, 2021 L. Berger Expires: March 14, 2021 L. Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
Malis Consulting Malis Consulting
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
August 16, 2020 September 10, 2020
DetNet Data Plane: MPLS DetNet Data Plane: MPLS
draft-ietf-detnet-mpls-11 draft-ietf-detnet-mpls-12
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking data plane when
operating over an MPLS Packet Switched Network. It leverages operating over an MPLS Packet Switched Network. It leverages
existing pseudowire (PW) encapsulations and MPLS Traffic Engineering existing pseudowire (PW) encapsulations and MPLS Traffic Engineering
encapsulations and mechanisms. This document builds on the DetNet encapsulations and mechanisms. This document builds on the DetNet
Architecture and Data Plane Framework. Architecture and Data Plane Framework.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 February 17, 2021. This Internet-Draft will expire on March 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 3, line 8 skipping to change at page 3, line 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 with a network to DetNet flows. DetNet provides a capability for the
extremely low packet loss rates and assured maximum end-to-end delivery of data flows with extremely low packet loss rates and
delivery latency. General background and concepts of DetNet can be bounded end-to-end delivery latency. General background and concepts
found in [RFC8655]. of DetNet can be found in the DetNet Architecture [RFC8655].
The DetNet Architecture models the DetNet related data plane The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: a service sub-layer and a functions decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer. The service sub-layer is used to provide forwarding sub-layer. The service sub-layer is used to provide
DetNet service functions such as protection and reordering. The DetNet service functions such as protection and reordering. The
forwarding sub-layer is used to provide forwarding assurance (low forwarding sub-layer is used to provide forwarding assurance (low
loss, assured latency, and limited out-of-order delivery). loss, assured latency, and limited out-of-order delivery).
This document specifies the DetNet data plane operation and the on- This document specifies the DetNet data plane operation and the on-
wire encapsulation of DetNet flows over an MPLS-based Packet Switched wire encapsulation of DetNet flows over an MPLS-based Packet Switched
Network (PSN) using the service reference model. MPLS encapsulation Network (PSN) using the service reference model. MPLS encapsulation
already provides a solid foundation of building blocks to enable the already provides a solid foundation of building blocks to enable the
DetNet service and forwarding sub-layer functions. MPLS encapsulated DetNet service and forwarding sub-layer functions. MPLS encapsulated
DetNet can be carried over a variety of different network DetNet can be carried over a variety of different network
technologies that can provide the DetNet required level of service. technologies that can provide the DetNet required level of service.
However, the specific details of how DetNet MPLS is carried over However, the specific details of how DetNet MPLS is carried over
different network technologies is out of scope of this document. different network technologies are out of scope of this document.
MPLS encapsulated DetNet flows can carry different types of traffic. MPLS encapsulated DetNet flows can carry different types of traffic.
The details of the types of traffic that are carried in DetNet are The details of the types of traffic that are carried in DetNet are
also out of scope of this document. An example of IP using DetNet also out of scope of this document. An example of IP using DetNet
MPLS sub-networks can be found in [I-D.ietf-detnet-ip]. DetNet MPLS MPLS sub-networks can be found in [I-D.ietf-detnet-ip]. DetNet MPLS
may use an associated controller and Operations, Administration, and may use an associated controller and Operations, Administration, and
Maintenance (OAM) functions that are defined outside of this Maintenance (OAM) functions that are defined outside of this
document. document.
Background information common to all data planes for DetNet can be Background information common to all data planes for DetNet can be
skipping to change at page 4, line 11 skipping to change at page 4, line 11
basic MPLS related terminologies in [RFC3031]. basic MPLS related terminologies in [RFC3031].
The following terminology is introduced in this document: The following terminology is introduced in this document:
F-Label A Detnet "forwarding" label that identifies the LSP F-Label A Detnet "forwarding" label that identifies the LSP
used to forward a DetNet flow across an MPLS PSN, e.g., used to forward a DetNet flow across an MPLS PSN, e.g.,
a hop-by-hop label used between label switching routers a hop-by-hop label used between label switching routers
(LSR). (LSR).
S-Label A DetNet "service" label that is used between DetNet S-Label A DetNet "service" label that is used between DetNet
nodes that implement also the DetNet service sub-layer nodes that implement the DetNet service sub-layer
functions. An S-Label is also used to identify a functions. An S-Label is used to identify a DetNet
DetNet flow at DetNet service sub-layer at a receiving flow at DetNet service sub-layer at a receiving DetNet
DetNet node. node.
A-Label A special case of an S-Label, whose aggregation A-Label A special case of an S-Label, whose aggregation
properties are known only at the aggregation and properties are known only at the aggregation and
deaggregation end-points. deaggregation end-points.
d-CW A DetNet Control Word (d-CW) is used for sequencing d-CW A DetNet Control Word (d-CW) is used for sequencing
information of a DetNet flow at the DetNet service sub- information of a DetNet flow at the DetNet service sub-
layer. layer.
2.2. Abbreviations 2.2. Abbreviations
skipping to change at page 10, line 32 skipping to change at page 10, line 32
+---------------------------------+ +---------------------------------+
Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN
4.2.1. DetNet Control Word and the DetNet Sequence Number 4.2.1. DetNet Control Word and the DetNet Sequence Number
A DetNet control word (d-CW) conforms to the Generic PW MPLS Control A DetNet control word (d-CW) conforms to the Generic PW MPLS Control
Word (PWMCW) defined in [RFC4385]. The d-CW formatted as shown in Word (PWMCW) defined in [RFC4385]. The d-CW formatted as shown in
Figure 5 MUST be present in all DetNet packets containing app-flow Figure 5 MUST be present in all DetNet packets containing app-flow
data. This format of the d-CW was created in order (1) to allow data. This format of the d-CW was created in order (1) to allow
larger S/N space to avoid S/N rollover frequency in some applications larger sequence number space to avoid sequence number rollover
and (2) to allow non-skip zero S/N what simplifies implementation. frequency in some applications and (2) to allow sequence numbering
systems that include the value zero as a valid sequence number, which
simplifies implementation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Sequence Number | |0 0 0 0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DetNet Control Word Figure 5: DetNet Control Word
(bits 0 to 3) (bits 0 to 3)
skipping to change at page 10, line 48 skipping to change at page 11, line 4
|0 0 0 0| Sequence Number | |0 0 0 0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DetNet Control Word Figure 5: DetNet Control Word
(bits 0 to 3) (bits 0 to 3)
Per [RFC4385], MUST be set to zero (0). Per [RFC4385], MUST be set to zero (0).
Sequence Number (bits 4 to 31) Sequence Number (bits 4 to 31)
An unsigned value implementing the DetNet sequence number. The An unsigned value implementing the DetNet sequence number. The
sequence number space is a circular one. sequence number space is a circular one with no restriction on
initial value.
A separate sequence number space MUST be maintained by the node that A separate sequence number space MUST be maintained by the node that
adds the d-CW for each DetNet app-flow, i.e., DetNet service. The adds the d-CW for each DetNet app-flow, i.e., DetNet service. The
following sequence number field lengths MUST be supported: following sequence number field lengths MUST be supported:
0 bits 0 bits
16 bits 16 bits
28 bits 28 bits
skipping to change at page 11, line 29 skipping to change at page 11, line 32
A 0 bit sequence number field length indicates that there is no A 0 bit sequence number field length indicates that there is no
DetNet sequence number used for the flow. When the length is zero, DetNet sequence number used for the flow. When the length is zero,
the sequence number field MUST be set to zero (0) on all packets sent the sequence number field MUST be set to zero (0) on all packets sent
for the flow. for the flow.
When the sequence number field length is 16 or 28 bits for a flow, When the sequence number field length is 16 or 28 bits for a flow,
the sequence number MUST be incremented by one for each new app-flow the sequence number MUST be incremented by one for each new app-flow
packet sent. When the field length is 16 bits, d-CW bits 4 to 15 packet sent. When the field length is 16 bits, d-CW bits 4 to 15
MUST be set to zero (0). The values carried in this field can wrap MUST be set to zero (0). The values carried in this field can wrap
and it is important to note that zero (0) is a valid field value. and it is important to note that zero (0) is a valid field value.
For example, were the sequence number size is 16 bits, the sequence For example, where the sequence number size is 16 bits, the sequence
will contain: 65535, 0, 1, where zero (0) is an ordinary sequence will contain: 65535, 0, 1, where zero (0) is an ordinary sequence
number. number.
It is important to note that this document differs from [RFC4448] It is important to note that this document differs from [RFC4448]
where a sequence number of zero (0) is used to indicate that the where a sequence number of zero (0) is used to indicate that the
sequence number check algorithm is not used. sequence number check algorithm is not used.
The sequence number is optionally used during receive processing as The sequence number is optionally used during receive processing as
described below in Section 4.2.2.2 and Section 4.2.2.3. described below in Section 4.2.2.2 and Section 4.2.2.3.
skipping to change at page 12, line 24 skipping to change at page 12, line 29
member flows for the same DetNet service. member flows for the same DetNet service.
An S-Label will normally be at the bottom of the label stack once the An S-Label will normally be at the bottom of the label stack once the
last F-Label is removed, immediately preceding the d-CW. To support last F-Label is removed, immediately preceding the d-CW. To support
service sub-layer level OAM, an OAM Associated Channel Header (ACH) service sub-layer level OAM, an OAM Associated Channel Header (ACH)
[RFC4385] together with a Generic Associated Channel Label (GAL) [RFC4385] together with a Generic Associated Channel Label (GAL)
[RFC5586] MAY be used in place of a d-CW. [RFC5586] MAY be used in place of a d-CW.
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL)
[RFC6790] MAY be carried below the S-Label in the label stack in [RFC6790] MAY be carried below the S-Label in the label stack in
networks where DetNet flows would otherwise received ECMP treatment. networks where DetNet flows would otherwise receive ECMP treatment.
When ELs are used, the same EL value SHOULD be used for all of the When ELs are used, the same EL value SHOULD be used for all of the
packets sent using a specific S-Label to force the flow to follow the packets sent using a specific S-Label to force the flow to follow the
same path. However, as outlines in same path. However, as outlined in
[I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet [I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet
flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows
within a DetNet domain. within a DetNet domain.
When receiving a DetNet MPLS packet, an implementation MUST identify When receiving a DetNet MPLS packet, an implementation MUST identify
the DetNet service associated with the incoming packet based on the the DetNet service associated with the incoming packet based on the
S-Label. When a node is using platform labels for S-Labels, no S-Label. When a node is using platform labels for S-Labels, no
additional information is needed as the S-label uniquely identifies additional information is needed as the S-label uniquely identifies
the DetNet service. In the case where platform labels are not used, the DetNet service. In the case where platform labels are not used,
zero or more F-Labels and optionally, the incoming interface, zero or more F-Labels proceeding the S-Label MUST be used together
proceeding the S-Label MUST be used together with the S-Label to with the S-Label to uniquely identify the DetNet service associated
uniquely identify the DetNet service associated with a received with a received packet. The incoming interface MAY also be used
packet. The incoming interface MAY also be used together with any together with any present F-Label(s) and the S-Label to uniquely
present F-Label(s) and the S-Label to uniquely identify an incoming identify an incoming DetNet service, for example, in the case where
DetNet service, for example, in the case where PHP is used. Note PHP is used. Note that choice to use platform label space for
that choice to use platform label space for S-Label or S-Label plus S-Label or S-Label plus one or more F-Labels to identify DetNet
one or more F-Labels to identify DetNet services is a local services is a local implementation choice, with one caveat. When one
implementation choice, with one caveat. When one or more F-labels, or more F-labels, or incoming interface, is needed together with an
or incoming interface, is needed together with an S-Label to uniquely S-Label to uniquely identify a service, the controller plane must
identify a service, the controller plane must ensure that incoming ensure that incoming DetNet MPLS packets arrive with the needed
DetNet MPLS packets arrive with the needed information (F-label(s) information (F-label(s) and/or incoming interface) and provision the
and/or incoming interface) and provision the needed information. The needed information. The provisioned information MUST then be used to
provisioned information MUST then be used to identify incoming DetNet identify incoming DetNet service based on the combination of S-Label
service based on the combination of S-Label and F-Label(s) or and F-Label(s) or incoming interface.
incoming interface.
The use of platform labels for S-Labels matches other pseudowire The use of platform labels for S-Labels matches other pseudowire
encapsulations for consistency but there is no hard requirement in encapsulations for consistency but there is no hard requirement in
this regard. this regard.
4.2.2.1. Packet Replication Function Processing 4.2.2.1. Packet Replication Function Processing
The Packet Replication Function (PRF) function MAY be supported by an The Packet Replication Function (PRF) function MAY be supported by an
implementation for outgoing DetNet flows. The use of the PRF for a implementation for outgoing DetNet flows. The use of the PRF for a
particular DetNet service MUST be provisioned via configuration, particular DetNet service MUST be provisioned via configuration,
skipping to change at page 13, line 33 skipping to change at page 13, line 35
4.2.2.2. Packet Elimination Function Processing 4.2.2.2. Packet Elimination Function Processing
Implementations MAY support the Packet Elimination Function (PEF) for Implementations MAY support the Packet Elimination Function (PEF) for
received DetNet MPLS flows. When supported, use of the PEF for a received DetNet MPLS flows. When supported, use of the PEF for a
particular DetNet service MUST be provisioned via configuration, particular DetNet service MUST be provisioned via configuration,
e.g., via the controller plane described in e.g., via the controller plane described in
[I-D.ietf-detnet-data-plane-framework]. [I-D.ietf-detnet-data-plane-framework].
After a DetNet service is identified for a received DetNet MPLS After a DetNet service is identified for a received DetNet MPLS
packet, as described above, an implementation MUST check if PEF is packet, as described above, if PEF is configured for that DetNet
configured for that DetNet service. When configured, the service, duplicate (replicated) instances of a particular sequence
implementation MUST track the sequence number contained in received number MUST be discarded. The specific mechanisms used for an
d-CWs and MUST ensure that duplicate (replicated) instances of a implementation to identify which received packets are duplicates and
particular sequence number are discarded. The specific mechanisms which are new is an implementation choice. Note that per
used for an implementation to identify which received packets are Section 4.2.1 the sequence number field length may be 16 or 28 bits,
duplicates and which are new is an implementation choice. Note that and the field value can wrap. PEF MUST NOT be used with DetNet flows
per Section 4.2.1 the sequence number field length may be 16 or 28 configured with a d-CW sequence number field length of 0 bits.
bits, and the field value can wrap. PEF MUST NOT be used with DetNet
flows configured with a d-CW sequence number field length of 0 bits.
Note that an implementation MAY wish to constrain the maximum number An implementation MAY constrain the maximum number of sequence
of sequence numbers that are tracked, on platform-wide or per flow numbers that are tracked on either a platform-wide or per flow basis.
basis. Some implementations MAY support the provisioning of the Some implementations MAY support the provisioning of the maximum
maximum number of sequence numbers that are tracked on either a number of sequence numbers that are tracked on either a platform-wide
platform-wide or per flow basis. or per flow basis.
4.2.2.3. Packet Ordering Function Processing 4.2.2.3. Packet Ordering Function Processing
A function that is related to in-order delivery is the Packet A function that is related to in-order delivery is the Packet
Ordering Function (POF). Implementations MAY support POF. When Ordering Function (POF). Implementations MAY support POF. When
supported, use of the POF for a particular DetNet service MUST be supported, use of the POF for a particular DetNet service MUST be
provisioned via configuration, e.g., via the controller plane provisioned via configuration, e.g., via the controller plane
described by [I-D.ietf-detnet-data-plane-framework]. Implementations described by [I-D.ietf-detnet-data-plane-framework]. Implementations
MAY required that PEF and POF be used in combination. There is no MAY require that PEF and POF be used in combination. There is no
requirement related to the order of execution of the Packet requirement related to the order of execution of the Packet
Elimination and Ordering Functions in an implementation. Elimination and Ordering Functions in an implementation.
After a DetNet service is identified for a received DetNet MPLS After a DetNet service is identified for a received DetNet MPLS
packet, as described above, an implementation MUST check if POF is packet, as described above, if POF is configured for that DetNet
configured for that DetNet service. When configured, the service, packets MUST be processed in the order indicated in the
implementation MUST track the sequence number contained in received received d-CW sequence number field, which may not be in the order
d-CWs and MUST ensure that packets are processed in the order the packets are received. As defined in Section 4.2.1 the sequence
indicated in the received d-CW sequence number field, which may not number field length may be 16 or 28 bits, is incremented by one (1)
be in the order the packets are received. As defined in for each new MPLS packet sent for a particular DetNet service, and
Section 4.2.1 the sequence number field length may be 16 or 28 bits, the field value can wrap. The specific mechanisms used for an
is incremented by one (1) for each new MPLS packet sent for a implementation to identify the order of received packets is an
particular DetNet service, and the field value can wrap. The implementation choice.
specific mechanisms used for an implementation to identify the order
of received packets is an implementation choice.
Note that an implementation MAY wish to constrain the maximum number An implementation MAY constrain the maximum number of out of order
of out of order packets that can be processed, on platform-wide or packets that can be processed, on either a platform-wide or per flow
per flow basis. Some implementations MAY support the provisioning of basis. The number of out of order packets that can be processed also
this number on either a platform-wide or per flow basis. The number impacts the latency of a flow.
of out of order packets that can be processed also impacts the
latency of a flow.
4.2.3. F-Labels 4.2.3. F-Labels
F-Labels are supported the DetNet forwarding sub-layer. F-Labels are F-Labels support the DetNet forwarding sub-layer. F-Labels are used
used to provide LSP-based connectivity between DetNet service sub- to provide LSP-based connectivity between DetNet service sub-layer
layer processing nodes. processing nodes.
4.2.3.1. Service Sub-Layer Related Processing 4.2.3.1. Service Sub-Layer Related Processing
DetNet MPLS end systems, edge nodes and relay nodes may operate at DetNet MPLS end systems, edge nodes and relay nodes may operate at
the DetNet service sub-layer with understanding of DetNet services the DetNet service sub-layer with understanding of DetNet services
and their requirements. As mentioned earlier, when operating at this and their requirements. As mentioned earlier, when operating at this
layer such nodes can push, pop or swap (pop then push) S-Labels. In layer such nodes can push, pop or swap (pop then push) S-Labels. In
all cases, the F-Label(s) used for a DetNet service are always all cases, the F-Label(s) used for a DetNet service are always
replaced and the following procedures apply. replaced and the following procedures apply.
skipping to change at page 15, line 24 skipping to change at page 15, line 20
of F-Labels per DetNet member flow, each with a different S-Label. of F-Labels per DetNet member flow, each with a different S-Label.
When a single set of F-Labels is provisioned for a particular When a single set of F-Labels is provisioned for a particular
outgoing S-Label, that set of F-labels MUST be pushed after the outgoing S-Label, that set of F-labels MUST be pushed after the
S-Label is pushed. The outgoing packet is then forwarded as S-Label is pushed. The outgoing packet is then forwarded as
described below in Section 4.2.3.2. When a single outgoing interface described below in Section 4.2.3.2. When a single outgoing interface
is provisioned, the outgoing packet is then forwarded as described is provisioned, the outgoing packet is then forwarded as described
below in Section 4.2.3.2. below in Section 4.2.3.2.
When multiple sets of outgoing F-Labels or interfaces are provisioned When multiple sets of outgoing F-Labels or interfaces are provisioned
for a particular DetNet service, a copy of the outgoing packet, for a particular DetNet service (i.e., for PRF), a copy of the
including the pushed member flow-specific S-Label, MUST be made per outgoing packet, including the pushed member flow-specific S-Label,
F-label set and outgoing interface. Each set of provisioned F-Labels MUST be made per F-label set and outgoing interface. Each set of
are then pushed onto a copy of the packet. Each copy is then provisioned F-Labels are then pushed onto a copy of the packet. Each
forwarded as described below in Section 4.2.3.2. copy is then forwarded as described below in Section 4.2.3.2.
As described in the previous section, when receiving a DetNet MPLS As described in the previous section, when receiving a DetNet MPLS
flow, an implementation identifies the DetNet service associated with flow, an implementation identifies the DetNet service associated with
the incoming packet based on the S-Label. When a node is using the incoming packet based on the S-Label. When a node is using
platform labels for S-Labels, any F-Labels can be popped and the platform labels for S-Labels, any F-Labels can be popped and the
S-label uniquely identifies the DetNet service. In the case where S-label uniquely identifies the DetNet service. In the case where
platform labels are not used, incoming F-Label(s) and, optionally, platform labels are not used, incoming F-Label(s) and, optionally,
the incoming interface MUST also be provisioned for a DetNet service. the incoming interface MUST also be provisioned for a DetNet service.
4.2.3.2. Common F-Label Processing 4.2.3.2. Common F-Label Processing
skipping to change at page 16, line 20 skipping to change at page 16, line 16
be associated with a provisioned outgoing interface and, for non- be associated with a provisioned outgoing interface and, for non-
point-to-point outgoing interfaces, a next hop LSR. Note that this point-to-point outgoing interfaces, a next hop LSR. Note that this
information MUST be provisioned via configuration or the controller information MUST be provisioned via configuration or the controller
plane. In the previously mentioned special case where there are no plane. In the previously mentioned special case where there are no
added F-labels and the outgoing interface is not a point-to-point added F-labels and the outgoing interface is not a point-to-point
interface, the outgoing interface MUST also be associated with a next interface, the outgoing interface MUST also be associated with a next
hop LSR. hop LSR.
Resources may be allocated in a hierarchical fashion per LSP that is Resources may be allocated in a hierarchical fashion per LSP that is
represented by each F-Label. Each LSP MAY be provisioned with a represented by each F-Label. Each LSP MAY be provisioned with a
service parameters that dictates the specific traffic treatment to be service parameter that dictates the specific traffic treatment to be
received by the traffic carried over that LSP. Implementations of received by the traffic carried over that LSP. Implementations of
this document MUST ensure that traffic carried over each LSP this document MUST ensure that traffic carried over each LSP
represented by one or more F-Labels receives the traffic treatment represented by one or more F-Labels receives the traffic treatment
provisioned for that LSP. Typical mechanisms used to provide provisioned for that LSP. Typical mechanisms used to provide
different treatment to different flows includes the allocation of different treatment to different flows includes the allocation of
system resources (such as queues and buffers) and provisioning or system resources (such as queues and buffers) and provisioning of
related parameters (such as shaping, and policing) that may be found related parameters (such as shaping, and policing) that may be found
in implementations of Resource ReSerVation Protocol (RSVP) [RFC2205] in implementations of Resource ReSerVation Protocol (RSVP) [RFC2205]
(RSVP) and RSVP-TE [RFC3209] and [RFC3473]. Support can also be (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. Support can also be
provided via an underlying network technology such IEEE802.1 TSN provided via an underlying network technology such IEEE802.1 TSN
[I-D.ietf-detnet-mpls-over-tsn]. The specific mechanisms selected by [I-D.ietf-detnet-mpls-over-tsn]. The specific mechanisms selected by
a DetNet node to ensure DetNet service delivery requirements are met a DetNet node to ensure DetNet service delivery requirements are met
for supported DetNet flows is outside the scope of this document. for supported DetNet flows is outside the scope of this document.
Packets that are marked in a way that do not correspond to allocated Packets that are marked in a way that do not correspond to allocated
resources, e.g., lack a provisioned F-Label, can disrupt the QoS resources, e.g., lack a provisioned F-Label, can disrupt the QoS
skipping to change at page 17, line 7 skipping to change at page 17, line 4
o MUST NOT use a DetNet allocated resource, e.g. a queue or shaper o MUST NOT use a DetNet allocated resource, e.g. a queue or shaper
reserved for DetNet flows, for any packet that does match the reserved for DetNet flows, for any packet that does match the
corresponding DetNet flow. corresponding DetNet flow.
o MUST ensure a QoS flow does not exceed its allocated resources or o MUST ensure a QoS flow does not exceed its allocated resources or
provisioned service level, provisioned service level,
o MUST ensure a CoS flow or service class does not impact the o MUST ensure a CoS flow or service class does not impact the
service delivered to other flows. This requirement is similar to service delivered to other flows. This requirement is similar to
requirement for MPLS LSRs to that CoS LSPs do not impact the the requirement for MPLS LSRs that CoS LSPs do not impact the
resources allocated to TE LSPs, e.g., via [RFC3473]. resources allocated to TE LSPs, e.g., via [RFC3473].
Subsequent sections provide additional considerations related to CoS Subsequent sections provide additional considerations related to CoS
(Section 4.6.1), QoS (Section 4.6.2) and aggregation (Section 4.4). (Section 4.6.1), QoS (Section 4.6.2) and aggregation (Section 4.4).
4.3. OAM Indication 4.3. OAM Indication
OAM follows the procedures set out in [RFC5085] with the restriction OAM follows the procedures set out in [RFC5085] with the restriction
that only Virtual Circuit Connectivity Verification (VCCV) type 1 is that only Virtual Circuit Connectivity Verification (VCCV) type 1 is
supported. supported.
As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW
is 0x0 the payload following the d-CW is normal user data. However, is 0x0 the payload following the d-CW is normal user data. However,
when the first nibble of the d-CW is 0X1, the payload that follows when the first nibble of the d-CW is 0x1, the payload that follows
the d-CW is an OAM payload with the OAM type indicated by the value the d-CW is an OAM payload with the OAM type indicated by the value
in the d-CW Channel Type field. in the d-CW Channel Type field.
The reader is referred to [RFC5085] for a more detailed description The reader is referred to [RFC5085] for a more detailed description
of the Associated Channel mechanism, and to the DetNet work on OAM of the Associated Channel mechanism, and to the DetNet work on OAM
for more information DetNet OAM. for more information DetNet OAM.
Additional considerations on DetNet-specific OAM are subjects for Additional considerations on DetNet-specific OAM are subjects for
further study. further study.
skipping to change at page 18, line 8 skipping to change at page 18, line 6
4.4.1. Aggregation Via LSP Hierarchy 4.4.1. Aggregation Via LSP Hierarchy
DetNet flows forwarded via MPLS can leverage MPLS-TE's existing DetNet flows forwarded via MPLS can leverage MPLS-TE's existing
support for hierarchical LSPs (H-LSPs), see [RFC4206]. H-LSPs are support for hierarchical LSPs (H-LSPs), see [RFC4206]. H-LSPs are
typically used to aggregate control and resources, they may also be typically used to aggregate control and resources, they may also be
used to provide OAM or protection for the aggregated LSPs. Arbitrary used to provide OAM or protection for the aggregated LSPs. Arbitrary
levels of aggregation naturally falls out of the definition for levels of aggregation naturally falls out of the definition for
hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which
support aggregation (LSP hierarchy) map one or more LSPs (labels) support aggregation (LSP hierarchy) map one or more LSPs (labels)
into and from an H-LSP. Both carried LSPs and H-LSPs may or may not into and from an H-LSP. Both carried LSPs and H-LSPs may or may not
use the TC field, i.e., L-LSPs or E-LSPs. Such nodes will need to use the TC field, i.e., L-LSPs or E-LSPs [RFC3270]. Such nodes will
ensure that individual LSPs and H-LSPs receive the traffic treatment need to ensure that individual LSPs and H-LSPs receive the traffic
required to ensure the required DetNet service is preserved. treatment required to ensure the required DetNet service is
preserved.
Additional details of the traffic control capabilities needed at a Additional details of the traffic control capabilities needed at a
DetNet-aware node may be covered in the new service definitions DetNet-aware node may be covered in the new service definitions
mentioned above or in separate future documents. Controller plane mentioned above or in separate future documents. Controller plane
mechanisms will also need to ensure that the service required on the mechanisms will also need to ensure that the service required on the
aggregate flow are provided, which may include the discarding or aggregate flow are provided, which may include the discarding or
remarking mentioned in the previous sections. remarking mentioned in the previous sections.
4.4.2. Aggregating DetNet Flows as a new DetNet flow 4.4.2. Aggregating DetNet Flows as a new DetNet flow
skipping to change at page 19, line 18 skipping to change at page 19, line 18
by an MPLS label stack. A relay node processing the A-Label would by an MPLS label stack. A relay node processing the A-Label would
not know the underlying payload type, and the A-Label would be not know the underlying payload type, and the A-Label would be
processed as a normal S-Label. This would only be known to a node processed as a normal S-Label. This would only be known to a node
that was a peer of the node imposing the S-Label. However there is that was a peer of the node imposing the S-Label. However there is
no real need for it to know the payload type during aggregation no real need for it to know the payload type during aggregation
processing. processing.
As in the previous section, nodes supporting this type of aggregation As in the previous section, nodes supporting this type of aggregation
will need to ensure that individual and aggregated flows receive the will need to ensure that individual and aggregated flows receive the
traffic treatment required to ensure the required DetNet service is traffic treatment required to ensure the required DetNet service is
preserved. Also, it is the controller plane's responsibility to to preserved. Also, it is the controller plane's responsibility to
ensure that the service required on the aggregate flow are properly ensure that the service required on the aggregate flow are properly
provisioned. provisioned.
4.5. Service Sub-Layer Considerations 4.5. Service Sub-Layer Considerations
The edge and relay node internal procedures related to PREOF are The edge and relay node internal procedures related to PREOF are
implementation specific. The order of a packet elimination or implementation specific. The order of a packet elimination or
replication is out of scope in this specification. replication is out of scope in this specification.
It is important that the DetNet layer is configured such that a It is important that the DetNet layer is configured such that a
skipping to change at page 21, line 16 skipping to change at page 21, line 16
TTL processing models are described in [RFC3270] and [RFC3443] and TTL processing models are described in [RFC3270] and [RFC3443] and
MAY be used for MPLS LSPs supporting DetNet flows. MPLS Explicit MAY be used for MPLS LSPs supporting DetNet flows. MPLS Explicit
Congestion Notification (ECN) MAY also be used as defined in ECN Congestion Notification (ECN) MAY also be used as defined in ECN
[RFC5129] and updated by [RFC5462]. [RFC5129] and updated by [RFC5462].
4.6.2. Quality of Service 4.6.2. Quality of Service
In addition to explicit routes, and packet replication and In addition to explicit routes, and packet replication and
elimination, described in Section 4 above, DetNet provides zero elimination, described in Section 4 above, DetNet provides zero
congestion loss and bounded latency and jitter. As described in congestion loss and bounded latency and jitter. As described in
[RFC8655], there are different mechanisms that maybe used separately [RFC8655], there are different mechanisms that may be used separately
or in combination to deliver a zero congestion loss service. This or in combination to deliver a zero congestion loss service. This
includes Quality of Service (QoS) mechanisms at the MPLS layer, that includes Quality of Service (QoS) mechanisms at the MPLS layer, that
may be combined with the mechanisms defined by the underlying network may be combined with the mechanisms defined by the underlying network
layer such as 802.1TSN. layer such as 802.1TSN.
Quality of Service (QoS) mechanisms for flow specific traffic Quality of Service (QoS) mechanisms for flow specific traffic
treatment typically includes a guarantee/agreement for the service, treatment typically includes a guarantee/agreement for the service,
and allocation of resources to support the service. Example QoS and allocation of resources to support the service. Example QoS
mechanisms include discrete resource allocation, admission control, mechanisms include discrete resource allocation, admission control,
flow identification and isolation, and sometimes path control, flow identification and isolation, and sometimes path control,
traffic protection, shaping, policing and remarking. Example traffic protection, shaping, policing and remarking. Example
protocols that support QoS control include Resource ReSerVation protocols that support QoS control include Resource ReSerVation
Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473].
The existing MPLS mechanisms defined to support CoS [RFC3270] can The existing MPLS mechanisms defined to support CoS [RFC3270] can
also be used to reserve resources for specific traffic classes. also be used to reserve resources for specific traffic classes.
A baseline set of QoS capabilities for DetNet flows carried in PWs A baseline set of QoS capabilities for DetNet flows carried in PWs
and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE) and MPLS can be provided by MPLS with Traffic Engineering (MPLS-TE)
[RFC3209] and [RFC3473]. TE LSPs can also support explicit routes [RFC3209] and [RFC3473]. TE LSPs can also support explicit routes
(path pinning). Current service definitions for packet TE LSPs can (path pinning). Current service definitions for packet TE LSPs can
be found in "Specification of the Controlled Load Quality of be found in "Specification of the Controlled Load Quality of
Service", [RFC2211], "Specification of Guaranteed Quality of Service", [RFC2211], "Specification of Guaranteed Quality of
Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003].
Additional service definitions are expected in future documents to Additional service definitions are expected in future documents to
support the full range of DetNet services. In all cases, the support the full range of DetNet services. In all cases, the
existing label-based marking mechanisms defined for TE-LSPs and even existing label-based marking mechanisms defined for TE-LSPs and even
E-LSPs are use to support the identification of flows requiring E-LSPs are use to support the identification of flows requiring
DetNet QoS. DetNet QoS.
skipping to change at page 22, line 32 skipping to change at page 22, line 32
The following summarizes the information that is needed on service The following summarizes the information that is needed on service
sub-layer aware nodes that transmit DetNet MPLS traffic, on a per sub-layer aware nodes that transmit DetNet MPLS traffic, on a per
service basis: service basis:
o App-Flow identification information, e.g., IP information as o App-Flow identification information, e.g., IP information as
defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information
is not needed on DetNet relay nodes. is not needed on DetNet relay nodes.
o The sequence number length to be used for the service. Valid o The sequence number length to be used for the service. Valid
values included 0, 16 and 28 bits. 0 bits cannot be used when PEF values include 0, 16 and 28 bits. 0 bits cannot be used when PEF
or POF is configured for the service. or POF is configured for the service.
o If PRF is to be provided for the service. o If PRF is to be provided for the service.
o The outgoing S-Label for each of the service's outgoing DetNet o The outgoing S-Label for each of the service's outgoing DetNet
(member) flow. (member) flows.
o The forwarding sub-layer information associated with the output of o The forwarding sub-layer information associated with the output of
the service sub-layer. Note that when the PRF function is the service sub-layer. Note that when the PRF function is
provisioned, this information is per DetNet member flow. provisioned, this information is per DetNet member flow.
Logically the forwarding sub-layer information is a pointer to Logically the forwarding sub-layer information is a pointer to
further details of transmission of Detnet flows at the forwarding further details of transmission of Detnet flows at the forwarding
sub-layer. sub-layer.
The following summarizes the information that is needed on service The following summarizes the information that is needed on service
sub-layer aware nodes that receive DetNet MPLS traffic, on a per sub-layer aware nodes that receive DetNet MPLS traffic, on a per
skipping to change at page 23, line 43 skipping to change at page 23, line 43
o The S-Labels or F-Labels that are to be carried over each o The S-Labels or F-Labels that are to be carried over each
aggregated service. aggregated service.
o The A-Label associated with each aggregated service. o The A-Label associated with each aggregated service.
o The other S-Label information summarized above. o The other S-Label information summarized above.
On the receiving node, the A-Label provides the forwarding context of On the receiving node, the A-Label provides the forwarding context of
an incoming interface or an F-Label and is used in subsequent service an incoming interface or an F-Label and is used in subsequent service
or forwarding sub-layer receive processing, as appropriated. The or forwarding sub-layer receive processing, as appropriated. The
related addition configuration that may be provided discussed related additional configuration that may be provided is discussed
elsewhere in this section. elsewhere in this section.
5.2. Forwarding Sub-Layer Information Summary 5.2. Forwarding Sub-Layer Information Summary
The following summarizes the information that is needed on forwarding The following summarizes the information that is needed on forwarding
sub-layer aware nodes that send DetNet MPLS traffic, on a per sub-layer aware nodes that send DetNet MPLS traffic, on a per
forwarding sub-layer flow basis: forwarding sub-layer flow basis:
o The outgoing F-Label stack to be pushed. The stack may include o The outgoing F-Label stack to be pushed. The stack may include
H-LSP labels. H-LSP labels.
o The traffic parameters associated with a specific label in the o The traffic parameters associated with a specific label in the
stack. Note that there may be multiple sets of traffic paramters stack. Note that there may be multiple sets of traffic parameters
associated with specific labels in the stack, e.g., when H-LSPs associated with specific labels in the stack, e.g., when H-LSPs
are used. are used.
o Outgoing interface and, for unicast traffic, the next hop o Outgoing interface and, for unicast traffic, the next hop
information. information.
o Sub-network specific parameters on a technology specific basis. o Sub-network specific parameters on a technology specific basis.
For example, see [I-D.ietf-detnet-mpls-over-tsn]. For example, see [I-D.ietf-detnet-mpls-over-tsn].
The following summarizes the information that is needed on forwarding The following summarizes the information that is needed on forwarding
skipping to change at page 24, line 33 skipping to change at page 24, line 33
o The incoming interface. For some implementations and deployment o The incoming interface. For some implementations and deployment
scenarios, this information may not be needed. scenarios, this information may not be needed.
o The incoming F-Label stack to be popped. The stack may include o The incoming F-Label stack to be popped. The stack may include
H-LSP labels. H-LSP labels.
o How the incoming forwarding sub-layer flow is to be handled, i.e., o How the incoming forwarding sub-layer flow is to be handled, i.e.,
forwarded as a transit node, or provided to the service sub-layer. forwarded as a transit node, or provided to the service sub-layer.
It is the responsibility of the DetNet controller plane to properly It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow specific provision both flow identification information and the flow-specific
resources needed to provided the traffic treatment needed to meet resources needed to provided the traffic treatment needed to meet
each flow's service requirements. This applies for aggregated and each flow's service requirements. This applies for aggregated and
individual flows. individual flows.
6. Security Considerations 6. Security Considerations
Detailed security considerations for DetNet are cataloged in Detailed security considerations for DetNet are cataloged in
[I-D.ietf-detnet-security], and more general security considerations [I-D.ietf-detnet-security], and more general security considerations
are described in [RFC8655]. This section considers exclusively are described in [RFC8655]. This section considers exclusively
security considerations which are specific to the DetNet MPLS data security considerations which are specific to the DetNet MPLS data
plane. The considerations raised related to MPLS networks in general plane. The considerations raised related to MPLS networks in general
in [RFC5920] are equally applicable to the the DetNet MPLS data in [RFC5920] are equally applicable to the the DetNet MPLS data
plane. plane.
Security aspects which are unique to DetNet are those whose aim is to Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are protect the support of specific quality of service aspects of DetNet,
primarily to deliver data flows with extremely low packet loss rates which are primarily to deliver data flows with extremely low packet
and bounded end-to-end delivery latency. Achieving such loss rates loss rates and bounded end-to-end delivery latency. Achieving such
and bounded latency may not be possible in the face of a highly loss rates and bounded latency may not be possible in the face of a
capable adversary, such as the one envisioned by the Internet Threat highly capable adversary, such as the one envisioned by the Internet
Model of BCP 72 that can arbitrarily drop or delay any or all Threat Model of BCP 72 that can arbitrarily drop or delay any or all
traffic. In order to present meaningful security considerations, we traffic. In order to present meaningful security considerations, we
consider a somewhat weaker attacker who does not control the physical consider a somewhat weaker attacker who does not control the physical
links of the DetNet domain, but may have the ability to control a links of the DetNet domain, but may have the ability to control a
network node within the boundary of the DetNet domain. network node within the boundary of the DetNet domain.
The primary consideration for the DetNet data plane is to maintain An additional consideration for the DetNet data plane is to maintain
integrity of data and delivery of the associated DetNet service integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected traversing the DetNet network. Application flows can be protected
through whatever means are provided by the underlying technology. through whatever means are provided by the underlying technology.
For example, encryption may be used, such as that provided by IPsec For example, encryption may be used, such as that provided by IPsec
[RFC4301] for IP flows and/or by an underlying sub-net using MACSec [RFC4301] for IP flows and/or by an underlying sub-net using MACSec
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. MPLS
doesn't provide any native security services to account for
confidentiality and integrity.
From a data plane perspective this document does not add or modify From a data plane perspective this document does not add or modify
any header information. any application header information.
At the management and control level DetNet flows are identified on a At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane attackers with per-flow basis, which may provide controller plane attackers with
additional information about the data flows (when compared to additional information about the data flows (when compared to
controller planes that do not include per-flow identification). This controller planes that do not include per-flow identification). This
is an inherent property of DetNet which has security implications is an inherent property of DetNet which has security implications
that should be considered when determining if DetNet is a suitable that should be considered when determining if DetNet is a suitable
technology for any given use case. technology for any given use case.
To provide uninterrupted availability of the DetNet service, To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks. To provisions can be made against DOS attacks and delay attacks. To
protect against DOS attacks, excess traffic due to malicious or protect against DOS attacks, excess traffic due to malicious or
malfunctioning devices is prevented or mitigated through the use of malfunctioning devices is prevented or mitigated through the use of
existing mechanisms, for example by policing and shaping incoming existing mechanisms, for example by policing and shaping incoming
traffic. To prevent DetNet packets from being delayed by an entity traffic. To prevent DetNet packets from being delayed by an entity
external to a DetNet domain, DetNet technology definition can allow external to a DetNet domain, DetNet technology definition can allow
for the mitigation of Man-In-The-Middle attacks, for example through for the mitigation of on-path attackers, for example through use of
use of authentication and authorization of devices within the DetNet authentication and authorization of devices within the DetNet domain.
domain.
7. IANA Considerations 7. IANA Considerations
This document makes no IANA requests. This document makes no IANA requests.
8. Acknowledgements 8. Acknowledgements
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong Ryoo Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong Ryoo
and Carlos J. Bernardos for their various contributions to this and Carlos J. Bernardos for their various contributions to this
work. work.
9. Contributors 9. Contributors
RFC7322 limits the number of authors listed on the front page of a RFC7322 limits the number of authors listed on the front page of a
draft to a maximum of 5. The editor wishes to thank and acknowledge draft to a maximum of 5. The editor wishes to thank and acknowledge
the follow author for contributing text to this draft. the following author for contributing text to this draft.
Don Fedyk Don Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: dfedyk@labn.net Email: dfedyk@labn.net
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-06 (work in progress), May 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load [RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, DOI 10.17487/RFC2211, Network Element Service", RFC 2211, DOI 10.17487/RFC2211,
September 1997, <https://www.rfc-editor.org/info/rfc2211>. September 1997, <https://www.rfc-editor.org/info/rfc2211>.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
skipping to change at page 27, line 41 skipping to change at page 28, line 5
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>. 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>. 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-06 (work in progress), May 2020.
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07
(work in progress), July 2020. (work in progress), July 2020.
[I-D.ietf-detnet-ip-over-mpls] [I-D.ietf-detnet-ip-over-mpls]
Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. Varga, B., Berger, L., Fedyk, D., Bryant, S., and J.
Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf-
detnet-ip-over-mpls-06 (work in progress), May 2020. detnet-ip-over-mpls-07 (work in progress), September 2020.
[I-D.ietf-detnet-mpls-over-tsn] [I-D.ietf-detnet-mpls-over-tsn]
Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet
Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking
(TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in (TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in
progress), June 2020. progress), June 2020.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T. and E. Grossman, "Deterministic Networking Mizrahi, T. and E. Grossman, "Deterministic Networking
(DetNet) Security Considerations", draft-ietf-detnet- (DetNet) Security Considerations", draft-ietf-detnet-
skipping to change at page 29, line 42 skipping to change at page 30, line 5
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>. <https://www.rfc-editor.org/info/rfc4875>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<https://www.rfc-editor.org/info/rfc5921>. <https://www.rfc-editor.org/info/rfc5921>.
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
RFC 6003, DOI 10.17487/RFC6003, October 2010, RFC 6003, DOI 10.17487/RFC6003, October 2010,
<https://www.rfc-editor.org/info/rfc6003>. <https://www.rfc-editor.org/info/rfc6003>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, Aissaoui, "Segmented Pseudowire", RFC 6073,
DOI 10.17487/RFC6073, January 2011, DOI 10.17487/RFC6073, January 2011,
<https://www.rfc-editor.org/info/rfc6073>. <https://www.rfc-editor.org/info/rfc6073>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication "Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", RFC 8306, Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017, DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/info/rfc8306>. <https://www.rfc-editor.org/info/rfc8306>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
 End of changes. 46 change blocks. 
121 lines changed or deleted 118 lines changed or added

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