Applicability of SUPA
draft-vadrevu-supa-applicability-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Narasimha Rao Vadrevu , Dacheng Zhang , Alibaba Group | ||
| Last updated | 2015-10-19 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vadrevu-supa-applicability-05
Network Working Group N. Vadrevu
Internet Draft VN Telecom Consultancy
Intended status: Informational D. Zhang
Expires: April 19, 2016 S. Zhu
Alibaba Group
October 19, 2015
Applicability of SUPA
draft-vadrevu-supa-applicability-05
Abstract
SUPA will define a generic policy model, an imperative (Event-
Condition-Action, ECA) 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
Vadrevu et al. Expires April 19, 2016 [Page 1]
Internet-Draft SUPA Model Applicability September 2015
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 19, 2016.
Copyright Notice
Copyright (c) 2015 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
(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 ................................................ 3
2. Conventions ................................................. 3
3. Termilogy ................................................... 3
4. Framework ................................................... 4
4.1. Network Manager/Controller ............................. 6
5. SUPA Examples ............................................... 9
5.1. SES Use Case ........................................... 9
5.1.1. Scenario .......................................... 9
5.1.2. Generic Policy Models ............................ 10
5.1.3. Programmatic approach - SUPA modeling ............ 11
5.1.4. SUPA Data Model for SES Use Case ................. 12
5.2. VPC Use Case .......................................... 17
5.2.1. Generic .......................................... 17
5.2.2. Example1 ......................................... 18
5.2.3. Example2 ......................................... 20
5.3. DC Link Use Case ...................................... 21
5.4. Virtual SP Use Case ................................... 22
5.5. Instant VPN Use Case .................................. 25
6. Security Considerations .................................... 26
7. IANA Considerations ........................................ 26
8. Acknowledgments ............................................ 26
Vadrevu et al. Expires April 19, 2016 [Page 2]
Internet-Draft SUPA Model Applicability September 2015
9. References ................................................. 27
9.1. Normative References .................................. 27
9.2. Informative 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
should not 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.
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. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
3. Termilogy
DC Data Center
Vadrevu et al. Expires April 19, 2016 [Page 3]
Internet-Draft SUPA Model Applicability September 2015
PCE Path Computation Element
SES Switched Ethernet services
SP Service Provider
SUPA Simplified Use of Policy Abstractions
VM Virtual Machine
VPC Virtual Private Cloud
4. Framework
+-----------------------------------------------------------------+
| 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 |
| +--------------------+ | | +---------------------+ |
Vadrevu et al. Expires April 19, 2016 [Page 4]
Internet-Draft SUPA Model Applicability September 2015
| | 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
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.
Vadrevu et al. Expires April 19, 2016 [Page 5]
Internet-Draft SUPA Model Applicability September 2015
4.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 2 Network Manager / Controller
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,
Vadrevu et al. Expires April 19, 2016 [Page 6]
Internet-Draft SUPA Model Applicability September 2015
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.
Vadrevu et al. Expires April 19, 2016 [Page 7]
Internet-Draft SUPA Model Applicability September 2015
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.
Vadrevu et al. Expires April 19, 2016 [Page 8]
Internet-Draft SUPA Model Applicability September 2015
5. SUPA Examples
5.1. SES Use Case
5.1.1. Scenario
+-----------------------------------------------------------------+
| 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.
Vadrevu et al. Expires April 19, 2016 [Page 9]
Internet-Draft SUPA Model Applicability September 2015
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.
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
5.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.
Vadrevu et al. Expires April 19, 2016 [Page 10]
Internet-Draft SUPA Model Applicability September 2015
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.
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.
5.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.
Vadrevu et al. Expires April 19, 2016 [Page 11]
Internet-Draft SUPA Model Applicability September 2015
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.
5.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 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])
Vadrevu et al. Expires April 19, 2016 [Page 12]
Internet-Draft SUPA Model Applicability September 2015
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
The capability data models are supposed to contain the following:
<capability-data-model>
...
<services>
<service>
<service-name>ses</service-name>
<service-enhance>compression</service-enhance >
</service>
<service>
...
</service>
<services>
</capability-data-model>
Vadrevu et al. Expires April 19, 2016 [Page 13]
Internet-Draft SUPA Model Applicability September 2015
The SUPA XML example is shown below:
<supa-policy>
<supa-policy-name>ses-policy</supa-policy-name>
<supa-policy-priority>0</supa-policy-priority>
<supa-policy-validity-period>
<start>00-00-0000</start>
<end>00-00-0000</end>
</supa-policy-validity-period>
<supa-policy-target>
<profileType>domain</profileType>
<asDomainName>operatorA-domain1</asDomainName>
<businessTypeName>ses</businessTypeName>
<instance>
<instanceName>
// detail to be provided by controller
<flow-filter>
<src-ip-addr>10.1.1.0/24</src-ip-addr>
<dst-ip-addr>20.1.1.0/24</dst-ip-addr>
</flow-filter>
<flow-filter>
...... // more filters
</flow-filter>
</instanceName>
</instance>
</supa-policy-target>
<supa-policy-atomic>
<supa-ECA-policy-rule>
<policy-rule-deploy-status>
...... // to be provided by controller
</policy-rule-deploy-status>
<policy-rule-exec-status>
...... // to be provided by controller
</policy-rule-exec-status>
<supa-ECA-component>
<supa-policy-events>
<has-policy-events>YES</has-policy-events>
</supa-policy-events>
<supa-policy-conditions>
<has-policy-conditions>YES</has-policy-conditions>
<conjunctive-type>and</conjunctive-type>
</supa-policy-conditions>
<supa-policy-actions>
<action-execution>YES</action-execution>
Vadrevu et al. Expires April 19, 2016 [Page 14]
Internet-Draft SUPA Model Applicability September 2015
</supa-policy-actions>
</supa-ECA-component>
</supa-ECA-policy-rule>
</supa-policy-atomic>
<supa-policy-statement>
<event-list>
<event-name>
<eventType>entity</eventType>
// entity or script or boolean
<entity>"link-load > 90%"</entity>
</event-name>
</event-list>
<condition-list>
<condition-linkThreshold>
<conditionType>script</conditionType>
// entity or script or boolean
<supa-script>
<supa-script-content>hasAcceleration(ses)</supa-script-
content>
<supa-script-type>Python</supa-script-type>
// Python or Perl or any other script
</supa-script>
</condition-linkThreshold>
</condition-list>
<action-list>
<actionName>data compression</actionName>
<actionName>protocol acceleration</actionName>
</action-list>
</supa-policy-statement>
</supa-policy>
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;
Vadrevu et al. Expires April 19, 2016 [Page 15]
Internet-Draft SUPA Model Applicability September 2015
}
}
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;
}
}
// ------- yang model snippet end -------
// ------ xml model snippet start -------
// assume the above augmentation is in a name space "mymodel"
<supa-policy>
...... // others
<supa-policy-statement>
<event-list>
<event-name>
...... // other events
</event-name>
<mymodel:my-event>
true
</mymodel:my-event> // added event
</event-list>
<condition-list>
<condition-linkThreshold>
...... // other conditions
</condition-linkThreshold>
<mymodel:my-condition>
32
</mymodel:my-condition> // added condition
</condition-list>
<action-list>
<actionName>
Vadrevu et al. Expires April 19, 2016 [Page 16]
Internet-Draft SUPA Model Applicability September 2015
...... // other actions
</actionName>
<mymodel:my-action-drop>
drop
</mymodel:my-action-drop> // added action
</action-list>
</supa-policy-statement>
</supa-policy>
// ------ xml model snippet end ------
5.2. VPC Use Case
5.2.1. Generic
In practice, a public cloud operator can virtualize the cloud
resources into multiple isolated virtualized private clouds and
provide them to 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, a tenant can establish and
manage the network easily, for instance, deploying or removing
virtualized network devices (e.g., virtualized routers and
virtualized switches), adjusting the topology 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 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
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 many cases, a tenant may need to specify how the VPCs are
connected to its enterprise cloud networks. For instance, a tenant
may want to deploy multiple VPNs to connect the VPC with its private
Vadrevu et al. Expires April 19, 2016 [Page 17]
Internet-Draft SUPA Model Applicability September 2015
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.
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 the database services only
when the tenant has deployed database into its VPC through the
control portal.
5.2.2. Example1
+--------------------+
| DC2 |
| +----------------+ |
| |Tenant x (vDC) | |
| +----------------+ |
| |
| +----------------+ |
| | Tenant 1 (vDC) | |
| +----------------+ |
+----------|---------+
|
|
+-------------+
| Cloud |
/| |\
/ +-------------+ \
/ \
/ \
+-----------------/--+ +----\---------------+
| DC1 / | | DC3 \ |
| +----------------+ | | +----------------+ |
Vadrevu et al. Expires April 19, 2016 [Page 18]
Internet-Draft SUPA Model Applicability September 2015
| | Tenant 1 (vDC) | | | | Tenant 1 (vDC) | |
| +----------------+ | | +----------------+ |
| | | |
| +----------------+ | | +----------------+ |
| | Tenant n (VDC) | | | | Tenant k (vDC) | |
| +----------------+ | | +----------------+ |
+--------------------+ +--------------------+
Figure 4 Resource Inter-connection for a VPC Tenant
When cloud / DC operator signs a contract with customer, 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 inter-
connect these resources, which will make 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
Vadrevu et al. Expires April 19, 2016 [Page 19]
Internet-Draft SUPA Model Applicability September 2015
3. The VPNs associated to the services provided for a user must
match the user's profile in terms of latency, speed and bandwidth
5.2.3. Example2
+----------+ 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)
Vadrevu et al. Expires April 19, 2016 [Page 20]
Internet-Draft SUPA Model Applicability September 2015
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 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.
5.3. DC Link Use Case
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.
----------------------------
/ \
+--------+ +--------+
Vadrevu et al. Expires April 19, 2016 [Page 21]
Internet-Draft SUPA Model Applicability September 2015
| | | |
| DC 1 |--------------------| DC 2 |
| | | |
+--------+ +--------+
\ /
\ /
\ /
\ /
\ +--------+ /
\| | /
| DC 3 |
| |
+--------+
Figure 6 Multiple Disjoint Links Between DCs
Target: DC have multiple external links; when the load on a link is
too high, perform traffic steering for 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 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 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 this
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 further perform necessary actions
specified in the model.
5.4. Virtual SP Use Case
Virtual network operators usually do not have a complete network,
including access network, metro network, and backbone network. They
Vadrevu et al. Expires April 19, 2016 [Page 22]
Internet-Draft SUPA Model Applicability September 2015
need to rent network from other operators. An example is, a virtual
operator do not have the access network, traffic of broadband
network subscriber will go through other operators access network,
and then be directed to the virtual operators network from the BNG
via tunnels. In some other cases, the virtual operators may not have
the backbone network, the network islands and DCs will be connected
by tunnels.
The problem in this case is, virtual network operators have no
control over the tunnels and they cannot decide the exact path that
the tunnel should go through. In some scenarios, if the tunnel goes
through the border of two network operators, or the tunnel goes
through an area where network load is too high, the SLA will be a
problem. Virtual network operators who run the business in a large
geographical region often run into this problem. Due to cost issue,
virtual network operators cannot buy service from other operators
with critical SLA.
A possible solution is, the virtual network operator 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 |
+--------------+ +--------------+
| \
| \
| \
+--------------+ \
Vadrevu et al. Expires April 19, 2016 [Page 23]
Internet-Draft SUPA Model Applicability September 2015
| +----------+ | tunnel 2 +------------+
| | Router 2 | |---------------------| vNetwork 3 |
| +----------+ | +------------+
| Operator DC3 |
+--------------+
Figure 7 Segment Tunnels for Virtual Network Operator
If direct tunnel is built between virtual operator's networks (e.g.
vNetwork1-to-vNetwork3), route is out of control -- the route may go
through network node with problems, or with high load, or cross
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.
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.
Vadrevu et al. Expires April 19, 2016 [Page 24]
Internet-Draft SUPA Model Applicability September 2015
The traffic steering may need to be combined with the network
topology, and dynamically distribute traffic in the whole network.
5.5. Instant VPN Use Case
+------------------------+
| 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 service 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 information
back to the management system, and the management system will
configure the network according to this information together with
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 operation is error prone.
Vadrevu et al. Expires April 19, 2016 [Page 25]
Internet-Draft SUPA Model Applicability September 2015
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
ECA Policy:
Event: service management system receive a CE request for VPN
creation (forwarded by PE)
Condition: Authentication OK
Action: Configure VPN based on received request, including user
grade and physical info (port/slot/frame/route id, etc, from
which the request is received)
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.
7. IANA Considerations
This memo does not have any requirement to IANA.
8. Acknowledgments
This document has benefited from reviews, suggestions, comments
and proposed text provided by the following members, listed in
alphabetical order: Juergen Schoenwaelder, John Strassner, James
Huang
Vadrevu et al. Expires April 19, 2016 [Page 26]
Internet-Draft SUPA Model Applicability September 2015
This document was prepared using 2-Word-v2.0.template.dot.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, April 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
9.2. Informative References
[I-D.klyus-supa-proposition] Klyus, M., Strassner, J., "SUPA Value
Proposition", draft-klyus-supa-proposition-02 (work in
progress), July 4, 2015
[I-D.strassner-supa-generic-policy-info-model] Strassner, J.,
"Generic Policy Information Model for Simplified Use of
Policy Abstractions (SUPA)", draft-strassner-supa-
generic-policy-info-model-02, July 4, 2015
[I-D.chen-supa-eca-data-model] Chen, M., Contreras L., Fukushima, M.,
"ECA Policy YANG Data Model", draft-chen-supa-eca-data-
model-03 (work in progress), August 26, 2015
[I-D.ww-sfc-control-plane] Li, H., Wu, Q., et al, "Service Function
Chaining (SFC) Control Plane Components & Requirements",
draft-ww-sfc-control-plane-06 (work in progress), June 8,
2015
Authors' Addresses
Narasimha Vadrevu
VN Telecom Consultancy
Cupertino, California
Email: vadrevun@von20.com
Vadrevu et al. Expires April 19, 2016 [Page 27]
Internet-Draft SUPA Model Applicability September 2015
Dacheng Zhang
Alibaba Group
Email: Dacheng.zdc@alibaba-inc.com
Shunmin Zhu
Alibaba Group
Email: jianghe.zsm@taobao.com
Vadrevu et al. Expires April 19, 2016 [Page 28]