One document matched: draft-vadrevu-supa-applicability-01.txt
Differences from draft-vadrevu-supa-applicability-00.txt
Network Working Group N. Vadrevu
Internet Draft VN Telecom Consultancy
Intended status: Informational D. Zhang
Expires: January 2016 Alibaba Group
July 23, 2015
Applicability of SUPA
draft-vadrevu-supa-applicability-00
Abstract
SUPA will define a generic policy information 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 information model, and a set of policy data
models which will make use of the common concepts defined in the
information 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
xxx Expires January 23, 2016 [Page 1]
Internet-Draft SUPA Model Applicability July 2015
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
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 January 23, 2009.
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. Framework ................................................... 3
4. SUPA Model Applicability .................................... 5
4.1. ECA Data Model ......................................... 5
4.1.1. SES Use Case ...................................... 5
4.1.1.1. Scenario ..................................... 5
4.1.1.2. Generic Policy Information Models ............ 7
4.1.1.3. Programmatic approach - SUPA modeling......... 8
4.1.2. DDC Use Case ...................................... 8
4.1.3. Instant VPN ....................................... 8
4.2. Declarative Data Model.................................. 9
5. Security Considerations .................................... 11
6. IANA Considerations ........................................ 11
7. Acknowledgments ............................................ 11
8. References ................................................. 11
8.1. Normative References .................................. 11
8.2. Informative References ................................ 11
xxx Expires January 23, 2016 [Page 2]
Internet-Draft SUPA Model Applicability July 2015
Authors' Addresses ............................................ 12
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 information 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 information models are defined in [I-D.strassner-supa-generic-
policy-info-model]: Generic Policy Information Model (GPIM), Eca
Policy Rule Information Model (EPRIM), Logic Statement Information
Model (LSIM). The ECA information model is intended for dynamic
service automation; while the LSIM 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
information model. [I-D.chen-supa-eca-data-model] defines a policy
data model of Event-Condition-Action (ECA), which is an example.
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. Framework
xxx Expires January 23, 2016 [Page 3]
Internet-Draft SUPA Model Applicability July 2015
+-----------------------------------------------------------------+
| Service Management |
| |
| +----------------------------------+ |
| | Generic Policy Information 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
xxx Expires January 23, 2016 [Page 4]
Internet-Draft SUPA Model Applicability July 2015
D: Derived from
R: References (i.e., the information model is used by the system to
instantiate the data model).
As shown in Figure 1, SUPA will define generic policy information
models, which are independent of services and use cases. Policy data
models can be derived from the generic information 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.
4. SUPA Model Applicability
4.1. ECA Data Model
4.1.1. SES Use Case
4.1.1.1. Scenario
xxx Expires January 23, 2016 [Page 5]
Internet-Draft SUPA Model Applicability July 2015
+-----------------------------------------------------------------+
| Service Management |
| +----------------------------------+ |
| | Generic Policy Information Model | |
| +----+------------------------+----+ |
| |
| +---------------------------+ +-------------------------------+ |
| | Generic Policy Data Model | | Service Management Data Model | |
| +---------------------------+ +---------------+---------------+ |
+-----------------------------------------------------------------+
|
|
+------------------------------+
| Network Manager / Controller |
+------------------------------+
|
|
+------------------+
+-------------+ | Traffic Analysis | +--------+
| Headquarter |----------| |-------| Site 1 |
+-------------+ | WAN Optimization | +--------+
+------------------+
|
|
+----------+
| Site 2 |
+----------+
Figure 2 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
xxx Expires January 23, 2016 [Page 6]
Internet-Draft SUPA Model Applicability July 2015
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
4.1.1.2. Generic Policy Information 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
xxx Expires January 23, 2016 [Page 7]
Internet-Draft SUPA Model Applicability July 2015
4.1.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.
4.1.2. DDC Use Case
A data center can provide various services, such as video host, VMs,
etc. In order to provide better user experience, the contents may be
located in multiple geographically distributed data centers so that
the user can get service from a nearby location. The content
distribution between data centers is necessary, an example is, for a
social video service provider, they need to copy videos uploaded by
users to all the data centers. Another example is, cloud operator
may needs to migrate VMs from one location to another. This kind of
operation usually will require a lot of bandwidth. To avoid
consuming too much network resource in the busy hours, it is usually
done in the non-busy hours, such as 1 or 2 o'clock in the morning.
Example:
Event: time of the day
Condition: now is Evening
Action:
Configure a VPN for VM migration for 2 hours
4.1.3. Instant VPN
Provide VPN connection for Customer A when receiving a request.
xxx Expires January 23, 2016 [Page 8]
Internet-Draft SUPA Model Applicability July 2015
(Figure to be added)
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.
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.
Example:
Event: receive customer VPN service request
Condition: YES (received valid request)
Action:
Configure VPN service for the customer
In the above cases, the advantage of SUPA ECA model is, it can work
for different scenarios with a common set of concept: events,
conditions, actions, etc.
4.2. Declarative Data Model
Logic Statement Information Model (LSIM) can also be called as
declarative or intent model. This type of model will describe the
service intention without specifying low level details, such
xxx Expires January 23, 2016 [Page 9]
Internet-Draft SUPA Model Applicability July 2015
protocol level or network device level detail, but just the service
requirements itself.
Example1:
All SNMP agents in my network should drop all SNMP traffic unless
it is originating or targeted to the management network
The management system will expand this requirement according to
the network topology which is provided by other systems, and get
a list of all the involved network elements which should be
configured.
The SNMP traffic can be identified by the TCP/UDP port 161/162;
and if the traffic is originating or targeted to management can
be identified by the source or destination address or the traffic,
but, which is out of scope of SUPA.
With the above information, the management system can generate
and install configurations to all the related network elements.
The administrator does not have to specify any protocol level or
network device level details during network management.
Example: Virtual DC
Request: Create a virtual DC for customer B with specified
resource (BW, storage, compute)
(Figure to be added)
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
xxx Expires January 23, 2016 [Page 10]
Internet-Draft SUPA Model Applicability July 2015
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.
5. 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.
6. IANA Considerations
This memo does not have any requirement to IANA.
7. 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
This document was prepared using 2-Word-v2.0.template.dot.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.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
xxx Expires January 23, 2016 [Page 11]
Internet-Draft SUPA Model Applicability July 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-00 (work in progress), July 2, 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
Dacheng Zhang
Alibaba Group
<Address>
Email: Dacheng.zdc@alibaba-inc.com
xxx Expires January 23, 2016 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 06:53:41 |