One document matched: draft-karagiannis-aponf-problem-statement-01.txt
Differences from draft-karagiannis-aponf-problem-statement-00.txt
Network Working Group G. Karagiannis
Internet-Draft University of Twente
Intended status: Informational W. Liu
Expires: December 30, 2014 T. Tsou
Huawei Technologies
Q. Sun
China Telecom
D. Lopez
Telefonica
June 30, 2014
Problem Statement for Application Policy on Network Functions (APONF)
draft-karagiannis-aponf-problem-statement-01
Abstract
As more and more modern network management applications grow in scale
and complexity, their demands and requirements on the supporting
communication network will increase.
In particular, today network operators are challenged to create an
abstract view of their network infrastructure and help service
developers on using and programming this abstraction rather than
manipulating individual devices. In this context, network management
applications can be used to provide the required configuration and
application programming interfaces to such service developers. The
main goal of APONF is to (1) communicate the up to date abstract view
of the network between the network management application systems and
network management and controlling systems and (2) map the abstract
view of the network into specific network management policies, i.e.,
device level configuration 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 December 30, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Karagiannis, et al. Expires December 30, 2014 [Page 1]
Internet-Draft APONF Problem Statement June 2014
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.
Requirements Language
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements/Objectives . . . . . . . . . . . . . . . . . . . . 7
5 Relationships between APONF and other IETF Working Groups . . . 7
6. Existing Protocols and Methods . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Today, as the Internet grows, more and more new services keep on
arising, and network traffic is rapidly increased, which may result
in slow performance of network devices (e.g., BRAS) and poor end-user
experience. This also implies that demands and requirements of such
new services on the supporting communication network will increase.
Furthermore, and especially for cloud applications, the cloud tenants
and developers usually need to use the communication network
capabilities, such as dynamic network management easily, accurately
and efficiently. In this way, the deployment of new applications and
services may be accelerated and the user experience can be improved.
Moreover, the Development Operations (DevOps), see e.g., [DevOps], is
another network development trend which orchestrates the complex
interdependent processes associated with software development and
IT operations in order to accelerate the production and roll out of
software products and services.
Karagiannis, et al. Expires December 30, 2014 [Page 2]
Internet-Draft APONF Problem Statement June 2014
Currently, the separation of development and operation of network
technologies leads to slow deployment of network functions/devices
and poor user experiences. The communication network needs to provide
graceful adjustment capabilities in order to accommodate the diverse
needs of applications and the rapid network evolution.
In addition, today network operators are challenged to create an
abstract view of their network infrastructure and help service
developers on using and programming this abstraction rather than
manipulating individual devices. An abstract view of a network
infrastructure can be realized using a network configuration model,
that provides a declarative configuration and a network topology
model that describes a multi-layer network. Network management
applications are Operational Support System (OSS) like applications
that help a communication service provider to monitor, control,
analyze and manage a communication network.
In this context, network management applications can be used to
provide the required configuration and application programming
interfaces to such service developers. Subsequently, a network
management application can use the application based demands and
possibly update its associated network configuration and/or network
topology model. Examples of network management applications that can
modify the network configuration and/or network topology models are
for example, Distributed Data Center Application and IPv6
transitions, need to change the network infrastructure configuration.
The up to date network configuration and network topology model needs
to (1) be communicated to e.g., the network management and
controlling systems, (2) map the network configuration and network
topology models into specific device level configuration models.
Currently, there are no IETF standard mechanisms or modeling
languages that can directly be applied to model the network
configuration nor the network topology. IETF has however, created the
IETF SFC WG [SFC] to document a new approach to service delivery and
operation, where one of its goals is to realize an abstract view of a
network by using a service graph instance denoted as the Service
Function Path (SFP). This will enable the development of suitable
models for network configuration and network topology.
Furthermore, there are currently no IETF solutions that can be used
to provide the necessary configuration interfaces to service
developers to program the abstract view of a network infrastructure.
Currently, the Application Enabled Collaborative Network (AECON)
activity can provide these necessary solutions.
Moreover, there are no IETF solutions that can directly be used to
(1)enable the streaming transfer of bulk-variable/data of SFP based
network configuration and network topology models between network
management application systems and network management and controlling
systems, (2) map the SFP based network configuration and network
topology models into specific device level configuration models.
Karagiannis, et al. Expires December 30, 2014 [Page 3]
Internet-Draft APONF Problem Statement June 2014
The APONF activity can provide a solution to this challenge. A
possible signaling protocol framework that can be enhanced and used
is the flexible IETF signaling protocol NSIS, see [RFC4080],
[RFC5971], [RFC5973].
The main goal of APONF is to:
o) enable the streaming transfer of bulk-variable/data of the up to
date SFP based network configuration and network topology models
between network management application systems and the network
management and controlling systems, by using and extending the
IETF Next Steps in Signaling Protocol (NSIS).
o) map the SFP based network configuration and network topology
models into specific network management policies, i.e.,
device level configuration models.
This document is organized as follows. Section 2 presents the
terminology. Section 3 provides a brief overview of the use cases
associated with APONF. The requirements/objectives are provided in
Section 4. Section 5 presents the relationships between APONF and
other IETF Working Groups and other IETF activities. The existing
IETF protocols and methods that can be used by the APONF solutions
are given in Section 6. Section 7 provides the security
considerations. The IANA considerations are given in Section 8.
Section 9 gives the acknowledgements and Section 10 lists the used
references.
2. Terminology
AECON (Application Enabled Collaborative Network): The main goal of
the AECON activity (currently BOF) is to allow applications to
explicitly signal their flow characteristics to the network.
Device level configuration model: supports the description of the
network management policies and it describes the configuration
details at the device level.
Network Management Application: Operational Support System (OSS) like
applications that help a communication service provider to monitor,
control, analyze and manage a communication network.
Network configuration model: provides a declarative configuration of
the network
Network topology model: describes the topology of a multi-layer
network.
Service Function Chain (SFC): A service Function chain defines an
ordered set of service functions that must be applied to packets
and/or layer-2 frames selected as a result of classification. The
implied order may not be a linear progression as nodes may copy to
more than one branch. The term service chain is often used as
shorthand for service function chain.
Karagiannis, et al. Expires December 30, 2014 [Page 4]
Internet-Draft APONF Problem Statement June 2014
Service Function Path (SFP): The instantiation of a service function
chain in the network. Packets follow a service function path from
a classifier through the required instances of service functions
in the network.
VNF (Virtualized Network Function): An implementation of an
executable software program that constitutes the whole or a part of
an NF and can be deployed on a virtualization infrastructure.
3. Use Cases
This section briefly describes the use cases that are associated with
different types of network management applications. The detailed
description of these use cases is provided in other Internet
draft(s).
3.1 Distributed Data Center
A large-scale IDC (Inter Data Center) operator provides server
hosting, bandwidth, and value-added services to enterprises and ISPs,
and has more than 10 data centers and more than 1Tbs bandwidth in a
capital city. In current IDC network, traffic is
routed via configuring policy routes and adjusting routes
prioritization to choose an outgoing link. This type of static
provisioning comes with high costs and poor operability. Furthermore,
the link bandwidth resources in the data centers are not efficiently
utilized.
Services usually do not have consistent bandwidth requirements at
all times of a day, e.g. video ISP usually require more
bandwidth at non-working hours but require less bandwidth at working
hours. Some customers have relative high QoS requirement for their
services, e.g. IM (Instant Messaging). Static bandwidth and QoS
provisioning for all the customers and services is not reasonable and
not a cost-effective solution.
APONF can be used to optimize the traffic paths dynamically and
have the ability to load balance between data centers and links, and
direct customer traffic via network management policies (e.g.,
models, software programs routines) based on customer grade and QoS
requirements.
3.2 IPv6 transition
The IPv6 transition has been an ongoing process throughout the world
due to the exhaustion of the IPv4 address space. However, this
transition leads to costly end-to-end network upgrades and poses new
challenges of managing a large number of devices with a variety of
transitioning protocols. While IPv6 transition tools exist, there
are still new challenges to be solved. Operators may need various
types of IPv6 transition technologies depending on performance
requirements, deployment scenarios, etc.
Karagiannis, et al. Expires December 30, 2014 [Page 5]
Internet-Draft APONF Problem Statement June 2014
To address these difficulties, APONF can be used as the software
defined unifying approach that can provide a unified way to deploy
IPv6 in a cost-effective, flexible manner.
3.3. Virtualized Enterprise Applications
Virtualized Enterprise applications make the Virtualized Network
Function (VNF) functionality available to enterprise users as a
service, comparable to the cloud computing concept denoted as the
Software as a Service (SaaS), see [NIST SP 800-146].
Virtualized Enterprise application policies include dynamic
orchestration of virtualized network functions, dynamic
increase/decrease of network bandwidth, pay as you go billing and
charging.
GiLAN is another important application of network function
virtualization. In mobile core networks, it is preferable that QoS
provisioning and network function requirements are different for
subscribers with different profiles. In such scenarios, specialized
network management applications such as BSS/OSS can send application
based demands to a policy decision point, which further map these
application based demands to GiLAN specific VNF policies, and realize
the required QoS and with appropriate network functions, for example,
for dynamic path reconfiguration.
APONF can be used to support the dynamic network reconfiguration
demands imposed by such virtualized enterprise applications.
3.4. Source Address Validation and Traceback (SAVI)
It has been long known that the IPv4/IPv6 transition makes the
Tracking and validation of source IP address thorny. Whenever an
IPvX packet is translated into an IPvY packet, there are three
Troublesome issues: 1. how to track the origin of the IPvY packet
which is actually in the IPvX world? 2. how to validate the IPvX
packet at the edge of the IPvY world to prevent possible spoofing? 3.
how to protect the IPvY address from being spoofed in the IPvY world?
SAVI[RFC7039] has given the source address validation solutions for
both IPv4 and IPv6.
In order to address the above issues, APONF can be used to block or
permit the traffic based on the validation of the source address.
3.5 Using the abstract view of network by service developers
This use case description argues that service developers can profit
by using the abstract view of the network during the programming and
development process instead of manipulating individual devices.
In this way one can write software that programs an arbitrary
network.
APONF can be used to interface the programmed arbitrary network
into network management policies, i.e., device configuration
models.
Karagiannis, et al. Expires December 30, 2014 [Page 6]
Internet-Draft APONF Problem Statement June 2014
4. Requirements/Objectives
The requirements/objectives that need to be supported by the APONF
methods, models and protocol solutions are the following ones:
o) monitor and verify the freshness of the SFP based network
configuration and network topology models
o) extend the IETF NSIS protocol to securely and efficiently
distribute the SFP based network configuration and network
topology models between network management applications systems
(e.g., OSS) and the network management and/or controlling
systems.
o) use application based demands generated by network management
applications systems to map the SFP based network configuration
and network topology models into specific network management
policies, i.e., into device level configuration models. Such
application based demands are:
a) encapsulating, de-encapsulating packets associated with a
flow into a tunnel (for example, VPN service, IPv6
transition service demands on the network)
b) blocking, or dropping packets associated with a flow in
(the edge of) the network element when the network security
service is aware of the attack (for example, SAVI service,
Anti-DoS service demands on the network).
c) configure and dynamically reconfigure data centers to the
steer and reroute traffic associated with a specific flow
d) configure and dynamically reconfigure data centers to
change priorities of different types of traffic associated
with a specific flow
e) logging the traffic associated with a flow for network
security service, optimization of the traffic based on the
IETF ALTO [ALTO]
f) other actions defined by the administrator
o) specify the Authentication Authorization and Accounting (AAA)
method
5. Relationships between APONF and other IETF Working Groups
The following relationships between APONF and other IETF WGs have
been identified:
Karagiannis, et al. Expires December 30, 2014 [Page 7]
Internet-Draft APONF Problem Statement June 2014
IETF SFC WG: the main goal is to document a new approach to service
delivery and operation, where one of its goals is to realize an
abstract view of a network by using a service graph denoted as the
Service Function Path (SFP). This will enable the development of
suitable models for network configuration and network topology.
APONF can make use of such network configuration and network topology
models specified by the IETF SFC.
AECON (Application Enabled Collaborative Network): The main goal of
the AECON activity (currently BOF) is to allow applications to
explicitly signal their flow characteristics to the network. AECON
can be used to provide the necessary configuration interfaces to
service developers to program the abstract view of a network
infrastructure. The AECON activity can be used to provide the
necessary configuration interfaces to service developers to program
the SFP based abstract view of a network infrastructure.
APONF is different than existing WGs and other IETF activities, due
to the fact that APONF is the only activity that:
o) enables the streaming transfer of bulk-variable/data of the up
to date SFP based network configuration and network topology
models between network management application systems and the
network management and controlling systems, by using and
extending the IETF Next Steps in Signaling Protocol (NSIS).
o) map the SFP based network configuration and network topology
models into specific network management policies, i.e.,
device level configuration models.
6. Existing Protocols and Methods
The APONF protocol and mechanisms will have an impact on layers 4 and
above.
The IETF signaling protocol NSIS, see [RFC4080], [RFC5971], [RFC5973]
is the signaling protocol framework that can be enhanced and used
for the streaming transfer of bulk-variable/data of SFP based network
configuration and network topology models between network management
application systems and network management and controlling systems.
Currently NSIS is an on path protocol (supports only signaling for
entities that are part of the data plane), but APONF needs to use an
off path protocol (i.e., support signaling for entities that are not
located on the data plane). Therefore, NSIS needs to be extended in
two ways:
1) Extend NSIS GIST [RFC5971] in such a way that it can be used
for off-path support
2) Specify a new signaling protocol (NSIS Signaling Layer
Protocol), similar to the NAT/Firewall NSLP [RFC5973] that
can be applied and support the APONF use cases.
The following activities are out of the APONF scope:
o) the generation of the abstract view of the network infrastructure
using an SFP based network configuration and network topology models,
Karagiannis, et al. Expires December 30, 2014 [Page 8]
Internet-Draft APONF Problem Statement June 2014
o) the necessary configuration interfaces to service
developers to program the abstract view of a network
infrastructure.
o) definition of the used SFP based network configuration and
network topology models
o) the specification of the network management policies and their
associated device configuration models
7. Security Considerations
Security is a key aspect of any protocol that allows state
installation and extracting of detailed configuration states. More
investigation remains to fully define the security requirements, such
as authorization and authentication levels.
8. IANA Considerations
This document has no actions for IANA.
9. Acknowledgements
The authors of this draft would like to thank the following
persons for the provided valuable feedback: Spencer Dawkins, Jun Bi,
Xing Li, Chongfeng Xie, Benoit Claise, Ian Farrer, Marc
Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon Perreault,
Fernando Gont, Jose Saldana.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[ALTO] R. Alimi, R. Penno, Y. Yang, "ALTO Protocol", IETF Internet
draft (work in progress), March 2014
[DevOps] DevOps website, http://devops.com/
[NIST SP 800-146] Badger et al.: "Draft Cloud Computing Synopsis and
recommendations", NIST specifications, May 2011.
[RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch,
"Next Steps in Signaling (NSIS): Framework", IETF RFC 4080, June 2005
Karagiannis, et al. Expires December 30, 2014 [Page 9]
Internet-Draft APONF Problem Statement June 2014
[RFC5971] H. Schulzrinne, R. Hancock, "GIST: General Internet
Signalling Transport", IETF RFC 5971, October 2010
[RFC5973] M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", IETF RFC 5973,
October 2010
[RFC7039] J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, "Source
Address Validation Improvement (SAVI) Framework", IETF RFC 7039,
October 2013.
[SFC] IETF SFC (Service Function Chaining) WG charter,
http://datatracker.ietf.org/wg/sfc/charter/
Authors' Addresses
Georgios Karagiannis
University of Twente
Email: g.karagiannis@utwente.nl
Will(Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: Tina.Tsou.Zouting@huawei.com
Qiong Sun
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: sunqiong@ctbri.com.cn
Diego Lopez
Telefonica
Email: diego@tid.es
Karagiannis, et al. Expires December 30, 2014 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 03:04:01 |