--- 1/draft-ietf-detnet-data-plane-framework-05.txt 2020-05-06 06:13:26.476966841 -0700 +++ 2/draft-ietf-detnet-data-plane-framework-06.txt 2020-05-06 06:13:26.532968277 -0700 @@ -1,47 +1,48 @@ DetNet B. Varga, Ed. Internet-Draft J. Farkas Intended status: Informational Ericsson -Expires: October 25, 2020 L. Berger +Expires: November 7, 2020 L. Berger LabN Consulting, L.L.C. A. Malis Malis Consulting S. Bryant Futurewei Technologies - April 23, 2020 + May 6, 2020 DetNet Data Plane Framework - draft-ietf-detnet-data-plane-framework-05 + draft-ietf-detnet-data-plane-framework-06 Abstract This document provides an overall framework for the DetNet data plane. It covers concepts and considerations that are generally - common to any Deterministic Networking data plane specification. + common to any Deterministic Networking data plane specification. It + describes related controller plane considerations as well. 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 October 25, 2020. + This Internet-Draft will expire on November 7, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -97,49 +98,49 @@ concepts of DetNet can be found in [RFC8655]. This document describes the concepts needed by any DetNet data plane specification (i.e., the DetNet-specific use of packet header fields) and provides considerations for any corresponding implementation. It covers the building blocks that provide the DetNet service, the DetNet service sub-layer and the DetNet forwarding sub-layer functions as described in the DetNet Architecture. The DetNet Architecture models the DetNet related data plane - functions decomposed into two sub-layers: a service sub-layer and a - forwarding sub-layer. The service sub-layer is used to provide - DetNet service protection and reordering. The forwarding sub-layer - leverages Traffic Engineering mechanisms and provides congestion - protection (low loss, assured latency, and limited out-of-order - delivery). A particular forwarding sub-layer may have capabilities - that are not available on other forwarding-sub layers. DetNet makes - use of the existing forwarding sub-layers with their respective - capabilities and does not require 1:1 equivalence between different - forwarding sub-layer capabilities. + functions as being decomposed into two sub-layers: a service sub- + layer and a forwarding sub-layer. The service sub-layer is used to + provide DetNet service protection and reordering. The forwarding + sub-layer leverages Traffic Engineering mechanisms and provides + congestion protection (low loss, assured latency, and limited out-of- + order delivery). A particular forwarding sub-layer may have + capabilities that are not available on other forwarding-sub layers. + DetNet makes use of the existing forwarding sub-layers with their + respective capabilities and does not require 1:1 equivalence between + different forwarding sub-layer capabilities. As part of the service sub-layer functions, this document describes typical DetNet node data plane operation. It describes the functionality and operation of the Packet Replication (PRF), Packet Elimination (PEF), and the Packet Ordering (POF) functions within the service sub-layer. Furthermore, it describes the forwarding sub- layer. As defined in [RFC8655], DetNet flows may be carried over network technologies that can provide the DetNet required service characteristics. For example, DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive Network (TSN) [IEEE802.1TSNTG] sub- networks. However, IEEE 802.1 TSN support is not required in DetNet. TSN frame preemption is an example of a forwarding layer capability that is typically not replicated in other forwarding technologies. Most of DetNet benefits can be gained by running over a data link layer that has not been specifically enhanced to support all TSN - capabilities but for certain networks and traffic mixes delay and - jitter performance may vary due to the forwarding sub-layer intrinsic + capabilities but for such networks and traffic mixes delay and jitter + performance may vary due to the forwarding sub-layer intrinsic properties. Different application flows, such as Ethernet or IP, can be mapped on top of DetNet. DetNet can optionally reuse header information provided by, or shared with, applications. An example of shared header fields can be found in [I-D.ietf-detnet-ip]. This document also covers basic concepts related to the controller plane and Operations, Administration, and Maintenance (OAM). Data plane OAM specifics are out of scope for this document. @@ -220,57 +221,57 @@ The forwarding sub-layer provides the QoS related functions needed by the DetNet flow. It may do this directly through the use of queuing techniques and traffic engineering methods, or it may do this through the assistance of its underlying connectivity. For example it may call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN [IEEE802.1TSNTG]. The forwarding sub-layer uses buffer resources for packet queuing, as well as reservation and allocation of bandwidth capacity resources. The service sub-layer provides additional support beyond the - connectivity function of the forwarding sub-layer. An example of - this is Packet Replication, Elimination, and Ordering functions see - Section 4.3. The ordering function (POF) uses sequence numbers added + connectivity function of the forwarding sub-layer. See Section 4.3 + as an example for Packet Replication, Elimination, and Ordering + functions. The ordering function (POF) uses sequence numbers added to packets enabling a range of packet order protection from simple ordering and dropping out-of-order packets to more complex reordering of a fixed number of out-of-order, minimally delayed packets. Reordering requires buffer resources and has impact on the delay and jitter of packets in the DetNet flow. The method of instantiating each of the layers is specific to the particular DetNet data plane method, and more than one approach may - be applicable to a given bearer network type. + be applicable to a given network type. 3.1. Data Plane Characteristics There are two major characteristics to the data plane: the technology and the encapsulation, as discussed below. 3.1.1. Data Plane Technology The DetNet data plane is provided by the DetNet service and forwarding sub layers. The DetNet service sub-layer generally provides its functions for the DetNet application flows by using or applying existing standardized headers and/or encapsulations. The Detnet forwarding sub-layer may provide capabilities leveraging that same header or encapsulation technology (e.g., DN IP or DN MPLS) or - it may be achieved by other technologies (e.g., Figure 2). DetNet is - currently defined for operation over packet-switched (IP) networks or - label-switched (MPLS) networks. + it may be achieved by other technologies as shown in Figure 2. + DetNet is currently defined for operation over packet-switched (IP) + networks or label-switched (MPLS) networks. 3.1.2. Encapsulation DetNet encodes specific flow attributes (flow identity and sequence number) in packets. For example, in DetNet IP, zero encapsulation is used and no sequence number is available, and in DetNet MPLS, DetNet- specific information may be added explicitly to the packets in the - format of S-label and d-CW [I-D.ietf-detnet-mpls] . + form of S-label and d-CW [I-D.ietf-detnet-mpls] . The encapsulation of a DetNet flow allows it to be sent over a data plane technology other than its native type. DetNet uses header information to perform traffic classification, i.e., identify DetNet flows, and provide DetNet service and forwarding functions. As mentioned above, DetNet may add headers, as is the case for DN MPLS, or may use headers that are already present, as is the case in DN IP. Figure 2 illustrates some relationships between the components. +-----+ @@ -296,24 +297,24 @@ 3.2. DetNet-specific Metadata The DetNet data plane can provide or carry the following metadata: 1. Flow-ID 2. Sequence Number The DetNet data plane framework supports a Flow-ID (for identification of the flow or aggregate flow) and/or a Sequence - Number (for PREOF) for each DetNet flow. The DetNet Service sub- - layer requires both; the DetNet forwarding sub-layer requires only - Flow-ID. Metadata can also be used for OAM indications and - instrumentation of DetNet data plane operation. + Number (for PREOF) for each DetNet flow. The Flow-ID is used by both + the service and forwarding sub-layers, but the sequence number is + only used by the service layer. Metadata can also be used for OAM + indications and instrumentation of DetNet data plane operation. Metadata inclusion can be implicit or explicit. Explicit inclusions involve a dedicated header field that is used to include metadata in a DetNet packet. In the implicit method, part of an already existing header field is used to encode the metadata. Explicit inclusion of metadata is possible through the use of IP options or IP extension headers. New IP options are almost impossible to get standardized or to deploy in an operational network and will not be discussed further in this text. IPv6 extensions @@ -329,24 +330,24 @@ [I-D.ietf-detnet-mpls-over-udp-ip]. This is described in more detail in Section 3.5.5. Implicit metadata in IP can be included through the use of the network programming paradigm [I-D.ietf-spring-srv6-network-programming] in which the suffix of an IPv6 address is used to encode additional information for use by the network of the receiving host. - Some MPLS examples of implicit metadata include the sequence number - for use by the PREOF function, or even all the essential information - being included into the DetNet over MPLS label stack (the DetNet - Control Word and the DetNet Service label). + An MPLS example of explicit metadata is the sequence number used by + the PREOF function, or even the case where all the essential + information being included into the DetNet over MPLS label stack (the + DetNet Control Word and the DetNet Service label). 3.3. DetNet IP Data Plane An IP data plane may operate natively or through the use of an encapsulation. Many types of IP encapsulation can satisfy DetNet requirements and it is anticipated that more than one encapsulation may be deployed, for example GRE, IPSec. One method of operating an IP DetNet data plane without encapsulation is to use "6-tuple" based flow identification, where "6-tuple" refers @@ -452,24 +453,24 @@ and traffic loads, Network Coding can be used to improve a network's throughput, efficiency, latency, and scalability, as well as resilience to partition, attacks, and eavesdropping, as compared to traditional methods. DetNet could use Network coding as an alternative to other protection means. Network coding is often applied in wireless networks and is being explored for other network types. 3.5.1.5. Load sharing - Use of packet-by-packet distribution of the same DetNet flow over + Use of packet-by-packet load sharing of the same DetNet flow over multiple paths is not recommended except for the cases listed above where PREOF is utilized to improve protection of traffic and maintain - order. Packet by packet load sharing, e.g., via ECMP or UCMP, + order. Packet-by-packet load sharing, e.g., via ECMP or UCMP, impacts ordering and possibly jitter. 3.5.1.6. Troubleshooting Detnet leverages many different forwarding sub-layers, each of which supports various tools to troubleshoot connectivity, for example identification of misbehaving flows. The DetNet Service layer can leverage existing mechanisms to troubleshoot or monitor flows, such as those in use by IP and MPLS networks. At the Application layer a client of a DetNet service can use existing techniques to detect and @@ -608,23 +609,23 @@ added is implementation and technology specific. DetNet flows at edges must be able to handle rejection to an aggregation group due to lack of resources as well as conditions where requirements are not satisfied. 3.5.3.1. IP Aggregation IP aggregation has both data plane and controller plane aspects. For the data plane, flows may be aggregated for treatment based on shared - characteristics such as 6-tuple. Alternatively, an IP encapsulation - may be used to tunnel an aggregate number of DetNet Flows between - relay nodes. + characteristics such as 6-tuple [I-D.ietf-detnet-ip]. Alternatively, + an IP encapsulation may be used to tunnel an aggregate number of + DetNet Flows between relay nodes. 3.5.3.2. MPLS Aggregation MPLS aggregation also has data plane and controller plane aspects. MPLS flows are often tunneled in a forwarding sub-layer, under the reservation associated with that MPLS tunnel. 3.5.4. End-System-Specific Considerations Data-flows requiring DetNet service are generated and terminated on @@ -746,29 +747,30 @@ [I-D.ietf-detnet-flow-information-model], etc.) or hybrid combinations of the two, and could also make use of MPLS-based segment routing. In the abstract, the results of either distributed signaling or centralized provisioning are equivalent from a DetNet data plane perspective - flows are instantiated, explicit routes are determined, resources are reserved, and packets are forwarded through the domain using the DetNet data plane. - However, from a practical and implementation standpoint, they are not - equivalent at all. Some approaches are more scalable than others in - terms of signaling load on the network. Some can take advantage of - global tracking of resources in the DetNet domain for better overall - network resource optimization. Some are more resilient than others - if link, node, or management equipment failures occur. While a - detailed analysis of the control plane alternatives is out of the - scope of this document, the requirements from this document can be - used as the basis of a later analysis of the alternatives. + However, from a practical and implementation standpoint, controller + plane alternatives are not equivalent at all. Some approaches are + more scalable than others in terms of signaling load on the network. + Some alternatives can take advantage of global tracking of resources + in the DetNet domain for better overall network resource + optimization. Some solutions are more resilient than others if link, + node, or management equipment failures occur. While a detailed + analysis of the control plane alternatives is out of the scope of + this document, the requirements from this document can be used as the + basis of a later analysis of the alternatives. 4.2. Generic Controller Plane Considerations This section covers control plane considerations that are independent of the data plane technology used for DetNet service delivery. While the management plane and control planes are traditionally considered separately, from the data plane perspective there is no practical difference based on the origin of flow provisioning information, and the DetNet architecture [RFC8655] refers to these @@ -825,21 +827,21 @@ are updated and distributed in the databases, preventing over- subscription. 4.2.2. Explicit Routes Explicit routes are used to ensure that packets are routed through the resources that have been reserved for them, and hence provide the DetNet application with the required service. A requirement for the DetNet Controller Plane will be the ability to assign a particular identified DetNet IP flow to a path through the DetNet domain that - has been assigned the required nodal resources. This provides the + has been assigned the required per-node resources. This provides the appropriate traffic treatment for the flow and also includes particular links as a part of the path that are able to support the DetNet flow. For example, by using IEEE 802.1 TSN links (as discussed in [I-D.ietf-detnet-mpls-over-tsn] ) DetNet parameters can be maintained. Further considerations and requirements for the DetNet Controller Plane are discussed in Section 4.1. Whether configuring, calculating and instantiating these routes is a single-stage or multi-stage process, or in a centralized or distributed manner, is out of scope of this document. @@ -855,22 +857,23 @@ o The path could use a distributed control plane such as RSVP [RFC2205] or RSVP-TE [RFC3473] extended to support DetNet IP flows. o The path could be implemented using IPv6-based segment routing when extended to support resource allocation. See Section 4.1 for further discussion of these alternatives. In addition, [RFC2386] contains useful background information on QoS- - based routing, and [RFC5575] discusses a specific mechanism used by - BGP for traffic flow specification and policy-based routing. + based routing, and [RFC5575] (being updated by + [I-D.ietf-idr-rfc5575bis]) discusses a specific mechanism used by BGP + for traffic flow specification and policy-based routing. 4.2.3. Contention Loss and Jitter Reduction As discussed in Section 1, this document does not specify the mechanisms needed to eliminate packet contention, packet loss or reduce jitter for DetNet flows at the DetNet forwarding sub-layer. The ability to manage node and link resources to be able to provide these functions is a necessary part of the DetNet controller plane. It is also necessary to be able to control the required queuing mechanisms used to provide these functions along a flow's path @@ -930,44 +933,45 @@ this document. Example control plane solutions for MPLS can be found in [RFC3473] , [RFC6387] and [RFC7551]. These requirements are included in Section 4.1. 4.3. Packet Replication, Elimination, and Ordering (PREOF) The controller plane protocol solution required for managing the PREOF processing is outside the scope of this document. That said, it should be noted that the ability to determine, for a particular flow, optimal packet replication and elimination points in the DetNet - domain requires explicit support. There may be capabilities that can - be used, or extended, for example GMPLS end-to-end recovery [RFC4872] - and GMPLS segment recovery [RFC4873]. + domain requires explicit support. There may be existing capabilities + that can be used, or extended, for example GMPLS end-to-end recovery + [RFC4872] and GMPLS segment recovery [RFC4873]. 5. Security Considerations Security considerations for DetNet are described in detail in [I-D.ietf-detnet-security]. General security considerations for DetNet architecture are described in [RFC8655]. This section - considers general security considerations applicable to all data - planes. + considers architecture-level DetNet security considerations + applicable to all data planes. - 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. + Part of what makes DetNet unique is its ability to provide specific + and reliable quality of service (delivering data flows with extremely + low packet loss rates and bounded end-to-end delivery latency), and + the security-related aspects of protecting that quality of service + are similarly unique. - The primary consideration 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 Ethernet (Layer-2) flows. + As for all communications protocols, the primary consideration 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 Ethernet (Layer-2) flows. 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, @@ -1001,36 +1005,20 @@ The following people contributed substantially to the content of this document: Don Fedyk Jouni Korhonen 9. References 9.1. Normative References - [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., - and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP - Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, - . - - [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label - Switching (GMPLS) Signaling Resource ReserVation Protocol- - Traffic Engineering (RSVP-TE) Extensions", RFC 3473, - DOI 10.17487/RFC3473, January 2003, - . - - [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, - "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for - Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, - February 2006, . - [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . 9.2. Informative References [I-D.ietf-detnet-flow-information-model] Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- @@ -1057,20 +1045,26 @@ Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, "DetNet Data Plane: MPLS over UDP/IP", draft-ietf- detnet-mpls-over-udp-ip-05 (work in progress), February 2020. [I-D.ietf-detnet-security] Mizrahi, T. and E. Grossman, "Deterministic Networking (DetNet) Security Considerations", draft-ietf-detnet- security-09 (work in progress), March 2020. + [I-D.ietf-idr-rfc5575bis] + Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. + Bacher, "Dissemination of Flow Specification Rules", + draft-ietf-idr-rfc5575bis-24 (work in progress), April + 2020. + [I-D.ietf-pce-pcep-extension-for-pce-controller] Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- extension-for-pce-controller-04 (work in progress), March 2020. [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", @@ -1093,29 +1087,45 @@ [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, DOI 10.17487/RFC2386, August 1998, . + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + . + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation Protocol- + Traffic Engineering (RSVP-TE) Extensions", RFC 3473, + DOI 10.17487/RFC3473, January 2003, + . + [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, "Information Model for Describing Network Device QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, January 2004, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . + [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, + "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for + Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, + February 2006, . + [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, . [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, .