Internet DRAFT - draft-dong-rtgwg-enhanced-vpn-protocol
draft-dong-rtgwg-enhanced-vpn-protocol
Routing Area Working Group J. Dong
Internet-Draft S. Bryant
Intended status: Standards Track Huawei Technologies
Expires: May 3, 2018 October 30, 2017
Protocol Considerations for Enhanced VPN
draft-dong-rtgwg-enhanced-vpn-protocol-00
Abstract
This document describes the candidate protocol mechanisms which may
be used to meet the requirements of enhanced virtual private networks
(VPN+). The gaps and limitations of existing mechanisms are
analyzed, then a proposed mechanism is briefly described. The
proposed mechanism can be used to achieve network slicing to meet the
stringent requirement of emerging 5G services, but it can also be
useful in other general network scenarios.
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 May 3, 2018.
Copyright Notice
Copyright (c) 2017 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
Dong & Bryant Expires May 3, 2018 [Page 1]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Role of the Underlay and Overlay . . . . . . . . . . . . . . 3
4. Considerations about Network Isolation . . . . . . . . . . . 3
4.1. Data Plane Isolation . . . . . . . . . . . . . . . . . . 4
4.2. Control Plane Isolation . . . . . . . . . . . . . . . . . 4
5. Analysis of Existing Mechanisms . . . . . . . . . . . . . . . 5
5.1. Overlay Virtual Networks . . . . . . . . . . . . . . . . 5
5.2. Multiple-Topology Routing and Segment Routing . . . . . . 6
6. Proposed Mechanism . . . . . . . . . . . . . . . . . . . . . 6
6.1. Per-link/Node Resource Partitioning . . . . . . . . . . . 7
6.2. Construction of Isolated Logical Networks . . . . . . . . 8
6.3. Mapping Service to Logical Network . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Virtual networks, often referred to as virtual private networks
(VPNs) have been widely deployed to provide different groups of users
with logically isolated access to a common network. The common
network that is used to provide the VPNs is often referred to as the
underlay, and the VPN is often called an overlay.
As described in [I-D.bryant-rtgwg-enhanced-vpn], the enhanced virtual
private networks (VPN+) refers to a virtual network which has
dedicated network resources allocated from the underlay network, so
that can achieve greater isolation and guaranteed performance than
traditional VPNs. VPN+ aims to provide a set of enhancements to
existing VPN services, among which greater isolation is one of the
key requirements of many emerging services, such as financial and
vertical industrial services. Apparently such level of isolation
cannot be met with pure overlay networks, as it requires tighter
coordination and integration between the overlay and the underlay
network, also it may rely on necessary enhancements to both the data
plane and control plane of networks.
This document describes the candidate protocol mechanisms to meet the
requirements of enhanced virtual private networks (VPN+), analyses
Dong & Bryant Expires May 3, 2018 [Page 2]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
the limitations of some existing mechanisms, and proposes the
protocol mechanisms needed to provide VPN+ service.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Role of the Underlay and Overlay
Basically the VPN based multi-tenant networks consist of two layers:
the overlay and the underlay, each layer plays a different role. The
underlay is responsible for establishing the network connectivity
based on the physical network infrastructure, also the management of
physical network resources. The overlay is used to setup various
customized virtual network topologies, and the logical network
separation between different tenants.
The overlay and the underlay can be loosely coupled, in which case
the overlay only requires the underlay to provide the connectivity
between specific service nodes, without the control of the underlay
path and resources, which means network resources in underlay can be
shared by all the overlay networks. This can be desirable when
scalability is the primary goal, as it minimizes the amount of state
in the network.
However, as many emerging services require guaranteed performance and
greater isolation from each other in the network, this loose-couple
mode can not meet such requirements. The overlay and underlay need
to be further integrated with each other. Normally this means more
states need to be maintained in the network, which may cause
scalability problem with some mechanisms. To overcome the
scalability problem, VPN+ requires an efficient mechanism for network
resource allocation and the mapping between the overlay and underlay
networks.
4. Considerations about Network Isolation
The requirement of enhanced VPN is described in
[I-D.bryant-rtgwg-enhanced-vpn], in which isolation is identified as
one of the most important requirement. When a network is used to
carry different types of services of multiple tenants, it is required
to provide some levels of isolation between different services or
different tenants. Based on different dimensions of isolation,
network isolation is categorized and described in following sections.
Dong & Bryant Expires May 3, 2018 [Page 3]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
4.1. Data Plane Isolation
Isolation in data plane is the fundamental requirement of services
which are deployed as virtual private networks in a shared network
infrastructure. Depends on the level of data plane isolation, the
requirement is classified as soft isolation and hard isolation.
Soft isolation means that traffic of one application or tenant cannot
be received or inspected by any other application or tenant. Usually
soft isolation does not have strict resource or performance
requirement, the underlying network resource can be shared by
multiple applications or tenants, which is useful to achieve better
economy with statistical multiplexing. With soft isolation, when
service in one of the virtual networks experience some event such as
traffic burst or congestion, this may result in negative impacts to
other virtual networks in terms of bandwidth, latency, jitter, etc.
On the other hand, hard isolation means that any event happened to
the traffic in one virtual network will not interfere any other
application or tenant on the same network, which means the
characteristics of service can be more predictable. To achieve this,
at least some of the network resource need to be dedicated rather
than shared, which may reduce the economy due to statistical
multiplexing. Hard isolation is required by services that previously
have their own dedicated private networks and expect to have the same
network characteristics in a shared network.
4.2. Control Plane Isolation
There are many aspects in control plane, from router's perspective,
isolation in control plane can be achieved in different levels:
isolation of routing tables and isolation of routing protocols.
Isolation of routing tables is the preliminary requirement of multi-
tenancy, and can be achieved with many existing VPN mechanisms. It
usually can be done using a common control plane protocl such as BGP,
and the scalability has been proved by the wide deployment in the
field networks.
Isolation of routing protocols can provide further customization and
flexibility, as different tenants or applications can choose their
preferred protocols and provision it independently with customized
parameters. The cost of routing protocol isolation is that it
requires further complexity and more resource overhead, in some cases
the scalability of control protocol isolation can be challenging.
With the introduction of SDN, isolation of control plane can be
achieved by using separate controllers for different tenants or
Dong & Bryant Expires May 3, 2018 [Page 4]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
applications. For example, each tenant can have his own controller
for network information allocation, path computation and service
provisioning. Note in this case, each tenant's controller can only
see information specific to this tenant, and has no access to
information of any other tenants. The tenant's controller may have
limited access to information and states of the network
infrastructure.
5. Analysis of Existing Mechanisms
This section analyses several existing mechanisms which are
considered as the candidate protocol mechanisms for VPN+, and
illustrates the gaps in meeting the requirements as described in
section 4.
5.1. Overlay Virtual Networks
In this document, the conventional VPNs (L3VPN, L2VPN, EVPN etc.) and
the overlay technologies developed in [NVO3] working group are
classified as overlay virtual networks. These mechanisms aim at
providing multi-tenant overlay connectivity using a unified control
plane. The underlay provides no resource of performance commitment
to the tenants of the overlays, thus the tenant only gets the best
effort provided to any traffic carried with the same traffic class in
the network.
According to operator's policy, the overlay connections of different
tenants can either share the same underlay tunnel, or use separate
dedicated tunnels to provide some degree of data plane isolation. If
there is a requirement to provide guaranteed network bandwidth from a
particular tenant, the approach is to establish a set of dedicated
RSVP-TE [RFC3205] LSPs to carry the traffic of this tenant. However,
such tunnels only provide bandwidth reservation for the tenant but no
other guarantees. The mechanisms under development in [DETNET]
working group may be needed for guaranteed low latency and packet
loss.
However, as the number of tenants requiring guaranteed performance
rises, so does the number of RSVP-TE LSPs, which ultimately leads to
scalability problems in the network. There are ongoing efforts to
improve the scalability of RSVP-TE LSPs both in control plane
[I-D.ietf-teas-rsvp-te-scaling-rec] and in data plane
[I-D.sitaraman-mpls-rsvp-shared-labels].
Dong & Bryant Expires May 3, 2018 [Page 5]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
5.2. Multiple-Topology Routing and Segment Routing
Multi-topology Routing (MTR) [RFC4915][RFC5120] has been designed to
provide multiple customized network topologies for different
services. When native IP forwarding is used as the data plane, there
is limitation in mapping the incoming packets of one interface to
different MTR topologies. The major use cases of multi-topology
routing is to provide different topologies for different address
families, e.g. IPv4 and IPv6 with different topologies, or use
particular topology for non-forwarding purpose, e.g. RPF check of
multicast.
Segment Routing (SR) [I-D.ietf-spring-segment-routing] leverages the
source routing paradigm and allows for flexible designation of
forwarding paths by encoding the paths as sequences of "segments" in
the data packet. In the IGP extensions for segment routing, multi-
topology has been taken into consideration, which may be used to
solve the forwarding plane issues of multi-topology, although it is
not specified in what scenarios segment routing and multi-topology
routing need to be used together.
Although MTR can create multiple customized topologies in the
network, it was not designed for resource reservation and isolation
between different topologies. When some nodes or links belongs to
multiple topologies, network resources on these nodes and links are
shared by all those topologies. Thus it is not possible to provide
tenants with isolation and guaranteed performance based on multi-
topology routing.
It is well accepted that segment routing can provide traffic
engineering (TE) with better scalability than RSVP-TE, however all
that current SR can do is to create a set of non-shortest paths in
the network, with network resource planning executed in the
controller. Different service traffic can be mapped to different
paths to achieve some service differentiation. Currently SR does not
provide any mechanism for resource reservation and isolation in the
network data plane, thus all network resources are shared by the
services carried by the same set of links and nodes.
6. Proposed Mechanism
This section describes the proposed mechanisms to meet the isolation
requirements of VPN+.
The overall solution is segment routing based, with necessary
extensions to create multiple isolated logical networks using a
common network infrastructure. Each logical network can have its own
customized topology and guaranteed network resources. Hard isolation
Dong & Bryant Expires May 3, 2018 [Page 6]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
can be achieved between different logical networks, so that services
in different logical networks will not interfere with each other.
Segment Routing uses different types of Segment Identifiers (SIDs) to
build the SR path, in which the adjacency SID and the node SID are
the basic building blocks. Taking advantage of the SR architecture,
with some proper extensions, each logical network can be constructed
with a dedicated set of SIDs, each of which represents a subset of
resource reserved on a specific link or node. Based on the SIDs with
resource reservation, isolation between different logical networks
can be achieved. Compared to the resource reservation using RSVP-TE,
which is per end-to-end path based reservation, the SR based resource
reservation is per-hop per-virtual- network based, which could
significantly reduce the amount of states introduced to the network,
thus can avoid the scalability problem of RSVP-TE.
6.1. Per-link/Node Resource Partitioning
To achieve resource reservation with SR, resources of the links and
nodes needs to be partitioned into isolated pieces, so that different
pieces of the node and link resources can be allocated to different
logical networks independently. Normally a network controller is
responsible for the collection of network resource information, and
the computation of the subset of network resources needed on each
node or link for a particular virtual network based on tenant's
service requirement. The controller may also be used to trigger the
allocation of network resources on the network equipments using some
appropriate protocol.
Some enhancement in the data plane may be needed to meet the
requirement of hard resource isolation. For example, FlexE [FLEXE]
can provide time slot based link channelization, which could be used
as one mechanism for link resource partitioning and reservation.
Also there are efforts for resource partitioning inside the routing
nodes. The mechanisms of link and node resource partitioning can be
implementation specific, which are outside the scope of this
document. While the capability and information about link and node
resource partitioning needs to be advertised using some control
protocol, so that different partitions of link and node resources can
be used to set up different isolated networks.
When a link is partitioned into several pieces, information about
each piece of the link needs to be advertised, so that there is no
ambiguity about which particular piece of the link resource is
allocated for which particular logical network. Using segment
routing paradigm, each link partition needs to be assigned with a
dedicated adj-SID. In order to ensure that a particular link
partition would only be used for the path computation and data
Dong & Bryant Expires May 3, 2018 [Page 7]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
forwarding of a particular logical network, each link partition needs
to be associated with the unique identifier of the logical network.
[I-D.ietf-isis-l2bundles] specifies a mechanism to advertise the link
attributes of the member links of a link bundle. Such mechanism can
be reused for the link partitioning case described in this document,
while some further extensions are needed to advertise the mapping
between the link attributes and the Logical Network Identifiers (LN-
ID).
Similarly, for node resource partitioning, different node-SIDs can be
assigned for each partition of node resource. Different Node-SIDs
are also needed for loose path forwarding of SR, service of different
logical networks uses different node-SIDs of the same node to
identify the logical networks it belongs to, so that the node could
steer different service inside their own logical networks using the
dedicated resource reserved for the logical network. In this way,
network isolation can also be achieved with SR loose path forwarding.
6.2. Construction of Isolated Logical Networks
With the mechanism described in section 6.1, each link or node
partition can be identified with a (SID, LN-ID) tuple, which
associate the SID and the resource it represents with a particular
logical network. Such information needs to be distributed both in
the network and to the network controller using protocol extensions
of IGP and BGP-LS, so that every node in the network and the
controller obtain the same link-state information of different
logical networks, so as to create the logical network topology using
the subset of the adj-SIDs and node-SIDs which associate with the
same LN-ID. From network resource perspective, each logical network
is constructed with the cluster of reserved network resources the
SIDs point to, and different logical networks are isolated from each
other. The SR path computation of each logical network SHOULD be
constrained to only use the SIDs belong to the logical network.
When service traffic is carried in a particular logical network, the
data packet is encapsulated with a sequence of Adj-SIDs and Node-SIDs
dedicated to this logical network, so that in forwarding plane the
packet will be steered through the link and node resources allocated
for those SIDs. Service of different logical networks always use
different SIDs when traversing the same physical links or nodes.
This ensures that service always use the network resources allocated
for its logical network.
Dong & Bryant Expires May 3, 2018 [Page 8]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
6.3. Mapping Service to Logical Network
Mapping of service to logical networks can be quite flexible.
According to the different isolation requirements, one tenant who
requires hard isolation can be mapped to a dedicated logical network,
so that the network resource of the logical network are dedicated to
this tenant. If this tenant have multiple services, the resources
can be shared by all the services of this tenant, but the service
performance will never be impacted by service of other tenants. Some
service may require stringent performance in terms of bounded latency
and packet loss, then mechanisms of [DETNET] may be applied to this
service.
For tenants who only expect soft isolation and resource sharing or
competing is allowed between these tenants, these tenants can be
mapped to the same logical network for better economy and
scalability. Service traffic of tenants which mapped to the same
logical network may compete for some shared resources, but they will
never impact another tenant who owns a separate logical network.
According to the customized requirements, different group of tenants
can be mapped to different logical networks.
7. Security Considerations
The security concerns about segment routing
[I-D.ietf-spring-segment-routing] applies here.
8. IANA Considerations
There are no requested IANA actions.
9. References
9.1. Normative References
[I-D.bryant-rtgwg-enhanced-vpn]
Bryant, S. and J. Dong, "Enhanced Virtual Private Networks
(VPN+)", draft-bryant-rtgwg-enhanced-vpn-00 (work in
progress), July 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Dong & Bryant Expires May 3, 2018 [Page 9]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
9.2. Informative References
[DETNET] "IETF Detnet Working Group", 2017,
<https://datatracker.ietf.org/wg/detnet/>.
[FLEXE] "Flex Ethernet Implementation Agreement", March 2016,
<http://www.oiforum.com/wp-content/uploads/
OIF-FLEXE-01.0.pdf>.
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-02 (work in progress), June 2017.
[I-D.ietf-isis-l2bundles]
Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
E. Aries, "Advertising L2 Bundle Member Link Attributes in
IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
May 2017.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-12 (work in progress), June 2017.
[I-D.ietf-teas-rsvp-te-scaling-rec]
Beeram, V., Minei, I., Shakir, R., Pacella, D., and T.
Saad, "Techniques to Improve the Scalability of RSVP
Traffic Engineering Deployments", draft-ietf-teas-rsvp-te-
scaling-rec-07 (work in progress), September 2017.
[I-D.sitaraman-mpls-rsvp-shared-labels]
Sitaraman, H., Beeram, V., Parikh, T., and T. Saad,
"Signaling RSVP-TE tunnels on a shared MPLS forwarding
plane", draft-sitaraman-mpls-rsvp-shared-labels-02 (work
in progress), September 2017.
Dong & Bryant Expires May 3, 2018 [Page 10]
Internet-Draft Enhanced VPN Protocol Considerations October 2017
[NVO3] "IETF NVO3 Working Group", 2017,
<https://datatracker.ietf.org/wg/nvo3/>.
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
RFC 3205, DOI 10.17487/RFC3205, February 2002,
<https://www.rfc-editor.org/info/rfc3205>.
Authors' Addresses
Jie Dong
Huawei Technologies
Email: jie.dong@huawei.com
Stewart Bryant
Huawei Technologies
Email: stewart.bryant@gmail.com
Dong & Bryant Expires May 3, 2018 [Page 11]
