DetNet Working Group A. Malis Internet-Draft S. Bryant Intended status: Standards Track M. Chen Expires: September 6, 2018 Huawei Technologies B. Varga Ericsson March 05, 2018 DetNet IP Encapsulation draft-malis-detnet-ip-dp-00 Abstract This document specifies Deterministic Networking data plane operation over an IP network. It is primarily aimed at IPv4, but would work with IPv6 as well if a unified solution is desired. This document is a derivative work from draft-ietf-detnet-dp-sol-01, to augment or replace the text currently contained in section 5.2.2. Whether this is published as a stand-alone text, or serves as a focal point to refine the IP design and subsequently remerged with draft- ietf-detnet-dp-sol-01 is a matter for the DETNET WG. 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 September 6, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Malis, et al. Expires September 6, 2018 [Page 1] Internet-Draft DetNet IP March 2018 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms used in this document . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements language . . . . . . . . . . . . . . . . . . . . 3 4. DetNet Over an IP Network . . . . . . . . . . . . . . . . . . 3 5. DetNet over IP Encapsulation . . . . . . . . . . . . . . . . 5 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction This document is a derivative work from [I-D.ietf-detnet-dp-sol]. Whether this is published as a stand-alone text, or serves as a focal point to refine the IP design and subsequently remerged with draft- ietf-detnet-dp-sol-01 is a matter for the DetNet WG. 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 [I-D.ietf-detnet-architecture]. This document specifies the encapsulation and operation of deterministic networking over an IP data-plane. The approach is modeled on the operation of PseudoWires (PW) over an IP Packet Switched Network (PSN) [RFC3985][RFC4385][RFC7510]. It is based on the "simplified model" discussed during the DetNet Interim Meeting held on 14 February 2018 Malis, et al. Expires September 6, 2018 [Page 2] Internet-Draft DetNet IP March 2018 [http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018- detnet-03]. It is also based on the MPLS encapsulation described in draft-bryant- detnet-mpls-dp (this reference to be updated once draft is available). The DetNet transport layer functionality that provides congestion protection for DetNet flows is assumed to be in place in a DetNet node. This document does not currently define the associated control plane functions, or Operations, Administration, and Maintenance (OAM). It also does not currently specify traffic handling capabilities required to deliver congestion protection and latency control for DetNet flows at the DetNet transport layer. These aspects may be included in future revisions of this draft, or in other DetNet documents. 2. Terminology 2.1. Terms used in this document This document uses the same terminology as [I-D.ietf-detnet-dp-sol]. Please see that document for the definitions. 2.2. Abbreviations This document uses the same abbreviations as [I-D.ietf-detnet-dp-sol]. Please see that document for the list of abbreviations. 3. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. DetNet Over an IP Network The "simplified model" of DetNet, as discussed during the interim meeting, is carried over an IP network is shown in Figure 1: Malis, et al. Expires September 6, 2018 [Page 3] Internet-Draft DetNet IP March 2018 DetNet Edge Transit Relay Edge DetNet End Sys Node Node Node Node End Sys +-----+ End to End Service +-----+ |Appln|<..............................................>|Appln| +-----+ +---------+ DN Flow +---------+ +---------+ +-----+ | TSN | | Service |<------->| Service |--| Service | | TSN | +-----+ +---+ +---+ +-----+ +---+ +---+ +---+ +---+ +-----+ |DNXpt| |Xpt| |Xpt| |IPXpt| |Xpt| |Xpt| |Xpt| |Xpt| |DNXpt| +--.--+ +-.-+ +-.-+ +-.-.-+ +-.-+ +-.-+ +-.-+ +-.-+ +--.--+ : : : : :Link : :Link : : : +-------+ /-------\+-----+ +------+ /-------\ TSN |Sub N/W| |TSN N/W| Link \-------/ \-------/ Figure 1: Simplified Model of a DetNet Enabled Network In this figure, "DNXpt" and "Xpt" are abbreviations for "DetNet Transport" and "IPXpt" is an abbreviation for "IP Transport". DetNet End Systems sent and receive packets over the DetNet. The supported packet types are IP and Ethernet. Note that in the Simplified Model, while the DetNet service is end- to-end, the End Systems are not DetNet-aware and do not include DetNet information to their packet headers. Rather, the packets between the End Systems and the Edge Nodes may typically consist of application information, L4 Transport (such as TCP or UDP), IP, and Ethernet headers, transmitted over a TSN link or (sub)-Network between the End System and the Edge Node. Alternatively, the packets could contain Ethernet-native applications, with the application information directly encapsulated within Ethernet without L4 Transport or IP headers. Because the End Systems are not DetNet-aware, Edge Nodes are responsible for the imposition and disposition of the required DetNet encapsulation. This functionality is similar to that in pseudowire (PW) Provider Edge (PE) routers. Relay Nodes are also strategically placed and used enhance the reliability of delivery by enabling the DetNet-layer replication of packets so that multiple copies, possibly over multiple paths. They also reduce the impact of replication by the eliminating surplus copies of DetNet packets. These functions may not be performed in End Systems, as they are not DetNet-aware. Malis, et al. Expires September 6, 2018 [Page 4] Internet-Draft DetNet IP March 2018 Relay Nodes are aware of the needs of particular DetNet flows and take care to process them in accordance with the required performance needs. Transit nodes are normal IP routers. They are unaware of DetNet flows per se, although they may be configured to provide congestion protection and delay control in order to meet the required DetNet service level agreement (SLA) via non-DetNet-specific means (IP traffic engineering, queuing mechanisms based on DiffServ markings, etc.). 5. DetNet over IP Encapsulation To carry DetNet over IP the following is required: 1. A method of identifying the DetNet flow to the processing element. 2. A method of carrying the DetNet sequence number. These latter two pieces of information are already carried in the DetNet over MPLS Encapsulation, as shown in Figure 1, where the Control Word contains a 28-bit sequence number, and the S-Label is used to identify the particular flow. +---------------------------------+ | | | DetNet Flow | | Payload Packet | | | +---------------------------------+ <--\ | DetNet Control Word | | +---------------------------------+ +--> DetNet data plane | S-Label | | MPLS encapsulation +---------------------------------+ <--/ | T-Label(s) | +---------------------------------+ Figure 2: MPLS Encapsulation of DetNet To simplify operations and implementations, rather than inventing a brand new encapsulation, the IP encapsulation can take advantage of the MPLS encapsulation. By using the specification of MPLS over UDP and IP in [RFC7510], the T-Label(s) in Figure 2 can be replaced by UDP and IP, resulting in the following encapsulation: Malis, et al. Expires September 6, 2018 [Page 5] Internet-Draft DetNet IP March 2018 +---------------------------------+ | | | DetNet Flow | | Payload Packet | | | +---------------------------------+ <--\ | DetNet Control Word | | +---------------------------------+ +--> DetNet data plane | S-Label | | MPLS encapsulation +---------------------------------+ <--/ | UDP Header | +---------------------------------+ | IP Header | +---------------------------------+ Figure 3: IP Encapsulation of DetNet Where the UDP header is used as defined in Section 3 of [RFC7510]. In ingress Edge Nodes, the encapsulation in Figure 3 will be imposed on Detnet Flow Payload Packets as received from DetNet End Systems, and the encapsulation will be removed in egress Edge Nodes as they transmit the Payload Packets to the End Systems. Note that this encapsulation works equally well with IPv4 and IPv6. This encapsulation can also be used in conjunction with segment routing as specified in [I-D.ietf-spring-segment-routing-mpls]. In this case, the T-Label(s) in Figure 2 should be retained, and at each hop, the top T-label is popped and mapped to a corresponding UDP/IP tunnel, resulting in the following encapsulation: Malis, et al. Expires September 6, 2018 [Page 6] Internet-Draft DetNet IP March 2018 +---------------------------------+ | | | DetNet Flow | | Payload Packet | | | +---------------------------------+ <--\ | DetNet Control Word | | +---------------------------------+ +--> DetNet data plane | S-Label | | MPLS encapsulation +---------------------------------+ <--/ | T-Label(s) | +---------------------------------+ | UDP Header | +---------------------------------+ | IP Header | +---------------------------------+ Figure 4: IP Encapsulation of DetNet with MPLS-SR Again, the UDP header is used as defined in Section 3 of [RFC7510]. 6. Security considerations The security considerations of DetNet in general are discussed in [I-D.ietf-detnet-security]. Other security considerations will be added in a future version of this draft. 7. IANA considerations This document makes no IANA requests. 8. Acknowledgements 9. References 9.1. Normative References [I-D.ietf-detnet-dp-sol] Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- sol-01 (work in progress), January 2018. [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-12 (work in progress), February 2018. Malis, et al. Expires September 6, 2018 [Page 7] Internet-Draft DetNet IP March 2018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . 9.2. Informative References [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- detnet-architecture-04 (work in progress), October 2017. [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-01 (work in progress), October 2017. [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 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, . Authors' Addresses Andrew G. Malis Huawei Technologies Email: agmalis@gmail.com Stewart Bryant Huawei Technologies Email: stewart.bryant@gmail.com Malis, et al. Expires September 6, 2018 [Page 8] Internet-Draft DetNet IP March 2018 Mach Chen Huawei Technologies Email: mach.chen@huawei.com Balazs Varga Ericsson Email: balazs.a.varga@ericsson.com Malis, et al. Expires September 6, 2018 [Page 9]