idnits 2.17.1 draft-femmreali-sfc-offpath-signaling-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 64 characters in excess of 72. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 560 has weird spacing: '... state machi...' == Line 563 has weird spacing: '...cluding the ...' == Line 574 has weird spacing: '... The signal...' == Line 575 has weird spacing: '...network regio...' == Line 576 has weird spacing: '...ception capab...' == (5 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 1, 2016) is 2674 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M. Femminella 2 SFC Working Group G. Reali 3 Internet Draft University of Perugia 4 Intended status: Informational D. Valocchi 5 University College London 6 Expires: June 2017 December 1, 2016 8 Off-Path Signaling Protocol for Service Function Chaining 9 draft-femmreali-sfc-offpath-signaling-03 11 Abstract 13 This document illustrates a reference protocol able to discover 14 deployed instances of Service Functions (SFs), which can be located 15 also off-path with respect to the IP datapath between flow source 16 and flow destination. It is an application protocol organized in two 17 layers: signaling transport, which deal lower layer signaling 18 transport, and signaling application, which directly interfaces with 19 the intended SF. Discovery of SFs is a primary step to for 20 implementing Service Function Chaining (SFC). 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on June 1, 2009. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................ 3 63 1.1. Document scope ......................................... 4 64 2. Conventions used in this document ............................ 5 65 3. Related work ................................................ 5 66 3.1. Signaling protocols in data network ..................... 5 67 3.2. Platforms for hosting virtualized SFs ................... 6 68 3.3. Service redirect solutions .............................. 7 69 4. Off-path Signaling Protocol description ...................... 7 70 4.1. The peer discovery in the Signaling Transport layer ...... 8 71 4.2. Signaling distribution ................................. 13 72 4.2.1. Finite state machines for SA and ST ............... 15 73 4.2.2. ST messages ....................................... 25 74 4.2.3. Error management and termination procedures ........ 27 75 4.2.4. Forwarder management procedures ................... 28 76 4.2.5. SA messages ....................................... 28 77 5. Transport Layer Considerations .............................. 30 78 5.1. Peer discovery ........................................ 30 79 5.2. Signaling distribution ................................. 31 80 6. Security Considerations ..................................... 32 81 7. IANA Considerations ........................................ 32 82 8. Conclusions ................................................ 32 83 9. References ................................................. 32 84 9.1. Normative References ................................... 32 85 9.2. Informative References ................................. 33 86 10. Acknowledgments ........................................... 34 88 1. Introduction 90 Service Function Chaining (SFC) enables the creation of composite 91 services that consist of an ordered set of Service Functions (SF) 92 that are be applied to packet flows as a result of classification. 93 SFC is a concept that provides for more than just the application of 94 an ordered set of SFs to selected traffic; rather, it describes a 95 method for deploying SFs in a way that enables dynamic ordering and 96 topological independence of those SFs as well as the exchange of 97 metadata between participating entities. Foundations of the SFC are 98 described in below documents: 100 o SFC problem statement [3]. 102 o Various individual drafts. 104 SFs is an area that has recently gained attention as one of the most 105 successful novelty in networking research. Many essential functions 106 can be virtualized, such as security functions (firewalling, 107 intrusion detection, traffic scrubbing), shaping functions (rate 108 limiting, load balancing), addressing, caching, and middlebox 109 management [4][5]. The strategic importance of SF is also 110 demonstrated by the related ongoing standardization activities. For 111 example, in addition to the IETF SFC Working Group, in 2012 seven 112 leading network operators selected ETSI to host the Industry 113 Specification Group for Network Function Virtualization (NFV) [6]. 114 Furthermore, the IETF Service Function Chaining (SFC) working group 115 has been addressing strictly related functions since mid 2014. 116 Another related effort is the IETF Network Virtualization Overlays 117 (nvo3) working group. Since mid 2012, the nvo3 working group has 118 been dealing with solutions for supporting multi-tenancy in data 119 centers managing virtualized hosts. The considered approaches reside 120 at the network layer and aim at deploying Data Center Virtual 121 Private Network (DCVPN) across a range from thousands to millions of 122 virtual machines (VMs) with good scaling properties. In addition, 123 the IEEE has recently standardized the Next Generation Service 124 Overlay Network (NGSON), including entities for service composition 125 and routing. Their combination allows combining computing services 126 and routing for data communications [9]. In [7], the authors address 127 the problem of composing SFs automatically and propose a formal 128 representation of the semantics of data connections, along with the 129 relevant functions and policies. 131 The common aspect of all these activities is the collection and 132 joint management of network resources distributed over geographical 133 networks and made available through a virtualized interface. Thus, 134 SF resource discovery is a critical aspect preliminary to all the 135 mentioned proposals, and not enough considered so far in the 136 technical literature. A survey the research developments in the 137 closely related area of service discovery for realizing NaaS 138 (Network as a Service) to support network-cloud convergence can be 139 found in [9]. However, in the perspective of a service composition 140 through SFs, the importance of the resource awareness is higher when 141 resources are located close to data paths, so that they can be 142 considered candidate for implementing or adapting service delivery. 144 To sum up, even if a number of proposals for virtualized SF/NFV 145 exists, however, some management issues are still unexplored. One 146 issue is the discovery of SF instances. Another issue is that is it 147 often desirable to maintain the SF instances sufficiently close to 148 IP data paths. The first issue is related to deployments of SF 149 instances in clouds, where they could be moved and/or replicated. 150 The second one refers to chaining NFV instances while keeping 151 acceptable the increase of network traffic. 153 This document describes the off-path signaling protocol (OSP), 154 designed for distributing signaling messages over portions of data 155 networks around data paths (configurable network scope). The main 156 issue that is addressed by this document is the need of discovering 157 network nodes, hosting virtualized SFs, within network scopes 158 destined to deploy a wide class of services. The protocol is 159 designed to be distributed, autonomic, and easy to deploy solution. 160 This protocol leverages on two main network functions, namely, on- 161 path packet interception and off-path signaling distribution [8]. 163 Specifically, this document provides: 165 o a survey of the existing signaling protocols that could be 166 regarded as alternative solutions to OSP and currently available 167 NFV platforms to implements virtualized SFs. 169 o a formal description of the OSP protocol, by using finite state 170 machine diagrams. 172 1.1. Document scope 174 The focus of this document is to provide the description of a 175 discovery protocol for SFC named off-path signaling protocol (OSP). 176 Actual solutions and implementation mechanisms are outside the scope 177 of this document. 179 2. Conventions used in this document 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC-2119 [1]. 185 In this document, these words will appear with that interpretation 186 only when in ALL CAPS. Lower case uses of these words are not to be 187 interpreted as carrying RFC-2119 significance. 189 3. Related work 191 3.1. Signaling protocols in data network 193 This section illustrates the mostly used signaling protocols in data 194 network and evaluate their suitability in accomplishing the desired 195 functions for resource discovery of SFs. 197 A special mention is due to the Session Initiation Protocol (SIP, 198 IETF RFC 3261, [19]), an application-layer signaling protocol. It is 199 the protocol mostly used for establishing multimedia sessions over 200 IP networks. Although its diffusion is an attractive property, its 201 intrinsic end-to-end scope, assisted by intermediate proxies, makes 202 its usage unfeasible for the aims of this paper. 204 The REsource LOcation And Discovery (RELOAD) protocol, specified by 205 the ITEF RFC 6940 [20], extends the SIP capabilities by introducing 206 peer-to-peer (P2P) message exchange. Nevertheless, on-path packet 207 interception is not present. This (missing) feature does not allow 208 to properly identify SFs which are deployed around a data path. 210 Also protocols for high volume messaging, such as eXtensible 211 Messaging and Presence Protocol (XMPP, IETF RFC 6120 [21]) or 212 similar, are unsuitable, since they rely on a client-server 213 architecture, and clients may not exchange messages directly to one 214 another. Also in these protocols, features allowing to properly 215 identify SFs which are deployed around a data path are missing. 217 The EvoArch evolutionary model, presented in [10], shows that in 218 order to design protocol having a significant change to survive over 219 time, it is necessary either to replace an incumbent one, by 220 including similar services and significant novelties, or to make 221 them largely non-overlapping, in terms of features, with existing 222 and largely used ones. In terms of features and capabilities, the 223 Next Steps in Signaling (NSIS, IETF RFC 4080 [22]) architecture 224 partially addresses the needs of the SFs resource discovery. In 225 fact, NSIS was defined for signaling information about a data flow 226 along its path in the network, in order to allows signaling 227 applications to install and manage states in the network though on- 228 path packet interception. It consists of two layers, namely, NSIS 229 transport layer protocol (NTLP), which is a generic lower layer used 230 for on-path node discovery and message sending, and NSIS signaling 231 layer protocol (NSLP), the upper layer implementing specific 232 signaling application logic. The IETF-defined version of the NTLP is 233 the General Internet Signaling Transport protocol (GIST, IETF RFC 234 5971 [23]). It allows sending signaling messages either towards an 235 explicit destination or path-coupled, that allows installing states 236 in all the NSIS peers that lie on the path between two end points. 237 GIST does not support off-path signaling. Nevertheless, it includes 238 extensibility functions, that have been used to introduce an off- 239 path routing support [12]. The weakness of this solution consists of 240 the complexity of the NSIS architecture, which has hampered its 241 widespread adoption. 243 3.2. Platforms for hosting virtualized SFs 245 Some recently developed research platforms able to host SF in a 246 virtualized fashion through deployment in the cloud are reported 247 below. Given likely deployment in clouds, they could benefit of the 248 functions provided by OSP. 250 o NetVM: a high-speed network packet processing platform, 251 implemented by using the Intel's DPDK library [13]. It provides 252 capabilities for traffic steering network function chaining. 254 o ClickOS: a Xen-based virtualized platform optimized for middlebox 255 processing [4]. It can execute hundreds of middleboxes on 256 commodity hardware. 258 o NetServ: it is a programmable node platform designed for 259 deploying in-network services [11]. It includes in-network 260 virtualized service containers and a common execution environment 261 for both network services and traditional addressable services 262 (e.g. a Web server). 264 o OpenANFV: a platform designed to consolidate various hardware 265 resources [14]. It is programmable and supports virtualized 266 acceleration for middleboxes in a cloud environment. 268 o OpenNF: it is a control plane architecture including a set of 269 APIs managing combination of events and forwarding updates to 270 address race conditions, accommodating different network 271 functions [15]. 273 3.3. Service redirect solutions 275 Traffic redirection is a research area strongly related to NFV. It 276 essentially consists of implementing service paths, different from 277 data paths, by means of tunnels. It is worth mentioning the Network 278 Service Header [16] solution proposed by the IETF SFC working group, 279 which allows forming service paths, which transport not only data 280 traffic but also configuration metadata. 282 Another interesting solution, based on the software defined network 283 paradigm, is shown in [17]. 285 4. Off-path Signaling Protocol description 287 The definition of OSP was inspired by the design and implementation 288 experience of designing an off-path extension of GIST [12]. The new 289 signaling protocol includes all the necessary features of NSIS while 290 removing all the components that have been demonstrated to be 291 scarcely acceptable. In addition, following the guidelines of the 292 EvoArch evolutionary model [10], the protocol natively integrate new 293 features, such as the support for off-path signaling, the importance 294 which was still not well understood at the time of the NSIS 295 introduction. In more detail, the protocol architecture inherits 296 some of the key features of two existing solutions which compensate 297 each other's shortcomings. These solutions are the NSIS protocol 298 architecture and P2P gossip message exchange [18]. In addition, some 299 key features, suitable to support NFV needs, have been included. 300 They are listed below. 302 NSIS inheritance: 304 o Two-layer protocol organization. The upper layer of the OSP 305 architecture, called Signaling Application (SA), implements the 306 application signaling logic. The lower layer, called Signaling 307 Transport (ST), distributes the SA messages to the intended 308 recipients. 310 o On-path packet interception capability, available at ST, to 311 assist off-path operation at ST. Packet interception can be 312 implemented in a number of ways (port-based traffic filtering, 313 RAO IP option, specific rules in OpenFlow switches, and so on), 314 which are implementation specific and thus out of the scope of 315 this document. 317 P2P gossip protocols inheritance: 319 o Randomized, gossip-based message exchange, used for peer 320 discovery in ST. 322 o Robustness (no single point of failure) due to distributed nature 323 of the protocol and scalability. 325 New features: 327 o Simplified state definition in ST in comparison to the many state 328 variables organized in multiple tables of GIST. 330 o Off-path signaling capability as native function. 332 The OSP natively extends the path-coupled operation of GIST with 333 off-path signaling, and without including all complexity of GIST due 334 to the initial support of QoS network protocols currently unused. 336 The combination mentioned above allows also avoiding the 337 shortcomings of the P2P-based approaches, which offer little or no 338 support to proximity-based solutions, trying instead to limit the 339 network overhead. 341 In order to implement the off-path signaling distribution functions, 342 the OSP protocol defines, at the lower layer (ST), a peer discovery 343 function, which identifies neighboring nodes running the OSP 344 protocol. This function allows building a peer table, which is used 345 during the signaling distribution in the ST layer itself. 347 4.1. The peer discovery in the Signaling Transport layer 349 Peer discovery is a function which allows building peer tables, 350 which are data structures used in the off-path signaling 351 distribution. It is implemented in the ST layer. The peer discovery 352 is used both to collect identity of peers and to measure IP distance 353 and latency between them. It exploits the interception capabilities 354 inherited from NSIS and the flexibility of gossiping. 356 Each ST node stores information on the previously discovered ST 357 nodes in the Peer Table (PeT). Each PeT entry stores the following 358 information: 360 o the unique identifier of a ST node, called Peer Identity (PID), 362 o its IP address, 364 o metric values, consisting of its IP hop distance and of its 365 estimated round-trip network latency, 367 o the timestamp of the last gossip session with the peer, 369 o a boolean flag used to mark if the initiator has tried to 370 contacted or contacted that peer. 372 An example of PeT is reported in Figure 1. 374 +----------------------------------------------------------------+ 375 | # | PeerId | IP Address | Metrics | Timestamp | Flag | 376 +----------------------------------------------------------------+ 377 | | | | IP Hops | Latency | | | 378 +================================================================+ 379 | | | | | | | | 380 | 1 | kJNg | 10.0.3.1 | / | / | 1410704001| 0 | 381 | | | | | | | | 382 | 2 | p2uQ | 10.0.32.2 | 2 | 400 | 1410704003| 1 | 383 | | | | | | | | 384 | 3 | AuSp | 10.0.223.1 | -1 | -1 | 1410704005| 1 | 385 | | | | | | | | 386 +----------------------------------------------------------------+ 387 Figure 1 Example of a Peer Table. 389 The communicating protocol entities of the ST gossip-based peer 390 discovery process are the initiator, which aims to collect 391 information about the other peers, and the responder. The collected 392 information includes the position of responder, which is considered 393 relative to the initiator, and the identities of other peers, shared 394 by the responder, as it typically happens in gossip protocols 396 The protocol is asynchronous and round based. When an ST node is 397 turned on, it does not store any information on the reachable ST 398 nodes. It is only aware of a default node called tracker, used to 399 receive an initial set of peers. Then, an ST node tries to 400 periodically establish gossip sessions with the known peers to 401 discover further ST nodes. The messages used for this discovery are 402 Registration (REG), RegResponse (RES), and Ack (ACK). Only 403 Registration messages can be intercepted. 405 In order to limit the network overhead, the considered scope 406 extension of each node is 1 ST hops. All Registration messages are 407 intercepted and dropped by the first ST node on path (responder), as 408 the message sent by N2 to TR in Figure 2. The responder replies with 409 a RegResponse, followed by a final Ack. Registrations and 410 RegResponses include one or more PIDs, together with one of their IP 411 addresses. This list forms the peer to share list (PTS). The PTS 412 peer selection is random. . The time evolution of the activity of a 413 set of peer is illustrated in Figure 2. In each message, in addition 414 to the message type (REG, RES, or ACK), it is indicated within () 415 the destination identity and the list of PIDs in the transported 416 PTS. TR indicates the tracker. The tracker node can be configured in 417 the OSP configuration file, or retrieved through properly set up 418 information services, which are out of the scope of this document. 420 When an initiator receives the RegResponse, it stores the identity 421 of the responder in its PeT, along with the relevant measured 422 metrics, and the flag is set to 1, which indicates that the 423 responder has been contacted. In case of interception of 424 Registration by another ST node (responder), the flag associated 425 with the destination peer is set to 1, whereas its relevant metric 426 values are set to a non-significant value (e.g. -1). It means that 427 the destination is out of scope (unreachable). The identity of the 428 intercepting responder is added/updated as a contacted peer (see 429 Figure 2, gossip registration of N2 to the tracker intercepted and 430 answered by N3). 432 In order to compute its IP distance to the responder in the 433 downstream direction, the initiator carries the original value of 434 the IP TTL used at the IP layer (ST-HOP field in the ST payload). 435 The intercepting node, which acts as a responder, reads the current 436 values of the IP TTL, and inserts the ST-HOP, decremented by the IP 437 TTL, into the Gossip-Response, thus communicating the IP distance in 438 the downstream direction (initiator->responder). 440 By using this procedure, the initiator can also estimate the round 441 trip latency to the responding node. The Ack message notifies the 442 responder of the reception of the PTS by the initiator. 444 Each peer whose identity was discovered by receiving it in a PTS and 445 not by interception has the flag temporarily set to 0 (uncontacted). 446 The selection of the peer to gossip (i.e., the destination of the 447 Registration) is random, giving higher priority to those peers whose 448 flag in the PeT is still 0. 450 Each peer element in the PeT is associated with a lifetime, in order 451 to cope with variable topology networks, where SF instances can 452 migrate. Still uncontacted entries can be removed according to the 453 Least Recently Used eviction policy. 455 The structure of gossip messages are shown in Figure 3, according to 456 the ABNF format [2]. The following fields are used: 458 o Message Type: identifies the type of the message (REG, RES, 459 ACK). 461 o Peer Identity: uniquely identifies a ST peer. Each ST message 462 must carry a source and a destination Peer-Identity. 464 o Source IP address: this field contains the IP address of the node 465 that forged the packet. In the Registration message contains 466 the IP address of the gossip initiator, and can be used by the 467 intercepting nodes to address their responses. In the Response 468 message it contains the IP address of the intercepting node, 469 and can be stored by the initiator in its peer table. 471 o Session-Identifier: uniquely identifies the signaling session, it 472 allows distinguishing messages belonging to different gossip 473 rounds. 475 o Metric value: this value has the following syntax: in the 476 Registration message the field replicates the value set in the 477 TTL field of the IP header by the IP Layer. In the RegResponse 478 message the value specifies the IP distance from the Source 479 Peer to the Destination Peer. The Destination Peer computes 480 this value after reading the Metric Value and the residual IP 481 TTL value in the Registration message. 483 o IP address type: the version number of the IP address of the 484 shared peer, IPv4 or IPv6. 486 o IP address: one of the IP addresses of the shared peer. 488 ---- ---- ---- 489 / \ / \ / \ 490 N1----/Legacy\----N2----/Legacy\----N3----/Legacy\------TR 491 | \ IP / | \ IP / | \ IP / | 492 | \ Net/ | \ Net/ | \ Net/ | 493 | ---- | ---- | ---- | 494 | | | | 495 | | REG1 | | 496 | | (TR,<->) | | 497 | |-----------------|--X--> | 498 | | |Intercepted | 499 | | |and | 500 | | RES1 |dropped | 501 | | (N2,)| | 502 | |<----------------| | 503 | | ACK1 | | 504 | |---------------->| | 505 | REG2 | | | 506 | (N6,)| | | 507 <-X-|-----------------| | | 508 | RES2 | | | 509 | (N2,)| | | 510 |---------------->| | | 511 | ACK2 | | | 512 |<----------------| | | 513 | | | | 514 | | REG3 | | 515 | | (N2,)| | 516 | |<----------------| | 517 | | RES3 | | 518 | | (N3,)| | 519 | |---------------->| | 520 | | ACK1 | | 521 | |<----------------| | 522 | | | | 523 v v v v 525 Figure 2 Gossip-based peer discovery sequence diagram 527 Registration = Message Type 528 Source Peer-Identity 529 Destination Peer-Identity 530 Source IP address 531 Session-Identifier 532 Metric value 533 *(Shared PId) 535 RegResponse = Message Type 536 Source Peer-Identity 537 Destination Peer-Identity 538 Source IP address 539 Session-Identifier 540 Metric value 541 *(Shared PId) 543 Ack = Message Type 544 Source Peer-Identity 545 Destination Peer-Identity 546 Session-Identifier 548 Shared PId = Peer-Identity 549 IP address type 550 IP address 552 Figure 3 Gossip-based peer discovery packet format. 554 4.2. Signaling distribution 556 The distribution function is jointly implemented in both ST and SA 557 layers, through suitable communication primitives, which confine 558 transport issues at the ST layer, and decision logic at the SA 559 layer. Figure 4, Figure 5, Figure 6, and Figure 7 show the finite 560 state machines (FSMs) of SA and ST entities, initiator and 561 forwarder, respectively. In these diagrams, transition edges are 562 labeled with the transition label. A detailed explanation of these 563 transitions, including the triggering event and the triggered 564 actions, is reported immediately below the relevant figure. 566 The SA behavior is modeled by using three states: IDLE, Wait 567 Notification, and Wait Responses. This state definition is flexible 568 enough to adapt to many different SA protocols, but it is also easy 569 enough to allow integrating with SF instances easily. 571 The ST FSM is slightly more complex, since it has to deal with lower 572 layer issues, including packet interception and peer selection. 574 The signaling distribution allows disseminating signaling over 575 network regions of nearly arbitrary shape. By leveraging the 576 interception capabilities of ST, this signaling dissemination 577 protocol is highly efficient, and may allow finding resources which 578 are close to a given network path. Since SF instances in data 579 centers could not be on the IP path connecting two communicating 580 entities (just routers are on path), only a signaling protocol with 581 off-path discovery capabilities can find reachable SF resources, 582 which helps limiting network traffic. 584 The off-path domain considered in this document is the so-called 585 hose domain, which includes the ST nodes staying within a maximum 586 distance (expressed in IP hops or in latency units) from at least 587 one of the nodes of the IP data path, which can be regarded as the 588 axis of the hose. This distance will be referred to as the radius of 589 the hose. If the sender and destination are the same node, then the 590 hose collapses into a spherical region around that node. To simplify 591 the description, in what follows the IP hop count is the selected 592 metric. 594 At the ST layer, the off-path signaling distribution adopts a 595 flooding algorithm, which makes use of two main sets of peers. The 596 peers laying on the IP path between the initiator and the signaling 597 destination (on-path peers), and the peers laying within a distance 598 of radius IP hops from the path (off-path peers). 600 The signaling exchange is always initiated by the SA protocol, 601 triggered by an external application (transition from IDLE to Wait 602 Notification in the SA FSM of the initiator in Figure 4). This 603 translates into a command received from the ST layer of the 604 initiator (transition from IDLE to ACTIVE in the ST FSM of the 605 initiator, Figure 6). The signaling initiator generates an initial 606 query message, by setting both the desired values of hose radius and 607 a dedicated on-path flag in the message header, and sends it to the 608 signaling destination. This flag marks the signaling messages 609 delivered through the axis of the hose. Queries, such as Gossip- 610 Registration in the gossip-based peer discovery, are intercepted by 611 the other ST nodes. This happens for on-path queries. Each node 612 receiving an on-path query must accept the peering request by a 613 response message and be ready to receive SA data from the upstream 614 node (transition from IDLE to On-path Forwarder in the ST FSM of the 615 forwarder, Figure 7). Upon receiving these data, they are sent to 616 the SA (loop on On-path Forwarder in Figure 7 and transition from 617 IDLE to Wait Notification in Figure 5). Then, the SA layer triggers 618 the ST layer to deliver the signaling message not only on-path, but 619 also to nodes at a metric value lower than the hose radius received 620 in the query, namely off-path ST nodes. The relevant pseudo-code of 621 the algorithm executed at the ST layer to implement the flooding 622 approach is shown in Figure 8. It uses the information stored in the 623 PeT, an example of which is shown in Figure 1. For each selected 624 peer, the ST node generates a new query and decrements the query 625 radius by the peer metric. In addition, the on-path flag is set to 626 0. The new queries are then sent to all the selected peers. Clearly, 627 the upstream ST node is not selected for off-path distribution. 629 At this time, the ST layer notifies the SA and performs a transition 630 towards the Active state (On-path or Off-path, Figure 7), waiting 631 for responses from the queried peers. In turn, the SA FSM moves into 632 the Wait Responses state (both Figure 4 and Figure 5), and creates a 633 stack data structure to store data responses, which are expected 634 during the signaling responses traveling back towards the initiator. 636 At the ST layer, when positive responses are received by queried 637 peers in Active states, data are delivered to them (loops on Active 638 states in Figure 7 and on ACTIVE in Figure 6). 640 4.2.1. Finite state machines for SA and ST 642 +---------------+ 643 +---------->| WAIT |-----+ 644 | T1 | NOTIFICATION | | T2 645 | +---------------+ | 646 | | 647 | | 648 | V 649 +------+ +-----------+ 650 | IDLE |<------------------------| WAIT | 651 +------+ T4 | RESPONSES| 652 +-----------+ 653 ^ | 654 | | 655 +-----+ 656 T3 658 Figure 4 SA initiator FSM 660 For each transition Ti in Figure 4, the transition list below 661 reports the condition that triggers that transition, and the 662 relevant actions carried out upon entering the new state. 664 Transition List for Figure 4: 666 o T1: a NFV application triggers a signaling session to the SA. 667 The SA sends the data to the ST and triggers the start of the 668 signaling session. 669 Condition: reception of trigger from a NFV instance. 670 Action: send command QueryFwd to ST, Send Data to ST. 672 o T2: the ST notifies the SA that all the expected queries have 673 been sent. 674 Condition: reception of notification QuerySent from ST. 675 Action: create RespStack data structure, Start WaitResp Timer. 677 o T3: 678 Condition: receive Data-Response from a downstream peer. 679 Action: increment the response counter 680 (Data-Response.depth++), and add the response to the stack 681 (RespStack.add(Data-Response)). 683 o T4: the ST notifies the SA that all the expected responses have 684 been received OR the maximum waiting time is expired. The 685 collected responses are sent to the NFV instance that 686 triggered the signaling session. 687 Condition: reception of notification RspRcv from ST OR 688 WaitResp timeout. 689 Action: send RespStack to the NFV instance. 691 +---------------+ 692 +---------->| WAIT |-----+ 693 | T1 | NOTIFICATION | | T2 694 | +---------------+ | 695 | | 696 | | 697 | V 698 +------+ +-----------+ 699 | IDLE |<------------------------| WAIT | 700 +------+ T4 | RESPONSES| 701 +-----------+ 702 ^ | 703 | | 704 +-----+ 705 T3 707 Figure 5 SA forwarder FSM 709 Transition List for Figure 5: 711 o T1: 712 Condition: reception of Data from ST from an upstream peer. 713 Action: send command QueryFwd to ST, Send Data to ST. 715 o T2: the ST notifies the SA that all the expected queries have 716 been sent. A stack to store the expected responses is created 717 and a timer is started 718 Condition: reception of notification QuerySent from ST. 719 Action: create RespStack data structure, start WaitResp Timer. 721 o T3: 722 Condition: reception of Data-Response from a downstream peer. 723 Action: increment the response counter 724 (Data-Response.depth++), and add the response to the stack 725 (RespStack.add(Data-Response)). 727 o T4: T4.1 OR T4.2 729 T4.1: the ST notifies the SA that all the expected responses have 730 been received OR the maximum waiting time is expired. 731 The local NFV instance is queried, and its response is 732 stored inside the stack. The depth of the response is set 733 to 0. The SA then sends the response stack to the ST to be 734 sent upstream. 735 Condition: reception of notification RspRcv from ST OR sdsd 736 WaitResp timeout. 737 Action: query NFV instance, NFV-Response.depth=0, 738 RespStack.add(NFV-Response),Cmd SendData-Resp(RespStack) to 739 ST. 741 T4.2: 742 Condition: reception of Abort from ST. 743 Action: delete RespStack. 745 +--------------------------------+ 746 | T1 | 747 | | 748 | | 749 | | 750 | V 751 +------+ +------------+ 752 | IDLE |<------------------------| WAIT | 753 +------+ T3 | RESPONSES | 754 +------------+ 755 ^ | 756 | | 757 +-----+ 758 T2 760 Figure 6 ST initiator FSM 762 Transition List for Figure 6: 764 o T1: 765 Condition: reception of command QueryFwd and Data from SA. 766 Action: Send n off-path Queries, send 1 on-path Query, notify 767 QuerySent to SA. 769 o T2: T2.1 OR T2.2 OR T2.3 OR T2.4 771 T2.1: 772 Condition: reception of Response from a downstream peer. 773 Action: Send Data to downstream peer. 775 T2.2: 776 Condition: reception of Query from a downstream peer. 777 Action: Send Error to downstream peer. 779 T2.3: 780 Condition: reception of Error from a downstream peer. 781 Action: Increment the error counter(ErrorCount++). 783 T2.4: 784 Condition: reception of Data-Response from a downstream peer. 785 Action: increment the response counter(RespCoun++), send Data- 786 Response to SA. 788 o T3: T3.1 OR T3.2 790 T3.1: all the expected responses have been collected. The ST 791 notifies the SA and clears the counters. 792 Condition: RespCount+ErrorCount=n+1. 793 Action: notify RespRcv to SA, clear counters. 795 T3.2: 796 Condition: reception of Abort from SA. 797 Action: clear all counters. 799 +-------------------------------------------+ 800 | T16 | 801 | T2 T4 | 802 | +--+ +--+ | 803 | | | | | | 804 | | v | v | 805 | +-----------+ T3 +----------+ 806 | +-->| Off-path |------------>| Off-path | 807 | T1| | Forwarder |<------------| Active | 808 | | +-----------+ T5 +----------+ 809 | | | | | 810 | | |T8 | | 811 | | | | +-----------------+ 812 v | v | | T7 813 +----------+ | | 814 | IDLE | T6| | 815 +----------+ | | 816 ^ | ^ | | 817 | | | | | 818 | T9| |T10 | | 819 | | | | | 820 | | | v v 821 | | +-----------+ T11 +----------+ 822 | +-->| On-path |------------>| Off-path | 823 | | Forwarder |<------------| Active | 824 | +-----------+ T12 +----------+ 825 | | ^ | ^ | 826 | | | | | | 827 | +---+ +---+ | 828 | T14 T13 | 829 | T15 | 830 +-------------------------------------------+ 832 Figure 7 ST forwarder FSM 834 Transition List for Figure 7: 836 o T1: 837 Condition: reception of off-path Query from an upstream peer. 838 Action: Send back Response, save the radius value in a local 839 variable (radius=Query.radius). 841 o T2: T2.1 OR T2.2 OR T2.3 843 T2.1: the node receives a query for the same session with a 844 radius greater than the stored radius. The ST must abort the 845 current status of the SA and accept the peering, storing the 846 new radius value. 847 Condition: Reception of off-path Query && Query.radius>radius. 848 Action: Send back Response. Send Abort to SA, save the new 849 radius value to a local variable(radius=Query.radius). 851 T2.2: the node receives a query for the same session with a 852 radius less or equal to the stored radius. The node sends back 853 an error. 854 Condition: reception of off-path Query && 855 Query.radius<=radius. 856 Action: Send Error. 858 T2.3 859 Condition: reception of Data from the upstream peer. 860 Action: Send Data to SA. 862 o T3: the ST receives the trigger from the SA to forward the 863 received Data. The node is an off-path node, hence it sends n 864 Queries to its n one-hop peers and notifies the SA. 865 Condition: Reception of command QueryFwd and Data from SA. 866 Action: Send n off-path Queries, notify QuerySent to SA. 868 T4: T4.1 OR T4.2 OR T4.3 OR T4.4 870 T4.1: the node receives a query for the same session with a 871 radius less or equal to the stored radius. The node sends back 872 an error. 873 Condition: reception of off-path Query && 874 Query.radius<=radius. 875 Action: Send Error. 877 T4.2: 878 Condition: reception of Data-Response from a downstream peer. 879 Action: increment the response counter(RespCount++), Send 880 Data-Response to SA. 882 T4.3: 883 Condition: reception of Error from a downstream peer. 884 Action: increment the error counter(ErrorCount++). 886 T4.4: the downstream peer accepted the peering with a Response 887 message. The node must forward it the Data. 888 Condition: Reception of Response from a downstream peer. 889 Action: Send Data to the downstream peer. 891 o T5: T5.1 OR T5.2 893 T5.1: all the expected responses have been collected. The ST 894 notifies the SA and clears the counters. 895 Condition: RespCount+ErrorCount==n. 896 Action: notify RespRcv to SA, Clear counters. 898 T5.2: the node receives a query for the same session with a 899 radius greater than the stored radius. The ST must abort the 900 current status of the SA and accept the peering with a 901 Response message, storing the new radius value. 902 Condition: reception of off-path Query && Query.radius>radius 903 Action: send back Response, send Abort to SA, store the new 904 radius value to a local variable(radius=Query.radius), clear 905 counters. 907 o T6: when an off-path node receives an on-path query, it must send 908 back a response and abort the current SA status. 909 Condition: reception of on-path Query from an upstream peer. 910 Action: send back Response, Send Abort to SA. 912 o T7: when an off-path node receives an on-path query, it must send 913 back a response and abort the current SA status. 914 Condition: reception of on-path Query from an upstream peer. 915 Action: send back Response, send Abort to SA. 917 o T8: 918 Condition: reception of command SendData-Resp from SA. 919 Action: send Data-Response to the upstream peer. 921 o T9: 922 Condition: reception of on-path Query from an upstream peer. 923 Action: send back Response. 925 o T10: 926 Condition: reception of command SendData-Resp from SA. 927 Action: send Data-Response to the upstream peer. 929 o T11: the ST receives the trigger from the SA to forward the 930 received Data. The node is an on-path node, hence it sends n 931 Queries to its n one-hop peers and 1 Query to the on-path peer 932 and notifies the SA. 933 Condition: reception of command QueryFwd and Data from SA. 934 Action: send n off-path Queries, send 1 on-path Query, notify 935 QuerySent to SA. 937 o T12: all the expected responses have been collected. The ST 938 notifies the SA and clears the counters. 939 Condition: RespCount+ErrorCount==n+1. 940 Action: notify RespRcv to SA, clear counters. 942 o T13: T13.1 OR T13.2 OR T13.3 OR T13.4 944 T13.1: when an on-path node receive an off-path query it must 945 reject the peering and send back an error. 946 Condition: reception of off-path Query from a peer. 947 Action1: send Error. 949 T13.2: 950 Condition: receive Data-Response from a downstream peer. 951 Action: increment the response counter(RespCount++), Send 952 Data-Response to SA. 954 T13.3 955 Condition: reception of Error from a downstream peer. 956 Action: increment the error counter(ErrorCount++). 958 T13.4 959 Condition: reception of Response from a downstream peer. 960 Action: send Data to the downstream peer. 962 o T14: T14.1 OR T14.2 964 T14.1: when an on-path node receive an off-path query it must 965 send back an error. 966 Condition: reception of off-path Query from a peer. 967 Action: send Error. 969 T14.2 970 Condition: reception of Data from the upstream peer. 971 Action: send Data to SA. 973 o T15: 974 Condition: reception of command SendData-Resp from SA. 975 Action: send Data-Response to the upstream peer. 977 o T16: 978 Condition: reception of command SendData-Resp from SA. 979 Action: send Data-Response to the upstream peer. 981 Algorithm: selectOffpathDestinations 982 Input: (peerTable, radius) 984 for peer in peerTable 985 if peer.metric exists 986 if radius>peer.metric 987 destination.peer=peer 988 destination.radius=radius-peer.metric 989 destinationList.append(destination) 990 endif 991 endif 992 endfor 994 Output: destinationList 996 Figure 8 peer selection algorithm for off-path distribution 998 4.2.2. ST messages 1000 The message used for signaling distribution at ST, in the ABNF 1001 format, are reported in the Figure 9 below. 1003 Query = Message Type 1004 Source Peer-Identity 1005 Destination Peer-Identity 1006 Source IP address 1007 Destination IP address 1008 Session-Identifier 1009 On-path flag 1010 Metric Type 1011 Radius 1012 SA-Identifier 1014 Response = Message Type 1015 Source Peer-Identity 1016 Destination Peer-Identity 1017 Source IP address 1018 Destination IP address 1019 Session-Identifier 1020 SA-Identifier 1022 Error = Message Type 1023 Source Peer-Identity 1024 Destination Peer-Identity 1025 Session-Identifier 1026 Source IP address 1027 Destination IP address 1028 Error code 1030 Data = Message Type 1031 Source Peer-Identity 1032 Destination Peer-Identity 1033 Source IP address 1034 Destination IP address 1035 Session-Identifier 1036 SA-Identifier 1037 SA-Payload 1039 Data-Response = Message Type 1040 Source Peer-Identity 1041 Destination Peer-Identity 1042 Source IP address 1043 Destination IP address 1044 Session-Identifier 1045 SA-Identifier 1046 SA-Payload 1048 Figure 9 ST layer packet format. 1050 The fields used in ST distribution messages are: 1052 o On-path flag: this flag has the following meaning: the value 1 1053 indicates that the peering request must be accepted in any 1054 case, it must be acknowledged with a Response and any other 1055 signaling session for the same id must be aborted. The value 0 1056 indicates that the peering request can be accepted or rejected 1057 according to the ST layer status (see Figure 6 and Figure 7). 1059 o Metric Type: specifies the type of the metric used to define the 1060 off-path radius (IP hop, latency, other to be defined). 1062 o Radius: specifies the radius of the off-path distribution. 1064 o Error code: specifies the type of the error. 1066 o SA-Identifier: uniquely identifies a SA with the following 1067 syntax: the first n bits identify the SF type (i.e., cache, 1068 firewall, proxy, etc...), the second m bits identify the SF 1069 platform. 1071 o SA-Payload: the opaque SA message transported by the ST. 1073 4.2.3. Error management and termination procedures 1075 When a node receives an off-path query, it reads the radius value. 1076 If this value is greater than 1, it iterates the same procedure 1077 illustrated above in order to select the set of signaling 1078 destinations to be included in the distribution set. The relevant 1079 transition in the ST state machine is from IDLE to Off-path 1080 Forwarder, as shown in Figure 7. In order to avoid the packet 1081 duplication problem, typical of flooding algorithms when the network 1082 topology includes cycles, an ST error message was introduced to 1083 limit overhead. In more detail, when a forwarder receives a 1084 signaling message, it creates an internal soft state for the 1085 signaling session storing: the identifier of the served SA protocol, 1086 the session identifier, the upstream PID, and the radius of the 1087 latest processed query. Then, if it receives a further ST off-path 1088 query from another peer, with the same set of values and a hose 1089 radius lower than the stored one, it replies by sending an error 1090 message, rejecting the peering request (error loops on all states 1091 except IDLE in Figure 6 and Figure 7), and the ErrorCount variable, 1092 set to 0 at session state creation, is incremented. Instead, if the 1093 hose radius is higher than the stored one, the previous session is 1094 aborted, the SA is notified (transition to IDLE in Figure 7), and a 1095 new session is created at ST (transition to Off-path Forwarder in 1096 Figure 7). 1098 Similarly, when an off-path node receives an on-path query, it must 1099 abort the previous session and establishes a new one, now acting as 1100 an on-path node. In this case, the SA is also notified and the 1101 relevant states are deleted. The relevant transitions on Figure 7 1102 are those from off-path states to On-path Forwarder. 1104 When the ST layer realizes that it cannot further forward the query, 1105 according to the algorithm in Figure 8, it starts transmitting the 1106 data responses back to the initiator, by notifying the relevant SA 1107 layer with empty data, and moves back into the Off-path Forwarder 1108 state (Figure 7). The SA layer queries the local SF instance and 1109 adds its response to the stack with depth equal to 0, and triggers 1110 the underlying ST to transmit upstream the data response. Session 1111 state at SA is cleared, and the FSM returns into the IDLE state. 1112 When the ST receives this command from the above SA, it sends 1113 upstream the data response, clears all state information, and 1114 returns into IDLE. 1116 4.2.4. Forwarder management procedures 1118 The management of an intermediate forwarder is slightly more 1119 complex. When an ST peer receives a data response, it increments the 1120 local counter RespCounter, set to 0 at session state creation, and 1121 passes data response to the SA layer through the relevant APIs 1122 (loops on Active states in Figure 6 and Figure 7), by adding also 1123 the metric value towards the peer that has sent such a response, 1124 retrievable from the PeT. The SA, in turn, adds this data response 1125 to the stack prepared upon entering the Wait Response state, and 1126 increases its depth value (loops on Wait Responses state in Figure 4 1127 and Figure 5). When all waited responses have been received by the 1128 ST layer, which means that the number of responses and error message 1129 is equal to the number of sent queries, the ST comes back into the 1130 Forwarder state (Figure 7), by notifying the SA. The SA queries the 1131 local NFV instance, adds the relevant data to the stack with dept 1132 equal to 0, and triggers the ST to send all the data response stack 1133 upstream. Then, it clears all state variables and moves back into 1134 IDLE. In turn, the ST sends these data upstream, clears all state 1135 information, and moves back into IDLE. A similar behavior is 1136 followed when, at the SA layer, the WaitResp timer, started upon 1137 entering the Wait Responses state, expires. In this case, it 1138 triggers the delivery of received response data upstream, without 1139 waiting for the notification from the ST. In Figure 7, this 1140 corresponds to edges from Active states to IDLE. 1142 When either the desired responses are received or the wait time 1143 expires, the SA initiator moves again into the IDLE state, by 1144 sending the collected responses to the SF instance. 1146 Additional timers for managing situations in which either the SA, or 1147 the ST layer, crashes or freezes, can been added optionally. 1148 However, they are implementation dependent details, and thus out of 1149 the scope of this document. 1151 4.2.5. SA messages 1153 In order to manage the SF states and discovery, three SA messages 1154 have been introduced, referred to as data in FSMs, illustrated in 1155 the ABNF format in Figure 10 below. The SETUP and REMOVE messages 1156 enable the SA instance to add or delete states, respectively, within 1157 the SF application. These messages can be acknowledged with a simple 1158 response code (e.g. 200 OK or Error code) by the SA forwarder, 1159 indicated as data response in FSMs. However, it is also possible to 1160 enable the overall FSM functioning without data response, by simply 1161 setting WaitResp=0 at the SA layer. The PROBE message is more 1162 interesting, since it allows collecting information on the status of 1163 a SF application and the relative position of the hosting nodes, 1164 represented as an overlay tree. In this case, the data on the NFV 1165 status are transported within data responses. 1167 Setup = Message Type 1168 Service Type 1169 [SF Payload] 1171 Remove = Message Type 1172 Service Type 1173 [SF Payload] 1175 Probe = Message Type 1176 Service Type 1177 [SF Payload] 1179 Response = Message Type 1180 Response code 1181 *(SF Status Element) 1183 SF Status Element = Node-Identifier 1184 Status code 1185 Depth 1187 Figure 10 SA layer packet format 1189 The fields used in SA messages are: 1191 o Message Type: identifies the type of the message. 1193 o Service type: this flag has the following meaning: the value 0 1194 indicates that the signaling session does not require a Response 1195 message, the value 1 indicates that the signaling session must be 1196 acknowledged with a Response message. 1198 o Response code: identifies the response code of the NFV 1199 application. 1201 o SF Payload: optional SF opaque data 1202 o Node-Identifier: this field identifies the node hosting the SF. 1203 It can be set with the main IP address of the node or with a 1204 unique identifier. 1206 o Status code: a code representing the status of the SF. 1208 o Depth: this field is interpreted as an integer value and has the 1209 following meaning. Each SA sets the depth field of its own 1210 status element to 0. The SF Status Elements are added 1211 recursively to a stack by each forwarder, as the responses 1212 were collected and sent upstream. As indicated in Figure 5, 1213 each SA forwarder increments by one the depth value of the 1214 Status Elements received by the downstream peer, and adds its 1215 own Status element to the stack only when all the expected 1216 responses have been collected (i.e., on the top of the stack). 1217 This syntax allows the initiator to parse the stack of the 1218 Status Element with the relevant depth field and to build a 1219 tree of the off-path domain with the following logic: the 1220 first element of the stack represents the root, with depth 0. 1221 For each element E in the stack with depth i, its father 1222 node is the first element of depth i-1, found parsing the list 1223 backward from E toward the root. Its children set is composed 1224 by each element C with depth i+1, found parsing the list from 1225 E toward the end until a node with depth k<=i is found. 1227 5. Transport Layer Considerations 1229 Messages of OSP can be transported by any layer 4 protocol. This 1230 section illustrates sensitivity to packet losses and overhead in 1231 case UDP or TCP is used. 1233 5.1. Peer discovery 1235 Peer discovery is a process based on gossiping between peers. Since 1236 it consists of three messages (Registration, RegResponse, and Ack, 1237 see Figure 3), the most reasonable choice is to use UDP, due to the 1238 high overhead in establishing a TCP session for exchanging just 1239 three small application layer messages. The gossip mechanism, which 1240 adopts a soft state based on timers, is intrinsically robust to 1241 packet losses. 1243 Peer discovery could also allow distributing some information about 1244 the service status of close peers. This can be easily implemented by 1245 adding a payload "Status info" in addition to the Shared PId field 1246 into Registration and RegResponse messages, whose format is 1247 illustrated in Figure 3. This could highly simplify the task of the 1248 SA in providing fresh service info to specific applications 1249 interested only to "close" peers. 1251 5.2. Signaling distribution 1253 The signaling distribution is a more complex process, and can use 1254 both pure UDP and mixed UDP/TCP. In any case, the OSP protocol uses 1255 timer-based soft states also in the signaling distribution. This 1256 means that that a session will not be locked by a packet loss, but, 1257 at most, some part of the overlay distribution tree will not be 1258 covered. 1260 If UDP is used, it could happen that one of the messages listed in 1261 Figure 9 is lost. However, this does not necessarily means that a 1262 portion of the network is not be reached by signaling messages. In 1263 fact, due to the flooding-based operation of the OSP protocol, most 1264 of the potential losses can be compensated by additional Queries, 1265 arriving from a different path. If the Response is lost, the queried 1266 node could send an Error message upon receiving a new Query, based 1267 on the comparison between the stored "radius" value and the 1268 "Query.radius" one (see transition T2.2 in Figure 7). Finally, if 1269 Data or Data-Response messages are lost, the initiator does not 1270 distribute to and/or get info from a portion of the overlay 1271 distribution tree. 1273 Also the TCP protocol can be used to transport signaling 1274 distribution messages. However, due to the flooding-based operation 1275 of the signaling distribution, there would likely be a significant 1276 number of Query + Error exchanges. Since the overhead to set up and 1277 tear down a TCP session just to exchange a Query + Error messages 1278 could be excessive, it seems more reasonable to set up the TCP 1279 session only between those peers that have established a "peering 1280 agreement" (Query followed by a Response, both transported over 1281 UDP). In this case, TCP guarantees the reliable delivery of larger 1282 Data and Data-Response messages, and the number of TCP session would 1283 be much lower, thus with a significantly lower overhead. In 1284 addition, as in the UDP case, the flooding-based operation 1285 guarantees the coverage of most of peers through multiple paths, 1286 thus limiting the impact of packet losses on Query messages. 1288 6. Security Considerations 1290 Messages of OSP can be transported by any layer 4 protocol, 1291 including UDP and TCP. In case security is desired, TLS/SSL over TCP 1292 can be used. 1294 SFC and OSP must provide mechanisms for: 1296 o Rate control methods should be deployed to avoid DDOS attack with 1297 Gossip or Query messages. 1299 o Avoiding leakage of SFC information beyond its administrative 1300 domain. 1302 7. IANA Considerations 1304 No action is required by IANA for this document. 1306 8. Conclusions 1308 This document illustrates a new signaling protocol, called OSP, for 1309 discovering network resources and made them available to the SF 1310 framework. The original feature of this protocol is its off-path 1311 scope, which is enabled through gossip-based discovery and flooding- 1312 based distribution. 1314 Signaling distribution leverages on the protocol packet capture 1315 capability by means of software defined networking techniques. 1317 9. References 1319 9.1. Normative References 1321 [1] Bradner, S., "Key words for use in RFCs to Indicate 1322 Requirement Levels", BCP 14, IETF RFC 2119, March 1997. 1324 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 1325 Syntax Specifications: ABNF", IETF RFC 2234, Internet Mail 1326 Consortium and Demon Internet Ltd., November 1997. 1328 9.2. Informative References 1330 [3] Quinn, P. and T. Nadeau, "Service Function Chaining Problem 1331 Statement", IETF Interned draft, draft-ietf-sfc-problem- 1332 statement-13 (work in progress), February 2015. 1334 [4] J. Martins et al., "ClickOS and the Art of Network Function 1335 Virtualization", NSDI '14, April 2-4, 2014 Seattle, WA, USA 1337 [5] J. Sherry et al., "Making middleboxes someone else's problem: 1338 Network processing as a cloud service", ACM SIGCOMM, 2012. 1340 [6] "Network Functions Virtualisation (NFV) Network Operator 1341 Perspectives on Industry Progress", ETSI, October 2013, 1342 http://portal.etsi.org/NFV/NFV_White_Paper2.pdf. 1344 [7] S. Shanbhag and T. Wolf, "Automated Composition of Data-Path 1345 Functionality in the Future Internet", IEEE Network, 2011, 25 1346 (6), pp. 8-14. 1348 [8] S. Guha, P. Francis, "An end-middle-end approach to connection 1349 establishment," ACM SIGCOMM Comput. Commun. Rev., 37(4), pp. 1350 193-204, Aug. 2007. 1352 [9] Q. Duan, Y. Yan, A.V. Vasilakos, "A Survey on Service-Oriented 1353 Network Virtualization Toward Convergence of Networking and 1354 Cloud Computing", IEEE Transactions on Network and Service 1355 Management, 9(4), 2012. 1357 [10] C. Dovrolis, S. Akhshabi, "The Evolution of Layered Protocol 1358 Stacks Leads to an Hourglass-Shaped Architecture", ACM 1359 SIGCOMM'11, August 2011, Canada. 1361 [11] M. Femminella et al., "An enabling platform for autonomic 1362 management of the future internet", IEEE Network, 2011, 25 1363 (6), pp. 24-32. 1365 [12] M. Femminella et al, "Gossip-based signaling dissemination 1366 extension for next steps in signaling". IEEE/IFIP NOMS 2012, 1367 April 2012, USA. 1369 [13] J. Hwang, K.K. Ramakrishnan, T. Wood, "NetVM: High Performance 1370 and Flexible Networking Using Virtualization on Commodity 1371 Platforms", NSDI '14, Apil 2014, USA 1373 [14] X. Ge et al., "OpenANFV: Accelerating Network Function 1374 Virtualization with a Consolidated Framework in OpenStack", 1375 ACM SIGCOMM'14, August 2014, USA. 1377 [15] A. Gember-Jacobson et al., "OpenNF: Enabling Innovation in 1378 Network Function Control", ACM SIGCOMM'14, August 2014, USA. 1380 [16] P. Quinn et al., "Network Service Header", IETF Interned 1381 draft, work in progress, draft-quinn-sfc-nsh-07.txt, (work in 1382 progress), February 2015. 1384 [17] Y. Zhang, "StEERING: A Software-Defined Networking for Inline 1385 Service Chaining", IEEE ICNP'13, October 2013, Germany. 1387 [18] M. Jelasity, A. Montresor, O. Babaoglu, "T-man: Gossip-based 1388 fast overlay topology construction," Computer Networks, 1389 53(13), 2009, pp. 2321-2339. 1391 [19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1392 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1393 Session Initiation Protocol", IETF RFC 3261, June 2002. 1395 [20] C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. 1396 Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base 1397 Protocol", IETF RFC 6940, January 2014. 1399 [21] P. Saint-Andre, "Extensible Messaging and Presence Protocol 1400 (XMPP): Core", IETF RFC 6120, March 2011. 1402 [22] R. Hancock, G. Karagiannis, J. Loughney and S. Van den Bosch, 1403 "Next Steps in Signaling (NSIS): Framework", IETF RFC 4080, 1404 June 2005. 1406 [23] H. Schulzrinne, R. Hancock, "GIST: General Internet Signalling 1407 Transport", IETF RFC 5971, October 2010. 1409 10. Acknowledgments 1411 This work has been partially supported by EU under the project ARES, 1412 funded by GEANT/GN3plus in the framework of the first GEANT open 1413 call. 1415 This document was prepared using 2-Word-v2.0.template.dot. 1417 Authors' Addresses 1419 Mauro Femminella 1420 Engineering Department, University of Perugia 1421 Via G. Duranti 93, 06125 Perugia, Italy 1423 Phone: +39 075 585 3630 1424 Email: mauro.femminella@unipg.it 1426 Gianluca Reali 1427 Engineering Department, University of Perugia 1428 Via G. Duranti 93, 06125 Perugia, Italy 1430 Phone: +39 075 585 3651 1431 Email: gianluca.reali@unipg.it 1433 Dario Valocchi 1434 Department of Electronic and Electrical Engineering, Faculty of 1435 Engineering Science, University College London 1436 WC1E 6BT London, UK 1438 Email: dario.valocchi@gmail.com