Network Working Group J. Dong
Internet-Draft S. Bryant
Intended status: Standards Track Huawei Technologies
Expires: September 6, 2018 Z. Li
China Mobile
T. Miyasaka
KDDI Corporation
March 5, 2018
Segment Routing for Enhanced VPN Service
draft-dong-spring-sr-for-enhanced-vpn-00
Abstract
Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it
to support the needs of new applications, particularly applications
that are associated with 5G services. These applications require
better isolation and have more stringent performance requirements
than can be provided with overlay VPNs. The characteristics of an
enhanced VPN as perceived by its tenant needs to be comparable to
those of a dedicated private network. This requires tight
integration between the overlay VPN and the underlay network
resources in a scalable manner. An enhanced VPN may form the
underpin of 5G network slicing, but will also be of use in its own
right. This document describes the use of segment routing based
mechanisms to provide the enhanced VPN service with dedicated
underlay network resources.
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
Dong, et al. Expires September 6, 2018 [Page 1]
Internet-Draft SR for VPN+ March 2018
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.
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. Segment Routing with Resource Reservation . . . . . . . . . . 3
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Topology and Resource Computation . . . . . . . . . . . . 5
3.2. Network Resource and SID Allocation . . . . . . . . . . . 5
3.3. Construction of Isolated Virtual Networks . . . . . . . . 5
3.4. VPN to Virtual Network Mapping . . . . . . . . . . . . . 5
4. Benefits of SR based Mechanism . . . . . . . . . . . . . . . 6
4.1. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Classic SR . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. SR with Resource Reservation . . . . . . . . . . . . . . 7
5. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Driven largely by needs arising from the 5G mobile network design,
the concept of network slicing has gained traction. There is a need
to create a VPN with enhanced characteristics. Specifically there is
Dong, et al. Expires September 6, 2018 [Page 2]
Internet-Draft SR for VPN+ March 2018
a need for a transport network supporting a set of virtual networks
each of which provides the client with dedicated (private) network
resources drawn from a shared pool. The tenant of such a network can
require a degree of isolation and performance that previously could
only be satisfied by dedicated networks. Additionally the tenant may
ask for some level of control of their virtual network e.g. to
customize the service paths in the network slice.
The enhanced VPN service (VPN+) as specified in
[I-D.bryant-rtgwg-enhanced-vpn] is targeted at new applications which
require better isolation and have more stringent performance
requirements than can be provided with existing overlay VPNs. An
enhanced VPN may form the underpin of 5G network slicing, but will
also be of use in its own right. Although VPNs can be associated
with dedicated RSVP-TE [RFC3209] LSPs to provide some guarantee to
service performance, such end-to-end per-flow based resource
reservation for each VPN has well-known scalability issues and has
not been the choice in most IP/MPLS networks.
Segment Routing (SR) [I-D.ietf-spring-segment-routing] specifies a
mechanism to steer packet through an ordered list of segments. It
can achieve explicit source routing without introducing per-flow
state into the network. However, currently SR does not have the
capability of resource reservation, it relies on the DiffServ QoS
model to provide coarse-grained service differentiation in the
network. While this may be sufficient for some traditional services,
it cannot meet the requirement of the emerging services.
This document describes the use of segment routing based mechanisms
to provide the enhanced VPN service with dedicated underlay network
resources.
2. Segment Routing with Resource Reservation
In segment routing, several types of segments are defined to
represent either topological elements or service instructions. Node
segment and adjacency segment are two major types of topological
segments. Some other segments may be associated with specific
service functions for service chaining purpose. However, currently
the segments are not associated with network resources for the QoS
purpose.
In order to provide the enhanced VPN for the emerging applications
which require guaranteed performance and isolation from other service
in the network, the overlay VPN needs to been deeply integrated with
underlay network. This requires that some dedicated network
resources need to be allocated exclusively for each enhanced VPN.
When segment routing is used in the network, it is necessary to
Dong, et al. Expires September 6, 2018 [Page 3]
Internet-Draft SR for VPN+ March 2018
introduce resource reservation into segment routing to meet the
enhanced VPN requirements.
Following the segment routing paradigm, on each network segment,
dedicated network resources are reserved for a particular enhanced
VPN. This avoids introducing per-flow state into the network.
Specifically, this per-segment resource reservation is achieved by
associating the adjacency segments and node segments with resources
reserved on the corresponding links and nodes. For example, multiple
adjacency segment identifiers (Adj-SIDs) can be allocated for one
link, each of which is associated with a set of resource reserved on
this link for a particular enhanced VPN, such as link bandwidth,
queues, etc. For one particular node, multiple node-SIDs can be
allocated for one node, each of which is associated with a set of
resource reserved on this node for a particular enhanced VPN. Note
that when node-SID is used to build a loose SR path for a particular
enhanced VPN, Penultimate Hop Popping (PHP) MUST be disabled, so that
every node could use the node-SID to identify the enhanced VPN and
the corresponding network resources.
According to the requirement from a particular customer for an
enhanced VPN service, the underlay network sub-topology used to
support this enhanced VPN is determined. In this sub-topology, the
network resources required on each network element are also
determined. Network resources are reserved for this enhanced VPN
customer in a per-segment manner, and are represented by dedicated
node and adjacency SIDs. All the node and adjacency SIDs allocated
for this enhanced VPN constitute a virtual SR network, which is used
as the underlay of the enhanced VPN service. The extensions to IGP
protocol to support the segment routing based resource reservation
for enhanced VPN is specified in another document.
3. Procedures
This section describes the detailed procedures of provisioning an
enhanced VPN service using segment routing based resource reservation
for the enhanced VPN.
Assume that customer A requests an enhanced VPN service from the
network operator. The fundamental requirement is that customer A's
traffic does not experience interference from other traffic in the
network, such as traffic in other VPNs, or the default traffic in the
network. The detailed requirements can be described with following
characteristics:
o Service topology
o Service bandwidth
Dong, et al. Expires September 6, 2018 [Page 4]
Internet-Draft SR for VPN+ March 2018
o Reliability
o Latency, jitter, etc.
3.1. Topology and Resource Computation
It is assumed that a centralized network controller is responsible
for the provisioning of enhanced VPNs. The controller needs to
collect the network connectivity, resources and other relevant
network state information of the underlay network. This usually can
be done using either the IGP [RFC5305] [RFC3630] or BGP-LS [RFC7752].
Based on the network information collected from the elements in the
underlay, the controller can compute the best way to meet the
requirements of a new tenant whilst maintaining the needs of the
existing tenants that are using the same network. The output of the
computation is a sub-topology of the underlay network, along with the
network resources needed on each network element (e.g. links and
nodes) in the sub-topology. This is the underlay network which can
fully meet the customer's service requirement.
3.2. Network Resource and SID Allocation
According to the computation output, the network controller sends
requests to all the network devices involved in the sub-topology to
allocate the network resources required for this enhanced VPN. This
can be done with either PCEP [RFC5440] or Netconf [RFC6241] with
necessary extensions. The network resources are allocated in a per-
segment manner. Dedicated segment identifiers, e.g. node-SIDs and
adj-SIDs are allocated for each network segment along with the
network resources reserved for this enhanced VPN.
3.3. Construction of Isolated Virtual Networks
A virtual SR network can then be constructed using the node-SIDs and
adj-SIDs allocated for this enhanced VPN. Unlike classical segment
routing in which network resources are shared between different
services and customers, the proposed mechanism provides a virtual
network with dedicated resource reserved in the underlay, so that it
can always meet the service requirement of the customer and provide
the required isolation from other customers in the same network.
3.4. VPN to Virtual Network Mapping
The services of an enhanced VPN customer would be provisioned using
the customized virtual SR networks as the underlay. This ensures
that services of different enhanced VPNs will only use the network
resources reserved for them and not interfere with each other. For
Dong, et al. Expires September 6, 2018 [Page 5]
Internet-Draft SR for VPN+ March 2018
each enhanced VPN customer, the service paths can be customized for
different services within the virtual SR network, and the reserved
network resources can be shared by different services of the same
enhanced VPN customer.
4. Benefits of SR based Mechanism
The SR based mechanism described in this document provides three
things:
o More flexibility and better scaling.
o Lower state maintenance overhead and fewer protocols types in the
code than RSVP-TE.
o Better isolation and performance than Classic SR due to allocation
of resources in the underlay to specific services.
This SR based mechanism can provide the required isolation between
different enhanced VPNs, without introducing per-flow state into the
network. For each enhanced VPN, the resource reservation is done in
a per-segment manner, which aligns with the segment routing paradigm.
This provides better scalability compared to RSVP-TE based per-flow
resource reservation.
In addition to isolation, the SR based mechanism also allows resource
sharing between different services of the same enhanced VPN customer.
This gives the customer more flexibility and control in service
planning and provisioning in their dedicated virtual networks, the
experience is similar to using a dedicated private network. The
performance of critical services in a particular enhanced VPN can be
further ensured using the mechanisms defined in [DetNet].
The detailed comparison with other candidates are given in the
following sub-sections.
4.1. MPLS-TP
MPLS-TP could be enhanced to include the allocation of specific
resources along the path to a specific LSP. This would require that
the SDN system set up and maintain every resource at every path for
every tenant, and map this to the LSP and hence the unique LSP label
at every hop. Whilst this would be a way to produce a proof of
concept for network slicing of an MPLS underlay, delegation would be
difficult, resulting in a high overhead and high touch system. This
leads to scaling concerns. The number of labels needed at any node
would be the total number of services passing through that node.
Dong, et al. Expires September 6, 2018 [Page 6]
Internet-Draft SR for VPN+ March 2018
Experience with early pseudowire designs shows that this can lead to
scaling issues.
4.2. RSVP-TE
RSVP-TE would have the same scaling concern as MPLS-TP in terms of
the number of LSPs that need to be maintained being equal to the
number of service passing through any given node. Additionally it
would have the two RSVP disadvantages that basic SR seeks to address:
o The use of additional protocol (RSVP) in addition to the routing
protocol used to discover the topology and the network resources.
o The overhead of the soft-state maintenance associated with RSVP.
The impact of this overhead would be exacerbated by the increased
number of end to end paths requiring state maintenance.
4.3. Classic SR
Classic SR minimizes the number of control protocols compared to RSVP
to just the routing protocol. It also attempts to minimize the core
state by pushing state into the packet. It is not entirely
successful with this in that in practise binding SIDs are required to
overcome limitations in the ability of some nodes to push large label
stacks. Binding SIDs increase network state at strategic places in
order to overcome the imposition SID size limit.
In addition, classic SR does not have any resource reservation system
below the level of link, and none at node level, which restricts the
extent to which some particular tenant traffic can be isolated from
other traffic in the network.
4.4. SR with Resource Reservation
The approach described in this document seeks to achieve a compromise
between the state limitations of classic TE system and the lack of
resource reservation in classic SR.
Specifically, by segmenting the path and allocating resources to
virtual network topologies, the operator can choose the granularity
of resource to path binding within a topology. In network segments
where resource is scarce such that the service requirement cannot be
delivered, the SR approach is able to allocate specific resources to
a particular service. By contrast, in other parts of the network
where resource is plentiful, the resource may be shared by a number
of services. The decision to do this is in the hands of the operator
or the tenant. Because of the segmented nature of the path, resource
aggregation is possible in a way that is not possible with RSVP and
Dong, et al. Expires September 6, 2018 [Page 7]
Internet-Draft SR for VPN+ March 2018
MPLS-TP due to the use of dedicated label to identify each end-to-end
path.
5. Service Assurance
In order to provide service assurance it is necessary to instrument
the network at multiple levels. The network operator needs to
ascertain that the underlay is operating correctly. A tenant needs
to ascertain that their services are correctly operating. In
principle these can use existing techniques. These are well known
problems and solutions either exist or are in development to address
them.
However new work is needed to instrument the virtual network slices
that are created. Such instrumentation needs to operate without
causing disruption to other services using the network. Given the
sensitivity of some applications care needs to be taken to ensure
that the instrumentation itself does not cause disruption either to
the service being instrumented or to another service.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
The normal security considerations of VPNs are applicable and it is
assumed that industry best practise is applied to an enhanced VPN.
The security considerations of segment routing are applicable and it
is assumed that these are applied to an enhanced VPN that uses SR.
Some applications of enhanced VPNs are sensitive to packet latency,
and the enhanced VPNs provisioned to carry their traffic have latency
SLAs. By disrupting the latency of such traffic an attack can be
directly targeted at the customer application, or can be targeted at
the network operator by causing them to violate their service level
agreement and thus causing them commercial consequences. Dynamic
attacks of this sort are not something that networks have
traditionally guarded against, and networking techniques need to be
developed to defend against this type of attack. By rigorously
policing ingress traffic and carefully provisioning the resources
provided to critical services this type of attack can be prevented.
However case needs to be taken where it is necessary to provide
Dong, et al. Expires September 6, 2018 [Page 8]
Internet-Draft SR for VPN+ March 2018
shared resources, and when the network needs to be reconfigured as
part of ongoing maintenance or in response to a failure.
It is important that steps are taken to ensure that details of the
underlay are not exposed to third parties to minimise the possibility
that an exploit be developed as a result of exploiting a shared
resource.
8. Acknowledgements
The authors would like to thank Mach Chen, Zhenbin Li for the
discussion and suggestions to this document.
9. References
9.1. Normative References
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[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>.
9.2. Informative References
[DetNet] "DetNet WG", 2016,
<https://datatracker.ietf.org/wg/detnet>.
[I-D.bryant-rtgwg-enhanced-vpn]
Bryant, S. and J. Dong, "Enhanced Virtual Private Networks
(VPN+)", draft-bryant-rtgwg-enhanced-vpn-01 (work in
progress), October 2017.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
Dong, et al. Expires September 6, 2018 [Page 9]
Internet-Draft SR for VPN+ March 2018
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
Authors' Addresses
Jie Dong
Huawei Technologies
Email: jie.dong@huawei.com
Stewart Bryant
Huawei Technologies
Email: stewart.bryant@gmail.com
Zhenqiang Li
China Mobile
Email: li_zhenqiang@hotmail.com
Takuya Miyasaka
KDDI Corporation
Email: ta-miyasaka@kddi.com
Dong, et al. Expires September 6, 2018 [Page 10]