| 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
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.
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.
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.
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 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:
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
To be completed.
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.
Security considerations section to be completed.
No IANA considerations.
There are no acknowledgments in this version.