Internet DRAFT - draft-tremblay-aponf-gap-analysis
draft-tremblay-aponf-gap-analysis
Network Working Group JF. Tremblay
Internet-Draft Viagenie
Intended status: Informational J. Bi
Expires: January 5, 2015 Tsinghua University
July 4, 2014
Application-based Policy for Network Functions Gap Analysis
draft-tremblay-aponf-gap-analysis-00
Abstract
As operators struggle to optimize their network for different
applications while maximizing network resources usage, there's
growing business pressure to minimize operational tasks and the
deployment time of new services.
New automation paradigms are meant to help reach these goals,
including the optimization of network functions through application
control. This control could be signaled directly by an application,
through a proxy or orchestrated in a centralized manner.
The current version of the Application-based Policy for Network
Functions (APONF) proposed working group mentions the NSIS framework
as a possible signaling protocol, through the definition of a new
NSIS Signaling Layer Protocol (NSLP). The present memo analyses if
this proposition is suitable for the designed purpose and if other
protocols would be more suitable.
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 January 5, 2015.
Tremblay & Bi Expires January 5, 2015 [Page 1]
Internet-Draft APONF Gap Analysis July 2014
Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability to APONF Problem Statement . . . . . . . . . . 4
3. Gap Analysis for NSIS . . . . . . . . . . . . . . . . . . . . 4
3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Mode of operation . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Operation with NAT . . . . . . . . . . . . . . . . . 5
3.3. Data and State Reporting . . . . . . . . . . . . . . . . 5
3.4. Authentication, Authorization and Security . . . . . . . 5
3.5. Existing Implementations . . . . . . . . . . . . . . . . 5
4. Gap analysis for Netconf . . . . . . . . . . . . . . . . . . 6
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Network operators, including Internet Service Providers, Datacenters
operators and others, are under constant pressure to optimize the
usage of their installed network resources while maintaining high
availability and deploying new services at an ever-increasing pace.
The capabilities of the deployment teams are often already stretched
and scaling their efforts further while maintaining quality requires
significant efforts. The introduction of new paradigms aims at
reducing these efforts, optimize network resource usage and minimize
operational overhead.
Two of these paradigms are the virtualization of some network
functions (as discussed in the Service Function Chaining or SFC
Tremblay & Bi Expires January 5, 2015 [Page 2]
Internet-Draft APONF Gap Analysis July 2014
workgroup) and the automation in real time of network optimization
based on application needs. The latter may be realized by an
application signaling directly some needs to network elements in the
path using protocols such as RSVP or the NSIS framework.
If the application does not support natively such protocols, the
signaling function can be delegated to a proxy. This delegation to a
third party may incur some loss of functionality, as the proxy must
rely on the examination of flows to trigger signaling or use an out-
of-band mechanisms to exchange with the application.
A third possibility for the deployment of automated network
optimization is to use a centralized network management system. Some
functions such as access control and policy enforcement can be
simplified as they are implemented from a centralized point.
However, this technique requires previous knowledge and access to
network elements by the network management system. The usage of two
protocols is likely to be required, as the protocol requirements for
the application exchanging with the management system are different
than those of the management system exchanging with network elements.
The use of two independent protocols may be an opportunity to provide
isolation from the network implementation through an abstraction
layer, as discussed in the ACTN working group.
Three signaling protocols may therefore be used for application-based
network optimization:
1. A protocol for application signaling directly to network elements
(such as RSVP) and report back the related states.
2. A protocol for applications to signal their needs to a central
management system and get states from the network, possibly using
an abstracted view optimized for the application.
3. A protocol for the signaling between the central management
system and network elements, including the reporting of states.
The present memo provides an analysis of the applicability of the
NSIS framework and other protocols for the signaling cases described
at point 2 and 3 above. The NSIS framework could be used to provide
these functions through the addition of a new NSIS Signaling Layer
Protocol (NSLP). Other protocols such as Netconf are also
considered.
Tremblay & Bi Expires January 5, 2015 [Page 3]
Internet-Draft APONF Gap Analysis July 2014
2. Applicability to APONF Problem Statement
Although the NSIS framework [RFC4080] defines both path-decoupled (or
loosely coupled) and path-coupled modes of operation, subsequent work
such as GIST [RFC5971] have been designed to work mainly with network
elements located on the path taken by the data flow, as its
predecessor RSVP.
The NSIS framework is therefore well adapted to a scenario where an
application would signal its needs to network elements directly in
the data path (the first scenario described in the introduction).
However, according to the APONF problem statement document
[ID.karagiannis-aponf-problem-statement], the goal would be to have a
protocol between a management application and network devices (the
third scenario from the introduction).
According to [ID.karagiannis-aponf-problem-statement], the second
scenario where a protocol is used between an application and a
central management would not be in scope either, because some level
of abstraction would have to be presented by this protocol. The
generation of an abstract view of the network is described as out of
scope in the problem statement.
This document will therefore analyze the use of NSIS and other
protocols such as netconf only for the signaling between a central or
distributed management system/application and network elements (the
third scenario in the instrocution).
3. Gap Analysis for NSIS
3.1. Scope
NSIS has been designed to work across multiple administrative domains
and across the whole Internet. This does not preclude using it
within a single administrative domain. Although the APONF problem
statement does not state it explicitly, the APONF protocol would very
likely be used within a single administrative boundary.
3.2. Mode of operation
The NSIS framework and the related NSIS Transport Layer Protocol
(NTLP) GIST allow the presence of forwarding elements that are not
NSIS Entities (NE) and do not understand NSIS or GIST. The most
degenerated case where only two NEs exist is allowed. The management
system and a network element separated by multiple hops would be
allowed to become GIST adjacent.
Tremblay & Bi Expires January 5, 2015 [Page 4]
Internet-Draft APONF Gap Analysis July 2014
However the sender of the messages is also considered to be the
originator of the traffic, because GIST has been designed to be path-
coupled only. The data used for routing is the same than a NSIS Flow
Identifier. Both would have to be decoupled in GIST in order to be
used in APONF.
3.2.1. Operation with NAT
Although not mentioned in the APONF problem statement, it is possible
that the management application and the network elements are in
different IP domains and separated by one or multiple NAT devices.
Operation of NSIS through NAT devices may be problematic because flow
information is present in the signaling payload. This problem can be
circumvented using GIST-aware NAT implementations, a type or
application-level gateway (ALG) for NSIS.
In this case however any existing GIST ALG would have to be modified
in order not to interfere with the protocol. If flow information is
exchanged outside of the data path, the flow data is likely to use
another path through the network that may or not be within the same
IP domain and go through different NAT devices.
3.3. Data and State Reporting
The nature of the data being exchanged and the related messages are
defined in a NSIS Signaling Layer Protocol (NSLP). One or multiple
new NSLP would have to be defined in the context of APONF in order to
support the new parameters to be configured and reported on.
3.4. Authentication, Authorization and Security
Authentication and confidentiality features are built in the C-mode
of operation of GIST using TLS. This part could be used as-is by
APONF.
However authentication is performed per node only, against a database
of known IPs. If finer-grain authorization were required, for
example per user or per role, this would have to be added to GIST or
another NTLP.
3.5. Existing Implementations
Two experimental implementations of NSIS have been developed
independently. The first is called FreeNSIS and has been implemented
by a group from the Georg-August University of Goettingen. It was
last updated in July 2008.
Tremblay & Bi Expires January 5, 2015 [Page 5]
Internet-Draft APONF Gap Analysis July 2014
A second implementation is called NSIS-ka and is from the Karlsruhe
Institute of Technology (KIT). This implementation is more recent
and includes working NATFW and QoS NSLP. It is doubtful that the
interoperability of the two implementations was ever tested.
4. Gap analysis for Netconf
To be completed.
5. Conclusions
The NSIS framework and NSIS Transport Layer protocol GIST would
support operation between a management application and a network
elements separated by multiple hops. However GIST having been
designed for path-coupled operation only, it would need to be changed
significantly to support path-decoupled operation. Designing another
NTLP might be another option.
The design of one or many new NSLP would also be required, depending
of the type of information exchanged and required message types.
Overall, the NSIS framework could be used in the context of APONF,
but feature re-use would be minimal and the amount of modification
required important. Given that NSIS has shown very few independent
implementations and market traction, using it in the context of APONF
would probably involve a significant amount of work in design,
implementation and testing.
6. Security Considerations
Security considerations section to be completed.
7. IANA Considerations
No IANA considerations.
8. Acknowledgements
There are no acknowledgments in this version.
9. Informative References
[ID.cheng-aponf-ddc-use-cases]
Cheng, Y., Zhou, C., Karagiannis, G., and JF. Tremblay,
"Use Cases for Distributed Data Center Applicatinos in
APONF", June 2014.
Tremblay & Bi Expires January 5, 2015 [Page 6]
Internet-Draft APONF Gap Analysis July 2014
[ID.karagiannis-aponf-problem-statement]
Karagiannis, G., Liu, W., Tsou, T., Sun, Q., and D. Lopez,
"Problem Statement for Application Policy on Network
Functions (APONF)", June 2014.
[ID.sun-aponf-openv6-use-cases]
Xie, C. and Q. Sun, "Use case of IPv6 transition in
APONF", June 2014.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC
3726, April 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC
4080, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, October 2010.
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC
5973, October 2010.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
Authors' Addresses
JF Tremblay
Viagenie
Email: jean-francois.tremblay@viagenie.ca
Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China
Email: junbi@cernet.edu.cn
Tremblay & Bi Expires January 5, 2015 [Page 7]
