idnits 2.17.1 draft-trossen-sfc-name-based-sff-02.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 301: '...Execution Points MUST be abstracted so...' RFC 2119 keyword, line 304: '...on Points from the abstract SFP SHOULD...' RFC 2119 keyword, line 307: '...vice Execution Points SHOULD not use a...' RFC 2119 keyword, line 328: '...tifier, the nSFF MAY operate as descri...' RFC 2119 keyword, line 794: '... and/or NR SHOULD be implemented via...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Identification of the Service Execution Points SHOULD not use a combination of Layer 2 or Layer 3 mechanisms. -- The document date (December 11, 2018) is 1961 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Trossen 3 Internet-Draft D. Purkayastha 4 Intended status: Informational A. Rahman 5 Expires: June 14, 2019 InterDigital Communications, LLC 6 December 11, 2018 8 Name-Based Service Function Forwarder (nSFF) component within SFC 9 framework 10 draft-trossen-sfc-name-based-sff-02 12 Abstract 14 Many stringent requirements are imposed on today's network, such as 15 low latency, high availability and reliability in order to support 16 several use cases such as IoT, Gaming, Content distribution, Robotics 17 etc. Adoption of cloud and fog technology at the edge of the network 18 allows operator to deploy a single "Service Function" to multiple 19 "Execution locations". The decision to steer traffic to a specific 20 location may change frequently based on load, proximity etc. Under 21 the current SFC framework, steering traffic dynamically to the 22 different execution end points require a specific 're-chaining', 23 i.e., a change in the service function path reflecting the different 24 IP endpoints to be used for the new execution points. In order to 25 address this, we discuss separating the logical Service Function Path 26 from the specific execution end points. This can be done by 27 identifying the Service Functions using a name rather than a routable 28 IP endpoint (or Layer 2 address). This draft describes the necessary 29 extensions, additional functions and protocol details in SFF (Service 30 Function Forwarder) to handle name based relationships. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on June 14, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Example use case: 5G control plane services . . . . . . . . . 4 68 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Relevant part of SFC architecture . . . . . . . . . . . . 6 70 3.2. Challenges with current framework . . . . . . . . . . . . 6 71 4. Name based operation in SFF . . . . . . . . . . . . . . . . . 7 72 4.1. General Idea . . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. Name-Based Service Function Path (nSFP) . . . . . . . . . 8 74 4.3. Name Based Network Locator Map (nNLM) . . . . . . . . . . 9 75 4.4. Name-based Service Function Forwarder (nSFF) . . . . . . 11 76 4.5. High Level Architecture . . . . . . . . . . . . . . . . . 12 77 4.6. Operational Steps . . . . . . . . . . . . . . . . . . . . 13 78 5. nSFF Forwarding Operations . . . . . . . . . . . . . . . . . 15 79 5.1. nSFF Protocol Layers . . . . . . . . . . . . . . . . . . 15 80 5.2. nSFF Operations . . . . . . . . . . . . . . . . . . . . . 17 81 5.2.1. Forwarding between nSFFs and nSFF-NR . . . . . . . . 17 82 5.2.2. SF Registration . . . . . . . . . . . . . . . . . . . 18 83 5.2.3. Local SF Forwarding . . . . . . . . . . . . . . . . . 19 84 5.2.4. Remote SF Forwarding . . . . . . . . . . . . . . . . 20 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 87 8. Informative References . . . . . . . . . . . . . . . . . . . 23 88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 The requirements on today's networks are very diverse, enabling 94 multiple use cases such as IoT, Content Distribution, Gaming and 95 Network functions such as Cloud RAN and 5G control planes based on a 96 service-based architecture . These network services are deployed, 97 provisioned and managed using Cloud based techniques as seen in the 98 IT world. Virtualization of compute and storage resources is at the 99 heart of providing (often web) services to end users with the ability 100 to quickly provisioning such virtualized service endpoints through, 101 e.g., container based techniques. This creates a dynamicity with the 102 capability to dynamically compose new services from available 103 services as well as move a service instance in response to user 104 mobility or resource availability where desirable. When moving from 105 a pure 'distant cloud' model to one of localized micro data centers 106 with regional, metro or even street level, often called 'edge' data 107 centers, such virtualized service instances can be instantiated in 108 topologically different locations with the overall 'distant' data 109 center now being transformed into a network of distributed ones. 111 The Service Function Chaining (SFC) framework [RFC7665] allows 112 network operators as well as service providers to compose new 113 services by chaining individual "Service Functions (SFs)". Such 114 chains are expressed through explicit relationships of functional 115 components (the service functions), realized through their direct 116 Layer 2 (e.g., MAC address) or Layer 3 (e.g., IP address) 117 relationship as defined through next hop information that is being 118 defined by the network operator, see Section 3 for more background on 119 SFC. 121 In a dynamic service environment of distributed data centers as the 122 one outlined above, with the ability to create and recreate service 123 endpoints frequently, the SFC framework requires to reconfigure the 124 existing chain through information based on the new relationships, 125 causing overhead in a number of components, specifically the 126 orchestrator that initiates the initial service function chain and 127 any possible reconfiguration. 129 This document describes how such changes can be handled without 130 involving the initiation of new and reconfigured SFCs by lifting the 131 chaining relationship from Layer 2 and 3 information to that of 132 service function 'names', such as names for instance being expressed 133 as URIs. In order to transparently support such named relationships, 134 we propose to embed the necessary functionality directly into the 135 Service Function Forwarder (SFF, see [RFC7665]). With that, the SFF 136 described in this document allows for keeping an existing SFC intact, 137 as described by its service function path (SFP), while enabling the 138 selection of an appropriate service function endpoint(s) during the 139 traversal of packets through the SFC. 141 2. Example use case: 5G control plane services 143 We exemplify the need for chaining service functions at the level of 144 a service name through a use case stemming from the current 3GPP Rel 145 16 work on Service Based Architecture (SBA) [_3GPP_SBA], 146 [_3GPP_SBA_ENHANCEMENT]. In this work, mobile network control planes 147 are proposed to be realized by replacing the traditional network 148 function interfaces with a fully service-based one. HTTP was chosen 149 as the application layer protocol for exchanging suitable service 150 requests [_3GPP_SBA]. With this in mind, the exchange between, say 151 the 3GPP (Rel. 15) defined Session Management Function (SMF) and the 152 Access and Mobility management Function (AMF) in a 5G control plane 153 is being described as a set of web service like requests which are in 154 turn embedded into HTTP requests. Hence, interactions in a 5G 155 control plane can be modelled based on service function chains where 156 the relationship is between the specific (IP-based) service function 157 endpoints that implement the necessary service endpoints in the SMF 158 and AMF. The service functions are exposed through URIs with work 159 ongoing to define the used naming conventions for such URIs. 161 This move from a network function model (in pre-Rel 15 systems of 162 3GPP) to a service-based model is motivated through the proliferation 163 of data center operations for mobile network control plane services. 164 In other words, typical IT-based methods to service provisioning, in 165 particular that of virtualization of entire compute resources, are 166 envisioned to being used in future operations of mobile networks. 167 Hence, operators of such future mobile networks desire to virtualize 168 service function endpoints and direct (control plane) traffic to the 169 most appropriate current service instance in the most appropriate 170 (local) data centre, such data centre envisioned as being 171 interconnected through a software-defined wide area network (SD-WAN). 172 'Appropriate' here can be defined by topological or geographical 173 proximity of the service initiator to the service function endpoint. 174 Alternatively, network or service instance compute load can be used 175 to direct a request to a more appropriate (in this case less loaded) 176 instance to reduce possible latency of the overall request. Such 177 data center centric operation is extended with the trend towards 178 regionalization of load through a 'regional office' approach, where 179 micro data centers provide virtualizable resources that can be used 180 in the service execution, creating a larger degree of freedom when 181 choosing the 'most appropriate' service endpoint for a particular 182 incoming service request. 184 While the move to a service-based model aligns well with the 185 framework of SFC, choosing the most appropriate service instance at 186 runtime requires so-called 're-chaining' of the SFC since the 187 relationships in said SFC are defined through Layer 2 or 3 188 identifiers, which in turn are likely to be different if the chosen 189 service instances reside in different parts of the network (e.g., in 190 a regional data center). 192 Hence, when a traffic flow is forwarded over a service chain 193 expressed as an SFC-compliant Service Function Path (SFP), packets in 194 the traffic flow are processed by the various service function 195 instances, with each service function instance applying a service 196 function prior to forwarding the packets to the next network node. 197 It is a Service layer concept and can possibly work over any Virtual 198 network layer and an Underlay network, possibly IP or any Layer 2 199 technology. At the service layer, Service Functions are identified 200 using a path identifier and an index. Eventually this index is 201 translated to an IP address (or MAC address) of the host where the 202 service function is running. Because of this, any change of service 203 function instance is likely to require a change of the path 204 information since either IP address (in the case of changing the 205 execution from one data centre to another) or MAC address will change 206 due to the newly selected service function instance. 208 Returning to our 5G Control plane example, a user's connection 209 request to access an application server in the internet may start 210 with signaling in the Control Plane to setup user plane bearers. The 211 connection request may flow through service functions over a service 212 chain in the Control plane, as deployed by network operator. Typical 213 SFs in a 5G control plane may include "RAN termination / processing", 214 "Slice Selection Function", "AMF" and "SMF". The Classifier, as 215 described in SFC architecture, may reside in the user terminal or at 216 the eNB. These service functions can be configured to be part of a 217 Service Function Chain. We can also say that some of the 218 configurations of the Service Function Path may change at the 219 execution time. E.g. SMF may be relocated as user moves and a new 220 SMF may be included in the Service Function Path based on user 221 location. The following diagram in Figure 1 shows the example 222 Service Function Chain described here. 224 +------+ +---------+ +-----+ +-----+ 225 | User | | Slice | | | | | 226 | App |-->| Control |->| AMF |-->| SMF |--> 227 | Fn | | Function| | | | | 228 +------+ +---------+ +-----+ +-----+ 230 Figure 1: Mapping SFC onto Service Function Execution Points along a 231 Service Function Path 233 3. Background 235 [RFC7665] describes an architecture for the specification, creation, 236 and ongoing maintenance of Service Function Chains (SFCs). It 237 includes architectural concepts, principles, and components used in 238 the construction of composite services through deployment of SFCs. 239 In the following, we outline the parts of this SFC architecture 240 relevant for our proposed extension, followed by the challenges with 241 this current framework in the light of our example use case. 243 3.1. Relevant part of SFC architecture 245 SFC Architecture [RFC7665], describes architectural components such 246 as Service Function (SF), Classifier, and Service Function Forwarder 247 (SFF). It describes the Service Function Path (SFP) as the logical 248 path of an SFC. Forwarding traffic along such SFP is the 249 responsibility of the SFF. For this, the SFFs in a network maintain 250 the requisite SFP forwarding information. Such SFP forwarding 251 information is associated with a service path identifier (SPI) that 252 is used to uniquely identify an SFP. The service forwarding state is 253 represented by the Service Index (SI) and enables an SFF to identify 254 which SFs of a given SFP should be applied, and in what order. The 255 SFF also has information that allows it to forward packets to the 256 next SFF after applying local service functions. 258 The operational steps to forward traffic are then as follows: Traffic 259 arrives at an SFF from the network. The SFF determines the 260 appropriate SF the traffic should be forwarded to via information 261 contained in the SFC encapsulation. After SF processing, the traffic 262 is returned to the SFF, and, if needed, is forwarded to another SF 263 associated with that SFF. If there is another non-local hop (i.e., 264 to an SF with a different SFF) in the SFP, the SFF further 265 encapsulates the traffic in the appropriate network transport 266 protocol and delivers it to the network for delivery to the next SFF 267 along the path. Related to this forwarding responsibility, an SFF 268 should be able to interact with metadata. 270 3.2. Challenges with current framework 272 As outlined in previous section, the Service Function Path defines an 273 ordered sequence of specific Service Functions instances being used 274 for the interaction between initiator and service functions along the 275 SFP. These service functions are addressed by IP (or any L2/MAC) 276 addresses and defined as next hop information in the network locator 277 maps of traversing SFF nodes. 279 As outlined in our use case, however, the service provider may want 280 to provision SFC nodes based on dynamically spun up service function 281 instances so that these (now virtualized) service functions can be 282 reached in the SFC domain using the SFC underlay layer. 284 Following the original model of SFC, any change in a specific 285 execution point for a specific Service Function along the SFP will 286 require a change of the SFP information (since the new service 287 function execution point likely carries different IP or L2 address 288 information) and possibly even the Next Hop information in SFFs along 289 the SFP. In case the availability of new service function instances 290 is rather dynamic (e.g., through the use of container-based 291 virtualization techniques), the current model and realization of SFC 292 could lead to reducing the flexibility of service providers and 293 increasing the management complexity incurred by the frequent changes 294 of (service) forwarding information in the respective SFF nodes. 295 This is because any change of the SFP (and possibly next hop info) 296 will need to go through suitable management cycles. 298 To address these challenges through a suitable solution, we identify 299 the following requirements: 301 o Relations between Service Execution Points MUST be abstracted so 302 that, from an SFP point of view, the Logical Path never changes. 304 o Deriving the Service Execution Points from the abstract SFP SHOULD 305 be fast and incur minimum delay. 307 o Identification of the Service Execution Points SHOULD not use a 308 combination of Layer 2 or Layer 3 mechanisms. 310 The next section outlines a solution to address the issue, allowing 311 for keeping SFC information (represented in its SFP) intact while 312 addressing the desired flexibility of the service provider. 314 4. Name based operation in SFF 316 4.1. General Idea 318 The general idea is two-pronged. Firstly, we elevate the definition 319 of a Service Function Path onto the level of 'name-based 320 interactions' rather than limiting SFPs to Layer 3 or Layer 2 321 information only. Secondly, we extend the operations of the SFF to 322 allow for forwarding decisions that take into account such name-based 323 interaction while remaining backward compatible to the current SFC 324 architecture [RFC7665]. In the following sections, we outline these 325 two components of our solution. 327 If the next hop information in the Network Locator Map is described 328 using L2/L3 identifier, the nSFF MAY operate as described in 330 [RFC7665]. On the other hand, if the next hop information in the NLM 331 is described as a name, then the nSFF operates as described in the 332 following sections. 334 In the following sections, we outline the two components of our 335 solution. 337 4.2. Name-Based Service Function Path (nSFP) 339 In the existing SFC framework [RFC7665], as outlined in Section 3, 340 the SFP information is representing path information based on Layer 2 341 or 3 information, i.e., MAC or IP addresses , causing the 342 aforementioned frequent adaptations in cases of execution point 343 changes. Instead, we introduce the notion of a 'name-based service 344 function path (nSFP)' 346 In today's networking terms, any identifier can be treated as a name 347 but we will illustrate the realization of a "Name based SFP" through 348 extended SFF operations (see Section 5) based on URIs as names and 349 HTTP as the protocol of exchanging information . Here, URIs are being 350 used to name for a Service Function along the nSFP. It is to be 351 noted that the Name based SFP approach is not restricted to HTTP (as 352 the protocol) and URIs (as next hop identifier within the SFP). 353 Other identifiers such as an IP address itself can also be used and 354 are interpreted as a 'name' in the nSFP . With this, our notion of 355 the nSFP goes beyond the initial proposals made in 356 [I-D.purkayastha-sfc-service-indirection], which limited the notion 357 of a 'name' to a URL (uniform resource locator), commonly used in the 358 addressing of HTTP requests. In other words, IP addresses as well as 359 fully qualified domain names forming complex URIs (uniform resource 360 identifiers), such as www.foo.com/service_name1, are all captured by 361 the notion of 'name' in this draft. 363 Generally, nSFPs are defined as an ordered sequence of the "name" of 364 Service Functions (SF) and a typical name-based Service Function Path 365 may look like: 192.168.x.x -> www.foo.com -> www.foo2.com/service1 -> 366 www.foo2.com/service2 368 Our use case in Section 2 can then be represented as an ordered named 369 sequence. An example for a session initiation that involves an 370 authentication procedure, this could look like 192.168.x.x -> 371 smf.3gpp.org/session_initiate -> amf.3gpp.org/auth -> smf.3gpp.org/ 372 session_complete -> 192.168.x.x [Note that this example is only a 373 conceptual one, since the exact nature of any future SBA-based 374 exchange of 5G control plane functions is yet to be defined by 375 standardization bodies such as 3GPP] 376 In accordance with our use case in Section 2, any of these named 377 services can potentially be realized through more than one replicated 378 SF instances. This leads to make dynamic decision on where to send 379 packets along the SAME service function path information, being 380 provided during the execution of the SFC. Through elevating the SFP 381 onto the notion of name-based interactions, the SFP will remain the 382 same even if those specific execution points change for a specific 383 service interaction. 385 The following diagram in Figure 2, describes this name-based SFP 386 concept and the resulting mapping of those named interactions onto 387 (possibly) replicated instances. 389 +---------------------------------------------------------------+ 390 |SERVICE LAYER | 391 | 192.168.x.x --> www.foo.com --> www.foo2.com --> www.fooN.com | 392 | || || | 393 +----------------------||--------------||-----------------------+ 394 || || 395 || || 396 +----------------------||--------------||-----------------------+ 397 | Underlay network \/ \/ | 398 | +--+ +--+ +--+ +--+ +--+ +--+ | 399 | | | | | | | | | | | | | | 400 | +--+ +--+ +--+ +--+ +--+ +--+ | 401 | Compute and Compute and | 402 | storage nodes storage nodes | 403 +---------------------------------------------------------------+ 405 Figure 2: Mapping SFC onto Service Function Execution Points along a 406 Service Function Path based on Virtualized Service Function Instance 408 4.3. Name Based Network Locator Map (nNLM) 410 In order to forward a packet within a name-based SFP, we need to 411 extend the network locator map as originally defined in [RFC8300] 412 with the ability to consider name relations based on URIs as well as 413 high-level transport protocols such as HTTP for means of SFC packet 414 forwarding. Another example for SFC packet forwarding could be that 415 of CoAP. 417 The extended Network Locator Map or name-based Network Locator Map 418 (nNLM) is shown in Figure 3 as an example for www.foo.com being part 419 of the nSFP. Such extended nNLM is stored at each SFF throughout the 420 SFC domain with suitable information populated to the nNLM during the 421 configuration phase 422 +------+------+---------------------+-------------------------+ 423 | SPI | SI | Next Hop(s) | Transport Encapsulation | 424 +------+------+---------------------+-------------------------+ 425 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 426 | | | | | 427 | 10 | 254 | 198.51.100.10 | GRE | 428 | | | | | 429 | 10 | 253 | www.foo.com | HTTP | 430 ----------------------------------------------------------- 431 | | | | | 432 | 40 | 251 | 198.51.100.15 | GRE | 433 | | | | | 434 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 435 | | | | | 436 | 15 | 212 | Null (end of path) | None | 437 +------+------+---------------------+-------------------------+ 439 Figure 3: Name-based Network Locator Map 441 Alternatively, the extended network locator map may be defined with 442 implicit name information rather than explicit URIs as in Figure 3. 443 In the example of Figure 4 below, the next hop is represented as a 444 generic HTTP service without a specific URI being identified in the 445 extended network locator map. In this scenario, the SFF forwards the 446 packet based on parsing the HTTP request in order to identify the 447 host name or URI. It retrieves the URI and may apply policy 448 information to determine the destination host/service. 450 +------+------+---------------------+-------------------------+ 451 | SPI | SI | Next Hop(s) | Transport Encapsulation | 452 +------+------+---------------------+-------------------------+ 453 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 454 | | | | | 455 | 10 | 254 | 198.51.100.10 | GRE | 456 | | | | | 457 | 10 | 253 | HTTP Service | HTTP | 458 ----------------------------------------------------------- 459 | | | | | 460 | 40 | 251 | 198.51.100.15 | GRE | 461 | | | | | 462 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 463 | | | | | 464 | 15 | 212 | Null (end of path) | None | 465 +------+------+---------------------+-------------------------+ 467 Figure 4: Name-based Network Locator Map with Implicit Name 468 information 470 4.4. Name-based Service Function Forwarder (nSFF) 472 While [I-D.purkayastha-sfc-service-indirection] outlined the 473 realization of forwarding packets in URL-based interaction through 474 HTTP via a specific function (called Service Request Routing (SRR) in 475 [I-D.purkayastha-sfc-service-indirection] ), it is desirable to 476 extend the SFF of the SFC underlay in order to handle nSFPs 477 transparently and without the need to insert a special (SRR) service 478 function into the nSFP. Such extended name-based SFF would then be 479 responsible for forwarding a packet in the SFC domain as per the 480 definition of the (extended) nSFP. 482 In our exemplary realization for an extended SFF, the solution 483 described in this document uses HTTP as the protocol of forwarding 484 SFC packets to the next (name-based) hop in the nSFP. The URI in the 485 HTTP transaction are the names in our nSFP information, which will be 486 used for name based forwarding. 488 Following our reasoning so far, HTTP requests (and more specifically 489 the plain text encoded requests above) are the equivalent of Packets 490 that enter the SFC domain. In the existing SFC framework, typically 491 an IP payload is assumed to be a packet entering the SFC domain. 492 This packet is forwarded to destination nodes using the L2 493 encapsulation. Any layer 2 network can be used as an underlay 494 network. This notion is now extended to packets being possibly part 495 of a entire higher layer application, such as HTTP requests. The 496 handling of any intermediate layers such as TCP, IP is left to the 497 realization of the (extended) SFF operations towards the next (named) 498 hop. For this, we will first outline the general lifecycle of an SFC 499 packet in the following subsection, followed by two examples for 500 determining next hop information in Section 5.2.3, finalized by a 501 layered view on the realization of the nSFF in Section 5.2.4 503 4.5. High Level Architecture 505 +----------+ 506 | SF1 | +--------+ +------+ 507 | instance |\ | NR | | SF2 | 508 +----------+ \ +--------+ +------+ 509 \ || || 510 +------------+ \ +-------+ +---------+ +---------+ +-------+ 511 | Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 | 512 +------------+ +-------+ +---------+ +---------+ +-------+ 513 || 514 +----------+ 515 | Boundary | 516 | node | 517 +----------+ 519 Figure 5: High-level architecture 521 The high-level architecture for name based operation shown in 522 Figure 5 is very similar to the SFC architecture, as described in 523 [RFC7665]. Two new functions are introduced, as shown in the above 524 diagram, namely the name-based Service Function Forwarder (nSFF) and 525 the Name Resolver (NR). The former is an extension of the existing 526 SFF and is capable of processing SFC packets based on name-based 527 network locator map (nNLM) information, determining the next SF, 528 where the packet should be forwarded and the required transport 529 encapsulation. Like standard SFF operation, it adds transport 530 encapsulation to the SFC packet and forwards it. The Name Resolver 531 is a new functional component, capable of identifying the execution 532 end points, where a "named SF" is running, triggered by suitable 533 resolution requests sent by the nSFF. 535 The other functional components such as Classifier, SF are same as 536 described in SFC architecture [RFC7665], while the Forwarders shown 537 in the above diagram are traditional Layer 2 switches. 539 4.6. Operational Steps 541 In the proposed solution, the operations are realized by the name- 542 based SFF, called nSFF. We utilize the high-level architecture in 543 Figure 5 to describe the traversal between two service function 544 instances of an nSFP-based transactions in an example chain of : 545 192.168.x.x -> SF1 (www.foo.com) -> SF2 (www.foo2.com) -> SF3 -> ... 547 According to the SFC lifecycle [RFC7665] and based on our example 548 chain above, the traffic originates from a Classifier or another SFF 549 on the left. The traffic is processed by the incoming nSFF1 (on the 550 left side) through the following steps. The traffic exits at nSFF2. 552 o Step 1: At nSFF1 the following nNLM is assumed 554 +------+------+---------------------+-------------------------+ 555 | SPI | SI | Next Hop(s) | Transport Encapsulation | 556 +------+------+---------------------+-------------------------+ 557 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 558 | | | | | 559 | 10 | 254 | 198.51.100.10 | GRE | 560 | | | | | 561 | 10 | 253 | www.foo.com | HTTP | 562 | | | | | 563 | 10 | 252 | www.foo2.com | HTTP | 564 | | | | | 565 | 40 | 251 | 198.51.100.15 | GRE | 566 | | | | | 567 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 568 | | | | | 569 | 15 | 212 | Null (end of path) | None | 570 +------+------+---------------------+-------------------------+ 572 Figure 6: nNLM at nSFF1 574 o Step 2: nSFF1 removes the previous transport encapsulation (TE) 575 for any traffic originating from another SFF or classifier 576 (traffic from an SF instance does not carry any TE and is 577 therefore directly processed at the nSFF). 579 o Step 3: nSFF1 then processes the NSH information to identify the 580 next SF at the nSFP level by mapping the NSH information to the 581 appropriate entry in its nNLM (see Figure 6) based on the provided 582 SPI/SI information in the NSH (see Section 3) in order to 583 determine the name-based identifier of the next hop SF. With such 584 nNLM in mind, the nSFF searches the map for SPI = 10 and SI = 253. 586 It identifies the next hop as = www.foo.com and HTTP as the 587 protocol to be used. Given the next hop resides locally , the SFC 588 packet is forwarded to the SF1 instance of www.foo.com. Note that 589 the next hop could also be identified from the provided HTTP 590 request, if the next hop information was identified as a generic 591 HTTP service, as defined in Section 5.3. 593 o Step 4: The SF1 instance then processes the received SFC packet 594 according to its service semantics and modifies the NSH by setting 595 SPI = 10, SI = 252 for forwarding the packet along the SFP. It 596 then forwards the SFC packet to its local nSFF, i.e., nSFF1. 598 o Step 5: nSSF1 processes the NSH of the SFC packet again, now with 599 the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It 600 retrieves the next hop information from its nNLM in Figure 6, to 601 be www.foo2.com. Due to this SF not being locally available , the 602 nSFF consults any locally available information regarding routing/ 603 forwarding towards a suitable nSFF that can serve this next hop. 605 o Step 6: If such information exists, the Packet (plus the NSH 606 information) is marked to be sent towards the nSFF serving the 607 next hop based on such information in step 8. 609 o Step 7: If such information does not exist, nSFF1 consults the 610 Name Resolver (NR) to determine the suitable routing/forwarding 611 information towards the identified nSFF serving the next hop of 612 the SFP. For future SFC packets towards this next hop, such 613 resolved information may be locally cached , avoiding to contact 614 the Name Resolver for every SFC packet forwarding. The packet is 615 now marked to be sent via the network in step 8. 617 o Step 8: Utilizing the forwarding information determined in steps 6 618 or 7, nSFF1 adds the suitable transport encapsulation (TE) for the 619 SFC packet before forwarding via the forwarders in the network 620 towards the next nSFF22. 622 o Step 9: When the Packet (+NSH+TE) arrives at the outgoing nSFF2, 623 i.e., the nSFF serving the identified next hop of the SFP, removes 624 the TE and processes the NSH to identify the next hop information. 625 At nSFF2 the nNLM in Figure 7 is assumed. Based on this nNLM and 626 NSH information where SPI = 10 and SI = 252, nSFF2 identifies the 627 next SF as www.foo2.com. 629 +------+------+---------------------+-------------------------+ 630 | SPI | SI | Next Hop(s) | Transport Encapsulation | 631 +------+------+---------------------+-------------------------+ 632 | | | | | 633 | 10 | 252 | www.foo2.com | HTTP | 634 | | | | | 635 | 40 | 251 | 198.51.100.15 | GRE | 636 | | | | | 637 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 638 | | | | | 639 | 15 | 212 | Null (end of path) | None | 640 +------+------+---------------------+-------------------------+ 642 Figure 7: nNLM at SFF2 644 o Step 10: If the next hop is locally registered at the nSFF, it 645 forwards the packet (+NSH) to the service function instance, using 646 suitable IP/MAC methods for doing so. 648 o Step 11: Otherwise, the outgoing nSFF adds a new TE information to 649 the packet and forwards the packet (+NSH+TE) to the next SFF or 650 boundary node, as shown in Figure 7. 652 5. nSFF Forwarding Operations 654 This section outlines the realization of various nSFF forwarding 655 operations in Section 4.6. Although the operations in Section 4 656 utilize the notion of name-based transactions in general, we 657 exemplify the operations here in Section 5 specifically for HTTP- 658 based transactions to ground our description into a specific protocol 659 for such name-based transaction. We will refer to the various steps 660 in each of the following sub-sections. 662 5.1. nSFF Protocol Layers 664 Figure 8 shows the protocol layers, based on the high-level 665 architecture in Figure 5. 667 +-------+ +------+----+ +----+-----+ 668 |App | | | | +--------+ | | | 669 |HTTP | |--------> | | NR | |nSFF----->|-- 670 |TCP |->| TCP |nSFF| +---/\---+ | | TCP | | 671 |IP | | IP | | || | | IP | | 672 +-------+ +------+----+ +---------+ +---------+ +----------+ | 673 | L2 | | L2 |->|Forwarder|-->|Forwarder|-->| L2 | | 674 +-------+ +------+----+ +---------+ +---------+ +----------+ | 675 SF1 nSFF1 nSFF2 | 676 +-------+ | 677 | App |/ | 678 | HTTP | -----------+ 679 | TCP |\ 680 | IP | 681 | L2 | 682 +-------+ 683 SF2 685 Figure 8: Protocol layers 687 The nSFF component here is shown as implementing a full incoming/ 688 outgoing TCP/IP protocol stack towards the local service functions, 689 while implementing the nSFF-NR and nSFF-nSFF protocols based on the 690 descriptions in Section 5.2.3. 692 For the exchange of HTTP-based service function transactions, the 693 nSFF terminates incoming TCP connections from as well as outgoing TCP 694 connections to local SFs, e.g., the TCP connection from SF1 695 terminates at nSFF1, and nSFF1 may store the connection information, 696 such as socket information. It also maintains the mapping 697 information for the HTTP request such as originating SF, destination 698 SF and socket ID. nSFF1 may implement sending keep-alive messages 699 over the socket to maintain the connection to SF1. Upon arrival of 700 an HTTP request from SF1, nSFF1 extracts the HTTP Request and 701 forwards it towards the next node, as outlined in Section 5.2. Any 702 returning response is mapped onto the suitable open socket (for the 703 original request) and send towards SF1. 705 At the outgoing nSFF2, the destination SF2/Host is identified from 706 the HTTP request message. If no TCP connection exists to the SF2, a 707 new TCP connection is opened towards the destination SF2 and the HTTP 708 request is sent over said TCP connection. The nSFF2 may also save 709 the TCP connection information (such as socket information) and 710 maintain the mapping of the socket information to the destination 711 SF2. When an HTTP response is received from SF2 over the TCP 712 connection, nSFF2 extracts the HTTP response, which is forwarded to 713 the next node. nSFF2 may maintain the TCP connection through keep- 714 alive messages. 716 5.2. nSFF Operations 718 In this section, we present three key aspects of operations for the 719 realization of the steps in Section 4.6, namely (i) the registration 720 of local SFs (for step 3 in Section 4.6), (ii) the forwarding of SFC 721 packets to and from local SFs (for step 3 and 4 as well as 10 in 722 Section 4.6), (iii) the forwarding to a remote SF (for steps 5, 6., 723 and 7 in Section 4.6) and to the NR as well as (iv) for the lookup of 724 a suitable remote SF (for step 7 in Section 4.6). We also cover 725 aspects of maintaining local lookup information for reducing lookup 726 latency and others issues. 728 5.2.1. Forwarding between nSFFs and nSFF-NR 730 Forwarding between the distributed nSFFs as well as between nSFF and 731 NR is realized over the operator network via a path-based approach. 732 A path-based approach utilizes path information provided by the 733 source of the packet for forwarding said packet in the network. This 734 is similar to segment routing albeit differing in the type of 735 information provided for such source-based forwarding, as described 736 in this section. In this approach, the forwarding information to a 737 remote nSFF or the NR is defined as a 'path identifier' (pathID) of a 738 defined length where said length indicate the overall pathID length 739 as the 2 to the power of 'length', i.e., maximum 2^16 bits as path 740 information. The payload of the packet is defined by the various 741 operations outlined in the following sub-sections, resulting in an 742 overall packet being transmitted. With this, the generic forwarding 743 format (GFF) for transport over the operator network is defined in 744 Figure 9 with the length field defining the length of the pathID 745 provided. 747 +---------+-----------------+------------------------//------------+ 748 | | | // | 749 | Length | Path ID | Payload // | 750 | (4 bit) | | // | 751 +---------+-----------------+--------------------//----------------+ 753 Figure 9: Generic Forwarding Format(GFF) 755 For the pathID information, solutions such as those in [Reed2016] can 756 be used. Here, the IPv6 source and destination addresses are used to 757 realize a so-called path-based forwarding from the incoming to the 758 outgoing nSFF or the NR. The forwarders in Figure 8 are realized via 759 SDN (software-defined networking) switches, implementing an AND/CMP 760 operation based on arbitrary wildcard matching over the IPv6 source 761 and destination addresses, as outlined in [Reed2016]. Note that in 762 the case of using IPv6 address information for path-based forwarding, 763 the step of removing the transport encapsulation at the outgoing nSFF 764 in Figure 8 is realized by utilizing the provided (existing) IP 765 header (which was used for the purpose of the path-based forwarding 766 in [Reed2016]) for the purpose of next hop forwarding, such as that 767 of IP-based routing. As described in step 8 of the extended nSFF 768 operations, this forwarding information is used as traffic 769 encapsulation. With the forwarding information utilizing existing 770 IPv6 information, IP headers are utilized as TE in this case. The 771 next hop nSFF (see Figure 8) will restore the IP header of the packet 772 with the relevant IP information used to forward the SFC packet to 773 SF2 or it will create a suitable TE (Transport Encapsulation) 774 information to forward the information to another nSFF or boundary 775 node. Forwarding operations at the intermediary forwarders, i.e., 776 SDN switches, examine the pathID information through a flow matching 777 rule in which a specific switch-local output port is represented 778 through the specific assigned bit position in the pathID. Upon a 779 positive match in said rule, the packet is forwarded on said output 780 port. 782 Alternatively, the solution in [I-D.purkayastha-bier-multicast-http] 783 suggests using a so-called BIER (Binary Indexed Explicit Replication) 784 underlay. Here, the nSFF would be realized at the ingress to the 785 BIER underlay, injecting the SFC packet (plus the NSH) header with 786 BIER-based traffic encapsulation into the BIER underlay with each of 787 the forwarders in Figure 8 being realized as a so-called Bit- 788 Forwarding Router (BFR) [RFC8279]. 790 5.2.1.1. Transport Protocol Considerations 792 Given that the proposed solution operates at the 'named transaction' 793 level, particularly for HTTP transactions, forwarding between nSFFs 794 and/or NR SHOULD be implemented via a transport protocol between 795 nSFFs and/or NR in order to provide reliability, segmentation of 796 large GFF packets, and flow control. The details of this protocol 797 will be outlined at a later stage, with the GFF in Figure 9 being the 798 basic forwarding format for this. 800 5.2.2. SF Registration 802 As outlined in step 3 and 10 of Section 4.6, the nSFF needs to 803 determine if the SF derived from the nNLM is locally reachable or 804 whether the packet needs forwarding to a remote SFF. For this, a 805 registration mechanism is provided for such local SF with the local 806 nSFF. Two mechanisms can be used for this: 808 1. SF-initiated: We assume that the SF registers its FQDN to the 809 local nSFF. As local mechanisms, we foresee that either a REST-based 810 interface over the link-local link or configuration of the nSFF 811 (through configuration files or management consoles) can be utilized. 812 Such local registration event leads to the nSFF to register the given 813 FQDN with the NR in combination with a system-unique nSFF identifier 814 that is being used for path computation purposes in the NR. For the 815 registration, the packet format in Figure 10 is used (inserted as the 816 payload in the GFF of Figure 9 with the pathID towards the NR), with 817 a hash over the FQDN being conveyed in the registration and the R/D 818 bit set to 0 (for registration). We assume that the pathID towards 819 the NR is known to the nSFF through configuration means. 821 +---------+-----------------+------------------+ 822 | | | | 823 | R/D | hash(FQDN) | nSFF_ID | 824 | (1 bit) | (16 bit) | (8 bit) | 825 +---------+-----------------+------------------+ 827 Figure 10: Registration packet format 829 The NR maintains an internal table that associates the hash(FQDN), 830 the nSFF_id information as well as the pathID information being used 831 for communication between nSFF and NR. The nSFF locally maintains a 832 mapping of registered FQDNs to IP addresses, for the latter using 833 link-local private IP addresses. 835 2. Orchestration-based: in this mechanism, we assume that SFC to be 836 orchestrated and the chain being provided through an orchestration 837 template with FQDN information associated to a compute/storage 838 resource that is being deployed by the orchestrator. We also assume 839 knowledge at the orchestrator of the resource topology. Based on 840 this, the orchestrator can now use the same REST-based protocol 841 defined in option 1 to instruct the NR to register the given FQDN, as 842 provided in the template, at the nSFF it has identified as being the 843 locally servicing nSFF, provided as the system-unique nSFF 844 identifier. 846 5.2.3. Local SF Forwarding 848 There are two cases of local SF forwarding, namely the SF sending an 849 SFC packet to the local nSFF (incoming requests) or the nSFF sending 850 a packet to the SF (outgoing requests) as part of steps 3 and 10 in 851 Section 4.6. In the following, we outline the operation for HTTP as 852 an example named transaction. 854 As shown in Figure 8, incoming HTTP requests from SFs are extracted 855 by terminating the incoming TCP connection at their local nSFFs at 856 the TCP level. The nSFF MUST maintain a mapping of open TCP sockets 857 to HTTP requests for HTTP response association. 859 For outgoing HTTP requests, the nSFF utilizes the maintained mapping 860 of locally registered FQDNs to link-local IP addresses (see 861 Section 5.2.2 option 1). Hence, upon receiving an SFC packet from a 862 remote nSFF (in step 9 of Section 4.6), the nSFF determines the local 863 existence of the SF through the registration mechanisms in 864 Section 5.2.2. If said SF does exist locally, the HTTP (+NSH) 865 packet, after stripping the TE, is sent to the local SF as step 10 in 866 Section 4.6 via a TCP-level connection. Outgoing nSFF SHOULD keep 867 TCP connections open to local SFs for improving SFC packet delivery 868 in subsequent transactions. 870 5.2.4. Remote SF Forwarding 872 In steps 5, 6, 7, and 8 of Section 4.6, an SFC packet is forwarded to 873 a remote nSFF based on the nNLM information for the next hop of the 874 nSFP. Section 5.2.4.1 handles the case of suitable forwarding 875 information to the remote nSFF not existing, therefore consulting the 876 NR to obtain suitable information, while Section 5.2.4.2 describes 877 the maintenance of forwarding information at the local nSFF, while 878 Section 5.2.4.3 describes the update of stale forwarding information. 879 Note that the forwarding described in Section 5.2.1 is used for the 880 actual forwarding to the various nSFF components. Ultimately, 881 Section 5.2.4.4 describes the forwarding to the remote nSFF via the 882 forwarder network 884 5.2.4.1. Remote SF Discovery 886 The nSFF communicates with the NR for two purposes, namely the 887 registration and discovery of FQDNs. The packet format for the 888 former was shown in Figure 10 in Section 5.2.2, while Figure 11 889 outlines the packet format for the discovery request. A path to a 890 specific FQDN is requested by sending a hash of the FQDN to the NR 891 together with its nSFF_id, receiving as a response a pathID with a 892 length identifier. The NR should maintain a table of discovery 893 requests that map discovered (hash of) FQDN to the nSFF_id that 894 requested it and the pathID that is being calculated as a result of 895 the discovery request. 897 The discovery request for an FQDN that has not previously been served 898 at the nSFF (or for an FQDN whose pathID information has been flushed 899 as a result of the update operations in Section 5.2.4.3), results in 900 an initial latency incurred by this discovery through the NR, while 901 any SFC packet sent over the same SFP in a subsequent transaction 902 will utilize the nSFF local mapping table. Such initial latency can 903 be avoided by pre-populating the FQDN-pathID mapping proactively as 904 part of the overall orchestration procedure, e.g., alongside the 905 distribution of the nNLM information to the nSFF. 907 +--------------+-------------+ +--------+-----------------//--------+ 908 | | | | | // | 909 | hash(FQDN) | nSFF_ID | | Length | pathID // | 910 | (16 bit) | (8 bit) | | (4 bit)| // | 911 +--------------+-------------+ +--------+-------------//------------+ 912 Path Request Path Response 914 Figure 11: Discovery packet format 916 5.2.4.2. Maintaining Forwarding Information at Local nSFF 918 Each nSFF MUST maintain an internal table that maps the (hash of the) 919 FQDN information to a suitable pathID information. As outlined in 920 step 7 of Section 4.6, if a suitable entry does not exist for a given 921 FQDN, the pathID information is requested with the operations in 922 Section 5.2.4.1 and the suitable entry is locally created upon 923 receiving a reply with the forwarding operation being executed as 924 described in Section 5.2.1. 926 If such entry does exist (i.e., step 6 of Section 4.6) the pathID is 927 locally retrieved and used for the forwarding operation in 928 Section 5.2.1. 930 5.2.4.3. Updating Forwarding Information at nSFF 932 The forwarding information maintained at each nSFF (see 933 Section 5.2.4.2) might need to be updated for three reasons: 935 o An existing SF is no longer reachable: In this case, the nSFF with 936 which the SF is locally registered, deregisters the SF explicitly 937 at the NR by sending the packet in Figure 10 with the hashed FQDN 938 and the R/D bit set to 1 (for deregister). 940 o Another SF instance has become reachable in the network (and 941 therefore might provide a better alternative to the existing SF): 942 in this case, the NR has received another packet with format 943 defined in Figure 11 but a different nSFF_id value. 945 o Links along paths might no longer be reachable: the NR might use 946 suitable southbound interface to transport networks to detect link 947 failures, which it associates to the appropriate pathID bit 948 position 950 For this purpose, the packet format in Figure 12 is sent from the NR 951 to all affected nSFFs, using the generic format in Figure 9. The 952 pathID to the affected nSFFs is computed as the binary OR over all 953 pathIDs to those nSFF_ids affected where the pathID information to 954 the affected nSFF_id values is determined from the NR-local table 955 maintained in the registration/deregistration operation of 956 Section 5.2.2. 958 +---------+-----------------+--------------//----+ 959 | | | // | 960 | Type | #IDs | IDs // | 961 | (1 bit) | (8 bit) | // | 962 +---------+-----------------+----------//--------+ 964 Figure 12: Path update format 966 In case 1 and 2, the Type bit is set to 1 (type nSFF_id) and the 967 affected nSFFs are determined by those nSFFs that have previously 968 sent SF discovery requests, utilizing the optional table mapping 969 previously registered FQDNs to nSFF_id values. If no table mapping 970 the (hash of) FQDN to nSFF_id is maintained, the update is sent to 971 all nSFFs. Upon receiving the path update at the affected nSFF, all 972 appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) 973 identifiers provided will be removed, leading to a new NR discovery 974 request at the next remote nSFF forwarding to the appropriate FQDN. 976 In case 3, the Type bit is set to 0 (type linkID) and the affected 977 nSFFs are determined by those nSFFs whose discovery requests have 978 previously resulted in pathIDs which include the affected link, 979 utilizing the optional table mapping previously registered FQDNs to 980 pathID values (see Section 5.2.4.1). Upon receiving the path update, 981 the affected nSFF will check its internal table that maps FQDNs to 982 pathIDs to determine those pathIDs affected by the link problems. 983 For this, the pathID entries of said table are checked against the 984 linkID values provided in the ID entry of the path update through a 985 binary AND/CMP operation to check the inclusion of the link in the 986 pathIDs to the FQDNs. If any pathID is affected, the FQDN-pathID 987 entry is removed, leading to a new NR discovery request at the next 988 remote nSFF forwarding to the appropriate FQDN. 990 5.2.4.4. Forwarding to remote nSFF 992 Once step 5, 6, and 7 in Section 4.6 are being executed, step 8 993 finally sends the SFC packet to the remote nSFF, utilizing the pathID 994 returned in the discovery request (Section 5.2.4.1) or retrieved from 995 the local pathID mapping table. The SFC packet is placed in the 996 payload of the generic forwarding format in Figure 14 together with 997 the pathID and the nSFF eventually executes the forwarding operations 998 in Section 5.2.1. 1000 6. IANA Considerations 1002 This document requests no IANA actions. 1004 7. Security Considerations 1006 The operations in Section 4 and 5 consider the forwarding of SFC 1007 packets between named SFs based on HTTP. The support for HTTPS is 1008 foreseen to ensure suitable encryption capability of such exchanges. 1009 Future updates to this draft will outline the support for such HTTPS- 1010 based SFC exchanges. 1012 8. Informative References 1014 [_3GPP_SBA] 1015 3GPP, "Technical Realization of Service Based 1016 Architecture", 3GPP TS 29.500 0.4.0, January 2018, 1017 . 1019 [_3GPP_SBA_ENHANCEMENT] 1020 3GPP, "New SID for Enhancements to the Service-Based 5G 1021 System Architecture", 3GPP S2-182904 , February 2018, . 1025 [I-D.purkayastha-bier-multicast-http] 1026 Purkayastha, D., Rahman, A., and D. Trossen, "Multicast 1027 HTTP using BIER", draft-purkayastha-bier-multicast-http-00 1028 (work in progress), March 2018. 1030 [I-D.purkayastha-sfc-service-indirection] 1031 Purkayastha, D., Rahman, A., Trossen, D., Despotovic, Z., 1032 and R. Khalili, "Alternative Handling of Dynamic Chaining 1033 and Service Indirection", draft-purkayastha-sfc-service- 1034 indirection-02 (work in progress), March 2018. 1036 [Reed2016] 1037 Reed, M., Al-Naday, M., Thomas, N., Trossen, D., and S. 1038 Spirou, "Stateless multicast switching in software defined 1039 networks", ICC 2016, 2016. 1041 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1042 Chaining (SFC) Architecture", RFC 7665, 1043 DOI 10.17487/RFC7665, October 2015, 1044 . 1046 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1047 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1048 Explicit Replication (BIER)", RFC 8279, 1049 DOI 10.17487/RFC8279, November 2017, 1050 . 1052 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1053 "Network Service Header (NSH)", RFC 8300, 1054 DOI 10.17487/RFC8300, January 2018, 1055 . 1057 Appendix A. Change Log 1059 [Note to Editor: Please remove this section before publication.] 1061 Changes from 01 version: 1063 o Added this Change Log in Appendix A. 1065 o Addressed Editorial Comments (nits) throughout the document from 1066 Dirk Hugo, DT. 1068 o Section 4.1, added a paragraph to clarify the execution path of 1069 nSFF when the next hop is identified by L2/L3 identifier or by 1070 using Name. 1072 o Section 5.1, added paragraphs to clarify how TCP connection is 1073 terminated and handled at the ingress nSFF and egress nSFF. 1075 Authors' Addresses 1076 Dirk Trossen 1077 InterDigital Communications, LLC 1078 64 Great Eastern Street, 1st Floor 1079 London EC2A 3QR 1080 United Kingdom 1082 Email: Dirk.Trossen@InterDigital.com 1083 URI: http://www.InterDigital.com/ 1085 Debashish Purkayastha 1086 InterDigital Communications, LLC 1087 Conshohocken 1088 USA 1090 Email: Debashish.Purkayastha@InterDigital.com 1092 Akbar Rahman 1093 InterDigital Communications, LLC 1094 Montreal 1095 Canada 1097 Email: Akbar.Rahman@InterDigital.com