[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03
TEAS Shaofu. Peng
Internet-Draft Ran. Chen
Intended status: Standards Track Gregory. Mirsky
Expires: August 19, 2020 ZTE Corporation
Fengwei. Qin
China Mobile
February 16, 2020
Packet Network Slicing using Segment Routing
draft-peng-teas-network-slicing-03
Abstract
This document presents a mechanism aimed at providing a solution for
network slicing in the transport network for 5G services. The
proposed mechanism uses a unified administrative instance identifier
to distinguish different virtual network resources for both intra-
domain and inter-domain network slicing scenarios. Combined with the
segment routing technology, the mechanism could be used for both
best-effort and traffic engineered services for tenants.
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 August 19, 2020.
Copyright Notice
Copyright (c) 2020 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
Peng, et al. Expires August 19, 2020 [Page 1]
Internet-Draft Packet Network Slicing using SR February 2020
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture of TN Slicing . . . . . . . . . . . . . . . . . 3
2.1. Key Technologies of Transport slice . . . . . . . . . . . 5
3. Slicing Requirements . . . . . . . . . . . . . . . . . . . . 6
3.1. Dedicated Virtual Networks . . . . . . . . . . . . . . . 6
3.2. End-to-End Slicing . . . . . . . . . . . . . . . . . . . 6
3.3. Unified NSI . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Traffic Engineering . . . . . . . . . . . . . . . . . . . 7
3.5. Summarized Requirements . . . . . . . . . . . . . . . . . 7
4. Conventions Used in This Document . . . . . . . . . . . . . . 8
5. Overview of Existing Identifiers . . . . . . . . . . . . . . 8
5.1. AG and EAG Bit . . . . . . . . . . . . . . . . . . . . . 8
5.2. Multi-Topology Identifier . . . . . . . . . . . . . . . . 9
5.3. SR Policy Color . . . . . . . . . . . . . . . . . . . . . 9
5.4. Flex-algorithm Identifier . . . . . . . . . . . . . . . . 9
5.5. New Slice-based Identifier Introduced . . . . . . . . . . 10
6. Overview of AII-based Mechanism . . . . . . . . . . . . . . . 10
6.1. Physical Network Partition by AII . . . . . . . . . . . . 11
6.2. Path within AII specific Slice . . . . . . . . . . . . . 11
6.2.1. SR-BE Path within AII specific Slice . . . . . . . . 11
6.2.2. SR-TE Path within AII specific Slice . . . . . . . . 12
6.3. Traffic Steering to SR policy within Slice . . . . . . . 12
6.4. Simple Variant of AII-based Slicing Scheme . . . . . . . 13
7. Resource Allocation per AII . . . . . . . . . . . . . . . . . 13
7.1. L3 Link Resource AII Configuration . . . . . . . . . . . 13
7.2. L2 Link Resource AII Configuration . . . . . . . . . . . 14
7.3. Node Resource AII Configuration . . . . . . . . . . . . . 14
7.4. Service Function Resource AII Configuration . . . . . . . 15
8. E2E Slicing with Centralized Mode . . . . . . . . . . . . . . 15
9. E2E Slicing with Distributed Mode . . . . . . . . . . . . . . 16
10. Combined with SR Flex-algorithm for Stack Depth Optimization 16
10.1. Flex-algo Using AII Criteria . . . . . . . . . . . . . . 17
10.2. Best-effort Color Template Mapping to Flex-algo . . . . 17
10.3. Traffic Engineering Color Template Mapping to Flex-algo 17
11. Network Slicing Examples . . . . . . . . . . . . . . . . . . 17
11.1. Intra-domain Network Slicing Example . . . . . . . . . . 18
11.1.1. Best-effort Service over Network Slice Example . . . 18
11.1.2. TE Service over Network Slice Example . . . . . . . 18
11.1.3. TE Service over Network Slice with Flex-algo Example 19
11.2. Inter-domain Network Slicing via BGP-LS Example . . . . 19
Peng, et al. Expires August 19, 2020 [Page 2]
Internet-Draft Packet Network Slicing using SR February 2020
11.2.1. Best-effort Service Example . . . . . . . . . . . . 19
11.2.2. TE Service Example . . . . . . . . . . . . . . . . . 20
11.2.3. TE Service Using Flex-algo Example . . . . . . . . . 20
11.3. Inter-domain Network Slicing via BGP-LU Example . . . . 21
12. Implementation Suggestions . . . . . . . . . . . . . . . . . 21
12.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
14. Security Considerations . . . . . . . . . . . . . . . . . . . 24
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
16. Normative references . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
According to 5G context, network slicing is the collection of a set
of technologies to create specialized, dedicated logical networks as
a service (NaaS) in support of network service differentiation and
meeting the diversified requirements from vertical industries.
Through the flexible and customized design of functions, isolation
mechanisms, and operation and management (O&M) tools, network slicing
is capable of providing dedicated virtual networks over a shared
infrastructure. A Network Slice Instance (NSI) is the realization of
network slicing concept. It is an E2E logical network, which
comprises of a group of network functions, resources, and connection
relationships. An NSI typically covers multiple technical domains,
which include a terminal, access network (AN), transport network (TN)
and a core network (CN), as well as a DC domain that hosts third-
party applications from vertical industries. Different NSIs may have
different network functions and resources. They may also share some
of the network functions and resources.
For a transport network, network slicing requires the underlying
network to support partitioning of the network resources to provide
the client with dedicated (private) networking, computing, and
storage resources drawn from a shared pool. The slices may be seen
as virtual networks.
2. Architecture of TN Slicing
Relationship with NS Design Team:
The current scope of NS design team will focus on the framework of
the TN Slice. We would like to make some contributions of it, and
will sent this section to the NS Design Team for dicussion.
Peng, et al. Expires August 19, 2020 [Page 3]
Internet-Draft Packet Network Slicing using SR February 2020
+-----------+ +-----------+ +-----------+
|Tenant VPN | | eMBB | | uRLLC | ...... Client/Tenant
+-----------+ +-----------+ +-----------+ Layer
-----------------------------------------------------------------------------------------------------
L2VPN L3VPN EVPN Service Layer
o
o--o---o / o--o---o
/| \ o--o---o /
o o o /| \ o
o o o
------------------------------------------------------------------------------------------------------
Virtual-Network-1 Virtual-Network-2
__________________________________ ________________________________
/ / / /
/ ++++ ++++ ++++ / / ++++ ++++ /
/ + +---+ +---+ + / / + +--------+ + /
/ ++++ ++++ ++++ / / ++++ ++++ /
/ | | / / | | / Transport-Slice
/ ++++ ++++ / / ++++ ++++ / Layer
/ + +----+ + / / +--+------- +--+ /
/ ++++ ++++ / / ++++ ++++ /
/__ ______________________________/ /_____________________________ /
------------------------------------------------------------------------------------------------------
++++ ++++ ++++
+--+------------+--+-----------+--+
++++ ++++ ++++ Physical Network
| | | Layer
| | |
++++ ++++ ++++
+--+-----------+--+----------+--+
++++ ++++ ++++
Figure 1 Architecture of TN Slicing
Based on the concept and architecture of Transport slice, the basic
requirements and features of Transport slice are as following:
o On-Demand network reconstitution: The slice network can be
reconstituted in network topology and node capability to meet
service needs. Each slice network has its own specific bandwidth,
latency and lifecycle. Different Transport Slice networks are
isolated from each other, and have independent topology and
network resources.
Peng, et al. Expires August 19, 2020 [Page 4]
Internet-Draft Packet Network Slicing using SR February 2020
o Decoupling of Service Slice Layer and Physical Network Layer: The
Service Slice Layer and the Physical Network Layer are decoupled,
and unaware of the details of each other, which simplifies the
deployment of services.
o Similarity of Transport Slice Network and Physical Network for
Service Layer: A Transport Slice Network Layer provides network
resources to the upper layer (Service Layer) which is the same as
the resources provided directly by a physical network from the
point view of the upper layer. Services such as VPN service etc.
can be deployed directly on the Transport slice network just as
they are deployed on the physical network. One Transport slice
network can support the deployment of more than one services or
VPNs.
o Data Plane Isolation of Transport Slice Network: The TN provides
two types of traffic isolation between different TN slices: hard
isolation and soft isolation. Hard isolation is implemented by
providing independent circuit switched connections for the
exclusive use of one slice, such as MTN (Metro Transport Network,
see ITU-T G.mtn), and ODUk. Soft isolation is implemented by
using a packet technology (e.g., Ethernet VLAN, MPLS tunnel, and
VPN). Services of different slices are isolated from each other.
o Transport Slice Network: There may be multiple Sub-TN-slices in a
Transport Slice Network, and those Sub-Transport slices may be
nested. Different sub-TN-slices can be also combined together for
an end-to-end TN slice service.
2.1. Key Technologies of Transport slice
For the transport network forwarding plane slicing, there are
basically two kinds of isolation technology: soft isolation
technology and hard isolation technology. The soft isolation is a
Layer 2 or Layer 3 technology, such as SR/IP/MPLS based tunnel
technology and VPN/VLAN based virtualization technology. The hard
isolation is a Layer 1 or optical-layer slicing technology based on
physically rigid pipelines, such as MTN, OTN and Wavelength Division
Multiplexing (WDM) technologies. In applications, the hybrid hard
and soft isolation solution is always used. The hard isolation
ensures service isolation, and the soft isolation supports service
bandwidth reuse.
So, The Key Technologies of Transport slice should include: Layer-one
Data Plane, Layer-Two Data Plane, and Layer-Three Data Plane.
Peng, et al. Expires August 19, 2020 [Page 5]
Internet-Draft Packet Network Slicing using SR February 2020
3. Slicing Requirements
3.1. Dedicated Virtual Networks
An end-to-end virtual network with dedicated resources is the
advantage of network slicing than traditional DiffServ QoS and VPN.
For example, DiffServ QoS can distinguish VoIP traffic and other type
of traffic (such as high-definition video, web browsing), but can not
distinguish the same type of traffic from different tenants, nor
isolation of these traffic at all.
Another example is the IoT traffic of health monitoring network which
connected hospital and outpatient, it always has strict privacy and
safety requirements, including where the data can be stored and who
can access the data, all this can not be satisfied by DiffServ QoS as
it has not any function of network computing and storage.
Dedicated VN is a distinct object purchased by a customer, and it
provides specific function with predictable performance, guaranteed
level of isolation and safety. It is not just as QoS.
3.2. End-to-End Slicing
Only an end-to-end slice and fine-grained network can match ultra
delay and safety requirements of special service. End-to-end means
that it is constructed with AN-slice, TN-slice, and CN-slice part.
Although 3GPP technical specifications mainly focus on the operation
and management of AN-slice and CN-slice, which include some NF
(network function) components, TN-slice is also created and destroyed
according to the related NSI lifecycle. In fact, the 3GPP management
system will request expected link requirements related to the network
slice (e.g., topology, QOS parameters) with the help of the
management system that handles the TN part related to the slice.
For TN part, the link requirements are independent of the existing
domain partition of the network, i.e., any intra- or inter-domain
link is the candidate resource for the slice. It is also independent
of the existing underlay frame or routing technologies (IGP, BGP,
Segment Routing, Flex-E, etc.), i.e., any L2 or L3 link is the
candidate resource.
3.3. Unified NSI
An NSI is indentified by S-NSSAI (Single Network Slice Selection
Assistance Information), which is allocated per PDU session and has
semantic global within the AN and CN.
Peng, et al. Expires August 19, 2020 [Page 6]
Internet-Draft Packet Network Slicing using SR February 2020
For the purpose of operation and management simplicity, it is also
better to have a unified identifier with semantic global to
distinguish different TN-slice during the whole TN. TN-slice
identifier has a mapping relation with S-NSSAI, perhaps 1:1 or 1:n.
Instead, using different slice identifier across multi-domain of TN
for the specific TN-slice will introduce much and unnecessary
complexity, especially for case two devices belongs to different
domain try to exchange slice-based information directly, without the
help of SDN controller to translate the unified TN-slice identifier
to an individual domain-wide indentifier.
3.4. Traffic Engineering
5G system is expected to be able to provide optimized support for a
variety of different communication services, different traffic loads,
and different end-user communities. For example, the communication
services using network slicing may include: vehicle-to-everything
(V2X) services, 5G seamless enhanced Mobile BroadBand (eMBB) service
with FMC (fixed-mobile convergence), massive IoT connections. Among
these service types, high data rates, high traffic densities, low-
latency, high-reliability are highlighted requirements.
Traffic engineering mechanism in TN must support the above
requirements, bandwidth and delay are two primary TE constraints.
3.5. Summarized Requirements
In summary, the following requirements would be satisfied:
REQ1: Provide a distinct virtual network, including dedicated
topology, computation, and storage resource, not only traditional
QoS;
REQ2: Unified NSI for easy operation and maintenance;
REQ3: E2E network slicing, including both intra-domain and inter-
domain case;
REQ4: Customization resource for QoS purpose, bandwidth and delay are
basic constraints;
REQ5: Layer 2 as well as Layer 3 link resource partition;
Peng, et al. Expires August 19, 2020 [Page 7]
Internet-Draft Packet Network Slicing using SR February 2020
4. Conventions Used in This Document
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 RFC2119.
5. Overview of Existing Identifiers
Currently there are multiple existing mature identifiers that could
be used to identify the virtual network resource in the transport
network, such as:
o Administrative Group (AG) described in [RFC3630], [RFC5329],
[RFC5305] and Extended Administrative Groups (EAGs) described in
[RFC7308]
o Multi-Topology Routing (MTR) described in [RFC5120], [RFC4915],
[RFC5340]
o SR policy color described in
[I-D.ietf-spring-segment-routing-policy]
o FA-id described in [I-D.ietf-lsr-flex-algo]
However, all these identifiers are not sufficient to meet the above
requirements of TN-slice. Note that all these identifiers have use
case of their own, besides the network slicing use case. Next, we
will discuss each of them to determine their matching of slicing
requirements.
5.1. AG and EAG Bit
AG and EAG are limited to serve as a link color scheme used in TE
path computation to meet the requirements of TE service for a tenant.
It is difficult to use them for an NSI allocation mapping (assuming
that each bit position of AG/EAG represents an NSI). Hence, they do
not meet REQ1. At the same time, AG or EAG cannot be a FIB
identifier for best-effort service for the same tenant.
AG and EAG are only as L3 link attribute, not appropriate for
L2-bundles member, i.e., not meeting REQ5.
Note that AG and EAG have semantic global, so they meet REQ2,3.
Peng, et al. Expires August 19, 2020 [Page 8]
Internet-Draft Packet Network Slicing using SR February 2020
5.2. Multi-Topology Identifier
MTR is limited to serve as an IGP logical topology scheme only used
in the intra-domain scenario. Thus it is challenging to select
inter-area link resources based on MT-ID when E2E inter-domain TE
path needs to be created for a tenant. That is, it does not meet
REQ3.
Different IGP domain within the same TN-slice may be configured with
different MT-ID. Thus MT-ID does not meet REQ2.
MT-ID is only as L3 link attribute, not appropriate for L2-bundles
member, so it does not meet REQ5.
5.3. SR Policy Color
The color of SR policy defines a TE purpose, which includes a set of
constraints such as bandwidth, delay, TE metric, etc. Therefore
color is an abstract target, and it is difficult to get a distinct
virtual network according to a specific color value. In most cases,
only the headend and some other border nodes need to maintain the
color template, and a color-based virtual network is hard to present
because of too few participants and lack of interaction scheme. That
is, the color does not meet REQ1.
We can continue to define TE affinity information in color-template,
but that is only appropriate for L3 link, not for L2-bundles member,
so the color does not meet REQ5.
Note that the color has global semantic, so it meets REQ3.
5.4. Flex-algorithm Identifier
Indeed, FA-id is a short mapping of SR policy color, and it may
inherit the matched-degree of the Policy Color. However, FA-id has
its own characteristics. A specific FA-id can have more distributed
participants and define explicit link resource so that an explicit FA
plane can be created. Unfortunately, different best-effort and TE
service of the same slice-tenant will define different constraints,
resulting in the need to occupy more FA-id resources for one slice-
tenant. The relationship between FA-id and slice is not clear. That
is, FA-id does not meet REQ1.
On the other hand, FA-id, like MT-ID, is limited to serve as an IGP
algorithm scheme used in the intra-domain scenario. It is
challenging to select inter-area (especially inter-AS) link resources
according to FA-id when the E2E inter-domain TE path needs to be
created for the tenant. So, FA-id does not meet REQ3.
Peng, et al. Expires August 19, 2020 [Page 9]
Internet-Draft Packet Network Slicing using SR February 2020
Different IGP domain within the same TN-slice may configure different
FA-ids, so it does not meet REQ2.
What is more important, tha the path in FA plane identified by FA-id
is MP2P LSP, so it is hard to define bandwidth reservation for
service. So, FA-id does not meet REQ4. Unless each link is totally
dedicated to a single FA plane, i.e., link resources are not shared
among multiple FA plane.
The link include/exclude rules defined by FA-id is only appropriate
for the L3 link, not for L2-bundles member, so FA-id does not meet
REQ5.
5.5. New Slice-based Identifier Introduced
Thus, there needs to introduce a new characteristic of NSI that meets
the above-listed requirements to isolate underlay resources, and it
is a slice-based identifier.
Firstly, it could serve as TE criteria for TE service, this aspect is
like AG/EAG; and secondly, as a FIB table identifier for best-effort
service, this aspect is like MT-ID or FA-id.
This document introduces a new property of NSI called "Administrative
Instance Identifier" (AII) and corresponding method of how to
instantiate it in the underlay network to match the above-listed
requirements.
6. Overview of AII-based Mechanism
[I-D.ali-spring-network-slicing-building-blocks] described how SR
policy [I-D.ietf-spring-segment-routing-policy] can be used to create
service slice. This document continues to discuss AII-based
mechanism to enhance SR policy to support tenant slice as well as
service slice. It will signal the association of AII and shared
resources required to create and manage an NSI, and steer the packets
to the path within the specific NSI according to SR policy color.
SR policy color has semantic global in order to be conveniently
exchanged between two PE routers. They configure the same color
template information for the same color value. AII, also with global
semantic, can be contained in color template to enhance SR policy to
create a TE path within global TN-slice identified by AII. Besides
TE service served by explicit SR policy instance, best-effort service
is served by AII-specific FIB that is created by default once AII
configured.
The following is how AII-based mechanism works.
Peng, et al. Expires August 19, 2020 [Page 10]
Internet-Draft Packet Network Slicing using SR February 2020
6.1. Physical Network Partition by AII
At the initial stage, each link in a physical network can be colored
to conform with network slicing requirements. As previously
mentioned, AII can be used to color links to partition underlay
resources. Also, we may continue to use AG or EAG to color links for
traditional TE within a virtual network specified by an AII. A
single or multiple AIIs could be configured on each intra-domain or
inter-domain link regardless of IGP instance configuration. At the
minimum, a link always belongs to default AII (the value is 0). The
number of AIIs configured on a node's links determines the number of
virtual networks the node belongs to.
The extension of the existing IGP-TE mechanisms [RFC3630] and
[RFC5305] to distribute AII information in an AS as a new TE
parameter of a link will be defined in another document.
An SDN controller, using BGP-LS [RFC7752] or another interface, will
have a distinct view of each virtual network specified by AII. The
extension of BGP-LS will also be defined in another document.
6.2. Path within AII specific Slice
Using the CSPF algorithm, a TE path for any best-effort (BE) or
traffic-engineered (TE) service can be calculated within a virtual
network specified by the AII. The computation criteria could be
<AII, min igp-metric> or <AII, traditional TE critieria> for the BE
and TE respectively. Combined with segment routing, the TE path
could be represented as:
o a single node-SID of the destination node, for the best-effort
service in the domain;
o node-SIDs of the border node and the destination node, adjacency-
SID of inter-domain link, for the inter-domain best-effort
service;
o an explicit adjacency-SID list or compressed with several loose
node-SID, for P2P traffic engineered service.
6.2.1. SR-BE Path within AII specific Slice
Because packets of the best-effort service could be transported over
an MP2P LSP without congestion control, SR best-effort FIB for each
virtual network specified by AII to forward best-effort packets may
be created in the IGP domain. Thus, CSPF computation with criteria
<AII, min igp-metric> is distributed on each node in the IGP domain.
Peng, et al. Expires August 19, 2020 [Page 11]
Internet-Draft Packet Network Slicing using SR February 2020
That is similar to the behavior in [I-D.ietf-lsr-flex-algo], but the
distributed CSPF computation is triggered by AII.
Besides the best-effort service, SR best-effort FIB entry for
specific AII also provide an escape way for traffic engineering
service within the same slice when the expected TE purpose can not be
meet.
To distinguish forwarding behavior of different virtual networks,
prefix-SID need to be allocated per AII and advertised in the IGP
domain.
For inter-domain case, in addition to the destination node-SID,
several node-SIDs of the domain border node and adjacency-SID of
inter-domain link are also needed to construct the E2E segment list.
The segment list could be computed with the help of the SDN
controller, which needs to take account of AII information during the
computation. Even for best-effort service, the head-end has to
maintain the corresponding SR-TE tunnel or SR policy.
As same as the prefix-SID, adjacency-SID needs to be allocated per
AII to distinguish the forwarding behavior of different virtual
networks.
6.2.2. SR-TE Path within AII specific Slice
For P2P traffic engineering service, especially such as the ulra-
reliable low-latency communication service, it SHOULD not transfer
over an MP2P LSP to avoid the risk of traffic congestion. The
segment list could consist of pure adjacency-SID per AII specific.
The segment list could be computed by headend or SDN controller. The
head-end of the segment list maintains the corresponding SR-TE tunnel
or SR policy.
However, label stack depth of the segment list MAY be optimized at a
later time based on local policies.
6.3. Traffic Steering to SR policy within Slice
At this moment, we can steer traffic of overlay service to the above
SR best-effort FIB, SR-TE tunnel, or SR policy instance for the
specific virtual network. The overlay service could specify a color
for TE purposes.
For example, color 1000 means <AII=10, min igp-metric> to say "I need
best-effort forwarding within AII 10 resource", color 1001 means
<AII=10, delay=10ms, AG=0x1> to say "I need traffic engineering
Peng, et al. Expires August 19, 2020 [Page 12]
Internet-Draft Packet Network Slicing using SR February 2020
forwarding within AII 10 resource, and only using link with AG equal
to 0x1 to reach guarantee of not exceeding 10ms delay time".
Service with color 1000 will be steered to an SR best-effort FIB
entry, or an SR-TE tunnel/policy in case of inter-domain.
Service with color 1001 will be steered to an SR-TE tunnel/policy.
6.4. Simple Variant of AII-based Slicing Scheme
There is a simple variant of AII-based slicing scheme for initial
slicing requirement of service, where the SDN controller in
management partition the whole E2E network topology to multiple
strictly isolated VNs identified by AII in local, but let the
forwarding equipments be totally unware of that.
The overlay service is steered to the SR policy whose path is limited
within specific VN using a pure adjacency-segment list.
This variant need not introduce any complex virtual network
technologies to forwarding equipments, however only for limited
scenes.
7. Resource Allocation per AII
7.1. L3 Link Resource AII Configuration
In IGP domain, each numbered or unnumbered L3 link could be
configured with AII information and synchronized among IGP neighbors.
The IGP link-state database will contain L3 links with AII
information to support TE path computation taking account of AII
criteria. For a numbered L3 link, it could be represented as a tuple
<local node-id, remote node-id, local ip-address, remote ip-address>
, for unnumbered it could be <local node-id, remote node-id, local
interface-id, remote interface-id>. Each L3 link could be configured
to belong to a single AII or multiple AIIs. Note that an L3 link
always belongs to default AII(0).
For different <L3 link, AII> tuple it would allocate a different
adjacency-SID, as well as advertising with different resource portion
such as bandwidth occupied.
Note that AII is independent of IGP instance. An L3 link that is not
part of the IGP domain, such as the special purpose for a static
route, or an inter-domain link, can also be configured with AII
information and allocate adjacency-SID per AII as the same as IGP
links. BGP-LS could be used to collect link state data with AII
information to the controller, BGP-LS has already provided a
Peng, et al. Expires August 19, 2020 [Page 13]
Internet-Draft Packet Network Slicing using SR February 2020
mechanism to collect link state data from many source protocols, such
as IGP, Direct, Static configuration, etc., to cover network slicing
requirements.
7.2. L2 Link Resource AII Configuration
[I-D.ietf-isis-l2bundles] described how to encode adjacency-SID for
each L2 member link of an L3 parent link. In the network slicing
scenario, it is beneficial to deploy LAG or another virtual
aggregation interface between two nodes. If that, the dedicated link
resources belong to different virtual networks could be added or
removed on demand, they are treated as L2 member links of a single L3
virtual interface. It is the single L3 virtual interface which needs
to occupy IP resource and join the IGP instance. Creating a new
slice-specific link on demand or removing the old one is likely to
affect little configurations.
For network slicing purpose, [I-D.ietf-isis-l2bundles] need to be
extended to advertise the AII attribute for each L2 member link. For
different <L2 link, AII> tuple it would allocate a different
adjacency-SID, as well as advertising with different resource portion
such as bandwidth occupied.
In practice, for hard isolation purpose, different L2 member link of
the same L3 parent link SUGGESTED to be configured to belong to
different AII, with different adjacency-SID. Note that in this case,
the L3 parent link belongs to default AII(0), but each L2 member link
belongs to the specific non-default AII. An L2 member link maybe a
Flex-E channel or ODUK tunnel created/destroyed on demand.
In the control plane, routing protocol packets following the L3
parent link will select the L2 member link with the highest priority.
In the forwarding plane, data packets that belong to the specific
virtual network will pass along the L2 member link with the specific
AII value.
TE path computation based on link-state database need inspect the
detailed L2 members of an L3 adjacency to select the expected L2 link
resource.
7.3. Node Resource AII Configuration
For topology resource, each node needs to allocate node-SID per AII
when it joins the related virtual network. All nodes in the IGP
domain can run the CSPF algorithm with criteria <AII, min IGP metric>
to compute best-effort next-hop to any other destination nodes for a
virtual network AII-specific based on the link-state database that
Peng, et al. Expires August 19, 2020 [Page 14]
Internet-Draft Packet Network Slicing using SR February 2020
containing AII information, so that SR best-effort FIB can be
constructed for each AII. Static routes could also be added to the
AII-specific FIB.
An intra-domain overlay best-effort service belongs to a virtual
network could be directly matched in the SR best-effort FIB for the
specific AII.
An inter-domain overlay best-effort service belongs to a virtual
network could be over a segment list containing domain border node-
SID and destination node-SID which could be matched in the SR best-
effort FIB for the specific AII.
7.4. Service Function Resource AII Configuration
[I-D.ietf-spring-sr-service-programming] introduces the notion of
service segments, and describes how to implement service segments and
achieve stateless service programming in SR-MPLS and SRv6 networks.
The ability of encoding the service segments along with the
topological segment enables service providers to forward packets
along a specific network path and through VNFs or physical service
appliances available in the network. Typically, a Service Function
may be any purposeful execution for the packet, such as DPI,
firewall, NAT, etc.
The Service Function is independent of topology, it can also be
instantiated per AII, each with different priority to be executed or
scheduled. For example, a docker container including specific
Service Funciton process can be generated or destroyed on demand
according to the life-cycle of a particular slice. It will have a
particular CPU scheduling priority.
At a node, multiple instance of the same type of Service Function for
different slice will allocate different Service SID and advertise to
other nodes.
8. E2E Slicing with Centralized Mode
[RFC7752] BGP-LS describes the methodology that using BGP protocol to
transfer the Link-State information that maybe originated from IGP
instance (for intra-domain topology information) or from local direct
interface or static configuration(for inter-domain topology
information). [I-D.ietf-idr-bgpls-inter-as-topology-ext] also
describes a method to firstly put inter-domain interconnections to
IGP instance, then always import data from IGP protocol source to
BGP-LS. In any case BGP-LS need extend to transfer the Link-State
data with AII information.
Peng, et al. Expires August 19, 2020 [Page 15]
Internet-Draft Packet Network Slicing using SR February 2020
An E2E inner-AS SR-TE instance with particular color template could
be initiated on PE1, PE1 is head-end and PE2 is destination node.
BGP-LS could be used to inform the SDN controller about the underlay
network topology information including AII attribute. Thus the
controller could calculate E2E TE path within the particular virtual
network. Especially AII specific Adacency-SID of inter-domain link
is included in the E2E SID list.
9. E2E Slicing with Distributed Mode
In some deployments, especially the network evolution from seamless
MPLS in reality, operators adopt BGP-LU to build inter-domain MPLS
LSP, and overlay service will be directly over BGP-LU LSP.
In this case, the network is divided into some domains and each
domain will run its own IGP process. These IGP process are isolated
to each other to be simple. That means it is inconvenient to realize
network slicing depending on IGP itself with inter-area route leak or
redistribution.
For an E2E BGP-LU LSP, if overlay service has TE requirements that
defined by a color, the BGP-LU LSP need also have a sense of color,
i.e., BGP-LU label could be allocated per color.
At entry node of each domain, BGP-LU LSP generated for specific color
will be over intra-domain SR-TE or SR Best-effort path generated for
that color again. At exit node of each domain, BGP-LU LSP generated
for specific color will select inter-domain forwarding resource per
color. Especially, an ASBR will select slice-specfic inter-AS link
according to AII information of color template.
[RFC7911] defined that multiple paths UPDATE message for the same
destination prefix can be advertised in BGP, each UPDATE can contain
the Color Extended Community ([I-D.ietf-idr-tunnel-encaps]) with
different color value. That is a simple existing way to realize BGP-
LU color function, with needless new BGP extensions.
10. Combined with SR Flex-algorithm for Stack Depth Optimization
[I-D.ietf-lsr-flex-algo] introduced a mechanism to do label stack
depth optimization for an SR policy in IGP domain part. As the color
of SR policy defined a TE purpose, traditionally the headend or SDN
controller will compute an expected TE path to meet that purpose.
It is necessary to map a color (32 bits) to an FA-id (8 bits) when SR
flex-algorithm enabled for an SR policy. Besides that, it is
necessary to enable the FA-id on each node that wants to join the
Peng, et al. Expires August 19, 2020 [Page 16]
Internet-Draft Packet Network Slicing using SR February 2020
same FA plane manually. The FAD could copy the TE constraints (not
including bandwidth case) contained in the color template.
We need to consider the cost of losing the flexibility of color when
executing the flex-algo optimization, and also consider the gap
between P2P TE requirements and MP2P SR FA LSP capability, to reach
the right balance when deciding which SR policy need optimization.
10.1. Flex-algo Using AII Criteria
Because the first feature of AII is a TE criteria of link and node,
it could be served as a parameter of Flex-algo Definition.
[I-D.peng-lsr-flex-algo-opt-slicing] described how to extend IGP
Flex-algo to compute constraint based paths over the AII specific
network slice.
10.2. Best-effort Color Template Mapping to Flex-algo
As described above, for best-effort service we have already
constructed SR best-effort FIB per AII, that is mostly like Flex-
algo. Thus, it is not necessary to map to FA-id again for a color
template which has defined a best-effort behavior within the
dedicated AII. Of course, if someone forced to remap it, there is no
downside for the operation, the overlay best-effort service (with a
color which defined specific AII, best-effort requirement, and
mapping FA-id) in IGP domain will try to recurse over <AII, prefix>
or <FA-id, prefix> FIB entry.
10.3. Traffic Engineering Color Template Mapping to Flex-algo
An SR-TE tunnel/policy that served for traffic engineering service of
a virtual network specified by an AII was generated and computed
according to the relevant color template, which contained specific
AII and some other traditional TE constraints. If we config mapping
FA-id under the color template, the SR-TE tunnel/policy instance
could inherit forwarding information from corresponding SR Flex-Algo
FIB entry.
11. Network Slicing Examples
In this section, we will further illustrate the point through some
examples. All examples share the same figure below.
Peng, et al. Expires August 19, 2020 [Page 17]
Internet-Draft Packet Network Slicing using SR February 2020
.-----. .-----.
( ) ( )
.--( )--. .--( )--.
+---+----link A1----+---+ +---+----link A1----+---+
|PE1|----link A2----|PE2|---link A1---|PE3|----link A2----|PE2|
| |----link B1----| |---link B1---| |----link B1----| |
+---+----link B2----+---+ +---+----link B2----+---+
( ) ( )
'--( AS1 )--' '--( AS2 )--'
( ) ( )
'-----' '-----'
Figure 2 Network Slicing via AII
Suppose that each link belongs to separate virtual network, e.g.,
link Ax belongs to the virtual network colored by AII A, link Bx
belongs to the virtual network colored by AII B. link x1 has an IGP
metric smaller than link x2, but TE metric lager.
To simplify the use case, each AS just contained a single IGP area.
11.1. Intra-domain Network Slicing Example
11.1.1. Best-effort Service over Network Slice Example
From the perspective of node PE1 in AS1, it will calculate best-
effort forwarding entry for each AII instance (including default AII)
to destinations in the same IGP area. For example:
For <AII=0, destination=ASBR1> entry, forwarding information could be
ECMP during link A1 and link B1, with destination node-SID 100 for
<AII=0, destination=ASBR1>.
For <AII=A, destination=ASBR1> entry, forwarding information could be
link A1, with destination node-SID 200 for <AII=A,
destination=ASBR1>.
For <AII=B, destination=ASBR1> entry, forwarding information could be
link B1, with destination node-SID 300 for <AII=B,
destination=ASBR1>.
11.1.2. TE Service over Network Slice Example
It could also initiate an SR-TE instance (SR tunnel or SR policy)
with the particular color template on PE1, PE1 is headend and ASBR1
is destination node. For example:
Peng, et al. Expires August 19, 2020 [Page 18]
Internet-Draft Packet Network Slicing using SR February 2020
For SR-TE instance 1 with color template which defined criteria
including {default AII, min TE metric}, forwarding information could
be ECMP during two segment list {adjacency-SID 1002 for <AII=0, link
A2> @PE1} and {adjacency-SID 1004 for <AII=0, link B2> @PE1}.
For SR-TE instance 2 with the color template which defined criteria
including {AII=A, min TE metric}, forwarding information could be
presented as the segment list {adjacency-SID 2002 for <AII=A, link
A2> @PE1}.
For SR-TE instance 3 with the color template which defined criteria
including {AII=B, min TE metric}, forwarding information could be
presented as the segment list {adjacency-SID 3004 for <AII=B, link
B2> @PE1}.
11.1.3. TE Service over Network Slice with Flex-algo Example
Furthermore, we can use SR Flex-algo to optimize the above SR-TE
instance. For example, for SR-TE instance 1, we can define FA-ID 201
with FAD that contains the same information as the color template, in
turn, FA-ID 202 for SR-TE instance 2, FA-ID 203 for SR-TE instance 3.
Note that each FA-ID also needs to be enabled on ASBR1. So that the
corresponding SR FA entry could be:
For <FA-ID=201, destination=ASBR1> entry, forwarding information
could be ECMP during link A2 and link B2, with destination node-SID
600 for <FA-ID=201, destination=ASBR1>.
For <FA-ID=202, destination=ASBR1> entry, forwarding information
could be link A2, with destination node-SID 700 for <FA-ID=202,
destination=ASBR1>.
For <FA-ID=203, destination=ASBR1> entry, forwarding information
could be link B2, with destination node-SID 800 for <FA-ID=203,
destination=ASBR1>.
11.2. Inter-domain Network Slicing via BGP-LS Example
11.2.1. Best-effort Service Example
For SR-TE instance 4 with color template which defined criteria
including {default AII, min IGP metric}, forwarding information could
be segment list {node-SID 100 for <AII=0, destination=ASBR1> ,
adjacency-SID 1001 for <AII=0, link A1> @ASBR1, node-SID 400 for
<AII=0, destination=PE2> }.
For SR-TE instance 5 with color template which defined criteria
including {AII=A, min IGP metric}, forwarding information could be
Peng, et al. Expires August 19, 2020 [Page 19]
Internet-Draft Packet Network Slicing using SR February 2020
segment list {node-SID 200 for <AII=A, destination=ASBR1> ,
adjacency-SID 1001 for <AII=A, link A1> @ASBR1, node-SID 500 for
<AII=A, destination=PE2> }.
For SR-TE instance 6 with color template which defined criteria
including {AII=B, min IGP metric}, forwarding information could be
segment list {node-SID 300 for <AII=B, destination=ASBR1> ,
adjacency-SID 1003 for <AII=B, link B1> @ASBR1, node-SID 600 for
<AII=B, destination=PE2> }.
11.2.2. TE Service Example
For SR-TE instance 7 with color template which defined criteria
including {default AII, min TE metric}, forwarding information could
be ECMP during two segment list {adjacency-SID 1002 for <AII=0, link
A2> @PE1, adjacency-SID 1001 for <AII=0, link A1> @ASBR1, adjacency-
SID 1002 for <AII=0, link A2> @ASBR2} and {adjacency-SID 1004 for
<AII=0, link B2> @PE1, adjacency-SID 1003 for <AII=0, link B1>
@ASBR1, adjacency-SID 1004 for <AII=0, link B2> @ASBR2}.
For SR-TE instance 8 with color template which defined criteria
including {AII=A, min TE metric}, forwarding information could be
segment list {adjacency-SID 2002 for <AII=A, link A2> @PE1,
adjacency-SID 2001 for <AII=A, link A1> @ASBR1, adjacency-SID 2002
for <AII=A, link A2> @ASBR2}.
For SR-TE instance 9 with color template which defined criteria
including {AII=B, min TE metric}, forwarding information could be
segment list {adjacency-SID 3004 for <AII=B, link B2> @PE1,
adjacency-SID 3003 for <AII=B, link B1> @ASBR1, adjacency-SID 3004
for <AII=B, link B2> @ASBR2}.
11.2.3. TE Service Using Flex-algo Example
For TE service, if we use SR Flex-algo to do optimizaztion, the above
forwarding information of each TE instance could inherit the
corresponding SR FA entry, it would look like this:
For SR-TE instance 7, forwarding information could be ECMP during two
segment list {node-SID 600 for <FA-ID=201, destination=ASBR1> ,
adjacency-SID 1001 for <AII=0, link A1> @ASBR1, node-SID 600 for <FA-
ID=201, destination=PE2> } and {adjacency-SID 1004 for <AII=0, link
B2> @PE1, adjacency-SID 1003 for <AII=0, link B1> @ASBR1, adjacency-
SID 1004 for <AII=0, link B2> @ASBR2}.
For SR-TE instance 8 with color template which defined criteria
including {AII=A, min TE metric}, forwarding information could be
segment list {node-SID 700 for <FA-ID=202, destination=ASBR1> ,
Peng, et al. Expires August 19, 2020 [Page 20]
Internet-Draft Packet Network Slicing using SR February 2020
adjacency-SID 2001 for <AII=A, link A1> @ASBR1, node-SID 700 for <FA-
ID=202, destination=PE2> }.
For SR-TE instance 9 with color template which defined criteria
including {AII=B, min TE metric}, forwarding information could be
segment list {node-SID 800 for <FA-ID=203, destination=ASBR1> ,
adjacency-SID 3003 for <AII=B, link B1> @ASBR1, node-SID 800 for <FA-
ID=203, destination=PE2> }.
11.3. Inter-domain Network Slicing via BGP-LU Example
In figure 1, PE2 can allocate and advertise six labels for its
loopback plus color 1, 2, 3, 4, 5, 6 respectively. Suppose color 1
defines {default AII, min IGP metric}, color 2 defines {AII=A, min
IGP metric}, color 3 defines {AII=B, min IGP metric}, and color 4
defines {default AII, min TE metric}, color 5 defines {AII=A, min TE
metric}, color 6 defines {AII=B, min TE metric}. PE2 will advertise
these labels to ASBR2 and ASBR2 then continues to allocate six labels
each for prefix PE2 plus different color. Other nodes will have the
same operation. Ultimately PE1 will maintain six BGP-LU LSP.
For example, the BGP-LU LSP for color 1 will be over SR best-effort
FIB entry node-SID 100 for <AII=0, destination=ASBR1> to pass through
AS1, over adjacency-SID 1001 for <AII=0, link A1>@ASBR1 to pass
inter-AS, over SR best-effort FIB entry node-SID 400 for <AII=0,
destination=PE2> to pass through AS2.
For example, The BGP-LU LSP for color 4 will over SR-TE instance 1
(see section 10.1.2), or SR best-effort FIB entry node-SID 600 for
<FA-id=201, destination=ASBR1> (see section 10.1.3) to pass through
AS1, over adjacency-SID 1001 for <AII=0, link A1>@ASBR1 to pass
inter-AS, over SR-TE instance 1' or corresponding SR FA entry to pass
through AS2. Note that ASBR1 need also understand the meaning of a
specific color and select forwarding resource between two AS.
12. Implementation Suggestions
The implementation cost is low by means of existing segment routing
infrastructure.
12.1. SR-MPLS
As a node often contains control plane and forwarding plane, a
suggestion is that only default AII specific FTN table, i.e,
traditional FTN table, need be installed on forwarding plane, so that
there are not any modification and upgrade requirement for hardware
and existing MPLS forwarding mechanism. FTN entry for non-default
AII instance will only be maintained on the control plane and be used
Peng, et al. Expires August 19, 2020 [Page 21]
Internet-Draft Packet Network Slicing using SR February 2020
for overlay service iteration according to next-hop plus color (color
will give AII information and mapping FA-id information). Note that
ILM entry for all AII need be installed on forwarding plane, that
does not bring any confusion because of prefix-SID allocation per
AII.
SR NHLFE entry and other iteration entry such as <next-hop, color>
can contain AII information for expected packet scheduling. The
Slice Type value of AII can distinguish flows by coarse-grained
classification, while the Instance value of AII can be used for more
scheduling policy.
12.2. SRv6
For SRv6 case, IPv6 address resource is directly used to represent
SID, so that different IPv6 block could be allocated to different
slice. There are two possible ways to advertise slice specfic IPv6
block:
o Traditional prefix reachability, but only for default AII (0)
specific IPv6 block.
o New SRv6 Locator advertisement, for nonzero AII specific IPv6
block.
Forwarding entries for the default AII specific locators advertised
in prefix reachability MUST be installed in the forwarding plane of
receiving routers.
Forwarding entries for the nonzero AII specific locators advertised
in the SRv6 Locator MUST be also installed in the forwarding plane of
receiving SRv6 capable routers when the associated AII is supported
by the receiving node.
The entries of both the above two cases SHOULD be installed in the
unified FIB table, i.e., a single FIB table for default AII, because
different IPv6 block is allocated to different slice. Instead, more
FIB tables created for each VN in dataplane will bring comlexity for
overlay service iteration, that is why MTR has no practical
deployment.
The forwarding information of FIB entry can contain AII information
for expected packet scheduling.
Peng, et al. Expires August 19, 2020 [Page 22]
Internet-Draft Packet Network Slicing using SR February 2020
13. IANA Considerations
This document requests IANA to create a new top-level registry called
"Network Slicing Parameters". This registry is being defined to
serve as a top-level registry for keeping all other Network Slicing
sub-registries.
Additionally, a new sub-registry "AII (TN-slice Identifier)
codepoint" is to be created under top-level "Network Slicing
Parameters" registry. This sub-registry maintains 32-bit identifiers
and has the following registrations:
+============+======================================================+
| Slice Type | Instance | Description |
|(High 8bits)| (Low 24bits) | |
+============+==============+=======================================+
| | 0 | Default Slice: the original physical |
| 0(Normal) | | network. |
| +--------------+---------------------------------------+
| | nonzero | Normal Slice, for user defined. |
+------------+--------------+---------------------------------------+
| | 0 | Resevered. |
| +--------------+---------------------------------------+
| 1(eMBB) | | Slice suitable for the handling of 5G |
| | nonzero | enhanced Mobile Broadband, for user |
| | | defined. |
+------------+--------------+---------------------------------------+
| | 0 | Resevered. |
| +--------------+---------------------------------------+
| 2(URLLC) | | Slice suitable for the handling of |
| | nonzero | ultra- reliable low latency |
| | | communications, for user defined. |
+------------+--------------+---------------------------------------+
| | 0 | Resevered. |
| +--------------+---------------------------------------+
| 3(MIoT) | nonzero | Slice suitable for the handling of |
| | | massive IoT, for user defined. |
+------------+--------------+---------------------------------------+
| | 0 | Resevered. |
| +--------------+---------------------------------------+
| 4(V2X) | nonzero | Slice suitable for the handling of |
| | | V2X services, for user defined. |
+------------+--------------+---------------------------------------+
| 5-255 | any | Unassigned. |
+------------+--------------+---------------------------------------+
Table 1. AII Codepoint
Peng, et al. Expires August 19, 2020 [Page 23]
Internet-Draft Packet Network Slicing using SR February 2020
14. Security Considerations
TBD.
15. Acknowledgements
TBD.
16. Normative references
[I-D.ali-spring-network-slicing-building-blocks]
Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer,
"Building blocks for Slicing in Segment Routing Network",
draft-ali-spring-network-slicing-building-blocks-02 (work
in progress), November 2019.
[I-D.ietf-idr-bgpls-inter-as-topology-ext]
Wang, A., Chen, H., Talaulikar, K., Zhuang, S., and S. Ma,
"BGP-LS Extension for Inter-AS Topology Retrieval", draft-
ietf-idr-bgpls-inter-as-topology-ext-07 (work in
progress), September 2019.
[I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15
(work in progress), December 2019.
[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-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-05 (work in progress), November 2019.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-06 (work in progress),
December 2019.
Peng, et al. Expires August 19, 2020 [Page 24]
Internet-Draft Packet Network Slicing using SR February 2020
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-ietf-spring-sr-service-
programming-01 (work in progress), November 2019.
[I-D.nsdt-teas-transport-slice-definition]
Rokui, R., Homma, S., and K. Makhijani, "IETF Definition
of Transport Slice", draft-nsdt-teas-transport-slice-
definition-00 (work in progress), November 2019.
[I-D.peng-lsr-flex-algo-opt-slicing]
Peng, S., Chen, R., and G. Mirsky, "IGP Flexible Algorithm
Optimazition for Netwrok Slicing", draft-peng-lsr-flex-
algo-opt-slicing-00 (work in progress), November 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>.
[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>.
[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>.
[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>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
Peng, et al. Expires August 19, 2020 [Page 25]
Internet-Draft Packet Network Slicing using SR February 2020
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>.
[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>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>.
Authors' Addresses
Shaofu Peng
ZTE Corporation
Email: peng.shaofu@zte.com.cn
Ran Chen
ZTE Corporation
Email: chen.ran@zte.com.cn
Gregory Mirsky
ZTE Corporation
Email: gregimirsky@gmail.com
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
Peng, et al. Expires August 19, 2020 [Page 26]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/