DetNet Data Plane: IP over MPLS
draft-ietf-detnet-ip-over-mpls-03
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9056.
|
|
---|---|---|---|
Authors | Balazs Varga , János Farkas , Lou Berger , Don Fedyk , Andrew G. Malis , Stewart Bryant , Jouni Korhonen | ||
Last updated | 2019-11-17 (Latest revision 2019-10-28) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
TSVART Last Call review
(of
-05)
by Brian Trammell
Ready w/nits
GENART Last Call review
(of
-05)
by Tim Evens
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | Ethan Grossman | ||
IESG | IESG state | Became RFC 9056 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | Ethan Grossman <eagros@dolby.com> |
draft-ietf-detnet-ip-over-mpls-03
DetNet B. Varga, Ed. Internet-Draft J. Farkas Intended status: Standards Track Ericsson Expires: April 29, 2020 L. Berger D. Fedyk LabN Consulting, L.L.C. A. Malis Independent S. Bryant Futurewei Technologies J. Korhonen October 27, 2019 DetNet Data Plane: IP over MPLS draft-ietf-detnet-ip-over-mpls-03 Abstract This document specifies the Deterministic Networking data plane when operating in an IP over MPLS packet switched network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 29, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Varga, et al. Expires April 29, 2020 [Page 1] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 4. IP over DetNet MPLS . . . . . . . . . . . . . . . . . . . . . 4 4.1. IP Over DetNet MPLS Data Plane Scenarios . . . . . . . . 5 4.2. DetNet IP over DetNet MPLS Encapsulation . . . . . . . . 6 5. IP over DetNet MPLS Procedures . . . . . . . . . . . . . . . 8 5.1. DetNet IP over DetNet MPLS Flow Identification Procedures . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures . 8 6. Management and Control Information Summary . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative references . . . . . . . . . . . . . . . . . . 10 10.2. Informative references . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end delivery latency. General background and concepts of DetNet can be found in the DetNet Architecture [I-D.ietf-detnet-architecture]. This document specifies use of the IP DetNet encapsulation over an MPLS network. It maps the IP data plane encapsulation described in [I-D.ietf-detnet-ip] to the DetNet MPLS data plane defined in [I-D.ietf-detnet-mpls]. 2. Terminology Varga, et al. Expires April 29, 2020 [Page 2] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 2.1. Terms Used In This Document This document uses the terminology and concepts established in the DetNet architecture [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-data-plane-framework], and the reader is assumed to be familiar with these documents and their terminology. 2.2. Abbreviations This document uses the abbreviations defined in the DetNet architecture [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-data-plane-framework]. This document uses the following abbreviations: CE Customer Edge equipment. DetNet Deterministic Networking. DF DetNet Flow. DN DetNet. L2 Layer-2. L3 Layer-3. LSP Label-switched path. MPLS Multiprotocol Label Switching. PE Provider Edge. PREOF Packet Replication, Ordering and Elimination Function. PSN Packet Switched Network. PW Pseudowire. TE Traffic Engineering. TSN Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group. 2.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD> operation retrieves configuration data only, while the <get> operation retrieves configuration and state data. Note that the NETCONF protocol is focused on the information required to get the device into its desired running state. The inclusion of other important, persistent data is implementation specific. For example, user files and databases are not treated as configuration data by the NETCONF protocol. If a local database of user authentication data is stored on the device, whether it is included in configuration data is an implementation-dependent matter. 2. Transport Protocol Requirements NETCONF uses an RPC-based communication paradigm. A client sends a series of one or more RPC request operations, which cause the server to respond with a corresponding series of RPC replies. The NETCONF protocol can be layered on any transport protocol that provides the required set of functionality. It is not bound to any particular transport protocol, but allows a mapping to define how it can be implemented over any specific protocol. The transport protocol MUST provide a mechanism to indicate the session type (client or server) to the NETCONF protocol layer. This section details the characteristics that NETCONF requires from the underlying transport protocol. Enns Standards Track [Page 8] RFC 4741 NETCONF Protocol December 2006 2.1. Connection-Oriented Operation NETCONF is connection-oriented, requiring a persistent connection between peers. This connection must provide reliable, sequenced data delivery. NETCONF connections are long-lived, persisting between protocol operations. This allows the client to make changes to the state of the connection that will persist for the lifetime of the connection. For example, authentication information specified for a connection remains in effect until the connection is closed. In addition, resources requested from the server for a particular connection MUST be automatically released when the connection closes, making failure recovery simpler and more robust. For example, when a lock is acquired by a client, the lock persists until either it is explicitly released or the server determines that the connection has been terminated. If a connection is terminated while the client holds a lock, the server can perform any appropriate recovery. The lock operation is further discussed in Section 7.5. 2.2. Authentication, Integrity, and Confidentiality NETCONF connections must provide authentication, data integrity, and confidentiality. NETCONF depends on the transport protocol for this capability. A NETCONF peer assumes that appropriate levels of security and confidentiality are provided independently of this document. For example, connections may be encrypted in TLS [9] or SSH [10], depending on the underlying protocol. 2.3. Authentication NETCONF connections must be authenticated. The transport protocol is responsible for authentication. The peer assumes that the connection's authentication information has been validated by the underlying protocol using sufficiently trustworthy mechanisms and that the peer's identity has been sufficiently proven. One goal of NETCONF is to provide a programmatic interface to the device that closely follows the functionality of the device's native interface. Therefore, it is expected that the underlying protocol uses existing authentication mechanisms defined by the device. For example, a device that supports RADIUS [11] should allow the use of RADIUS to authenticate NETCONF sessions. The authentication process should result in an identity whose permissions are known to the device. These permissions MUST be enforced during the remainder of the NETCONF session. Enns Standards Track [Page 9] RFC 4741 NETCONF Protocol December 2006 2.4. Mandatory Transport Protocol A NETCONF implementation MUST support the SSH transport protocol mapping [4]. 3. XML Considerations XML serves as the encoding format for NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML. This section discusses a small number of XML-related considerations pertaining to NETCONF. 3.1. Namespace All NETCONF protocol elements are defined in the following namespace: urn:ietf:params:xml:ns:netconf:base:1.0 NETCONF capability names MUST be URIs [5]. NETCONF capabilities are discussed in Section 8. 3.2. No Document Type Declarations Document type declarations MUST NOT appear in NETCONF content. 4. RPC Model The NETCONF protocol uses an RPC-based communication model. NETCONF peers use <rpc> and <rpc-reply> elements to provide transport protocol-independent framing of NETCONF requests and responses. 4.1. <rpc> Element The <rpc> element is used to enclose a NETCONF request sent from the client to the server. The <rpc> element has a mandatory attribute "message-id", which is an arbitrary string chosen by the sender of the RPC that will commonly encode a monotonically increasing integer. The receiver of the RPC does not decode or interpret this string but simply saves it to be used as a "message-id" attribute in any resulting <rpc-reply> message. For example: Enns Standards Track [Page 10] RFC 4741 NETCONF Protocol December 2006 <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <some-method> <!-- method parameters here... --> </some-method> </rpc> If additional attributes are present in an <rpc> element, a NETCONF peer MUST return them unmodified in the <rpc-reply> element. The name and parameters of an RPC are encoded as the contents of the <rpc> element. The name of the RPC is an element directly inside the <rpc> element, and any parameters are encoded inside this element. The following example invokes a method called <my-own-method>, which has two parameters, <my-first-parameter>, with a value of "14", and <another-parameter>, with a value of "fred": <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <my-own-method xmlns="http://example.net/me/my-own/1.0"> <my-first-parameter>14</my-first-parameter> <another-parameter>fred</another-parameter> </my-own-method> </rpc> The following example invokes a <rock-the-house> method with a <zip-code> parameter of "27606-0100": <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rock-the-house xmlns="http://example.net/rock/1.0"> <zip-code>27606-0100</zip-code> </rock-the-house> </rpc> The following example invokes the NETCONF <get> method with no parameters: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get/> </rpc> Enns Standards Track [Page 11] RFC 4741 NETCONF Protocol December 2006 4.2. <rpc-reply> Element The <rpc-reply> message is sent in response to an <rpc> operation. The <rpc-reply> element has a mandatory attribute "message-id", which is equal to the "message-idquot;, "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP Varga, et al. Expires April 29, 2020 [Page 3] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. DetNet IP Data Plane Overview Figure 1 illustrates an IP DetNet, with an MPLS based DetNet network as a sub-network between the relay nodes. It shows a more complex DetNet enabled IP network where an IP flow is mapped to one or more PWs and MPLS (TE) LSPs. The end systems still originate IP encapsulated traffic that are identified as DetNet flows. The relay nodes follow procedures defined in Section 4 to map each DetNet flow to MPLS LSPs. While not shown, relay nodes can provide service sub- layer functions such as PREOF using DetNet over MPLS, and this is indicated by the solid line for the MPLS facing portion of the Service component. Note that the Transit node is MPLS (TE) LSP aware and performs switching based on MPLS labels, and need not have any specific knowledge of the DetNet service or the corresponding DetNet flow identification. See Section 4 for details on the mapping of IP flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of DetNet services using MPLS. DetNet IP Relay Transit Relay DetNet IP End System Node Node Node End System +----------+ +----------+ | Appl. |<------------- End to End Service ---------->| Appl. | +----------+ .....-----+ +-----..... +----------+ | Service |<--: Service |--DetNet flow ---| Service :-->| Service | | | : |<-DN MPLS flow ->| : | | +----------+ +---------+ +----------+ +---------+ +----------+ |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ : Link : / ,-----. \ : Link : / ,-----. \ +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ [Network] [Network] `-----' `-----' |<---- DetNet MPLS ---->| |<--------------------- DetNet IP ------------------>| Figure 1: DetNet IP Over DetNet MPLS Network 4. IP over DetNet MPLS This section defines how IP encapsulated flows are carried over a DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. Since both Non-DetNet and DetNet IP packet are identical on the wire, this Varga, et al. Expires April 29, 2020 [Page 4] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 section is applicable to any node that supports IP over DetNet MPLS, and this section refers to both cases as DetNet IP over DetNet MPLS. 4.1. IP Over DetNet MPLS Data Plane Scenarios An example use of DetNet IP over DetNet MPLS is presented here. Figure 1 illustrated DetNet enabled End Systems (hosts), connected to DetNet (DN) enabled IP networks, operating over a DetNet aware MPLS network. Using this figure we can have a case where the Relay nodes act as T-PEs and sit at the boundary of the MPLS domain since the non-MPLS domain is DetNet aware. This case is very similar to the DetNet MPLS Network figure 2 in [I-D.ietf-detnet-mpls]. However in [I-D.ietf-detnet-mpls] figure 2 the T-PEs are located at the end system and MPLS spans the whole DetNet service. The primary difference in this document is that the Relay nodes are at the edges of the MPLS domain and therefore function as T-PEs, and that MPLS service sub-layer functions are not provided over the DetNet IP network. The transit node functions show above are identical to those described in [I-D.ietf-detnet-mpls]. Figure 2 illustrates how relay nodes can provide service protection over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end systems which are interconnected via a MPLS domain such as described in [I-D.ietf-detnet-mpls]. Note that R1 and R3 sit at the edges of an MPLS domain and therefore are similar to T-PEs, while R2 sits in the middle of the domain and is therefore similar to an S-PE. Varga, et al. Expires April 29, 2020 [Page 5] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 DetNet DetNet IP Service Transit Transit Service IP DetNet |<-Tnl->| |<-Tnl->| DetNet End | V 1 V V 2 V | End System | +--------+ +--------+ +--------+ | System +---+ | | R1 |=======| R2 |=======| R3 | | +---+ | |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| | |CE1| | | \ | | X | | / | | |CE2| | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | +---+ | |=======| |=======| | +---+ ^ +--------+ +--------+ +--------+ ^ | Relay Node Relay Node Relay Node | | (T-PE) (S-PE) (T-PE) | | | |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->| | | |<-------------- End to End DetNet Service --------------->| -------------------------- Data Flow -------------------------> X = Service protection (PRF, PREOF, PEF/POF) DFx = DetNet member flow x over a TE LSP Figure 2: DetNet IP Over DetNet MPLS Network Figure 1 illustrates DetNet enabled End Systems, connected to DetNet (DN) enabled MPLS network. A similar situation occurs when end systems are are not DetNet aware. In this case, edge nodes sit at the boundary of the MPLS domain since it is also a DetNet domain boundary. The edge nodes provide DetNet service proxies for the end applications by initiating and terminating DetNet service for the application's IP flows. While the node types differ, there is essentially no difference in data plane processing between relay and edges. There are likely to be differences in controller plane operation, particularly when distributed control plane protocols are used. It is still possible to provided DetNet service protection for non- DetNet aware end systems. This case is basically the same as Figure 2, with the exception that CE1 and CE2 are non-DetNet aware end systems and R1 and R3 become edge nodes. 4.2. DetNet IP over DetNet MPLS Encapsulation The basic encapsulation approach is to treat a DetNet IP flow as an app-flow from the DetNet MPLS perspective. The corresponding example DetNet Sub-Network format is shown in Figure 3. Varga, et al. Expires April 29, 2020 [Page 6] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 /-> +------+ +------+ +------+ ^ ^ | | X | | X | | X |<- App-Flow : : | +------+ +------+ +------+ : : App-Flow <-+ |NProto| |NProto| |NProto| : :(1) for MPLS | +------+ +------+ +------+ : : | | IP | | IP | | IP | : v \-> +---+======+--+======+--+======+-----+ : DetNet-MPLS | d-CW | | d-CW | | d-CW | : +------+ +------+ +------+ :(2) |Labels| |Labels| |Labels| v +---+======+--+======+--+======+-----+ Link/Sub-Network | L2 | | TSN | | UDP | +------+ +------+ +------+ | IP | +------+ | L2 | +------+ (1) DetNet IP Flow (or simply IP flow) (2) DetNet MPLS Flow Figure 3: Example DetNet IP over MPLS Sub-Network Formats In Figure 3 "App-Flow" indicates the payload carried by the DetNet IP data plane. "IP" and "NProto" indicate the fields described in Section 5.1.1. IP Header Information and Section 5.1.2. Other Protocol Header Information in [I-D.ietf-detnet-ip], respectively. "App-Flow for MPLS" indicates that an individual DetNet IP flow is the payload from the perspective of the DetNet MPLS data plane defined in [I-D.ietf-detnet-mpls]. Per [I-D.ietf-detnet-mpls], the DetNet MPLS data plane uses a single S-Label to support a single app flow. Section 5.1. DetNet IP Flow Identification Procedures in [I-D.ietf-detnet-ip] states that a single DetNet flow is identified based on IP, and next level protocol, header information. Section 4.4. Aggregation Considerations in [I-D.ietf-detnet-ip] defines the ways in which aggregation is supported through the use of prefixes, wildcards, lists, and port ranges. Collectively, this results in the fairly straightforward procedures defined in this section. As shown in Figure 2, DetNet relay nodes are responsible for the mapping of a DetNet flow, at the service sub-layer, from the IP to MPLS DetNet data planes and back again. Their related DetNet IP over DetNet MPLS data plane operation is comprised of two sets of procedures: the mapping of flow identifiers, and ensuring proper traffic treatment. Varga, et al. Expires April 29, 2020 [Page 7] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows. The six-tuple of IP is mapped to the S-Label in both cases. The various fields may be mapped or ignored when going from IP to MPLS. 5. IP over DetNet MPLS Procedures 5.1. DetNet IP over DetNet MPLS Flow Identification Procedures A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a DetNet MPLS network MUST map a DetNet IP flow, as identified in [I-D.ietf-detnet-ip] into a single MPLS DetNet flow and MUST process it in accordance to the procedures defined in [I-D.ietf-detnet-mpls] Section 6.1. PRF MAY be supported at the MPLS level for DetNet IP flows sent over an DetNet MPLS network. Aggregation MAY be supported as defined in [I-D.ietf-detnet-mpls] Section 5.4. Aggregation considerations in [I-D.ietf-detnet-ip] MAY be used to identify an individual DetNet IP flow. The provisioning of the mapping of DetNet IP flows to DetNet MPLS flows MUST be supported via configuration, e.g., via the controller plane. A DetNet relay node (egress T-PE) MAY be provisioned to handle packets received via the DetNet MPLS data plane as DetNet IP flows. A single incoming DetNet MPLS flow MAY be treated as a single DetNet IP flow, without examination of IP headers. Alternatively, packets received via the DetNet MPLS data plane MAY follow the normal DetNet IP flow identification procedures defined in [I-D.ietf-detnet-ip] Section 7.1. An implementation MUST support the provisioning for handling any received DetNet MPLS data plane as DetNet IP flows via configuration. Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures The traffic treatment required for a particular DetNet IP flow is provisioned via configuration or the controller plane. When a DetNet IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure that the provisioned DetNet IP traffic treatment is provided at the forwarding sub-layer as described in [I-D.ietf-detnet-mpls] Section 5.2. Note that the PRF function MAY be utilized when sending IP over MPLS. Traffic treatment for DetNet IP flows received over the DetNet MPLS data plane MUST follow Section 5.3 DetNet IP Traffic Treatment Procedures in [I-D.ietf-detnet-ip]. Varga, et al. Expires April 29, 2020 [Page 8] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 6. Management and Control Information Summary The following summarizes the set of information that is needed to support DetNet IP over DetNet MPLS at the MPLS ingress node: o Each MPLS App-Flow is identified using the IP flow identification information as defined in [I-D.ietf-detnet-ip]. The information is summarized in Section 5.1 of that document, and includes all wildcards, port ranges and the ability to ignore specific IP fields. o The DetNet MPLS service that is to be used to send the matching IP traffic. This matching information is provided in [I-D.ietf-detnet-mpls] Section 5.1, and includes both service and traffic delivery information. The following summarizes the set of information that is needed to support DetNet IP over DetNet MPLS at the MPLS egress node: o S-Label values that are carrying MPLS over IP encapsulated traffic. o For each S-Label, how the received traffic is to be handled. The traffic may be processed according as any other DetNet IP traffic as defined in this document or in [I-D.ietf-detnet-ip], or the traffic may be directly treated as an MPLS App-flow for additional processing according to [I-D.ietf-detnet-mpls]. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific resources needed to provided the traffic treatment needed to meet each flow's service requirements. This applies for aggregated and individual flows. 7. Security Considerations This draft does not have additional security considerations. Security considerations for DetNet are described in detail in [I-D.ietf-detnet-security]. General security considerations are described in [I-D.ietf-detnet-architecture]. MPLS and IP specific considerations are described in [I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip]. Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are primarily to deliver data flows with extremely low packet loss rates and bounded end-to-end delivery latency. Varga, et al. Expires April 29, 2020 [Page 9] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 The primary considerations for the data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Application flows can be protected through whatever means is provided by the underlying technology. 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 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. From a data plane perspective this document does not add or modify any header information. At the management and control level DetNet flows are identified on a per-flow basis, which may provide controller plane attackers with additional information about the data flows (when compared to controller planes that do not include per-flow identification). This is an inherent property of DetNet which has security implications that should be considered when determining if DetNet is a suitable technology for any given use case. To provide uninterrupted availability of the DetNet service, provisions can be made against DOS attacks and delay attacks. To protect against DOS attacks, excess traffic due to malicious or malfunctioning devices can be prevented or mitigated, for example through the use of existing mechanism such as policing and shaping applied at the input of a DetNet domain. To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of Man-In-The- Middle attacks, for example through use of authentication and authorization of devices within the DetNet domain. 8. IANA Considerations This document makes no IANA requests. 9. Acknowledgements The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their various contributions to this work. 10. References 10.1. Normative references Varga, et al. Expires April 29, 2020 [Page 10] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- detnet-architecture-13 (work in progress), May 2019. [I-D.ietf-detnet-ip] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", draft-ietf-detnet-ip-01 (work in progress), July 2019. [I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-detnet-mpls-01 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 10.2. Informative references [I-D.ietf-detnet-data-plane-framework] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane Framework", draft-ietf-detnet-data-plane-framework-02 (work in progress), September 2019. [I-D.ietf-detnet-security] Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, J., Austad, H., Stanton, K., and N. Finn, "Deterministic Networking (DetNet) Security Considerations", draft-ietf- detnet-security-05 (work in progress), August 2019. [IEEE802.1AE-2018] IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC Security (MACsec)", 2018, <https://ieeexplore.ieee.org/document/8585421>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>. Varga, et al. Expires April 29, 2020 [Page 11] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2019 Authors' Addresses Balazs Varga (editor) Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: balazs.a.varga@ericsson.com Janos Farkas Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: janos.farkas@ericsson.com Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Don Fedyk LabN Consulting, L.L.C. Email: dfedyk@labn.net Andrew G. Malis Independent Email: agmalis@gmail.com Stewart Bryant Futurewei Technologies Email: stewart.bryant@gmail.com Jouni Korhonen Email: jouni.nospam@gmail.com Varga, et al. Expires April 29, 2020 [Page 12]