Internet DRAFT - draft-chen-detnet-det-vpn
draft-chen-detnet-det-vpn
Network Working Group Z. Chen
Internet-Draft L. Qiang
Intended status: Informational Huawei
Expires: September 9, 2019 March 8, 2019
Deterministic VPN
draft-chen-detnet-det-vpn-00
Abstract
Deterministic Networking (DetNet) services are expected to be
integrated with VPN technologies. Such deployment scenarios include
mobile backhauls and TSN islands inter-connections. This document
describes an overall VPN framework that provides deterministic
transport services (called deterministic VPN), specifies
corresponding control and data plane protocols that are required to
support the framework, and initially summarizes potential extensions
of existing protocols to enable deterministic VPNs.
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 RFC 2119 [RFC2119].
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 9, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chen & Qiang Expires September 9, 2019 [Page 1]
Internet-Draft Abbreviated-Title March 2019
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. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 3
2.1. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . 3
2.2. Inter-connection of TSN Islands . . . . . . . . . . . . . 3
3. Deterministic VPN Framework . . . . . . . . . . . . . . . . . 4
3.1. Control Plane Protocols . . . . . . . . . . . . . . . . . 5
3.2. Data Plane Protocols . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Deterministic Networking (DetNet) aims to provide bounded latency
transport as well as low data loss rate for specific data flows over
layer-3 networks [arch]. Potential use cases include electrical
utilities, building automation systems, and industrial machine to
machine [use-case]. From the perspective of real-world deployment,
DetNet services are expected to be integrated with VPN technologies,
e.g., MPLS/IP VPN, E-VPN. In particular, one or more VPN instances
of an ISP network are required to provide bounded latency and low
data loss rate transmission services for the customers. Such
deployment scenarios include mobile backhauls and TSN islands inter-
connections.
This document presents an overall VPN framework that provides
deterministic transport services (called deterministic VPN),
specifies corresponding control and data plane protocols that are
required to support the framework, and initially summarizes potential
extensions of existing protocols to enable deterministic VPNs. Note
that specific extensions of existing protocols will be defined by
separated documents.
Chen & Qiang Expires September 9, 2019 [Page 2]
Internet-Draft Abbreviated-Title March 2019
2. Deployment Scenarios
This section introduces deployment scenarios for the deterministic
VPN.
2.1. Mobile Backhaul
In the last decade, IP/MPLS devices are continuously replacing
traditional TDM-based devices in operators' mobile backhaul networks
for the benefits of simplicity and high bandwidth utilization.
However, best effort IP forwarding cannot provide deterministic
transport services as TDM could, making it hard to satisfy user's QoS
requirements. DetNet is expected to fill up this gap.
Simultaneously, layer-2 and layer-3 VPNs are also required in mobile
backhaul networks in order to isolate different PDU sessions.
Therefore, DetNet and VPN might be integrated in mobile backhaul
networks.
The example in Figure 1 further illustrates such scenarios, where
eNodeB and S-GW are connected by multiple IP routers (i.e., IP
backhaul). In this case, a layer-3 or layer-2 deterministic VPN
SHOULD be established between the eNodeB and the S-GW to carry the
GTP-U encapsulation.
+------+ GTP +------+ +------+ +------+ GTP +------+
| |<----->| | | | | |<----->| |
|eNodeB+-------+ IP +-------+ IP +-------+ IP +-------+ S-GW |
| | |Router| |Router| |Router| | |
+------+ +------+ +------+ +------+ +------+
<--------------L2/L3 VPN------------->
Figure 1
2.2. Inter-connection of TSN Islands
Another deployment scenario is using deterministic VPN to connect TSN
islands. In particular, an enterprise may intent to connect its two
(separately located) TSN networks by using an ISP network who can
provide deterministic transport services. Since the ISP may provide
the same service to different enterprises simultaneously, a layer-2
VPN SHOULD be established to isolate the traffic between different
enterprises, as shown in Figure 2.
Chen & Qiang Expires September 9, 2019 [Page 3]
Internet-Draft Abbreviated-Title March 2019
+------+ Eth +------+ +------+ +------+ Eth +------+
| |<----->| | | | | |<----->| |
| TSN +-------+ IP +-------+ IP +-------+ IP +-------+ TSN |
|Switch| |Router| |Router| |Router| |Switch|
+------+ +------+ +------+ +------+ +------+
<----------------L2 VPN-------------->
Figure 2
3. Deterministic VPN Framework
Figure 3 shows the overall framework of deterministic VPN, where CE1
and CE2 could be mobile network elements such as eNodeB, s-GW, or
p-GW, or could be TSN switches of an enterprise network. PE1, P1,
P2, and PE2 are ISP's IP/MPLS (layer-3) devices who have specific
scheduling and shaping capabilities in the data plane thus providing
deterministic transport (or DetNet) services. This document assumes
that the CQF-based mechanism described in [ldn] is running on PE1,
P1, P2 and PE2's data plane.
In this framework, a layer-2 or layer-3 VPN SHOULD be established
between PE1 and PE2 to provide the deterministic transport service
for CE1 and CE2. This requires that 1) data flows between CE1 and
CE2 MUST be forwarded with bounded latency and low loss rate, and 2)
the addresses as well as the traffic among CE1 and CE2 SHOULD be
isolated from other CEs'. Note that although the overall framework
is quite similar with existing VPN frameworks (e.g., IP/MPLS VPN and
E-VPN), extensions of existing protocols are needed to support the
deterministic transport, as will be discussed in the following sub-
sections.
Chen & Qiang Expires September 9, 2019 [Page 4]
Internet-Draft Abbreviated-Title March 2019
<-----------------MP-BGP---------------->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | |
| CE1 +-----+ PE1 +------+ P1 +------+ P2 +-------+ PE2 +------+ CE2 |
| | | |<---->| |<---->| |<----->| | | |
+-----+ +-----+ IGP +-----+ IGP +-----+ IGP +-----+ +-----+
<---------> <---------> <--------->
RSVP-TE RSVP-TE RSVP-TE
<-+-+-+-+-+-+-+-MPLS Tunnel-+-+-+-+-> <--------->
Control Plane
<-+-+-+-+-+-+-SR-MPLS Tunnel-+-+-+-+> <-+-+-+-+->
Data Plane
<-+-+-+-+-+-+-SRv6 Tunnel-+-+-+-+-+->
Figure 3
3.1. Control Plane Protocols
IGP: In the framework described above, IGP protocols such as IS-IS
and OSPF SHOULD be used to advertise underlay reachability
information. In the case where SR-MPLS and SRv6 encapsulations are
chose for data plane tunnels, the IGP protocol SHOULD also advertise
corresponding SIDs. To support deterministic VPN, corresponding
information of deterministic transport, e.g., interface-level
capability of scheduling and shaping, as well as available bandwidth
SHOULD also be advertised by the IGP protocols [igp-te-ext].
MP-BGP: MP-BGP is used to advertise VPN reachability information in
the framework, e.g., IP prefixes for layer-3 VPNs or MAC addresses
for layer-2 VPNs, and corresponding VPN labels, e.g., MPLS labels or
a SRv6 END.DX4 SIDs. To support deterministic VPN, MP-BGP SHOULD be
extended to deliver related information for the deterministic
transport services. Such extensions will be defined in separate
documents.
RSVP-TE: RSVP-TE is used to reserve dedicated resources for the
deterministic VPN flows. In the case where MPLS LSP is chose for the
data plane encapsulation, RSVP-TE will also be used to allocate MPLS
label(s) in each node along the forwarding path. To support
deterministic VPN, RSVP-TE SHOULD be extended to carry relative
information of the deterministic transport services. Such extensions
will be defined in separate documents.
Chen & Qiang Expires September 9, 2019 [Page 5]
Internet-Draft Abbreviated-Title March 2019
3.2. Data Plane Protocols
MPLS LSP Tunnel: If MPLS LSP tunnels are chose to be the data plane
encapsulations for deterministic VPN flows, a mechanism of multiple
MPLS labels per LSP per node SHOULD be used to identify different CQF
forwarding cycles, as per [ldn]. Such mechanism has been described
in [mpls-cqf].
SR-MPLS Tunnel: Accordingly, a SR-MPLS based mechanism to indicate
different forwarding cycles at the data plane will also be specified
in a separate document.
SRv6 Tunnel: Corresponding SRv6 based mechanism will also be
specified in a separate document.
4. IANA Considerations
TBD.
5. Security Considerations
TBD.
6. Acknowledgements
TBD.
7. Normative References
[arch] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", February 2019.
[igp-te-ext]
Geng, X., Chen, M., and Z. Li, "IGP-TE Extensions for
DetNet Information Distribution", October 2018.
[ldn] Qiang, L., Liu, B., Eckert, T., and L. Geng, "Large-Scale
Deterministic Network", March 2019.
[mpls-cqf]
Chen, Z. and L. Qiang, "Multiple MPLS Labels for Cyclic
Forwarding", March 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>.
Chen & Qiang Expires September 9, 2019 [Page 6]
Internet-Draft Abbreviated-Title March 2019
[use-case]
Grossman, E., "Deterministic Networking Use Cases",
December 2018.
Authors' Addresses
Zhe Chen
Huawei
Email: chenzhe17@huawei.com
Li Qiang
Huawei
Email: qiangli3@huawei.com
Chen & Qiang Expires September 9, 2019 [Page 7]
