--- 1/draft-ietf-detnet-tsn-vpn-over-mpls-01.txt 2020-03-06 09:16:21.985977065 -0800 +++ 2/draft-ietf-detnet-tsn-vpn-over-mpls-02.txt 2020-03-06 09:16:22.481989659 -0800 @@ -1,24 +1,24 @@ DetNet B. Varga, Ed. Internet-Draft J. Farkas Intended status: Standards Track Ericsson -Expires: April 29, 2020 A. Malis +Expires: September 7, 2020 A. Malis Independent S. Bryant Futurewei Technologies D. Fedyk LabN Consulting, L.L.C. - October 27, 2019 + March 6, 2020 DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS - draft-ietf-detnet-tsn-vpn-over-mpls-01 + draft-ietf-detnet-tsn-vpn-over-mpls-02 Abstract This document specifies the Deterministic Networking data plane when TSN networks are interconnected over a DetNet MPLS Network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -26,25 +26,25 @@ 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. + This Internet-Draft will expire on September 7, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + 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 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 @@ -58,63 +58,60 @@ 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4 4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7 5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8 5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8 5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 9 5.3. Edge Node DetNet Service and Forwarding Sub-Layer - Procedures . . . . . . . . . . . . . . . . . . . . . . . 9 - 6. Controller Plane (Management and Control) Considerations . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 10.2. Informative References . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Controller Plane (Management and Control) Considerations . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 10.2. Informative References . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1 Working Group deals with deterministic services through IEEE 802 networks. Deterministic Networking (DetNet) defined by IETF is a service that can be offered by a L3 network to DetNet flows. General - background and concepts of DetNet can be found in - [I-D.ietf-detnet-architecture]. + background and concepts of DetNet can be found in [RFC8655]. This document specifies the use of a DetNet MPLS network to interconnect TSN nodes/network segments. DetNet MPLS data plane is defined in [I-D.ietf-detnet-mpls]. 2. Terminology 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 + DetNet architecture [RFC8655] and [I-D.ietf-detnet-data-plane-framework], and [I-D.ietf-detnet-mpls]. The reader is assumed to be familiar with these documents and their terminology. 2.2. Abbreviations The following abbreviations are used in this document: AC Attachment Circuit. CE Customer Edge equipment. - CoS Class of Service. - CW Control Word. DetNet Deterministic Networking. DF DetNet Flow. FRER Frame Replication and Elimination for Redundancy (TSN function). L2 Layer 2. @@ -124,42 +121,30 @@ L3 Layer 3. LSR Label Switching Router. MPLS Multiprotocol Label Switching. MPLS-TE Multiprotocol Label Switching - Traffic Engineering. MPLS-TP Multiprotocol Label Switching - Transport Profile. - MS-PW Multi-Segment PseudoWire (MS-PW). - NSP Native Service Processing. OAM Operations, Administration, and Maintenance. PE Provider Edge. - PEF Packet Elimination Function. - - PRF Packet Replication Function. - PREOF Packet Replication, Elimination and Ordering Functions. - POF Packet Ordering Function. - - PSN Packet Switched Network. - PW PseudoWire. - QoS Quality of Service. - S-PE Switching Provider Edge. T-PE Terminating Provider Edge. TSN Time-Sensitive Network. 2.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and @@ -324,55 +309,106 @@ DetNet MPLS scenario follows the concept of [RFC3985] and covers the Edge Nodes components shown on Figure 1. In this section the following procedures of DetNet Edge Nodes are described: o TSN related (Section 5.1) o DetNet Service Proxy (Section 5.2) o DetNet service and forwarding sub-layer (Section 5.3) + The sub-sections describe procedures for forwarding packets by DetNet + Edge nodes, where such packets are received from either directly + connected CEs (TSN nodes) or some other DetNet Edge nodes. + 5.1. Edge Node TSN Procedures The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 Working Group have defined (and are defining) a number of amendments to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB] defines packet replication and elimination functions for a TSN network. - TSN specific functions are executed on the data received by the PE - from the CE before presentation to the DetNet PW for transmission - across the DetNet domain, or on the data received from a DetNet PW by - a PE before it is output on the Attachment Circuit (AC). + TSN specific functions are executed on the data received by the + DetNet Edge Node from the connected CE before forwarded to connected + CE(s) or presentation to the DetNet Service Proxy function for + transmission across the DetNet domain, or on the data received from a + DetNet PW by a PE before it is output on the Attachment Circuit(s) + (AC). TSN specific function(s) of Edge Nodes (T-PE) are belonging to the native service processing (NSP) [RFC3985] block. This is similar to other functionalities being defined by standard bodies other than the IETF (for example in case of Ethernet: stripping, overwriting or adding VLAN tags, etc.). Depending on the TSN role of the Edge Node in the end-to-end TSN service selected TSN functions must be supported. + When a PE receives a packet from a CE, on a given AC with DetNet + service, it MUST first check via Stream Identification whether the + packet belongs to a configured TSN Stream (i.e., App-flow from DetNet + perspective). If no Stream ID is matched and no other (VPN) service + is configured for the AC then packet MUST be dropped. If there is a + matching TSN Stream then the Stream-ID specific TSN functions MUST be + executed (e.g., ingress policing, header field manipulation in case + of active Stream Identification, FRER, etc.). Source MAC lookup MAY + also be used for local MAC address learning. + + If the PE decides to forward the packet, the packet MUST be forwarded + according to the TSN Stream specific configuration to connected CE(s) + (in case of local bridging) and/or to the DetNet Service Proxy (in + case of forwarding to remote CE(s) required). If there are no TSN + Stream specific forwarding configurations the PE MUST flood the + packet to other locally attached CE(s) and to the DetNet Service + Proxy. If the administrative policy on the PE does not allow + flooding the PE MUST drop the packet. + + When a TSN entity of the PE receives a packet from the DetNet Service + Proxy, it MUST first check via Stream Identification whether the + packet belongs to a configured TSN Stream. If no Stream ID is + matched then packet MUST be dropped. If there is a matching TSN + Stream then the Stream ID specific TSN functions MUST be executed + (e.g., header field manipulation in case of active Stream + Identification, FRER, etc.). Source MAC lookup MAY also be used for + local MAC address learning. + + If the PE decides to forward the packet, the packet MUST be forwarded + according to the TSN Stream specific configuration to connected + CE(s). If there are no TSN Stream specific forwarding configurations + the PE MUST flood the packet to locally attached CE(s). If the + administrative policy on the PE does not allow flooding the PE MUST + drop the packet. + Implementations of this document SHALL use management and control information to ensure TSN specific functions of the Edge Node according to the expectations of the connected TSN network. 5.2. Edge Node DetNet Service Proxy Procedures The Service Proxy function maps between App-flows and DetNet flows. - The DetNet Edge Node TSN function MUST support the TSN Stream + The DetNet Edge Node TSN entity MUST support the TSN Stream identification functions and the related managed objects as defined in IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb] to recognize the App-flow related packets. The Service Proxy presents TSN Streams as an App-flow to a DetNet Flow. + When a DetNet Service Proxy receives a packet from the TSN Entity it + MUST check whether such an App-flow is present in its mapping table. + If present it associates the internal DetNet flow-ID to the packet + and MUST forward it to the DetNet Service and Forwarding sub-layers. + If no matching statement is present it MUST drop the packet. + + When a DetNet Service Proxy receives a packet from the DetNet Service + and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN + Entity. + Implementations of this document SHALL use management and control information to map a TSN Stream to a DetNet flow. N:1 mapping (aggregating multiple TSN Streams in a single DetNet flow) SHALL be supported. The management or control function that provisions flow mapping SHALL ensure that adequate resources are allocated and configured to provide proper service requirements of the mapped flows. Due to the (intentional) similarities of the DetNet PREOF and TSN FRER functions service protection function interworking is possible @@ -395,26 +431,38 @@ [I-D.ietf-detnet-mpls] two sequence number sizes are supported: a 16 bit sequence number and a 28 bit sequence number. PREOF functions and the provided service recovery is available only within the DetNet domain as the DetNet flow-ID and the DetNet sequence number are not valid outside the DetNet network. MPLS (DetNet) Edge node terminates all related information elements encoded in the MPLS labels. The LSP used to forward the DetNet packet may be of any type (MPLS- - LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR - [I-D.ietf-spring-segment-routing-mpls]). The LSP (F-Label) label - and/or the S-Label may be used to indicate the queue processing as - well as the forwarding parameters. + LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR [RFC8660]). The LSP + (F-Label) label and/or the S-Label may be used to indicate the queue + processing as well as the forwarding parameters. - For further details see [I-D.ietf-detnet-mpls]. + When a PE receives a packet from the Service Proxy function it MUST + add to the packet the DetNet flow-ID specific S-label and create a + d-CW. The PE MUST forward the packet according to the configured + DetNet Service and Forwarding sub-layer rules to other PE nodes. + + When a PE receives an MPLS packet from a remote PE, then, after + processing the MPLS label stack, if the top MPLS label ends up being + a DetNet S-label that was advertised by this node, then the PE MUST + forward the packet according to the configured DetNet Service and + Forwarding sub-layer rules to other PE nodes or via the Detnet + Service Proxy function towards locally connected CE(s). + + For further details on DetNet Service and Forwarding sub-layers see + [I-D.ietf-detnet-mpls]. 6. Controller Plane (Management and Control) Considerations TSN Stream(s) to DetNet flow mapping related information are required only for the service proxy function of MPLS (DetNet) Edge nodes. From the Data Plane perspective there is no practical difference based on the origin of flow mapping related information (management plane or control plane). MPLS DetNet Edge nodes are member of both the DetNet domain and the @@ -460,87 +508,76 @@ Configuration of TSN specific functions (e.g., FRER) inside the TSN network is a TSN domain specific decision and may not be visible in the DetNet domain. Service protection interworking scenarios are left for further study. 7. 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]. DetNet MPLS data plane - specific considerations are summarized in [I-D.ietf-detnet-mpls]. - 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. + described in [RFC8655]. DetNet MPLS data plane specific + considerations are summarized in [I-D.ietf-detnet-mpls]. 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. 8. IANA Considerations This document makes no IANA requests. 9. Acknowledgements The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, Christophe Mangin and Jouni Korhonen for their various contributions to this work. 10. References 10.1. Normative References + [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-05 (work in progress), February + 2020. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References - [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-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-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. + Varga, B., Farkas, J., Berger, L., Malis, A., and S. + Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- + data-plane-framework-04 (work in progress), February 2020. [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. - - [I-D.ietf-spring-segment-routing-mpls] - Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., - Litkowski, S., and R. Shakir, "Segment Routing with MPLS - data plane", draft-ietf-spring-segment-routing-mpls-22 - (work in progress), May 2019. + J., Austad, H., and N. Finn, "Deterministic Networking + (DetNet) Security Considerations", draft-ietf-detnet- + security-08 (work in progress), February 2020. [IEEE802.1AE-2018] IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC Security (MACsec)", 2018, . [IEEE8021CB] Finn, N., "Draft Standard for Local and metropolitan area networks - Seamless Redundancy", IEEE P802.1CB /D2.1 P802.1CB, December 2015, @@ -565,20 +602,31 @@ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, . + [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, + "Deterministic Networking Architecture", RFC 8655, + DOI 10.17487/RFC8655, October 2019, + . + + [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., + Decraene, B., Litkowski, S., and R. Shakir, "Segment + Routing with the MPLS Data Plane", RFC 8660, + DOI 10.17487/RFC8660, December 2019, + . + Authors' Addresses Balazs Varga (editor) Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: balazs.a.varga@ericsson.com Janos Farkas