Segment Routing based Virtual Transport
Network (VTN) for Enhanced VPNHuawei Technologiesjie.dong@huawei.comFuturewei Technologiesstewart.bryant@gmail.comKDDI Corporationta-miyasaka@kddi.comChina Telecomzhuyq8@chinatelecom.cnChina Mobileqinfengwei@chinamobile.comChina Mobileli_zhenqiang@hotmail.comCisco Systemsfclad@cisco.comSPRING Working GroupSegment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called
"segments". A segment can represent topological or service based
instructions. A segment can further be associated with network resources
allocated for executing the instruction. Such a segment is called
resource-aware SID.Resource-aware SIDs may be used to build SR paths with a set of
reserved network resources. In addition, resource-aware SIDs may be used
to build SR based virtual underlay networks, which can provide the
customized network topology and resource attributes required by
different customers and/or services. Such virtual networks are called SR
based Virtual Transport Networks (VTNs). The SR based VTNs can be used
as the underlay network to enable services with required topology and
resource characteristics. This document describes a suggested use of
resource-aware SIDs to build SR based VTNs.Segment Routing (SR) specifies a mechanism
to steer packets through an ordered list of segments. A segment is
referred to by its Segment Identifier (SID). With SR, explicit source
routing can be achieved without introducing per-path state into the
network. When compared with RSVP-TE , SR
currently does not have the capability to reserve network resources or
identify different sets of network resources reserved for different
customers and/or services. proposes to extend SR
by associating SIDs with network resource attributes, (e.g. bandwidth,
processing or storage resources). On a network segment, multiple
resource-aware SIDs may be allocated, each of which represents a subset
of network resources assigned to meet the requirements of one or a group
of customers and/or services.Once allocated, Resource-aware SIDs can be used to build SR paths
using a set of reserved network resources. In addition, a group of
resource-aware SIDs can be used to build SR based virtual networks with
customized network topology and resource attributes. In this document,
such virtual networks are called SR based Virtual Transport Networks
(VTNs), and can be used to enable services with required topology and
resource characteristics, such as the enhanced VPN (VPN+) services as
described in .This document describes a suggested use of resource-aware SIDs to
build SR based VTNs. Although the procedure is illustrated using
SR-MPLS, the proposed mechanism is applicable to both segment routing
over MPLS data plane (SR-MPLS) and segment routing over IPv6 data plane
(SRv6).When SR is used as the data plane to provide multiple VTNs in one
network, it is necessary to compute and instantiate SR paths with the
topology constraints of the VTN, and from the set of network resources
allocated to the VTN.With the mechanism defined in , multiple SR SIDs can
be allocated for each network segment, with each SID used to identify
both the network topological instruction, and the set of network
resources allocated for a VTN. The mechanisms to identify the network
topology or path with a SID as defined in are
reused.The control plane mechanisms for advertising resource-aware SIDs for
different VTNs may be based on , and with
necessary extensions. This is further described in section 3.3.This section describes a mechanism of allocating resource-aware
SIDs to SR-MPLS based VTNs.For one IGP link, multiple Adj-SIDs are allocated, each of which is
associated with a VTN that link participates in, and represents a
subset of the link resources allocated to the VTN. Similarly, for one
IGP node, multiple prefix-SIDs are allocated, each of which is
associated with a VTN the node participates in, and represents a
subset of the node level processing resources allocated to the
VTN.In the case of multi-domain VTNs, on an inter-domain link, multiple
BGP peering SIDs are allocated, each
of which is associated with a VTN which spans multiple domains, and
represents a subset of resources allocated on the inter-domain
link.This section describes a mechanism of allocating resource-aware
SIDs to VTN based on SRv6.For a network node, multiple SRv6 Locators are allocated, each of
which is associated with a VTN that node participates in, and
represents a subset of the network resources allocated by the network
node to the VTN. The SRv6 SIDs associated with a VTN are allocated
from the SID space using the VTN-specific Locators as the prefix.
These SRv6 SIDs can be used to represent VTN-specific SRv6 functions
which are executed using the network resources allocated to the
VTN.Note that the introduction of SR based VTNs increases the number of
SIDs and SRv6 Locators needed in a network, there may be some concern,
especially about the prefix-SIDs, which are allocated from the Segment
Routing Global Block (SRGB). The amount of network state will also
increase accordingly. However, based on the SR paradigm,
resource-aware SIDs and the associated network state are allocated and
maintained per VTN, and per-path network state is avoided in the SR
network.This section describes possible procedures for creating SR based VTNs
and the corresponding forwarding tables and entries. Although it is
illustrated using SR-MPLS, the proposed mechanism is applicable to both
SR-MPLS and SRv6.Suppose a virtual network is requested by some customer or service.
One of the basic requirement is that customer or service is allocated
with some dedicated network resource, so that it does not experience
unexpected interference from other services in the same network. Other
possible requirements may include the required topology, bandwidth,
latency, reliability, etc.According to the received service requirement, a centralized network
controller calculates a subset of the underlay network topology to
support the service. Within this topology, the set of network resources
required on each network element is also determined. The subset of
network topology and network resources together constitute a VTN.
Depending on the service requirement, the network topology and resource
can be dedicated for an individual customer or service, or can be shared
by a group of customers and/or services.Based on the mechanisms defined in , the network topology
and resources of a VTN can be represented by a group of resource-aware
SIDs. With SR-MPLS, a group of prefix-SIDs and adj-SIDs will be used by
network nodes and the network controller to construct an SR based VTN,
which will be used as the virtual underlay network for the requested
service. Control plane protocols such as IGP (e.g. IS-IS or OSPF) and
BGP-LS can be used to distribute the SIDs and the associated resource
information of each VTN. The detailed control plane mechanisms and
possible extensions are out of the scope of this document.A centralized network controller can be responsible for the
planning of a VTN to meet the received service request. The controller
needs to collect information on network connectivity, network
resources, network performance and any other relevant network states
from the underlay network. This can be done using either IGP TE
extensions such as , or BGP-LS , or any other form of
control plane signaling.Based on the information collected from the underlay network, the
controller obtains the underlay network topology and the information
about the allocated and available network resources. When a service
request is received, the controller determines the subset of the
network topology, along with the set of the resources needed on each
network segment (e.g. links and nodes) in the topology to meet the
service requirements, whilst maintaining the needs of the existing
services that are using the same network. The subset of network
topology and network resources constitute a VTN, which will be used as
the virtual underlay network of the requested service.According to the result of VTN planning, the network controller
instructs the network nodes with the information of the VTN identifier
and the required network resources to be allocated to the VTN, so that
the involved network nodes could join the VTN and allocate the network
resources for the VTN accordingly. This may be done with PCEP , Netconf/YANG or with any other control plane mechanism with
necessary extensions. Thus, the controller not only allocates the
resources to the newly computed VTN but also keeps track of the
remaining available resources in order to cope with subsequent VTN
requests.On each network node involved in a VTN, a set of network resources
are allocated to that VTN. Such set of network resources can be
dedicated for the processing of traffic in that VTN, and cannot be
used for traffic in other VTNs. Note it is also possible that a group
of VTNs may share a set of network resources on some network segments.
Resource-aware SIDs are allocated to represent the set of resources
allocated on the network node and the attached links. Such group of
resource-aware SIDs, e.g. prefix-SIDs and adj-SIDs are used as the
data plane identifiers of the node and links in the VTN.In the underlying forwarding plane, there can be multiple ways of
allocating a subset of network resources to a VTN. The candidate data
plane technologies to support resource partitioning or reservation can
be found in . The
resource-aware SIDs are considered as a unified abstraction in the
network layer, which can work with various network resource partition
or reservation mechanisms in the underlying forwarding plane.Figure 1 shows an example of providing multiple VTNs in an SR based
network. Note that the format of the SIDs in this figure is for
illustration, both SR-MPLS and SRv6 can be used as the data plane. In
this example, three VTNs: red (r) , green (g) and blue (b) are created
to carry traffic of different customers or services. Both the red and
green VTNs consist of nodes A, B, C, D, and E with all their
interconnecting links, whilst the blue VTN only consists of nodes A,
B, C and D with all their interconnecting links. Note that different
VTNs may have a set of shared nodes and links. On each link, a
resource-aware adj-SID is allocated for each VTN it participates
in.In Figure 1, the notation x:nnnn:y means that in VTN x, the adj-SID
nnnn will steer the packet over a link which has bandwidth y reserved
for that VTN. For example, r:1002:1G in link C->D says that the VTN
red has a reserved bandwidth of 1Gb/s on link C->D, and will be
used by packets arriving at node C with an adj-SID 1002 at the top of
the label stack. Similarly, on each node, a resource-aware prefix-SID
is allocated for each VTN it participates in. The adj-SIDs can be
associated with different set of link resources (e.g. bandwidth)
allocated to different VTNs, so that the adj-SIDs can be used to steer
service traffic into different set of link resources in packet
forwarding. The prefix-SIDs can be associated with the nodal resources
allocated to different VTNs. In addition, the prefix-SIDs can be used
to build loose SR path within a VTN, in this case it can be used by
the transit nodes to steer service traffic into the set of local
network resources allocated to the VTN.The network controller needs to obtain the information of all the
VTNs in the network it oversees, and the network nodes need to obtain
the information of the VTNs they participate in. To achieve this, each
network node needs to advertise the identifiers of the VTNs it
participates in, together with the group of SIDs and the associated
resource attributes both to other network nodes and to the
controller. defines an IGP
mechanism to advertise the customized topology and resource attributes
of VTN, which allows flexible combination of the virtual network
topology and the network resources attribute to provide a relatively
large number of VTNs. The corresponding BGP-LS mechanism used to
distribute the VTN information to the controller is described in .For network scenarios which require less flexibility or
scalability, the simplified control plane mechanisms based on
Multi-Topology or Flex-Algo are described in and respectively. The
corresponding BGP-LS mechanisms used to distribute the VTN information
to the controller are described in and respectively.Based on the collected information of the topology, the allocated
network resources and the associated SIDs of VTNs, both the controller
and network nodes can construct the SR based VTNs and generate the
forwarding tables and entries for each VTN based on the SIDs and SRv6
Locators of each VTN. Unlike classic segment routing in which network
resources on a network segment are shared by all the SR traffic,
different SR VTNs can be associated with different set of resources
allocated in the underlay forwarding plane, so that they can be used
to provide the required resource isolation between different customers
and/or services in the same network.Figure 2 shows the SR based VTNs created in the network in Figure
1.For each SR based VTN, SR paths are computed within the VTN, taking
the VTN topology and resources as constraints. The SR path can be an
explicit path instantiated using SR policy , in which the
SID-list is built only with the SIDs allocated to the VTN. The SR path
can also be an IGP computed path associated with a prefix-SID or SRv6
End SID allocated by a node for the VTN, the IGP computation is also
based on the VTN constraints. Different SR paths in the same VTN may
use shared network resources when they use the same resource-aware
SIDs allocated to the VTN, while SR paths in different VTNs can be
steered to use different set of network resources over the shared
network links or nodes. These VTN-specific SR paths need to be
installed in the corresponding forwarding tables.For example, to create an explicit path A-B-D-E in VTN red in
Figure 2, the SR SID-list encapsulated in the service packet would be
(1001, 1002, 1003). For the same explicit path A-B-D-E in VTN green,
the SR segment list would be (2001, 2002, 2003). In the case where we
wish to construct a loose path A-D-E in VTN green, the service packet
SHOULD be encapsulated with the SR SID-list (201, 204, 205). At node
A, the packet can be sent towards D via either node B or C using the
link and node resources allocated for VTN green. At node D the packet
is forwarded to E using the link and node resource allocated for VTN
green. Similarly, a packet to be sent via loose path A-D-E in VTN red
would be encapsulated with segment list (101, 104, 105). In the case
where an IGP computed path can meet the service requirement, the
packet can be simply encapsulated with the prefix-SID of egress node E
in the corresponding VTN.Network services can be provisioned using SR based VTNs as the
virtual underlay networks. For example, different services may be
provisioned in different SR based VTNs, each of which would use the
network resources allocated to the VTN, so that they will not
interfere with each other. In another case, a group of services which
have similar characteristics and requirements may be provisioned in
the same VTN, in this case the network resources allocated to the VTN
are only shared among this group of services, but will not be shared
with other services in the network. The steering of service traffic to
SR based VTNs can be based on either local policy or the mechanisms as
defined in .The customers may request different granularity of visibility to
the VTN which deliver the service. Depending on the requirement, the
network can be exposed to the customer either as a virtual network
with both the edge nodes and the intermediate nodes, or a set of paths
with some of the transit nodes, or simply a set of virtual
connectivity between endpoints without any transit node information.
The visibility may be delivered through different possible mechanisms,
such as IGPs (e.g. IS-IS, OSPF), BGP-LS or Netconf/YANG. On the other
hand, network operators may want to restrict the visibility of the
network information it delivers to the customer by either hiding the
transit nodes between sites (and only delivering the endpoints
connectivity), or by hiding portions of the transit nodes (summarizing
the path into fewer nodes). Mechanisms such as BGP-LS allow the
flexibility of the advertisement of aggregated virtual network
information.The proposed mechanism provides several key characteristics:Customization: Different customized VTNs can be created in a
shared network to meet different customers' connectivity and service
requirement. Each customer is only aware of the topology and
attributes of his own VTN, and provision services on the VTN instead
of the shared physical network. This provides an practical mechanism
to support network slicing.Resource Isolation: The computation and instantiation of SR paths
in one VTN can be independent from other VTNs or other services in
the network. In addition, a VTN can be associated with a set of
dedicated network resources, which can avoid resource competition
and performance interference from other VTNs or other services in
the network. The proposed mechanism also allows resource sharing
between different service flows of the same customer, or between a
group of services which are provisioned in the same VTN. This gives
the operators and the customers the flexibility in network planning
and service provisioning. In a VTN, the performance of critical
services can be further ensured using other mechanisms, e.g. those
as defined in .Scalability: The introduction of resource aware SIDs for
different VTNs would increase the amount of SIDs and state in the
network. While the increased network state is considered an
inevitable price in meeting the requirements of some customers or
services, the SR based VTN mechanism seeks to achieve a balance
between the state limitations of traditional end-to-end TE mechanism
and the lack of resource awareness in classic segment routing.
Following the segment routing paradigm, network resources are
allocated on network segments in a per VTN manner and represented as
SIDs, this ensures that there is no per-path state introduced in the
network. In addition, operators can choose the granularity of
resource allocation on different network segments. In network
segments where resource is scarce such that the service requirement
may not always be met, the proposed approach can be used to allocate
a set of resources to a VTN which contains such network segment to
avoid possible competition. By contrast, in other segment of the
network where resource is considered plentiful, the resource may be
shared between a number of VTNs. The decision to do this is in the
hands of the operator. Because of the segmented nature of the SR
based VTN, resource aggregation is easier and more flexible than
RSVP-TE based approach.In order to provide assurance for services provisioned in the SR
based VTNs, it is necessary to instrument the network at multiple
levels, e.g. in both the underlay network level and the VTN level. The
operator or the customer may also monitor and measure the performance of
the services carried by the VTN. In principle these can be achieved
using existing or in development techniques in IETF. The detailed
mechanisms are out of the scope of this document.In case of failure or service performance degradation happens in a
VTN, it is necessary that some recovery mechanisms, e.g. local
protection or end-to-end protection mechanism is used to switch the
traffic to another path in the same VTN which could meet the service
performance requirement. Care must be taken that the service or path
recovery mechanism in one VTN does not impact other VTNs in the same
network.This document makes no request of IANA.Note to RFC Editor: this section may be removed on publication as an
RFC.The security considerations of segment routing and resource-aware
SIDs are applicable to this document.The SR VTNs may be used carry services with specific SLA parameters.
An attack can be directly targeted at the customer application by
disrupting the SLA, and can be targeted at the network operator by
causing them to violate their SLA, triggering commercial consequences.
By rigorously policing ingress traffic and carefully provisioning the
resources provided to the VTN, this type of attack can be prevented.
However care needs to be taken when shared resources are provided
between VTNs at some point in the network, and when the network needs to
be reconfigured as part of ongoing maintenance or in response to a
failure.The details of the underlying network should not be exposed to third
parties, some abstraction would be needed, this is also to prevent
attacks aimed at exploiting a shared resource between VTNs.The authors would like to thank Mach Chen, Stefano Previdi, Charlie
Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein, Joel
Halpern and James Guichard for the valuable discussion and suggestions
to this document.DetNet WG