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]