Internet DRAFT - draft-femmreali-sfc-offpath-signaling
draft-femmreali-sfc-offpath-signaling
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: June 2017 December 1, 2016
Off-Path Signaling Protocol for Service Function Chaining
draft-femmreali-sfc-offpath-signaling-03
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 June 1, 2009.
Femminella et al., Expires June 1, 2017 [Page 1]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 ................................. 31
6. Security Considerations ..................................... 32
7. IANA Considerations ........................................ 32
8. Conclusions ................................................ 32
9. References ................................................. 32
9.1. Normative References ................................... 32
9.2. Informative References ................................. 33
10. Acknowledgments ........................................... 34
Femminella et al., Expires June 1, 2017 [Page 2]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 3]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 4]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 5]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 6]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 7]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 8]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 9]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 10]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 11]
Internet-Draft Off-Path Signaling Protocol for SFC December 2016
---- ---- ----
/ \ / \ / \
N1----/Legacy\----N2----/Legacy\----N3----/Legacy\------TR
| \ IP / | \ IP / | \ IP / |
| \ Net/ | \ Net/ | \ Net/ |
| ---- | ---- | ---- |
| | | |
| | REG1 | |
| | (TR,<->) | |
| |-----------------|--X--> |
| | |Intercepted |
| | |and |
| | RES1 |dropped |
| | (N2,<N5,N6,...>)| |
| |<----------------| |
| | ACK1 | |
| |---------------->| |
| REG2 | | |
| (N6,<N3,N5,...>)| | |
<-X-|-----------------| | |
| RES2 | | |
| (N2,<N8,N9,...>)| | |
|---------------->| | |
| ACK2 | | |
|<----------------| | |
| | | |
| | REG3 | |
| | (N2,<N4,N9,...>)| |
| |<----------------| |
| | RES3 | |
| | (N3,<N1,N5,...>)| |
| |---------------->| |
| | ACK1 | |
| |<----------------| |
| | | |
v v v v
Figure 2 Gossip-based peer discovery sequence diagram
Femminella et al., Expires June 1, 2017 [Page 12]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 13]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 14]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 15]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 16]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 17]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 18]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 19]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 20]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 21]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 22]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 23]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 24]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 25]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 26]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 27]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 28]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 29]
Internet-Draft Off-Path Signaling Protocol for SFC December 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.
Peer discovery could also allow distributing some information about
the service status of close peers. This can be easily implemented by
adding a payload "Status info" in addition to the Shared PId field
into Registration and RegResponse messages, whose format is
Femminella et al., Expires June 1, 2017 [Page 30]
Internet-Draft Off-Path Signaling Protocol for SFC December 2016
illustrated in Figure 3. This could highly simplify the task of the
SA in providing fresh service info to specific applications
interested only to "close" peers.
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
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.
Femminella et al., Expires June 1, 2017 [Page 31]
Internet-Draft Off-Path Signaling Protocol for SFC December 2016
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.
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 by means of software defined networking techniques.
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.
Femminella et al., Expires June 1, 2017 [Page 32]
Internet-Draft Off-Path Signaling Protocol for SFC December 2016
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.
[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
Femminella et al., Expires June 1, 2017 [Page 33]
Internet-Draft Off-Path Signaling Protocol for SFC December 2016
[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.
[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 June 1, 2017 [Page 34]
Internet-Draft Off-Path Signaling Protocol for SFC December 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 June 1, 2017 [Page 35]
