Internet Engineering Task Force M. Femminella SFC Working Group G. Reali Internet Draft University of Perugia Intended status: Informational D. Valocchi University College London Expires: October 2016 April 4, 2016 Off-Path Signaling Protocol for Service Function Chaining draft-femmreali-sfc-offpath-signaling-02 Abstract This document illustrates a reference protocol able to discover deployed instances of Service Functions (SFs), which can be located also off-path with respect to the IP datapath between flow source and flow destination. It is an application protocol organized in two layers: signaling transport, which deal lower layer signaling transport, and signaling application, which directly interfaces with the intended SF. Discovery of SFs is a primary step to for implementing Service Function Chaining (SFC). 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), 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." 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 October 4, 2016. Femminella et al., Expires October 4, 2016 [Page 1] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 Copyright Notice Copyright (c) 2016 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 1.1. Document scope ......................................... 4 2. Conventions used in this document ............................ 5 3. Related work ................................................ 5 3.1. Signaling protocols in data network ..................... 5 3.2. Platforms for hosting virtualized SFs ................... 6 3.3. Service redirect solutions .............................. 7 4. Off-path Signaling Protocol description ...................... 7 4.1. The peer discovery in the Signaling Transport layer...... 8 4.2. Signaling distribution ................................. 13 4.2.1. Finite state machines for SA and ST ............... 15 4.2.2. ST messages ....................................... 25 4.2.3. Error management and termination procedures........ 27 4.2.4. Forwarder management procedures ................... 28 4.2.5. SA messages ....................................... 28 5. Transport Layer Considerations .............................. 30 5.1. Peer discovery ........................................ 30 5.2. Signaling distribution ................................. 30 6. Security Considerations ..................................... 31 7. IANA Considerations ........................................ 32 8. Conclusions ................................................ 32 9. References ................................................. 32 9.1. Normative References ................................... 32 9.2. Informative References ................................. 32 10. Acknowledgments ........................................... 34 Femminella et al., Expires October 4, 2016 [Page 2] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 1. Introduction Service Function Chaining (SFC) enables the creation of composite services that consist of an ordered set of Service Functions (SF) that are be applied to packet flows as a result of classification. SFC is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities. Foundations of the SFC are described in below documents: o SFC problem statement [3]. o Various individual drafts. SFs is an area that has recently gained attention as one of the most successful novelty in networking research. Many essential functions can be virtualized, such as security functions (firewalling, intrusion detection, traffic scrubbing), shaping functions (rate limiting, load balancing), addressing, caching, and middlebox management [4][5]. The strategic importance of SF is also demonstrated by the related ongoing standardization activities. For example, in addition to the IETF SFC Working Group, in 2012 seven leading network operators selected ETSI to host the Industry Specification Group for Network Function Virtualization (NFV) [6]. Furthermore, the IETF Service Function Chaining (SFC) working group has been addressing strictly related functions since mid 2014. Another related effort is the IETF Network Virtualization Overlays (nvo3) working group. Since mid 2012, the nvo3 working group has been dealing with solutions for supporting multi-tenancy in data centers managing virtualized hosts. The considered approaches reside at the network layer and aim at deploying Data Center Virtual Private Network (DCVPN) across a range from thousands to millions of virtual machines (VMs) with good scaling properties. In addition, the IEEE has recently standardized the Next Generation Service Overlay Network (NGSON), including entities for service composition and routing. Their combination allows combining computing services and routing for data communications [9]. In [7], the authors address the problem of composing SFs automatically and propose a formal representation of the semantics of data connections, along with the relevant functions and policies. The common aspect of all these activities is the collection and joint management of network resources distributed over geographical networks and made available through a virtualized interface. Thus, SF resource discovery is a critical aspect preliminary to all the Femminella et al., Expires October 4, 2016 [Page 3] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 mentioned proposals, and not enough considered so far in the technical literature. A survey the research developments in the closely related area of service discovery for realizing NaaS (Network as a Service) to support network-cloud convergence can be found in [9]. However, in the perspective of a service composition through SFs, the importance of the resource awareness is higher when resources are located close to data paths, so that they can be considered candidate for implementing or adapting service delivery. To sum up, even if a number of proposals for virtualized SF/NFV exists, however, some management issues are still unexplored. One issue is the discovery of SF instances. Another issue is that is it often desirable to maintain the SF instances sufficiently close to IP data paths. The first issue is related to deployments of SF instances in clouds, where they could be moved and/or replicated. The second one refers to chaining NFV instances while keeping acceptable the increase of network traffic. This document describes the off-path signaling protocol (OSP), designed for distributing signaling messages over portions of data networks around data paths (configurable network scope). The main issue that is addressed by this document is the need of discovering network nodes, hosting virtualized SFs, within network scopes destined to deploy a wide class of services. The protocol is designed to be distributed, autonomic, and easy to deploy solution. This protocol leverages on two main network functions, namely, on- path packet interception and off-path signaling distribution [8]. Specifically, this document provides: o a survey of the existing signaling protocols that could be regarded as alternative solutions to OSP and currently available NFV platforms to implements virtualized SFs. o a formal description of the OSP protocol, by using finite state machine diagrams. 1.1. Document scope The focus of this document is to provide the description of a discovery protocol for SFC named off-path signaling protocol (OSP). Actual solutions and implementation mechanisms are outside the scope of this document. Femminella et al., Expires October 4, 2016 [Page 4] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 2. Conventions used in this document 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 [1]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Related work 3.1. Signaling protocols in data network This section illustrates the mostly used signaling protocols in data network and evaluate their suitability in accomplishing the desired functions for resource discovery of SFs. A special mention is due to the Session Initiation Protocol (SIP, IETF RFC 3261, [19]), an application-layer signaling protocol. It is the protocol mostly used for establishing multimedia sessions over IP networks. Although its diffusion is an attractive property, its intrinsic end-to-end scope, assisted by intermediate proxies, makes its usage unfeasible for the aims of this paper. The REsource LOcation And Discovery (RELOAD) protocol, specified by the ITEF RFC 6940 [20], extends the SIP capabilities by introducing peer-to-peer (P2P) message exchange. Nevertheless, on-path packet interception is not present. This (missing) feature does not allow to properly identify SFs which are deployed around a data path. Also protocols for high volume messaging, such as eXtensible Messaging and Presence Protocol (XMPP, IETF RFC 6120 [21]) or similar, are unsuitable, since they rely on a client-server architecture, and clients may not exchange messages directly to one another. Also in these protocols, features allowing to properly identify SFs which are deployed around a data path are missing. The EvoArch evolutionary model, presented in [10], shows that in order to design protocol having a significant change to survive over time, it is necessary either to replace an incumbent one, by including similar services and significant novelties, or to make them largely non-overlapping, in terms of features, with existing and largely used ones. In terms of features and capabilities, the Next Steps in Signaling (NSIS, IETF RFC 4080 [22]) architecture partially addresses the needs of the SFs resource discovery. In fact, NSIS was defined for signaling information about a data flow Femminella et al., Expires October 4, 2016 [Page 5] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 along its path in the network, in order to allows signaling applications to install and manage states in the network though on- path packet interception. It consists of two layers, namely, NSIS transport layer protocol (NTLP), which is a generic lower layer used for on-path node discovery and message sending, and NSIS signaling layer protocol (NSLP), the upper layer implementing specific signaling application logic. The IETF-defined version of the NTLP is the General Internet Signaling Transport protocol (GIST, IETF RFC 5971 [23]). It allows sending signaling messages either towards an explicit destination or path-coupled, that allows installing states in all the NSIS peers that lie on the path between two end points. GIST does not support off-path signaling. Nevertheless, it includes extensibility functions, that have been used to introduce an off- path routing support [12]. The weakness of this solution consists of the complexity of the NSIS architecture, which has hampered its widespread adoption. 3.2. Platforms for hosting virtualized SFs Some recently developed research platforms able to host SF in a virtualized fashion through deployment in the cloud are reported below. Given likely deployment in clouds, they could benefit of the functions provided by OSP. o NetVM: a high-speed network packet processing platform, implemented by using the Intel's DPDK library [13]. It provides capabilities for traffic steering network function chaining. o ClickOS: a Xen-based virtualized platform optimized for middlebox processing [4]. It can execute hundreds of middleboxes on commodity hardware. o NetServ: it is a programmable node platform designed for deploying in-network services [11]. It includes in-network virtualized service containers and a common execution environment for both network services and traditional addressable services (e.g. a Web server). o OpenANFV: a platform designed to consolidate various hardware resources [14]. It is programmable and supports virtualized acceleration for middleboxes in a cloud environment. o OpenNF: it is a control plane architecture including a set of APIs managing combination of events and forwarding updates to address race conditions, accommodating different network functions [15]. Femminella et al., Expires October 4, 2016 [Page 6] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 3.3. Service redirect solutions Traffic redirection is a research area strongly related to NFV. It essentially consists of implementing service paths, different from data paths, by means of tunnels. It is worth mentioning the Network Service Header [16] solution proposed by the IETF SFC working group, which allows forming service paths, which transport not only data traffic but also configuration metadata. Another interesting solution, based on the software defined network paradigm, is shown in [17]. 4. Off-path Signaling Protocol description The definition of OSP was inspired by the design and implementation experience of designing an off-path extension of GIST [12]. The new signaling protocol includes all the necessary features of NSIS while removing all the components that have been demonstrated to be scarcely acceptable. In addition, following the guidelines of the EvoArch evolutionary model [10], the protocol natively integrate new features, such as the support for off-path signaling, the importance which was still not well understood at the time of the NSIS introduction. In more detail, the protocol architecture inherits some of the key features of two existing solutions which compensate each other's shortcomings. These solutions are the NSIS protocol architecture and P2P gossip message exchange [18]. In addition, some key features, suitable to support NFV needs, have been included. They are listed below. NSIS inheritance: o Two-layer protocol organization. The upper layer of the OSP architecture, called Signaling Application (SA), implements the application signaling logic. The lower layer, called Signaling Transport (ST), distributes the SA messages to the intended recipients. o On-path packet interception capability, available at ST, to assist off-path operation at ST. Packet interception can be implemented in a number of ways (port-based traffic filtering, RAO IP option, specific rules in OpenFlow switches, and so on), which are implementation specific and thus out of the scope of this document. P2P gossip protocols inheritance: Femminella et al., Expires October 4, 2016 [Page 7] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o Randomized, gossip-based message exchange, used for peer discovery in ST. o Robustness (no single point of failure) due to distributed nature of the protocol and scalability. New features: o Simplified state definition in ST in comparison to the many state variables organized in multiple tables of GIST. o Off-path signaling capability as native function. The OSP natively extends the path-coupled operation of GIST with off-path signaling, and without including all complexity of GIST due to the initial support of QoS network protocols currently unused. The combination mentioned above allows also avoiding the shortcomings of the P2P-based approaches, which offer little or no support to proximity-based solutions, trying instead to limit the network overhead. In order to implement the off-path signaling distribution functions, the OSP protocol defines, at the lower layer (ST), a peer discovery function, which identifies neighboring nodes running the OSP protocol. This function allows building a peer table, which is used during the signaling distribution in the ST layer itself. 4.1. The peer discovery in the Signaling Transport layer Peer discovery is a function which allows building peer tables, which are data structures used in the off-path signaling distribution. It is implemented in the ST layer. The peer discovery is used both to collect identity of peers and to measure IP distance and latency between them. It exploits the interception capabilities inherited from NSIS and the flexibility of gossiping. Each ST node stores information on the previously discovered ST nodes in the Peer Table (PeT). Each PeT entry stores the following information: o the unique identifier of a ST node, called Peer Identity (PID), o its IP address, o metric values, consisting of its IP hop distance and of its estimated round-trip network latency, Femminella et al., Expires October 4, 2016 [Page 8] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o the timestamp of the last gossip session with the peer, o a boolean flag used to mark if the initiator has tried to contacted or contacted that peer. An example of PeT is reported in Figure 1. +----------------------------------------------------------------+ | # | PeerId | IP Address | Metrics | Timestamp | Flag | +----------------------------------------------------------------+ | | | | IP Hops | Latency | | | +================================================================+ | | | | | | | | | 1 | kJNg | 10.0.3.1 | / | / | 1410704001| 0 | | | | | | | | | | 2 | p2uQ | 10.0.32.2 | 2 | 400 | 1410704003| 1 | | | | | | | | | | 3 | AuSp | 10.0.223.1 | -1 | -1 | 1410704005| 1 | | | | | | | | | +----------------------------------------------------------------+ Figure 1 Example of a Peer Table. The communicating protocol entities of the ST gossip-based peer discovery process are the initiator, which aims to collect information about the other peers, and the responder. The collected information includes the position of responder, which is considered relative to the initiator, and the identities of other peers, shared by the responder, as it typically happens in gossip protocols The protocol is asynchronous and round based. When an ST node is turned on, it does not store any information on the reachable ST nodes. It is only aware of a default node called tracker, used to receive an initial set of peers. Then, an ST node tries to periodically establish gossip sessions with the known peers to discover further ST nodes. The messages used for this discovery are Registration (REG), RegResponse (RES), and Ack (ACK). Only Registration messages can be intercepted. In order to limit the network overhead, the considered scope extension of each node is 1 ST hops. All Registration messages are intercepted and dropped by the first ST node on path (responder), as the message sent by N2 to TR in Figure 2. The responder replies with a RegResponse, followed by a final Ack. Registrations and RegResponses include one or more PIDs, together with one of their IP addresses. This list forms the peer to share list (PTS). The PTS peer selection is random. . The time evolution of the activity of a set of peer is illustrated in Figure 2. In each message, in addition Femminella et al., Expires October 4, 2016 [Page 9] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 to the message type (REG, RES, or ACK), it is indicated within () the destination identity and the list of PIDs in the transported PTS. TR indicates the tracker. The tracker node can be configured in the OSP configuration file, or retrieved through properly set up information services, which are out of the scope of this document. When an initiator receives the RegResponse, it stores the identity of the responder in its PeT, along with the relevant measured metrics, and the flag is set to 1, which indicates that the responder has been contacted. In case of interception of Registration by another ST node (responder), the flag associated with the destination peer is set to 1, whereas its relevant metric values are set to a non-significant value (e.g. -1). It means that the destination is out of scope (unreachable). The identity of the intercepting responder is added/updated as a contacted peer (see Figure 2, gossip registration of N2 to the tracker intercepted and answered by N3). In order to compute its IP distance to the responder in the downstream direction, the initiator carries the original value of the IP TTL used at the IP layer (ST-HOP field in the ST payload). The intercepting node, which acts as a responder, reads the current values of the IP TTL, and inserts the ST-HOP, decremented by the IP TTL, into the Gossip-Response, thus communicating the IP distance in the downstream direction (initiator->responder). By using this procedure, the initiator can also estimate the round trip latency to the responding node. The Ack message notifies the responder of the reception of the PTS by the initiator. Each peer whose identity was discovered by receiving it in a PTS and not by interception has the flag temporarily set to 0 (uncontacted). The selection of the peer to gossip (i.e., the destination of the Registration) is random, giving higher priority to those peers whose flag in the PeT is still 0. Each peer element in the PeT is associated with a lifetime, in order to cope with variable topology networks, where SF instances can migrate. Still uncontacted entries can be removed according to the Least Recently Used eviction policy. The structure of gossip messages are shown in Figure 3, according to the ABNF format [2]. The following fields are used: o Message Type: identifies the type of the message (REG, RES, ACK). Femminella et al., Expires October 4, 2016 [Page 10] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o Peer Identity: uniquely identifies a ST peer. Each ST message must carry a source and a destination Peer-Identity. o Source IP address: this field contains the IP address of the node that forged the packet. In the Registration message contains the IP address of the gossip initiator, and can be used by the intercepting nodes to address their responses. In the Response message it contains the IP address of the intercepting node, and can be stored by the initiator in its peer table. o Session-Identifier: uniquely identifies the signaling session, it allows distinguishing messages belonging to different gossip rounds. o Metric value: this value has the following syntax: in the Registration message the field replicates the value set in the TTL field of the IP header by the IP Layer. In the RegResponse message the value specifies the IP distance from the Source Peer to the Destination Peer. The Destination Peer computes this value after reading the Metric Value and the residual IP TTL value in the Registration message. o IP address type: the version number of the IP address of the shared peer, IPv4 or IPv6. o IP address: one of the IP addresses of the shared peer. Femminella et al., Expires October 4, 2016 [Page 11] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 ---- ---- ---- / \ / \ / \ N1----/Legacy\----N2----/Legacy\----N3----/Legacy\------TR | \ IP / | \ IP / | \ IP / | | \ Net/ | \ Net/ | \ Net/ | | ---- | ---- | ---- | | | | | | | REG1 | | | | (TR,<->) | | | |-----------------|--X--> | | | |Intercepted | | | |and | | | RES1 |dropped | | | (N2,)| | | |<----------------| | | | ACK1 | | | |---------------->| | | REG2 | | | | (N6,)| | | <-X-|-----------------| | | | RES2 | | | | (N2,)| | | |---------------->| | | | ACK2 | | | |<----------------| | | | | | | | | REG3 | | | | (N2,)| | | |<----------------| | | | RES3 | | | | (N3,)| | | |---------------->| | | | ACK1 | | | |<----------------| | | | | | v v v v Figure 2 Gossip-based peer discovery sequence diagram Femminella et al., Expires October 4, 2016 [Page 12] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 Registration = Message Type Source Peer-Identity Destination Peer-Identity Source IP address Session-Identifier Metric value *(Shared PId) RegResponse = Message Type Source Peer-Identity Destination Peer-Identity Source IP address Session-Identifier Metric value *(Shared PId) Ack = Message Type Source Peer-Identity Destination Peer-Identity Session-Identifier Shared PId = Peer-Identity IP address type IP address Figure 3 Gossip-based peer discovery packet format. 4.2. Signaling distribution The distribution function is jointly implemented in both ST and SA layers, through suitable communication primitives, which confine transport issues at the ST layer, and decision logic at the SA layer. Figure 4, Figure 5, Figure 6, and Figure 7 show the finite state machines (FSMs) of SA and ST entities, initiator and forwarder, respectively. In these diagrams, transition edges are labeled with the transition label. A detailed explanation of these transitions, including the triggering event and the triggered actions, is reported immediately below the relevant figure. The SA behavior is modeled by using three states: IDLE, Wait Notification, and Wait Responses. This state definition is flexible enough to adapt to many different SA protocols, but it is also easy enough to allow integrating with SF instances easily. The ST FSM is slightly more complex, since it has to deal with lower layer issues, including packet interception and peer selection. Femminella et al., Expires October 4, 2016 [Page 13] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 The signaling distribution allows disseminating signaling over network regions of nearly arbitrary shape. By leveraging the interception capabilities of ST, this signaling dissemination protocol is highly efficient, and may allow finding resources which are close to a given network path. Since SF instances in data centers could not be on the IP path connecting two communicating entities (just routers are on path), only a signaling protocol with off-path discovery capabilities can find reachable SF resources, which helps limiting network traffic. The off-path domain considered in this document is the so-called hose domain, which includes the ST nodes staying within a maximum distance (expressed in IP hops or in latency units) from at least one of the nodes of the IP data path, which can be regarded as the axis of the hose. This distance will be referred to as the radius of the hose. If the sender and destination are the same node, then the hose collapses into a spherical region around that node. To simplify the description, in what follows the IP hop count is the selected metric. At the ST layer, the off-path signaling distribution adopts a flooding algorithm, which makes use of two main sets of peers. The peers laying on the IP path between the initiator and the signaling destination (on-path peers), and the peers laying within a distance of radius IP hops from the path (off-path peers). The signaling exchange is always initiated by the SA protocol, triggered by an external application (transition from IDLE to Wait Notification in the SA FSM of the initiator in Figure 4). This translates into a command received from the ST layer of the initiator (transition from IDLE to ACTIVE in the ST FSM of the initiator, Figure 6). The signaling initiator generates an initial query message, by setting both the desired values of hose radius and a dedicated on-path flag in the message header, and sends it to the signaling destination. This flag marks the signaling messages delivered through the axis of the hose. Queries, such as Gossip- Registration in the gossip-based peer discovery, are intercepted by the other ST nodes. This happens for on-path queries. Each node receiving an on-path query must accept the peering request by a response message and be ready to receive SA data from the upstream node (transition from IDLE to On-path Forwarder in the ST FSM of the forwarder, Figure 7). Upon receiving these data, they are sent to the SA (loop on On-path Forwarder in Figure 7 and transition from IDLE to Wait Notification in Figure 5). Then, the SA layer triggers the ST layer to deliver the signaling message not only on-path, but also to nodes at a metric value lower than the hose radius received in the query, namely off-path ST nodes. The relevant pseudo-code of Femminella et al., Expires October 4, 2016 [Page 14] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 the algorithm executed at the ST layer to implement the flooding approach is shown in Figure 8. It uses the information stored in the PeT, an example of which is shown in Figure 1. For each selected peer, the ST node generates a new query and decrements the query radius by the peer metric. In addition, the on-path flag is set to 0. The new queries are then sent to all the selected peers. Clearly, the upstream ST node is not selected for off-path distribution. At this time, the ST layer notifies the SA and performs a transition towards the Active state (On-path or Off-path, Figure 7), waiting for responses from the queried peers. In turn, the SA FSM moves into the Wait Responses state (both Figure 4 and Figure 5), and creates a stack data structure to store data responses, which are expected during the signaling responses traveling back towards the initiator. At the ST layer, when positive responses are received by queried peers in Active states, data are delivered to them (loops on Active states in Figure 7 and on ACTIVE in Figure 6). 4.2.1. Finite state machines for SA and ST +---------------+ +---------->| WAIT |-----+ | T1 | NOTIFICATION | | T2 | +---------------+ | | | | | | V +------+ +-----------+ | IDLE |<------------------------| WAIT | +------+ T4 | RESPONSES| +-----------+ ^ | | | +-----+ T3 Figure 4 SA initiator FSM For each transition Ti in Figure 4, the transition list below reports the condition that triggers that transition, and the relevant actions carried out upon entering the new state. Femminella et al., Expires October 4, 2016 [Page 15] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 Transition List for Figure 4: o T1: a NFV application triggers a signaling session to the SA. The SA sends the data to the ST and triggers the start of the signaling session. Condition: reception of trigger from a NFV instance. Action: send command QueryFwd to ST, Send Data to ST. o T2: the ST notifies the SA that all the expected queries have been sent. Condition: reception of notification QuerySent from ST. Action: create RespStack data structure, Start WaitResp Timer. o T3: Condition: receive Data-Response from a downstream peer. Action: increment the response counter (Data-Response.depth++), and add the response to the stack (RespStack.add(Data-Response)). o T4: the ST notifies the SA that all the expected responses have been received OR the maximum waiting time is expired. The collected responses are sent to the NFV instance that triggered the signaling session. Condition: reception of notification RspRcv from ST OR WaitResp timeout. Action: send RespStack to the NFV instance. +---------------+ +---------->| WAIT |-----+ | T1 | NOTIFICATION | | T2 | +---------------+ | | | | | | V +------+ +-----------+ | IDLE |<------------------------| WAIT | +------+ T4 | RESPONSES| +-----------+ ^ | | | +-----+ T3 Figure 5 SA forwarder FSM Femminella et al., Expires October 4, 2016 [Page 16] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 Transition List for Figure 5: o T1: Condition: reception of Data from ST from an upstream peer. Action: send command QueryFwd to ST, Send Data to ST. o T2: the ST notifies the SA that all the expected queries have been sent. A stack to store the expected responses is created and a timer is started Condition: reception of notification QuerySent from ST. Action: create RespStack data structure, start WaitResp Timer. o T3: Condition: reception of Data-Response from a downstream peer. Action: increment the response counter (Data-Response.depth++), and add the response to the stack (RespStack.add(Data-Response)). o T4: T4.1 OR T4.2 T4.1: the ST notifies the SA that all the expected responses have been received OR the maximum waiting time is expired. The local NFV instance is queried, and its response is stored inside the stack. The depth of the response is set to 0. The SA then sends the response stack to the ST to be sent upstream. Condition: reception of notification RspRcv from ST OR sdsd WaitResp timeout. Action: query NFV instance, NFV-Response.depth=0, RespStack.add(NFV-Response),Cmd SendData-Resp(RespStack) to ST. T4.2: Condition: reception of Abort from ST. Action: delete RespStack. Femminella et al., Expires October 4, 2016 [Page 17] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 +--------------------------------+ | T1 | | | | | | | | V +------+ +------------+ | IDLE |<------------------------| WAIT | +------+ T3 | RESPONSES | +------------+ ^ | | | +-----+ T2 Figure 6 ST initiator FSM Transition List for Figure 6: o T1: Condition: reception of command QueryFwd and Data from SA. Action: Send n off-path Queries, send 1 on-path Query, notify QuerySent to SA. o T2: T2.1 OR T2.2 OR T2.3 OR T2.4 T2.1: Condition: reception of Response from a downstream peer. Action: Send Data to downstream peer. T2.2: Condition: reception of Query from a downstream peer. Action: Send Error to downstream peer. T2.3: Condition: reception of Error from a downstream peer. Action: Increment the error counter(ErrorCount++). T2.4: Condition: reception of Data-Response from a downstream peer. Action: increment the response counter(RespCoun++), send Data- Response to SA. Femminella et al., Expires October 4, 2016 [Page 18] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o T3: T3.1 OR T3.2 T3.1: all the expected responses have been collected. The ST notifies the SA and clears the counters. Condition: RespCount+ErrorCount=n+1. Action: notify RespRcv to SA, clear counters. T3.2: Condition: reception of Abort from SA. Action: clear all counters. Femminella et al., Expires October 4, 2016 [Page 19] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 +-------------------------------------------+ | T16 | | T2 T4 | | +--+ +--+ | | | | | | | | | v | v | | +-----------+ T3 +----------+ | +-->| Off-path |------------>| Off-path | | T1| | Forwarder |<------------| Active | | | +-----------+ T5 +----------+ | | | | | | | |T8 | | | | | | +-----------------+ v | v | | T7 +----------+ | | | IDLE | T6| | +----------+ | | ^ | ^ | | | | | | | | T9| |T10 | | | | | | | | | | v v | | +-----------+ T11 +----------+ | +-->| On-path |------------>| Off-path | | | Forwarder |<------------| Active | | +-----------+ T12 +----------+ | | ^ | ^ | | | | | | | | +---+ +---+ | | T14 T13 | | T15 | +-------------------------------------------+ Figure 7 ST forwarder FSM Transition List for Figure 7: o T1: Condition: reception of off-path Query from an upstream peer. Action: Send back Response, save the radius value in a local variable (radius=Query.radius). Femminella et al., Expires October 4, 2016 [Page 20] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o T2: T2.1 OR T2.2 OR T2.3 T2.1: the node receives a query for the same session with a radius greater than the stored radius. The ST must abort the current status of the SA and accept the peering, storing the new radius value. Condition: Reception of off-path Query && Query.radius>radius. Action: Send back Response. Send Abort to SA, save the new radius value to a local variable(radius=Query.radius). T2.2: the node receives a query for the same session with a radius less or equal to the stored radius. The node sends back an error. Condition: reception of off-path Query && Query.radius<=radius. Action: Send Error. T2.3 Condition: reception of Data from the upstream peer. Action: Send Data to SA. o T3: the ST receives the trigger from the SA to forward the received Data. The node is an off-path node, hence it sends n Queries to its n one-hop peers and notifies the SA. Condition: Reception of command QueryFwd and Data from SA. Action: Send n off-path Queries, notify QuerySent to SA. Femminella et al., Expires October 4, 2016 [Page 21] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 T4: T4.1 OR T4.2 OR T4.3 OR T4.4 T4.1: the node receives a query for the same session with a radius less or equal to the stored radius. The node sends back an error. Condition: reception of off-path Query && Query.radius<=radius. Action: Send Error. T4.2: Condition: reception of Data-Response from a downstream peer. Action: increment the response counter(RespCount++), Send Data-Response to SA. T4.3: Condition: reception of Error from a downstream peer. Action: increment the error counter(ErrorCount++). T4.4: the downstream peer accepted the peering with a Response message. The node must forward it the Data. Condition: Reception of Response from a downstream peer. Action: Send Data to the downstream peer. o T5: T5.1 OR T5.2 T5.1: all the expected responses have been collected. The ST notifies the SA and clears the counters. Condition: RespCount+ErrorCount==n. Action: notify RespRcv to SA, Clear counters. T5.2: the node receives a query for the same session with a radius greater than the stored radius. The ST must abort the current status of the SA and accept the peering with a Response message, storing the new radius value. Condition: reception of off-path Query && Query.radius>radius Action: send back Response, send Abort to SA, store the new radius value to a local variable(radius=Query.radius), clear counters. o T6: when an off-path node receives an on-path query, it must send back a response and abort the current SA status. Condition: reception of on-path Query from an upstream peer. Action: send back Response, Send Abort to SA. Femminella et al., Expires October 4, 2016 [Page 22] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o T7: when an off-path node receives an on-path query, it must send back a response and abort the current SA status. Condition: reception of on-path Query from an upstream peer. Action: send back Response, send Abort to SA. o T8: Condition: reception of command SendData-Resp from SA. Action: send Data-Response to the upstream peer. o T9: Condition: reception of on-path Query from an upstream peer. Action: send back Response. o T10: Condition: reception of command SendData-Resp from SA. Action: send Data-Response to the upstream peer. o T11: the ST receives the trigger from the SA to forward the received Data. The node is an on-path node, hence it sends n Queries to its n one-hop peers and 1 Query to the on-path peer and notifies the SA. Condition: reception of command QueryFwd and Data from SA. Action: send n off-path Queries, send 1 on-path Query, notify QuerySent to SA. o T12: all the expected responses have been collected. The ST notifies the SA and clears the counters. Condition: RespCount+ErrorCount==n+1. Action: notify RespRcv to SA, clear counters. Femminella et al., Expires October 4, 2016 [Page 23] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o T13: T13.1 OR T13.2 OR T13.3 OR T13.4 T13.1: when an on-path node receive an off-path query it must reject the peering and send back an error. Condition: reception of off-path Query from a peer. Action1: send Error. T13.2: Condition: receive Data-Response from a downstream peer. Action: increment the response counter(RespCount++), Send Data-Response to SA. T13.3 Condition: reception of Error from a downstream peer. Action: increment the error counter(ErrorCount++). T13.4 Condition: reception of Response from a downstream peer. Action: send Data to the downstream peer. o T14: T14.1 OR T14.2 T14.1: when an on-path node receive an off-path query it must send back an error. Condition: reception of off-path Query from a peer. Action: send Error. T14.2 Condition: reception of Data from the upstream peer. Action: send Data to SA. o T15: Condition: reception of command SendData-Resp from SA. Action: send Data-Response to the upstream peer. o T16: Condition: reception of command SendData-Resp from SA. Action: send Data-Response to the upstream peer. Femminella et al., Expires October 4, 2016 [Page 24] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 Algorithm: selectOffpathDestinations Input: (peerTable, radius) for peer in peerTable if peer.metric exists if radius>peer.metric destination.peer=peer destination.radius=radius-peer.metric destinationList.append(destination) endif endif endfor Output: destinationList Figure 8 peer selection algorithm for off-path distribution 4.2.2. ST messages The message used for signaling distribution at ST, in the ABNF format, are reported in the Figure 9 below. Query = Message Type Source Peer-Identity Destination Peer-Identity Source IP address Destination IP address Session-Identifier On-path flag Metric Type Radius SA-Identifier Response = Message Type Source Peer-Identity Destination Peer-Identity Source IP address Destination IP address Session-Identifier SA-Identifier Error = Message Type Source Peer-Identity Destination Peer-Identity Session-Identifier Femminella et al., Expires October 4, 2016 [Page 25] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 Source IP address Destination IP address Error code Data = Message Type Source Peer-Identity Destination Peer-Identity Source IP address Destination IP address Session-Identifier SA-Identifier SA-Payload Data-Response = Message Type Source Peer-Identity Destination Peer-Identity Source IP address Destination IP address Session-Identifier SA-Identifier SA-Payload Figure 9 ST layer packet format. The fields used in ST distribution messages are: o On-path flag: this flag has the following meaning: the value 1 indicates that the peering request must be accepted in any case, it must be acknowledged with a Response and any other signaling session for the same id must be aborted. The value 0 indicates that the peering request can be accepted or rejected according to the ST layer status (see Figure 6 and Figure 7). o Metric Type: specifies the type of the metric used to define the off-path radius (IP hop, latency, other to be defined). o Radius: specifies the radius of the off-path distribution. o Error code: specifies the type of the error. o SA-Identifier: uniquely identifies a SA with the following syntax: the first n bits identify the SF type (i.e., cache, firewall, proxy, etc...), the second m bits identify the SF platform. Femminella et al., Expires October 4, 2016 [Page 26] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o SA-Payload: the opaque SA message transported by the ST. 4.2.3. Error management and termination procedures When a node receives an off-path query, it reads the radius value. If this value is greater than 1, it iterates the same procedure illustrated above in order to select the set of signaling destinations to be included in the distribution set. The relevant transition in the ST state machine is from IDLE to Off-path Forwarder, as shown in Figure 7. In order to avoid the packet duplication problem, typical of flooding algorithms when the network topology includes cycles, an ST error message was introduced to limit overhead. In more detail, when a forwarder receives a signaling message, it creates an internal soft state for the signaling session storing: the identifier of the served SA protocol, the session identifier, the upstream PID, and the radius of the latest processed query. Then, if it receives a further ST off-path query from another peer, with the same set of values and a hose radius lower than the stored one, it replies by sending an error message, rejecting the peering request (error loops on all states except IDLE in Figure 6 and Figure 7), and the ErrorCount variable, set to 0 at session state creation, is incremented. Instead, if the hose radius is higher than the stored one, the previous session is aborted, the SA is notified (transition to IDLE in Figure 7), and a new session is created at ST (transition to Off-path Forwarder in Figure 7). Similarly, when an off-path node receives an on-path query, it must abort the previous session and establishes a new one, now acting as an on-path node. In this case, the SA is also notified and the relevant states are deleted. The relevant transitions on Figure 7 are those from off-path states to On-path Forwarder. When the ST layer realizes that it cannot further forward the query, according to the algorithm in Figure 8, it starts transmitting the data responses back to the initiator, by notifying the relevant SA layer with empty data, and moves back into the Off-path Forwarder state (Figure 7). The SA layer queries the local SF instance and adds its response to the stack with depth equal to 0, and triggers the underlying ST to transmit upstream the data response. Session state at SA is cleared, and the FSM returns into the IDLE state. When the ST receives this command from the above SA, it sends upstream the data response, clears all state information, and returns into IDLE. Femminella et al., Expires October 4, 2016 [Page 27] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 4.2.4. Forwarder management procedures The management of an intermediate forwarder is slightly more complex. When an ST peer receives a data response, it increments the local counter RespCounter, set to 0 at session state creation, and passes data response to the SA layer through the relevant APIs (loops on Active states in Figure 6 and Figure 7), by adding also the metric value towards the peer that has sent such a response, retrievable from the PeT. The SA, in turn, adds this data response to the stack prepared upon entering the Wait Response state, and increases its depth value (loops on Wait Responses state in Figure 4 and Figure 5). When all waited responses have been received by the ST layer, which means that the number of responses and error message is equal to the number of sent queries, the ST comes back into the Forwarder state (Figure 7), by notifying the SA. The SA queries the local NFV instance, adds the relevant data to the stack with dept equal to 0, and triggers the ST to send all the data response stack upstream. Then, it clears all state variables and moves back into IDLE. In turn, the ST sends these data upstream, clears all state information, and moves back into IDLE. A similar behavior is followed when, at the SA layer, the WaitResp timer, started upon entering the Wait Responses state, expires. In this case, it triggers the delivery of received response data upstream, without waiting for the notification from the ST. In Figure 7, this corresponds to edges from Active states to IDLE. When either the desired responses are received or the wait time expires, the SA initiator moves again into the IDLE state, by sending the collected responses to the SF instance. Additional timers for managing situations in which either the SA, or the ST layer, crashes or freezes, can been added optionally. However, they are implementation dependent details, and thus out of the scope of this document. 4.2.5. SA messages In order to manage the SF states and discovery, three SA messages have been introduced, referred to as data in FSMs, illustrated in the ABNF format in Figure 10 below. The SETUP and REMOVE messages enable the SA instance to add or delete states, respectively, within the SF application. These messages can be acknowledged with a simple response code (e.g. 200 OK or Error code) by the SA forwarder, indicated as data response in FSMs. However, it is also possible to enable the overall FSM functioning without data response, by simply Femminella et al., Expires October 4, 2016 [Page 28] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 setting WaitResp=0 at the SA layer. The PROBE message is more interesting, since it allows collecting information on the status of a SF application and the relative position of the hosting nodes, represented as an overlay tree. In this case, the data on the NFV status are transported within data responses. Setup = Message Type Service Type [SF Payload] Remove = Message Type Service Type [SF Payload] Probe = Message Type Service Type [SF Payload] Response = Message Type Response code *(SF Status Element) SF Status Element = Node-Identifier Status code Depth Figure 10 SA layer packet format The fields used in SA messages are: o Message Type: identifies the type of the message. o Service type: this flag has the following meaning: the value 0 indicates that the signaling session does not require a Response message, the value 1 indicates that the signaling session must be acknowledged with a Response message. o Response code: identifies the response code of the NFV application. o SF Payload: optional SF opaque data Femminella et al., Expires October 4, 2016 [Page 29] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o Node-Identifier: this field identifies the node hosting the SF. It can be set with the main IP address of the node or with a unique identifier. o Status code: a code representing the status of the SF. o Depth: this field is interpreted as an integer value and has the following meaning. Each SA sets the depth field of its own status element to 0. The SF Status Elements are added recursively to a stack by each forwarder, as the responses were collected and sent upstream. As indicated in Figure 5, each SA forwarder increments by one the depth value of the Status Elements received by the downstream peer, and adds its own Status element to the stack only when all the expected responses have been collected (i.e., on the top of the stack). This syntax allows the initiator to parse the stack of the Status Element with the relevant depth field and to build a tree of the off-path domain with the following logic: the first element of the stack represents the root, with depth 0. For each element E in the stack with depth i, its father node is the first element of depth i-1, found parsing the list backward from E toward the root. Its children set is composed by each element C with depth i+1, found parsing the list from E toward the end until a node with depth k<=i is found. 5. Transport Layer Considerations Messages of OSP can be transported by any layer 4 protocol. This section illustrates sensitivity to packet losses and overhead in case UDP or TCP is used. 5.1. Peer discovery Peer discovery is a process based on gossiping between peers. Since it consists of three messages (Registration, RegResponse, and Ack, see Figure 3), the most reasonable choice is to use UDP, due to the high overhead in establishing a TCP session for exchanging just three small application layer messages. The gossip mechanism, which adopts a soft state based on timers, is intrinsically robust to packet losses. 5.2. Signaling distribution The signaling distribution is a more complex process, and can use both pure UDP and mixed UDP/TCP. In any case, the OSP protocol uses Femminella et al., Expires October 4, 2016 [Page 30] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 timer-based soft states also in the signaling distribution. This means that that a session will not be locked by a packet loss, but, at most, some part of the overlay distribution tree will not be covered. If UDP is used, it could happen that one of the messages listed in Figure 9 is lost. However, this does not necessarily means that a portion of the network is not be reached by signaling messages. In fact, due to the flooding-based operation of the OSP protocol, most of the potential losses can be compensated by additional Queries, arriving from a different path. If the Response is lost, the queried node could send an Error message upon receiving a new Query, based on the comparison between the stored "radius" value and the "Query.radius" one (see transition T2.2 in Figure 7). Finally, if Data or Data-Response messages are lost, the initiator does not distribute to and/or get info from a portion of the overlay distribution tree. Also the TCP protocol can be used to transport signaling distribution messages. However, due to the flooding-based operation of the signaling distribution, there would likely be a significant number of Query + Error exchanges. Since the overhead to set up and tear down a TCP session just to exchange a Query + Error messages could be excessive, it seems more reasonable to set up the TCP session only between those peers that have established a "peering agreement" (Query followed by a Response, both transported over UDP). In this case, TCP guarantees the reliable delivery of larger Data and Data-Response messages, and the number of TCP session would be much lower, thus with a significantly lower overhead. In addition, as in the UDP case, the flooding-based operation guarantees the coverage of most of peers through multiple paths, thus limiting the impact of packet losses on Query messages. 6. Security Considerations Messages of OSP can be transported by any layer 4 protocol, including UDP and TCP. In case security is desired, TLS/SSL over TCP can be used. SFC and OSP must provide mechanisms for: o Rate control methods should be deployed to avoid DDOS attack with Gossip or Query messages. Femminella et al., Expires October 4, 2016 [Page 31] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 o Avoiding leakage of SFC information beyond its administrative domain. 7. IANA Considerations No action is required by IANA for this document. 8. Conclusions This document illustrates a new signaling protocol, called OSP, for discovering network resources and made them available to the SF framework. The original feature of this protocol is its off-path scope, which is enabled through gossip-based discovery and flooding- based distribution. Signaling distribution leverages on the protocol packet capture capability. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, IETF RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", IETF RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 9.2. Informative References [3] Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", IETF Interned draft, draft-ietf-sfc-problem- statement-13 (work in progress), February 2015. [4] J. Martins et al., "ClickOS and the Art of Network Function Virtualization", NSDI '14, April 2-4, 2014 Seattle, WA, USA [5] J. Sherry et al., "Making middleboxes someone else's problem: Network processing as a cloud service", ACM SIGCOMM, 2012. Femminella et al., Expires October 4, 2016 [Page 32] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 [6] "Network Functions Virtualisation (NFV) Network Operator Perspectives on Industry Progress", ETSI, October 2013, http://portal.etsi.org/NFV/NFV_White_Paper2.pdf. [7] S. Shanbhag and T. Wolf, "Automated Composition of Data-Path Functionality in the Future Internet", IEEE Network, 2011, 25 (6), pp. 8-14. [8] S. Guha, P. Francis, "An end-middle-end approach to connection establishment," ACM SIGCOMM Comput. Commun. Rev., 37(4), pp. 193-204, Aug. 2007. [9] Q. Duan, Y. Yan, A.V. Vasilakos, "A Survey on Service-Oriented Network Virtualization Toward Convergence of Networking and Cloud Computing", IEEE Transactions on Network and Service Management, 9(4), 2012. [10] C. Dovrolis, S. Akhshabi, "The Evolution of Layered Protocol Stacks Leads to an Hourglass-Shaped Architecture", ACM SIGCOMM'11, August 2011, Canada. [11] M. Femminella et al., "An enabling platform for autonomic management of the future internet", IEEE Network, 2011, 25 (6), pp. 24-32. [12] M. Femminella et al, "Gossip-based signaling dissemination extension for next steps in signaling". IEEE/IFIP NOMS 2012, April 2012, USA. [13] J. Hwang, K.K. Ramakrishnan, T. Wood, "NetVM: High Performance and Flexible Networking Using Virtualization on Commodity Platforms", NSDI '14, Apil 2014, USA [14] X. Ge et al., "OpenANFV: Accelerating Network Function Virtualization with a Consolidated Framework in OpenStack", ACM SIGCOMM'14, August 2014, USA. [15] A. Gember-Jacobson et al., "OpenNF: Enabling Innovation in Network Function Control", ACM SIGCOMM'14, August 2014, USA. [16] P. Quinn et al., "Network Service Header", IETF Interned draft, work in progress, draft-quinn-sfc-nsh-07.txt, (work in progress), February 2015. [17] Y. Zhang, "StEERING: A Software-Defined Networking for Inline Service Chaining", IEEE ICNP'13, October 2013, Germany. Femminella et al., Expires October 4, 2016 [Page 33] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 [18] M. Jelasity, A. Montresor, O. Babaoglu, "T-man: Gossip-based fast overlay topology construction," Computer Networks, 53(13), 2009, pp. 2321-2339. [19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", IETF RFC 3261, June 2002. [20] C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", IETF RFC 6940, January 2014. [21] P. Saint-Andre, "Extensible Messaging and Presence Protocol (XMPP): Core", IETF RFC 6120, March 2011. [22] R. Hancock, G. Karagiannis, J. Loughney and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", IETF RFC 4080, June 2005. [23] H. Schulzrinne, R. Hancock, "GIST: General Internet Signalling Transport", IETF RFC 5971, October 2010. 10. Acknowledgments This work has been partially supported by EU under the project ARES, funded by GEANT/GN3plus in the framework of the first GEANT open call. This document was prepared using 2-Word-v2.0.template.dot. Femminella et al., Expires October 4, 2016 [Page 34] Internet-Draft Off-Path Signaling Protocol for SFC April 2016 Authors' Addresses Mauro Femminella Engineering Department, University of Perugia Via G. Duranti 93, 06125 Perugia, Italy Phone: +39 075 585 3630 Email: mauro.femminella@unipg.it Gianluca Reali Engineering Department, University of Perugia Via G. Duranti 93, 06125 Perugia, Italy Phone: +39 075 585 3651 Email: gianluca.reali@unipg.it Dario Valocchi Department of Electronic and Electrical Engineering, Faculty of Engineering Science, University College London WC1E 6BT London, UK Email: dario.valocchi@gmail.com Femminella et al., Expires October 4, 2016 [Page 35]