SUPA Y. Cheng
Internet-Draft China Unicom
Intended status: Informational D. Liu
Expires: February 6, 2017 Alibaba Group
B. Fu
China Telecom
D. Zhang
Freelancer
N. Vadrevu
VN Telecom Consultancy
August 5, 2016
Applicability of SUPA
draft-cheng-supa-applicability-00.txt
Abstract
SUPA will define a generic policy model, an imperative ECA (Event
Condition Action) policy information model and a declarative (intent-
based) policy information model which is the extension of the generic
model, and a set of policy data models which will make use of the
common concepts defined in the generic model. This memo will explore
some typical use cases and demonstrate the applicability of SUPA
policy models.
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 http://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 February 6, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cheng, et al. Expires February 6, 2017 [Page 1]
Internet-Draft Applicability of SUPA August 2016
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Network Manager/Controller . . . . . . . . . . . . . . . 5
4. Use Cases of SUPA . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Use Case 1: SES . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Scenario . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Generic Policy Models . . . . . . . . . . . . . . . . 9
4.1.3. Programmatic approach - SUPA modeling . . . . . . . . 10
4.1.4. SUPA Data Model for SES Use Case . . . . . . . . . . 10
4.2. Use Case 2: VPC . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Generic . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Use Case 3: Traffic Manipulation cross DCs . . . . . . . 20
4.4. Use Case 4: Virtual SP . . . . . . . . . . . . . . . . . 21
4.5. Use Case 5: Instant VPN . . . . . . . . . . . . . . . . . 23
4.6. Use Case 6: traffic optimization and Qos assurance on ISP
DC . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
8. Normative References . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
One of the ways for network service automation is using network
management and operation software applications. The applications may
not be able to directly communicate with each network element; a
hierarchical and extensible framework should be considered to hide
the protocol specific and/or vendor specific details, high level
network and service abstraction, and standardized programming API
will be necessary.
Cheng, et al. Expires February 6, 2017 [Page 2]
Internet-Draft Applicability of SUPA August 2016
SUPA will define policy generic models and data models, for service
management and operation applications. [I-D.strassner-supa-generic-
policy-info-model] defines a common set of concepts for various data
models which may use different languages, protocols, and
repositories.
Three generic models are defined in [I-D.strassner-supa-generic-
policy-info-model]: Generic Policy Model, Eca Policy Rule Model,
Logic Statement Model. The ECA information model is intended for
dynamic service automation; while the Logic Statement Model is
intended for expressing high requirements without being involved in
network details.
Data models can be defined by developers / operators or by any third
party, as long as they follow the common concepts defined in SUPA
generic model. [I-D.chen-supa-eca-data-model] defines a policy data
model of Event-Condition-Action (ECA), which is an example.
The generic data models will be used for domain or service specific
data model. And there is no interoperability requirement for domain
specific data models. The interoperability is guaranteed at the
generic data model level via the common concepts.
2. Terminology
DC Data Center
PCE Path Computation Element
SES Switched Ethernet services
SP Service Provider
SUPA Simplified Use of Policy Abstractions
VM Virtual Machine
VPC Virtual Private Cloud
3. Framework
Cheng, et al. Expires February 6, 2017 [Page 3]
Internet-Draft Applicability of SUPA August 2016
+-----------------------------------------------------------------+
| Service Management |
| |
| +----------------------------------+ |
| | Generic Policy Model | |
| +----+------------------------+----+ |
| D R |
| D R |
| \ / \ / |
| +---------------------------+ +-------------------------------+ |
| | Generic Policy Data Model | | Service Management Data Model | |
| +---------------------------+ +---------------+---------------+ |
| / \ / \ |
| | | |
| | | |
+--------------+--------------------------------+-----------------+
| |
| NETCONF/RESTCONF |
+----+----------------------+----+
C C
C C
\ / \ /
+----------------+-----------+ +-------+--------------------+
| Network Manager/Controller | | Network Manager/Controller |
| +--------------------+ | | +---------------------+ |
| | Network Resource | | | | Network Resource | |
| | Data Model | | | | Data Model | |
| +--------------------+ | | +---------------------+ |
+---+---+---+----------------+ +-----+---+---+--------------+
/ \ / \ / \ / \ / \ / \
C C C C C C
C C C C C C
C C C C C C
\ / \ / \ / \ / \ / \ /
NE1 NE2 NEn NE1 NE2 NEn
Figure 1: Use of SUPA Models
C: Communications
D: Derived from
R: References (i.e., the generic model is used by the system to
instantiate the data model).
As shown in Figure 1, SUPA will define generic policy models, which
are independent of services and use cases. Policy data models can be
derived from the generic models. The data model will define high
level, maybe network-wide policies. Policy data model will be used
Cheng, et al. Expires February 6, 2017 [Page 4]
Internet-Draft Applicability of SUPA August 2016
in conjunction with service data models to generate configurations
for network elements. The service data model is use case specific
and will be developed by operators or third parties, which is out the
scope of SUPA.
The service management applications will send SUPA data models to the
service management system, where policy making and automated policy
enforcement will be performed, and the data models will be mapped to
configuration of network elements. Configuration of network elements
is vendor specific, using various protocols, such Netconf, Restconf,
etc.
SUPA also make use of information collected from network elements.
The information may include warning or fault event, load status,
traffic statistics, etc, which can be used to adjust network
configurations. This kind of automation is done through ECA data
models.
3.1. Network Manager/Controller
+------------------------+ +---------------+
| SUPA Generic Model | | Administrator |
+------------------------+ +---------------+
| |
| | Policy Update
V V
+---------------------------------------------------------------+
| +-------------------+ +-------------------+ |
| | SUPA Data Model A | ... | SUPA Data Model N | |
| +-------------------+ +-------------------+ |
| |
| Network Management / Controller |
| |
| +----------------------------+ +-------------------------+ |
| | Network Resources | | Information Collecting | |
| | (Topology, inventory, etc) | | (Event, Statistic, etc) | |
| +----------------------------+ +---------^---------------+ |
+--------------------------------------------|------------------+
| | SNMP TRAP
| NETCONF | Syslog
| RESTCONF | Netconf Notification
V |
+--------------------------------+
| Network Infrastructure |
+--------------------------------+
Figure 1: Network Manager / Controller
Cheng, et al. Expires February 6, 2017 [Page 5]
Internet-Draft Applicability of SUPA August 2016
The internal details of the network manager / controller may be out
of the scope of SUPA, but explaining how it works may help people to
understand and implement SUPA.
Network administrator can send service deployment and management
request to network manager / controller via SUPA data models. The
data models will be converted into network elements configuration
snippets. The configuration change may be performed instantly, or
later triggered by events. The network manager / controller has the
intelligence to decide which network devices should be configured,
and what the configuration will be, which is derived from the actions
specific in the data models explicitly or implicitly.
Network management related resources and information are stored in
the network manager/controller, which contains the network topology
(physical and virtual interconnection of network elements, etc),
inventory (database of network elements, ports, device type,
capabilities, etc.), protocol specific information, etc.
SUPA will make use of the existing work of other IETF WGs and other
SDOs, such as if the topology data model is already defined in
another IETF WG, SUAP will reference it rather than trying to define
it again.
The network manager / controller will find out the list of network
devices which should be configured for a specific demand or service.
For example, there is a configuration request:
All edge routers shall have SSH disabled.
An edge router is a router with connection to network(s) outside of
the current network domain. The controller will query the topology
database and find out all the routers with the attribute of "device-
role == edge", or the controller may use more complicated algorithms
to find out if a router is an edge route, which is implementation
specific.
Similarly, another example is, the controller can make use of PCE
engine to plan the links between DCs, and make sure the links are
disjoint for better availability in case of failure. The PCE engine
will be used in conjunction with the topology database to find out
possible disjoint links.
The network manager / controller will also have other information,
such as protocol specific information, traffic with TCP destination
port 22 is SNMP traffic.
Cheng, et al. Expires February 6, 2017 [Page 6]
Internet-Draft Applicability of SUPA August 2016
The network manager / controller also collect information from the
network device, such events, logs, statistics, etc. The information
may come from SNMP TRAP, Syslog, NETCONF notification, and other
sources such as vendor specific protocols or extensions. The
collected information may be used in conjunction with SUPA ECA data
models for dynamic configuration change. An example use of the
information is, if the load on a link between two DC exceeds a
threshold, and there are multiple disjoint links between the two DCs,
traffic steering will be triggered.
Event: link_load > threshold
Condition: there are disjoint links
Action: perform traffic steering
Some of the events are already standardized, such SNMP TRAP and
NETCONF notification; some are implementation specific.
SUPA data models explicitly or implicitly specify network actions,
and the actions may be expanded into more detail actions if
necessary, and finally converted into protocol specific, vendor
specific network element configuration snippets.
In the previous example shown below again:
All edge routers shall have SSH disabled.
The action in this case is "disable SSH traffic", the network manager
/ controller should converted this action into configuration "disable
traffic on TCP port 22" in the IP stack, or an ACL rule which will
drop traffic with TCP destination port 22.
The network manager / controller can support various types of
southbound interface, such as NETCONF, RESTCONF, SNMP, OpenFLow, etc,
which make it possible to support devices from different vendors.
This is implementation specific and out of the scope of SUPA.
4. Use Cases of SUPA
4.1. Use Case 1: SES
4.1.1. Scenario
Cheng, et al. Expires February 6, 2017 [Page 7]
Internet-Draft Applicability of SUPA August 2016
+-----------------------------------------------------------------+
| Service Management |
| +----------------------------------+ |
| | Generic Policy Model | |
| +----+------------------------+----+ |
| |
| +---------------------------+ +-------------------------------+ |
| | Generic Policy Data Model | | Service Management Data Model | |
| +---------------------------+ +---------------+---------------+ |
+-----------------------------------------------------------------+
|
|
+------------------------------+
| Network Manager / Controller |
+------------------------------+
|
|
+------------------+
+-------------+ | Traffic Analysis | +--------+
| Headquarter |----------| |-------| Site 1 |
+-------------+ | WAN Optimization | +--------+
+------------------+
|
|
+----------+
| Site 2 |
+----------+
Figure 3: Switched Ethernet Service
Switched Ethernet services (SES) to Small and Medium Businesses
business is a growing business segment of the service provider. As
the Enterprise's applications grow in demands in terms of the
bandwidth and richness of applications, WAN optimization is needed to
improve the service quality. SUPA policy data models can be used for
maximizing the WAN performance by analyzing the traffic and
performing application management and acceleration tools for the
network.
In the use case below, Service Manager (SM) is used for service and
policy definition and Network Manager (Controller) is used for
network topology maintenance and mapping data models to detail
network configurations.
While speed and bandwidth are at the forefront of the WAN
Optimization there need to be tools in place to detect, diagnose,
remedy and report application performance to ensure the SLAs for a
customer are enforced.
Cheng, et al. Expires February 6, 2017 [Page 8]
Internet-Draft Applicability of SUPA August 2016
The service is modeled in terms of what kind of service (Ethernet,
VLAN), bandwidth (10Mbps- 10 Gbps), service package (platinum, gold,
silver) etc.
Policy models are based on an Event condition action like:
1. Bandwidth usage alarm triggers data caching
2. Latency alarm triggers reduction of re transmission
3. WAN outage at a specific site can trigger geographic redundancy
(provided the service is setup for GR)
The above are 3 of the primitives (Event condition action - ECA) on
which the run time operations could be based on. When the service
model is comprehensively designed with more possibilities
(variables), more policy models could be implemented
4.1.2. Generic Policy Models
Requirements and configurations derived from above application
scenarios can be described by service data model and policy data
models as below:
Service data model can be used to describe attributes for the SES,
including service package type (Platinum, gold etc), bandwidth bought
by the subscriber (100Mbps, 10Gbps), connection name -copper/ GigE,
latency, etc.
Policy data model describes a condition when the link capacity
reaches 90%, Service prioritization and WAN optimization need to be
enforced based on the customers service package. Event is the link
utilization and condition is the usage and action is the WAN
optimization. The actions could trigger multiple actions like data
compression, protocol acceleration (like streaming gets priority)
which are beyond the scope of SUPA.
ECA Policy:
Event: link_load > 90%
Condition: acceleration for service available
Action: data compression; protocol acceleration
It is assumed that the network management/controller module has the
network topology and monitors the load on links in the topology.
Cheng, et al. Expires February 6, 2017 [Page 9]
Internet-Draft Applicability of SUPA August 2016
When translating and processing the SUPA data model, the link
information, including link attributes and load, will be provided by
the network management/controller. If the load on a specific link
exceeds a threshold, the network manager/controller will trigger
actions specified in the model.
The actual actions may be vendor specific, network management/
controller specific or device specific. The actions will be mapped
into configuration for network devices. The network management/
controller also need to figure out the set of network devices which
need to be configured based on network topology together with some
other information, such as service specific information. This is the
internal functions of network management/controller, which is out of
the scope of SUPA.
4.1.3. Programmatic approach - SUPA modeling
The advantage of the programmatic approach can be maximized by
defining as many SUPA ECA models as possible in a top down approach.
In this use case, since this is a switched service, point to point
traffic can be identified (by IP Address and port number) and
segmented and whole bandwidth can be utilized by many applications
simultaneously. Examples are: Print jobs, backups etc..
The benefit of the SUPA is in creating many policies upfront. As the
operations grow in complexity SUPA can expand an existing policy by
adding more variables. This is how reusable policies can be
developed upfront and configuration and maintenance operations can be
dealt by modeling and programmatic approach.
Logic Statement Model can also be called as declarative or intent
model. This type of model will describe the service intention
without specifying low level details, such protocol level or network
device level detail, but just the service requirements itself.
4.1.4. SUPA Data Model for SES Use Case
The following model segment is based on [I-D.chen-supa-eca-data-
model].
In the model, the event can be expressed using some standardized
names, such as the SNMP TRAP (linkDown, linkup, Failure, etc), or
"link-load > 90%".
The condition(s) can be expressed using script, such as Python script
hasAcceleration("ses") or Python script hasDisjointLinks(DC1, DC2).
The script is supposed to be interpreted by a script tool and there
Cheng, et al. Expires February 6, 2017 [Page 10]
Internet-Draft Applicability of SUPA August 2016
are various script tools, the implementer can use any one as they
like, either an existing one like Python or a new one. The script
itself is out the scope of SUPA; a simple value will be return by the
script tool. Some complex combination of conditions can be expressed
using script which will give more flexibility.
When handling the condition script, the script tool will be called to
process the script. In this case, the script will communicate with
service management system and/or the tenant database to find out if
any optimization is available for this service or tenant.
Script can also be used for actions.
An example of the script using Python is:
service-name="ses"
// input: service-name, type: string
// output: enhancement, type: string or None if no enhance
def queryEnhanceinCapability(service-name):
for i in range(len(capability-models)):
if getServiceName(capability-models[i]) == service-name:
return getEnhance(capability-models[i])
return None
// input: service-name, type: string
// output: True/False, type: boolean
def hasAcceleration(service-name):
if queryEnhanceinCapability(service-name) == None:
return False
else:
return True
Cheng, et al. Expires February 6, 2017 [Page 11]
Internet-Draft Applicability of SUPA August 2016
The capability data models are supposed to contain the following:
...
ses
compression
...
The SUPA XML example is shown below:
ses-policy
0
00-00-0000
00-00-0000
domain
operatorA-domain1
ses
// detail to be provided by controller
10.1.1.0/24
20.1.1.0/24
Cheng, et al. Expires February 6, 2017 [Page 12]
Internet-Draft Applicability of SUPA August 2016
...... // more filters
...... // to be provided by controller
...... // to be provided by controller
YES
YES
and
YES
entity
// entity or script or boolean
"link-load > 90%"
script
// entity or script or boolean
hasAcceleration(ses)
Cheng, et al. Expires February 6, 2017 [Page 13]
Internet-Draft Applicability of SUPA August 2016
Python
// Python or Perl or any other script
data compression
protocol acceleration
The data model can be augmented according to developers' need. The
developers can add vendor specific events, conditions and actions via
"augment" Yang function in [RFC6020], as suggested in [I-D.chen-
supa-eca-data-model].
An example of of augmented model is shown below:
// ------- yang model snippet start -------
augment "/supa:supa-policy/supa:supa-policy-statement/supa:event-
list" {
leaf my-event{
description "customized event";
type bool;
}
}
augment "/supa:supa-policy/supa:supa-policy-
statement/supa:condition-list" {
container my-condition{
description "The bandwidth threshold, unit is Mbps";
type uint32;
}
}
augment "/supa:supa-policy/supa:supa-policy-statement/supa:action-
list" {
container my-action-drop{
description "drop packets";
type string;
}
}
Cheng, et al. Expires February 6, 2017 [Page 14]
Internet-Draft Applicability of SUPA August 2016
// ------- yang model snippet end -------
// ------ xml model snippet start -------
// assume the above augmentation is in a name space "mymodel"
...... // others
...... // other events
true
// added event
...... // other conditions
32
// added condition
...... // other actions
drop
// added action
// ------ xml model snippet end ------
Cheng, et al. Expires February 6, 2017 [Page 15]
Internet-Draft Applicability of SUPA August 2016
4.2. Use Case 2: VPC
4.2.1. Generic
In practice, a public cloud operator can virtualize the cloud
resources into multiple isolated virtualized private clouds and
provide them to different tenants. Such a Virtualized Private Cloud
is referred to as a VPC. In a typical VPC provided by, e.g., Alibaba
or Amazon, through a control portal, tenants can establish and manage
their VPC networks easily, for instance, deploying or removing
virtualized network devices (e.g., virtualized routers and
virtualized switches), adjusting the topologies of VPC networks,
specifying packet forwarding policies, and deploying or removing
virtual services (e.g., load balancers, firewalls, databases, DNS,
etc.). The network functionalities that the tenant can access are
virtualized and actually could be performed by the VMs located on the
servers connected through physical or overlay networks. Note that
the servers may be located in different data centers which are
geographically distributed.
The manipulation of the virtualized VPC network may also affect the
configuration of physical networks. For instance, when a tenant
cloud networks and specify the policies to steer the traffics through
different VPNs in different conditions. Note that the VPCs that the
tenant may be located in different geographic regions and the VPNs to
those VPCs may need to be generated at run time. newly deploys two
VMs in the VPC which are located in different DCs, the VPC control
mechanism may have to generate a VPN between two DCs for the internal
VPC communication. Therefore, the control mechanism for a VPC should
be able to adjust the underlying network when a tenant changes the
network or service deployment of the virtual VPC network.
In addition, a VPC, often provides other value added services (e.g.,
database Services, DNS) for VMs in certain VPCs. The VMs and the
value added services could be located in different DCs, or even
provided by different vendors. VPNs are configured for the VPCs to
provide connection to the internal services in a tenant's own DC or
organization. The access of such services should be controlled. For
instance, the VMs in a VPC can access the database services only when
the tenant has deployed a database within its VPC through the control
portal.
In many cases, a tenant may need to specify how the VPCs are
connected to its enterprise cloud networks. For instance, a tenant
wants to deploy multiple VPNs to connect the VPC with its private
cloud networks and specify the policies to steer the traffics through
different VPNs in different conditions. Note that the VPCs that the
Cheng, et al. Expires February 6, 2017 [Page 16]
Internet-Draft Applicability of SUPA August 2016
tenant may be located in different geographic regions and the VPNs to
those VPCs may need to be generated at run time.
In addition, a VPC, often provides other value added services (e.g.,
database Services, DNS) for VMs in certain VPCs. The VMs and the
value added services could be located in different DCs, or even
provided by different vendors. VPNs are configured for the VPCs to
provide connection to the internal services in tenant's own DC or
organization, and to create and manage VPNs to internal services.
The access of VMs to data resources should be controlled. For
instance, the VMs in a VPC can access a database service only when
the tenant has deployed a database service into its VPC through the
control portal.
4.2.2. Example 1
+--------------------+
| DC2 |
| +----------------+ |
| |Tenant x (vDC) | |
| +----------------+ |
| |
| +----------------+ |
| | Tenant 1 (vDC) | |
| +----------------+ |
+----------|---------+
|
|
+-------------+
| Cloud |
/| |\
/ +-------------+ \
/ \
/ \
+-----------------/--+ +----\---------------+
| DC1 / | | DC3 \ |
| +----------------+ | | +----------------+ |
| | Tenant 1 (vDC) | | | | Tenant 1 (vDC) | |
| +----------------+ | | +----------------+ |
| | | |
| +----------------+ | | +----------------+ |
| | Tenant n (VDC) | | | | Tenant k (vDC) | |
| +----------------+ | | +----------------+ |
+--------------------+ +--------------------+
Figure 4: Resource Inter-connection for a VPC Tenant
Cheng, et al. Expires February 6, 2017 [Page 17]
Internet-Draft Applicability of SUPA August 2016
When a cloud / DC operator signs a contract with customers, resource
information such as network bandwidth, storage size, number of CPU,
memory size, etc, will be specified.
But in deployment, the resources may be located in multiple
distributed data centers, and tunnels will be created to connect
these resources, which makes it look like one seamless entity - a
virtual DC. There could be quite a number of tunnels, and the
tunnels are dynamic, either for the reason of load balancing purpose
or VM migration, or other reasons. This will make it difficult to
configure the service statically or manually, service automation is
very necessary.
The service management system will have a repository of available
resources, including the topology. And also the management system
will have the customer specific information (location, SLA, agreed
resources, etc).
The administrator can send the service requirement to the management
system by a high level data model, which can further be mapped to low
level detail data models, then finally mapped to configurations of
network devices.
Target: Provide VPC service to customer A with specified resources
and function (storage, computing, DNS, etc)
Declarative policy:
1. Allocate the required services on DCs according to a user's
profile
2. Services located in multiple distributed DCs must be
interconnected via VPNs
3. The VPNs associated to the services provided for a user must
match the user's profile in terms of latency, speed and bandwidth
4.2.3. Example 2
Cheng, et al. Expires February 6, 2017 [Page 18]
Internet-Draft Applicability of SUPA August 2016
+----------+ Tenant move to +----------+
| Tenant A | ------------------> | Tenant A |
+----------+ another location +----------+
| |
| |
| |
+--------V-------+ _+--------V-------+
| +----------+ | | +----------+ |
| | VM for | | VM Migration | | VM for | |
| | Tenant A | | -----------------> | | Tenant A | |
| +----------+ | if network load | +----------+ |
| DC-Location1 | between DCs is low | DC-Location2 |
+----------------+ +----------------+
Figure 5: VM Migration if Tenant Move
As shown in the above figure, when a VPC tenant move from one
location to another, where it is near to another DC, and the network
load between the new DC and the previous DC is low, the tenant's VM
should be migrated to the new DC in order for better user experience.
After the VM is moved to the new DC, the network related to the VM
must be updated accordingly.
Target: Perform VM migration when user location changed and the
network load between the DCs is low.
ECA Policy:
Event: a VPC user's location is changed (near to another DC).
Condition: network_load(DC_old, DC_new) < threshold.
Action:
1. Migrate the VM to the new data center (DC_new).
2. Update the VPNs connecting the user's services.
In the above model it is assumed that the network management/
controller has the network topology, including attributes of the
links, such as bandwidth. The network management/controller also
monitors the real-time load on the links in the network topology.
The user's location can be identified by the user's IP address. When
a user login, the network management/controller will check the user's
Cheng, et al. Expires February 6, 2017 [Page 19]
Internet-Draft Applicability of SUPA August 2016
IP address against an IP address database, such as the IP address
assignments by IANA.
The network management/controller also maintain a mapping of DCs and
IP address segments, say, a DC should serve users in a near location
which can be identified by IP address segments. Though this is not
always the case, sometimes the geographical distribution of network
resource will also need to be considered besides the location (IP
address). But, anyway, a mapping of DC and the IP address it should
serve should be maintained.
If the controller detects a location change and a new DC is possible
for the user, and the network load between the new DC and the old DC
is low, then VM migration will be triggered and related network
configuration will be performed.
4.3. Use Case 3: Traffic Manipulation cross DCs
DCs usually have multiple external links, either to other DCs or to
the internet. Because of the dynamic nature of network traffic, the
load on a link may vary at different times of a day, e.g. link mainly
carries enterprise traffic may have a high load in the working hours
but less traffic in the night. Some events may also impact the load
of links, such as one link is physically damaged and the load in it
will go to another link.
In order to make full use of the bandwidth of the links, dynamic
traffic steering is necessary for SLA meanwhile with full use of
network resource.
----------------------------
/ \
+--------+ +--------+
| | | |
| DC 1 |--------------------| DC 2 |
| | | |
+--------+ +--------+
\ /
\ /
\ /
\ /
\ +--------+ /
\| | /
| DC 3 |
| |
+--------+
Figure 6: Multiple Disjoint Links Between DCs
Cheng, et al. Expires February 6, 2017 [Page 20]
Internet-Draft Applicability of SUPA August 2016
Target: a DC has multiple external links. When the load on a link is
over a threshold, perform traffic steering for a better bandwidth
resource usage
ECA Policy:
Event: load on a DC link exceeds threshold.
Condition: multiple disjoint links between DCs.
Action: steer some traffic to link with low load.
In the above case, it is assumed that the network management/
controller has the network topology, including attributes of the
links, such as bandwidth. The network management/controller also
monitors the real-time load on the links in the network topology.
The network topology also contains the connections between network
devices. The network management/controller will be able to figure
out if there are multiple disjoint links between two DCs. The
algorithm for finding out disjoint links is out of the scope of SUPA.
When the network management/controller detects the load on a link
exceeds a threshold, it can check if there are multiple disjoint
links, and if yes, it will then further perform necessary actions as
pre-specified.
4.4. Use Case 4: Virtual SP
Virtual network operators usually do not build all networks,
including access network, metro network, and backbone network, by
themselves. Instead, they rent network from other operators. For
instance, a virtual operator may not have the access network,
traffics of broadband network subscribers will go through an access
network rent from another operators, and then be directed to the
virtual operators network from the BNG via tunnels. In some another
case, a virtual operator may not have the backbone network, the
network islands and DCs will be connected by tunnels.
In above cases, virtual network operators may have to face an issue.
That is, they have no control over the tunnels and cannot decide the
exact path that a tunnel should go through. In some scenarios, if a
tunnel goes through the border of two network operators, or the
tunnel goes through an area where network load is too high, the SLA
may become a problem. Due to cost issue, virtual network operators
cannot buy service from other operators with critical SLA. This
problem will be even more serious to the a virtual network operator
who runs its business in a large geographical region.
Cheng, et al. Expires February 6, 2017 [Page 21]
Internet-Draft Applicability of SUPA August 2016
A possible solution for such a virtual network operator is to rent or
put some routers in network operators' DCs, and then configure
tunnels between the routers and perform traffic steering. In this
way, virtual network operators can have control over the tunnels, pin
down the path. When a problem is detected, such as QoS of a tunnel
is below a threshold, virtual network operator can perform "network
wide" optimization, reconfigure the tunnels and/or perform traffic
steering.
+------------+ +------------+
| vNetwork 1 | | vNetwork 2 |
+------------+ +------------+
\ /
\ /
\ /
+--------------+ +--------------+
| +----------+ | tunnel 1 | +----------+ |
| | Router 1 | |--------------| | Router 2 | |
| +----------+ | | +----------+ |
| Operator DC1 | | Operator DC2 |
+--------------+ +--------------+
| \
| \
| \
+--------------+ \
| +----------+ | tunnel 2 +------------+
| | Router 2 | |---------------------| vNetwork 3 |
| +----------+ | +------------+
| Operator DC3 |
+--------------+
Figure 7: Segment Tunnels for Virtual Network Operator
Assume the route of a direct tunnel built between virtual operator's
networks (e.g. vNetwork1-to-vNetwork3) is out of control. For
instance, the route may go through network node with problems, or the
route may go across the border of different operators where QoS
cannot be guaranteed.
In this case, the virtual network operator can configure three
tunnels rather than one to connect vNetwork1 to vNetwork3: vNetwork1-
to-Router1, Router1-to-Router2, Router2-to-vNetwork3.
After the initial network configuration is finished, if any problem
is detected in any tunnel, the network management system can perform
network wide optimization, taking all the routers into account and
working out another set of tunnels if necessary.
Cheng, et al. Expires February 6, 2017 [Page 22]
Internet-Draft Applicability of SUPA August 2016
ECA Policy:
Event: QoS parameters < threshold.
Condition: multiple disjoint tunnels available.
Action: Network wide tunnel optimization + traffic steering.
In this case, the virtual SP can monitor the real-time QoS parameters
between the virtual networks and the rented routers. If the QoS
parameters exceed a threshold, and the virtual has deployed multiple
rented routers which can provide multiple disjoint tunnels, then the
network management/controller can trigger network wide tunnel
optimization and/or perform traffic steering.
When performing the tunnel optimization, the network management/
controller may terminate the tunnel(s) which go through specific
network area with problems, and/or build new tunnels, and/or perform
network wide traffic steering. This will give the operator a lot of
flexibility in controlling the network.
The traffic steering may need to be combined with the network
topology, and dynamically distribute traffic in the whole network.
4.5. Use Case 5: Instant VPN
Cheng, et al. Expires February 6, 2017 [Page 23]
Internet-Draft Applicability of SUPA August 2016
+------------------------+
| SUPA Generic Model |
+------------------------+
|
|
+-------------------------------+
| +---------------------------+ |
| | SUPA Data Model | |
| +---------------------------+ |
| +---------------------------+ |
| | SUPA Translation Function | |
| +---------------------------+ |
+-------------------------------+
/
/VPN Req Forwarded to Management System
/
+------+ VPN +------+ +------+ +------+
| CE |-------| PE |------| PE |------| PE |
+------+ Req +------+ +------+ +------+
| | |
| | |
+------+ +------+ +------+
| PE |------| PE |------| PE |
+------+ +------+ +------+
Figure 8: Instant VPN
Traditionally, when an operator needs to deploy VPN services for an
enterprise customer, they will send a service staff to the customer
site and make the wire connection between the CE and PE. The service
staff will also collect the configuration information, e.g.
port/frame/slot of PE, PE ID, etc, and then send the collected
information back to the management system. The management system
will configure the network according to this information as well as
the customer' information (such as bandwidth, SLA, etc). The problem
of this approach is that the service staff needs to collect the
connection information and feedback to the management system, and
MUST make sure the information matches the actual connection. This
process is error prone.
New approach should not count on the physical / geographical
information feedback by the service staff, minimize the operation
procedures. The CE should send authentication (with credentials)
request to the PE, and PE should forward the request to the
management system together with port/frame/slot on which the request
is received, the PE ID etc.
Target: Configure VPN for an enterprise customer to connect its
enterprise network with VPC
Cheng, et al. Expires February 6, 2017 [Page 24]
Internet-Draft Applicability of SUPA August 2016
ECA Policy:
Event: service management system receive a CE request for VPN
creation (forwarded by PE).
Condition: Authentication and Authorization results are OK.
Action: Configure VPN based on received request, including the user's
grade and physical info (port/slot/frame/route id, etc, from which
the request is received).
4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC
ISPs usually build DCs at the core network border, DCs have more than
one uplinks to DC core network; users at MAN can access the core from
different links too. Different links may have unbalanced load
because of the nature of network traffic. In order to provide
service assurance for import tenant, network administrators need to
schedule the traffic in specific periods. Traditional network
management is usually complex with a long cycle, so it is difficult
to meet the request of real-time traffic optimization.
+-------------------+ +-------------------+ +-------------------+
| IDC | | | | MAN |
| | / X X \ | |
| +--------+ | / | | \ | +-------+ |
| | VIP | |/ | | \ | | VIP | |
| | Tenant | X | ISP CORE | X | User | |
| +--------+ |\ | | / | +-------+ |
| | \ | | / | |
| | \ X X / | |
| | | | | |
+-------------------+ +-------------------+ +-------------------+
Figure 9: traffic optimization and Qos assurance on ISP DC
Assume that a network controller or orchestrator can monitor network
topology, including real-time link utilization and flow information.
When utilization of a link reaches a certain threshold, specific
flows should be steered to a low load link according to IP address
and AS number.
Large service provider's traffic usually has time characteristics,
for example, online big sales, network administrator can provide
bandwidth assurance for important tenant according to their IP
address.
Cheng, et al. Expires February 6, 2017 [Page 25]
Internet-Draft Applicability of SUPA August 2016
Target 1: a DC has multiple external links. When the load on a link
is over a threshold, perform traffic steering for a better bandwidth
resource usage.
ECA Policy:
Event: load on a DC link exceeds threshold or a VIP tenant needs
bandwidth assurance.
Condition: DC has multiple external links.
Action: steer VIP's traffic to link with low load in a specific
period.
Target 2: Tenants or users may have critical request on network Qos.
When there are enough bandwidth along the link, perform resource
reservation for VIP's traffic on specific links.
ECA Policy:
Event: Tenants or users have critical network requests.
Condition: Resources along the link are enough for reservation.
Action: perform resource reservation for VIP's traffic on specific
links.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
Since SUPA models can be used to generate configurations for network
elements, the management applications which send models to service
management system must go through authentication and authorization.
The handling of conflicition of different polcies is out of scope of
this memo.
7. Acknowledgements
This document has benefited from reviews, suggestions, comments and
proposed text provided by the following members, listed in
Cheng, et al. Expires February 6, 2017 [Page 26]
Internet-Draft Applicability of SUPA August 2016
alphabetical order: Juergen Schoenwaelder, John Strassner, James
Huang.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
.
Authors' Addresses
Ying Cheng (Editor)
China Unicom
No.21 Financial Street, XiCheng District
Beijing 100033
China
Phone: +86-010-66259394
Email: chengying10@chinaunicom.cn
Dapeng Liu
Alibaba Group
Beijing 100022
China
Email: max.ldp@alibaba-inc.com
Borui Fu (Editor)
China Telecom
Beijing
China
Email: fubr@ctbri.com.cn
Cheng, et al. Expires February 6, 2017 [Page 27]
Internet-Draft Applicability of SUPA August 2016
Dacheng Zhang
Freelancer
Beijing
China
Email: Dacheng.zhang@gmail.com
Narasimha Vadrevu
VN Telecom Consultancy
Email: vadrevun@von20.com
Cheng, et al. Expires February 6, 2017 [Page 28]