idnits 2.17.1 draft-chen-detnet-det-vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2019) is 1875 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Chen 3 Internet-Draft L. Qiang 4 Intended status: Informational Huawei 5 Expires: September 9, 2019 March 8, 2019 7 Deterministic VPN 8 draft-chen-detnet-det-vpn-00 10 Abstract 12 Deterministic Networking (DetNet) services are expected to be 13 integrated with VPN technologies. Such deployment scenarios include 14 mobile backhauls and TSN islands inter-connections. This document 15 describes an overall VPN framework that provides deterministic 16 transport services (called deterministic VPN), specifies 17 corresponding control and data plane protocols that are required to 18 support the framework, and initially summarizes potential extensions 19 of existing protocols to enable deterministic VPNs. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 9, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Inter-connection of TSN Islands . . . . . . . . . . . . . 3 65 3. Deterministic VPN Framework . . . . . . . . . . . . . . . . . 4 66 3.1. Control Plane Protocols . . . . . . . . . . . . . . . . . 5 67 3.2. Data Plane Protocols . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Deterministic Networking (DetNet) aims to provide bounded latency 77 transport as well as low data loss rate for specific data flows over 78 layer-3 networks [arch]. Potential use cases include electrical 79 utilities, building automation systems, and industrial machine to 80 machine [use-case]. From the perspective of real-world deployment, 81 DetNet services are expected to be integrated with VPN technologies, 82 e.g., MPLS/IP VPN, E-VPN. In particular, one or more VPN instances 83 of an ISP network are required to provide bounded latency and low 84 data loss rate transmission services for the customers. Such 85 deployment scenarios include mobile backhauls and TSN islands inter- 86 connections. 88 This document presents an overall VPN framework that provides 89 deterministic transport services (called deterministic VPN), 90 specifies corresponding control and data plane protocols that are 91 required to support the framework, and initially summarizes potential 92 extensions of existing protocols to enable deterministic VPNs. Note 93 that specific extensions of existing protocols will be defined by 94 separated documents. 96 2. Deployment Scenarios 98 This section introduces deployment scenarios for the deterministic 99 VPN. 101 2.1. Mobile Backhaul 103 In the last decade, IP/MPLS devices are continuously replacing 104 traditional TDM-based devices in operators' mobile backhaul networks 105 for the benefits of simplicity and high bandwidth utilization. 106 However, best effort IP forwarding cannot provide deterministic 107 transport services as TDM could, making it hard to satisfy user's QoS 108 requirements. DetNet is expected to fill up this gap. 109 Simultaneously, layer-2 and layer-3 VPNs are also required in mobile 110 backhaul networks in order to isolate different PDU sessions. 111 Therefore, DetNet and VPN might be integrated in mobile backhaul 112 networks. 114 The example in Figure 1 further illustrates such scenarios, where 115 eNodeB and S-GW are connected by multiple IP routers (i.e., IP 116 backhaul). In this case, a layer-3 or layer-2 deterministic VPN 117 SHOULD be established between the eNodeB and the S-GW to carry the 118 GTP-U encapsulation. 120 +------+ GTP +------+ +------+ +------+ GTP +------+ 121 | |<----->| | | | | |<----->| | 122 |eNodeB+-------+ IP +-------+ IP +-------+ IP +-------+ S-GW | 123 | | |Router| |Router| |Router| | | 124 +------+ +------+ +------+ +------+ +------+ 126 <--------------L2/L3 VPN-------------> 128 Figure 1 130 2.2. Inter-connection of TSN Islands 132 Another deployment scenario is using deterministic VPN to connect TSN 133 islands. In particular, an enterprise may intent to connect its two 134 (separately located) TSN networks by using an ISP network who can 135 provide deterministic transport services. Since the ISP may provide 136 the same service to different enterprises simultaneously, a layer-2 137 VPN SHOULD be established to isolate the traffic between different 138 enterprises, as shown in Figure 2. 140 +------+ Eth +------+ +------+ +------+ Eth +------+ 141 | |<----->| | | | | |<----->| | 142 | TSN +-------+ IP +-------+ IP +-------+ IP +-------+ TSN | 143 |Switch| |Router| |Router| |Router| |Switch| 144 +------+ +------+ +------+ +------+ +------+ 146 <----------------L2 VPN--------------> 148 Figure 2 150 3. Deterministic VPN Framework 152 Figure 3 shows the overall framework of deterministic VPN, where CE1 153 and CE2 could be mobile network elements such as eNodeB, s-GW, or 154 p-GW, or could be TSN switches of an enterprise network. PE1, P1, 155 P2, and PE2 are ISP's IP/MPLS (layer-3) devices who have specific 156 scheduling and shaping capabilities in the data plane thus providing 157 deterministic transport (or DetNet) services. This document assumes 158 that the CQF-based mechanism described in [ldn] is running on PE1, 159 P1, P2 and PE2's data plane. 161 In this framework, a layer-2 or layer-3 VPN SHOULD be established 162 between PE1 and PE2 to provide the deterministic transport service 163 for CE1 and CE2. This requires that 1) data flows between CE1 and 164 CE2 MUST be forwarded with bounded latency and low loss rate, and 2) 165 the addresses as well as the traffic among CE1 and CE2 SHOULD be 166 isolated from other CEs'. Note that although the overall framework 167 is quite similar with existing VPN frameworks (e.g., IP/MPLS VPN and 168 E-VPN), extensions of existing protocols are needed to support the 169 deterministic transport, as will be discussed in the following sub- 170 sections. 172 <-----------------MP-BGP----------------> 174 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 175 | | | | | | | | | | | | 176 | CE1 +-----+ PE1 +------+ P1 +------+ P2 +-------+ PE2 +------+ CE2 | 177 | | | |<---->| |<---->| |<----->| | | | 178 +-----+ +-----+ IGP +-----+ IGP +-----+ IGP +-----+ +-----+ 180 <---------> <---------> <---------> 181 RSVP-TE RSVP-TE RSVP-TE 183 <-+-+-+-+-+-+-+-MPLS Tunnel-+-+-+-+-> <---------> 184 Control Plane 185 <-+-+-+-+-+-+-SR-MPLS Tunnel-+-+-+-+> <-+-+-+-+-> 186 Data Plane 187 <-+-+-+-+-+-+-SRv6 Tunnel-+-+-+-+-+-> 189 Figure 3 191 3.1. Control Plane Protocols 193 IGP: In the framework described above, IGP protocols such as IS-IS 194 and OSPF SHOULD be used to advertise underlay reachability 195 information. In the case where SR-MPLS and SRv6 encapsulations are 196 chose for data plane tunnels, the IGP protocol SHOULD also advertise 197 corresponding SIDs. To support deterministic VPN, corresponding 198 information of deterministic transport, e.g., interface-level 199 capability of scheduling and shaping, as well as available bandwidth 200 SHOULD also be advertised by the IGP protocols [igp-te-ext]. 202 MP-BGP: MP-BGP is used to advertise VPN reachability information in 203 the framework, e.g., IP prefixes for layer-3 VPNs or MAC addresses 204 for layer-2 VPNs, and corresponding VPN labels, e.g., MPLS labels or 205 a SRv6 END.DX4 SIDs. To support deterministic VPN, MP-BGP SHOULD be 206 extended to deliver related information for the deterministic 207 transport services. Such extensions will be defined in separate 208 documents. 210 RSVP-TE: RSVP-TE is used to reserve dedicated resources for the 211 deterministic VPN flows. In the case where MPLS LSP is chose for the 212 data plane encapsulation, RSVP-TE will also be used to allocate MPLS 213 label(s) in each node along the forwarding path. To support 214 deterministic VPN, RSVP-TE SHOULD be extended to carry relative 215 information of the deterministic transport services. Such extensions 216 will be defined in separate documents. 218 3.2. Data Plane Protocols 220 MPLS LSP Tunnel: If MPLS LSP tunnels are chose to be the data plane 221 encapsulations for deterministic VPN flows, a mechanism of multiple 222 MPLS labels per LSP per node SHOULD be used to identify different CQF 223 forwarding cycles, as per [ldn]. Such mechanism has been described 224 in [mpls-cqf]. 226 SR-MPLS Tunnel: Accordingly, a SR-MPLS based mechanism to indicate 227 different forwarding cycles at the data plane will also be specified 228 in a separate document. 230 SRv6 Tunnel: Corresponding SRv6 based mechanism will also be 231 specified in a separate document. 233 4. IANA Considerations 235 TBD. 237 5. Security Considerations 239 TBD. 241 6. Acknowledgements 243 TBD. 245 7. Normative References 247 [arch] Finn, N., Thubert, P., Varga, B., and J. Farkas, 248 "Deterministic Networking Architecture", February 2019. 250 [igp-te-ext] 251 Geng, X., Chen, M., and Z. Li, "IGP-TE Extensions for 252 DetNet Information Distribution", October 2018. 254 [ldn] Qiang, L., Liu, B., Eckert, T., and L. Geng, "Large-Scale 255 Deterministic Network", March 2019. 257 [mpls-cqf] 258 Chen, Z. and L. Qiang, "Multiple MPLS Labels for Cyclic 259 Forwarding", March 2019. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, 263 DOI 10.17487/RFC2119, March 1997, 264 . 266 [use-case] 267 Grossman, E., "Deterministic Networking Use Cases", 268 December 2018. 270 Authors' Addresses 272 Zhe Chen 273 Huawei 275 Email: chenzhe17@huawei.com 277 Li Qiang 278 Huawei 280 Email: qiangli3@huawei.com