draft-ietf-detnet-mpls-12.txt   draft-ietf-detnet-mpls-13.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: March 14, 2021 L. Berger Expires: April 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
September 10, 2020 October 11, 2020
DetNet Data Plane: MPLS DetNet Data Plane: MPLS
draft-ietf-detnet-mpls-12 draft-ietf-detnet-mpls-13
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 March 14, 2021. This Internet-Draft will expire on April 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5
3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5
3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6
4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8
4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8
4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9
4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 4.2.1. DetNet Control Word and the DetNet Sequence Number . 10
4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 15
4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17 4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17
4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17 4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 18
4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18 4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 19
4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 20
4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19 4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 20
4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 20 4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 20
4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 21
4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 21
4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21 4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21
5. Management and Control Information Summary . . . . . . . . . 21 5. Management and Control Information Summary . . . . . . . . . 22
5.1. Service Sub-Layer Information Summary . . . . . . . . . . 22 5.1. Service Sub-Layer Information Summary . . . . . . . . . . 23
5.1.1. Service Aggregation Information Summary . . . . . . . 23 5.1.1. Service Aggregation Information Summary . . . . . . . 24
5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23 5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 a capability for the a network to DetNet flows. DetNet provides a capability for the
delivery of data flows with extremely low packet loss rates and delivery of data flows with extremely low packet loss rates and
bounded end-to-end delivery latency. General background and concepts bounded end-to-end delivery latency. General background and concepts
of DetNet can be found in the DetNet Architecture [RFC8655]. of DetNet can be found in the DetNet Architecture [RFC8655].
The DetNet Architecture models the DetNet related data plane The purpose of this document is to describe the use of the MPLS data
functions decomposed into two sub-layers: a service sub-layer and a plane to establish and support DetNet flows. The DetNet Architecture
forwarding sub-layer. The service sub-layer is used to provide models the DetNet related data plane functions decomposed into two
DetNet service functions such as protection and reordering. The sub-layers: a service sub-layer and a forwarding sub-layer. The
service sub-layer is used to provide DetNet service functions such as
protection and reordering. At the DetNet data plane a new set of
functions (PREOF) provide the service sub-layer specific tasks. 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). The use
of the functionalities of the DetNet service sub-layer and the DetNet
forwarding sub-layer require careful design and control by the
controller plane in addition to the DetNet specific use of MPLS
encapsulation as specified by this document.
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 are out of scope of this document. different network technologies are out of scope of this document.
skipping to change at page 4, line 6 skipping to change at page 4, line 18
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [RFC8655] and the DetNet Data Plane Framework architecture [RFC8655] and the DetNet Data Plane Framework
[I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be
familiar with these documents, any terminology defined therein and familiar with these documents, any terminology defined therein and
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, i.e.,
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 the DetNet service sub-layer nodes that implement the DetNet service sub-layer
functions. An S-Label is used to identify a DetNet functions. An S-Label is used to identify a DetNet
flow at DetNet service sub-layer at a receiving DetNet flow at DetNet service sub-layer at a receiving 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
skipping to change at page 12, line 6 skipping to change at page 12, line 22
4.2.2. S-Labels 4.2.2. S-Labels
A DetNet flow at the DetNet service sub-layer is identified by an A DetNet flow at the DetNet service sub-layer is identified by an
S-Label. MPLS-aware DetNet end systems and edge nodes, which are by S-Label. MPLS-aware DetNet end systems and edge nodes, which are by
definition MPLS ingress and egress nodes, MUST add (push) and remove definition MPLS ingress and egress nodes, MUST add (push) and remove
(pop) a DetNet service-specific d-CW and S-Label. Relay nodes MAY (pop) a DetNet service-specific d-CW and S-Label. Relay nodes MAY
swap S-Label values when processing a DetNet flow, i.e., incoming and swap S-Label values when processing a DetNet flow, i.e., incoming and
outgoing S-Labels of a DetNet flow can be different. outgoing S-Labels of a DetNet flow can be different.
S-Label values MUST be provisioned per DetNet service via S-Label values MUST be provisioned per DetNet service via
configuration, e.g., via the controller plane described in configuration, i.e., via the controller plane described in
[I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide [I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide
identification at the downstream DetNet service sub-layer receiver, identification at the downstream DetNet service sub-layer receiver,
not the sender. As such, S-Labels MUST be allocated by the entity not the sender. As such, S-Labels MUST be allocated by the entity
that controls the service sub-layer receiving node's label space, and that controls the service sub-layer receiving node's label space, and
MAY be allocated from the platform label space [RFC3031]. Because MAY be allocated from the platform label space [RFC3031]. Because
S-Labels are local to each node rather than being a global identifier S-Labels are local to each node rather than being a global identifier
within a domain, they must be advertised to their upstream DetNet within a domain, they must be advertised to their upstream DetNet
service-aware peer nodes (e.g., a DetNet MPLS End System or a DetNet service-aware peer nodes (i.e., a DetNet MPLS End System or a DetNet
Relay or Edge Node) and interpreted in the context of their received Relay or Edge Node) and interpreted in the context of their received
F-Label(s). In some PREOF topologies, the node performing F-Label(s). In some PREOF topologies, the node performing
replication will be sending to multiple nodes performing PEF or POF, replication will be sending to multiple nodes performing PEF or POF,
and may need to send different S-Label values for the different and may need to send different S-Label values for the different
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)
skipping to change at page 13, line 13 skipping to change at page 13, line 30
ensure that incoming DetNet MPLS packets arrive with the needed ensure that incoming DetNet MPLS packets arrive with the needed
information (F-label(s) and/or incoming interface) and provision the information (F-label(s) and/or incoming interface) and provision the
needed information. The provisioned information MUST then be used to needed information. The provisioned information MUST then be used to
identify incoming DetNet service based on the combination of S-Label identify incoming DetNet service based on the combination of S-Label
and F-Label(s) or incoming interface. and F-Label(s) or 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.
Implementation details of PREOF functions are out of scope for this
document. [IEEE802.1CB-2017] defines equivalent replication and
elimination specific aspects, which can be applied to PRF and PEF.
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,
e.g., via the controller plane described in i.e., via the controller plane described in
[I-D.ietf-detnet-data-plane-framework]. When replication is [I-D.ietf-detnet-data-plane-framework]. When replication is
configured, the same app-flow data will be sent over multiple configured, the same app-flow data will be sent over multiple
outgoing DetNet member flows using forwarding sub-layer LSPs. An outgoing DetNet member flows using forwarding sub-layer LSPs. An
S-Label value MUST be configured per outgoing member flow. The same S-Label value MUST be configured per outgoing member flow. The same
d-CW field value MUST be used on all outgoing member flows for each d-CW field value MUST be used on all outgoing member flows for each
replicated MPLS packet. replicated MPLS packet.
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 i.e., 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, if PEF is configured for that DetNet packet, as described above, if PEF is configured for that DetNet
service, duplicate (replicated) instances of a particular sequence service, duplicate (replicated) instances of a particular sequence
number MUST be discarded. The specific mechanisms used for an number MUST be discarded. The specific mechanisms used for an
implementation to identify which received packets are duplicates and implementation to identify which received packets are duplicates and
which are new is an implementation choice. Note that per which are new is an implementation choice. Note that per
Section 4.2.1 the sequence number field length may be 16 or 28 bits, Section 4.2.1 the sequence number field length may be 16 or 28 bits,
and the field value can wrap. PEF MUST NOT be used with DetNet flows and the field value can wrap. PEF MUST NOT be used with DetNet flows
skipping to change at page 14, line 10 skipping to change at page 14, line 28
numbers that are tracked on either a platform-wide or per flow basis. numbers that are tracked on either a platform-wide or per flow basis.
Some implementations MAY support the provisioning of the maximum Some implementations MAY support the provisioning of the maximum
number of sequence numbers that are tracked on either a platform-wide number of sequence numbers that are tracked on either a 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, i.e., 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 require 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, if POF is configured for that DetNet packet, as described above, if POF is configured for that DetNet
service, packets MUST be processed in the order indicated in the service, packets MUST be processed in the order indicated in the
received d-CW sequence number field, which may not be in the order received d-CW sequence number field, which may not be in the order
the packets are received. As defined in Section 4.2.1 the sequence the packets are received. As defined in Section 4.2.1 the sequence
skipping to change at page 14, line 32 skipping to change at page 14, line 50
for each new MPLS packet sent for a particular DetNet service, and for each new MPLS packet sent for a particular DetNet service, and
the field value can wrap. The specific mechanisms used for an the field value can wrap. The specific mechanisms used for an
implementation to identify the order of received packets is an implementation to identify the order of received packets is an
implementation choice. implementation choice.
An implementation MAY constrain the maximum number of out of order An implementation MAY constrain the maximum number of out of order
packets that can be processed, on either a platform-wide or per flow packets that can be processed, on either a platform-wide or per flow
basis. The number of out of order packets that can be processed also basis. The number of out of order packets that can be processed also
impacts the latency of a flow. impacts the latency of a flow.
The latency impact on the system resources needed to support a
specific DetNet flow will need to be evaluated by the controller
plane based on that flow's traffic specification. An example traffic
specification that can be used with MPLS with Traffic Engineering
(MPLS-TE) can be found in [RFC2212].
DetNet implementations can use flow-specific requirements (e.g.,
maximum number of out-of-order packets, maximum latency of the flow)
for configuration of POF-related buffers. POF implementation details
are out-of-scope for this document and POF configuration parameters
are implementation specific. The Controller Plane identifies and
sets the POF configuration parameters.
4.2.3. F-Labels 4.2.3. F-Labels
F-Labels support the DetNet forwarding sub-layer. F-Labels are used F-Labels support the DetNet forwarding sub-layer. F-Labels are used
to provide LSP-based connectivity between DetNet service sub-layer to provide LSP-based connectivity between DetNet service sub-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.
When sending a DetNet flow, zero or more F-Labels MAY be pushed on When sending a DetNet flow, zero or more F-Labels MAY be pushed on
top of an S-Label by the node pushing an S-Label. The F-Label(s) to top of an S-Label by the node pushing an S-Label. The F-Label(s) to
be pushed when sending a particular DetNet service MUST be be pushed when sending a particular DetNet service MUST be
provisioned per outgoing S-Label via configuration, e.g., via the provisioned per outgoing S-Label via configuration, i.e., via the
controller plane discussed in [I-D.ietf-detnet-data-plane-framework]. controller plane discussed in [I-D.ietf-detnet-data-plane-framework].
F-Label(s) can also provide context for an S-Label. To allow for the F-Label(s) can also provide context for an S-Label. To allow for the
omission of F-Label(s), an implementation SHOULD also allow an omission of F-Label(s), an implementation SHOULD also allow an
outgoing interface to be configured per S-Label. outgoing interface to be configured per S-Label.
Note, when PRF is supported, the same app-flow data will be sent over Note, when PRF is supported, the same app-flow data will be sent over
multiple outgoing DetNet member flows using forwarding sub-layer multiple outgoing DetNet member flows using forwarding sub-layer
LSPs. This means that implementation may be sending different sets LSPs. This means that implementation may be sending different sets
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.
skipping to change at page 25, line 37 skipping to change at page 26, line 18
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 having their delay manipulated by
external to a DetNet domain, DetNet technology definition can allow an external entity, precautions need to be taken to ensure that all
for the mitigation of on-path attackers, for example through use of devices on an LSP are those intended to be there by the network
authentication and authorization of devices within the DetNet domain. operator and that they are well behaved. In addition to physical
security, technical methods such as authentication and authorization
of network equipment and the instrumentation and monitoring of the
LSP packet delay may be used. If a delay attack is suspected,
traffic may be moved to an alternate path, for example through
changing the LSP or management of the PREOF configuration.
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
skipping to change at page 28, line 34 skipping to change at page 29, line 20
10.2. Informative References 10.2. Informative References
[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-07 (work in progress), September 2020. detnet-ip-over-mpls-08 (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 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
(DetNet) Security Considerations", draft-ietf-detnet- Networking (DetNet) Security Considerations", draft-ietf-
security-11 (work in progress), August 2020. detnet-security-12 (work in progress), October 2020.
[I-D.ietf-detnet-yang] [I-D.ietf-detnet-yang]
Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Li, Z., and R. Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Li, Z., and R.
Rahman, "Deterministic Networking (DetNet) Configuration Rahman, "Deterministic Networking (DetNet) Configuration
YANG Model", draft-ietf-detnet-yang-07 (work in progress), YANG Model", draft-ietf-detnet-yang-07 (work in progress),
July 2020. July 2020.
[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>.
[IEEE802.1CB-2017]
IEEE Standards Association, "IEEE Std 802.1CB-2017 Frame
Replication and Elimination for Reliability", 2017,
<https://ieeexplore.ieee.org/document/8091139>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
 End of changes. 25 change blocks. 
46 lines changed or deleted 80 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/