idnits 2.17.1 draft-trossen-sfc-name-based-sff-07.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 5 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? 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 (May 26, 2019) is 1790 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-bier-multicast-http-response-00 Summary: 0 errors (**), 0 flaws (~~), 4 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 InterDigital Europe, Ltd 4 Intended status: Informational D. Purkayastha 5 Expires: November 27, 2019 A. Rahman 6 InterDigital Communications, LLC 7 May 26, 2019 9 Name-Based Service Function Forwarder (nSFF) component within SFC 10 framework 11 draft-trossen-sfc-name-based-sff-07 13 Abstract 15 Adoption of cloud and fog technology allows operators to deploy a 16 single "Service Function" to multiple "Execution locations". The 17 decision to steer traffic to a specific location may change 18 frequently based on load, proximity etc. Under the current SFC 19 framework, steering traffic dynamically to the different execution 20 end points require a specific 're-chaining', i.e., a change in the 21 service function path reflecting the different IP endpoints to be 22 used for the new execution points. This procedure may be complex and 23 take time. In order to simplify re-chaining and reduce the time to 24 complete the procedure, we discuss separating the logical Service 25 Function Path from the specific execution end points. This can be 26 done by identifying the Service Functions using a name rather than a 27 routable IP endpoint (or Layer 2 address). This document describes 28 the necessary extensions, additional functions and protocol details 29 in SFF (Service Function Forwarder) to handle name based 30 relationships. 32 This document presents InterDigital's approach to name-based service 33 function chaining. It does not represent IETF consensus and is 34 presented here so that the SFC community may benefit from considering 35 this mechanism and the possibility of its use in the edge data 36 centers. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on November 27, 2019. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Example use case: 5G control plane services . . . . . . . . . 4 75 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Relevant part of SFC architecture . . . . . . . . . . . . 6 77 4.2. Challenges with current framework . . . . . . . . . . . . 7 78 5. Name based operation in SFF . . . . . . . . . . . . . . . . . 8 79 5.1. General Idea . . . . . . . . . . . . . . . . . . . . . . 8 80 5.2. Name-Based Service Function Path (nSFP) . . . . . . . . . 8 81 5.3. Name Based Network Locator Map (nNLM) . . . . . . . . . . 10 82 5.4. Name-based Service Function Forwarder (nSFF) . . . . . . 12 83 5.5. High Level Architecture . . . . . . . . . . . . . . . . . 13 84 5.6. Operational Steps . . . . . . . . . . . . . . . . . . . . 14 85 6. nSFF Forwarding Operations . . . . . . . . . . . . . . . . . 16 86 6.1. nSFF Protocol Layers . . . . . . . . . . . . . . . . . . 16 87 6.2. nSFF Operations . . . . . . . . . . . . . . . . . . . . . 18 88 6.2.1. Forwarding between nSFFs and nSFF-NR . . . . . . . . 18 89 6.2.2. SF Registration . . . . . . . . . . . . . . . . . . . 21 90 6.2.3. Local SF Forwarding . . . . . . . . . . . . . . . . . 22 91 6.2.4. Handling of HTTP responses . . . . . . . . . . . . . 23 92 6.2.5. Remote SF Forwarding . . . . . . . . . . . . . . . . 23 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 95 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 98 10.2. Informative References . . . . . . . . . . . . . . . . . 28 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 101 1. Introduction 103 The requirements on today's networks are very diverse, enabling 104 multiple use cases such as IoT, Content Distribution, Gaming and 105 Network functions such as Cloud RAN and 5G control planes based on a 106 service-based architecture. These services are deployed, provisioned 107 and managed using Cloud based techniques as seen in the IT world. 108 Virtualization of compute and storage resources is at the heart of 109 providing (often web) services to end users with the ability to 110 quickly provisioning such virtualized service endpoints through, 111 e.g., container based techniques. This creates a dynamicity with the 112 capability to dynamically compose new services from available 113 services as well as move a service instance in response to user 114 mobility or resource availability where desirable. When moving from 115 a pure 'distant cloud' model to one of localized micro data centers 116 with regional, metro or even street level, often called 'edge' data 117 centers, such virtualized service instances can be instantiated in 118 topologically different locations with the overall 'distant' data 119 center now being transformed into a network of distributed ones. The 120 reaction of content providers, like Facebook, Google, NetFlix and 121 others, are not just relying on deploying content server at the 122 ingress of the customer network. Instead the trend is towards 123 deploying multiple POPs within the customer network, those POPs being 124 connected through proprietary mechanisms [Schlinker2017] to push 125 content. 127 The Service Function Chaining (SFC) framework [RFC7665] allows 128 network operators as well as service providers to compose new 129 services by chaining individual "Service Functions (SFs)". Such 130 chains are expressed through explicit relationships of functional 131 components (the service functions), realized through their direct 132 Layer 2 (e.g., MAC address) or Layer 3 (e.g., IP address) 133 relationship as defined through next hop information that is being 134 defined by the network operator, see Section 4 for more background on 135 SFC. 137 In a dynamic service environment of distributed data centers as the 138 one outlined above, with the ability to create and recreate service 139 endpoints frequently, the SFC framework requires to reconfigure the 140 existing chain through information based on the new relationships, 141 causing overhead in a number of components, specifically the 142 orchestrator that initiates the initial service function chain and 143 any possible reconfiguration. 145 This document describes how such changes can be handled without 146 involving the initiation of new and reconfigured SFCs by lifting the 147 chaining relationship from Layer 2 and 3 information to that of 148 service function 'names', such as names for instance being expressed 149 as URIs. In order to transparently support such named relationships, 150 we propose to embed the necessary functionality directly into the 151 Service Function Forwarder (SFF), as described in [RFC7665]). With 152 that, the SFF described in this document allows for keeping an 153 existing SFC intact, as described by its service function path (SFP), 154 while enabling the selection of an appropriate service function 155 endpoint(s) during the traversal of packets through the SFC. This 156 document is an Independent Submission to the RFC Editor. It is not 157 an output of the IETF SFC WG. 159 2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 3. Example use case: 5G control plane services 169 We exemplify the need for chaining service functions at the level of 170 a service name through a use case stemming from the current 3GPP Rel 171 16 work on Service Based Architecture (SBA) [_3GPP_SBA], 172 [_3GPP_SBA_ENHANCEMENT]. In this work, mobile network control planes 173 are proposed to be realized by replacing the traditional network 174 function interfaces with a fully service-based one. HTTP was chosen 175 as the application layer protocol for exchanging suitable service 176 requests [_3GPP_SBA]. With this in mind, the exchange between, say 177 the 3GPP (Rel. 15) defined Session Management Function (SMF) and the 178 Access and Mobility management Function (AMF) in a 5G control plane 179 is being described as a set of web service like requests which are in 180 turn embedded into HTTP requests. Hence, interactions in a 5G 181 control plane can be modelled based on service function chains where 182 the relationship is between the specific (IP-based) service function 183 endpoints that implement the necessary service endpoints in the SMF 184 and AMF. The service functions are exposed through URIs with work 185 ongoing to define the used naming conventions for such URIs. 187 This move from a network function model (in pre-Rel 15 systems of 188 3GPP) to a service-based model is motivated through the proliferation 189 of data center operations for mobile network control plane services. 190 In other words, typical IT-based methods to service provisioning, in 191 particular that of virtualization of entire compute resources, are 192 envisioned to being used in future operations of mobile networks. 194 Hence, operators of such future mobile networks desire to virtualize 195 service function endpoints and direct (control plane) traffic to the 196 most appropriate current service instance in the most appropriate 197 (local) data centre, such data centre envisioned as being 198 interconnected through a software-defined wide area network (SD-WAN). 199 'Appropriate' here can be defined by topological or geographical 200 proximity of the service initiator to the service function endpoint. 201 Alternatively, network or service instance compute load can be used 202 to direct a request to a more appropriate (in this case less loaded) 203 instance to reduce possible latency of the overall request. Such 204 data center centric operation is extended with the trend towards 205 regionalization of load through a 'regional office' approach, where 206 micro data centers provide virtualizable resources that can be used 207 in the service execution, creating a larger degree of freedom when 208 choosing the 'most appropriate' service endpoint for a particular 209 incoming service request. 211 While the move to a service-based model aligns well with the 212 framework of SFC, choosing the most appropriate service instance at 213 runtime requires so-called 're-chaining' of the SFC since the 214 relationships in said SFC are defined through Layer 2 or 3 215 identifiers, which in turn are likely to be different if the chosen 216 service instances reside in different parts of the network (e.g., in 217 a regional data center). 219 Hence, when a traffic flow is forwarded over a service chain 220 expressed as an SFC-compliant Service Function Path (SFP), packets in 221 the traffic flow are processed by the various service function 222 instances, with each service function instance applying a service 223 function prior to forwarding the packets to the next network node. 224 It is a Service layer concept and can possibly work over any Virtual 225 network layer and an Underlay network, possibly IP or any Layer 2 226 technology. At the service layer, Service Functions are identified 227 using a path identifier and an index. Eventually this index is 228 translated to an IP address (or MAC address) of the host where the 229 service function is running. Because of this, any change of service 230 function instance is likely to require a change of the path 231 information since either IP address (in the case of changing the 232 execution from one data centre to another) or MAC address will change 233 due to the newly selected service function instance. 235 Returning to our 5G Control plane example, a user's connection 236 request to access an application server in the internet may start 237 with signaling in the Control Plane to setup user plane bearers. The 238 connection request may flow through service functions over a service 239 chain in the Control plane, as deployed by network operator. Typical 240 SFs in a 5G control plane may include "RAN termination / processing", 241 "Slice Selection Function", "AMF" and "SMF". A Network Slice is a 242 complete logical network including Radio Access Network (RAN) and 243 Core Network (CN). Distinct RAN and Core Network Slices may exist. 244 A device may access multiple Network Slices simultaneously through a 245 single RAN. The device may provide Network Slice Selection 246 Assistance Information (NSSAI) parameters to the network to help it 247 select a RAN and a Core network part of a slice instance. Part of 248 the control plane, the Common Control Network Function (CCNF), the 249 Network Slice Selection Function (NSSF) is in charge of selecting 250 core Network Slice instances. The Classifier, as described in SFC 251 architecture, may reside in the user terminal or at the eNB. These 252 service functions can be configured to be part of a Service Function 253 Chain. We can also say that some of the configurations of the 254 Service Function Path may change at the execution time. For example, 255 the SMF may be relocated as user moves and a new SMF may be included 256 in the Service Function Path based on user location. The following 257 diagram in Figure 1 shows the example Service Function Chain 258 described here. 260 +------+ +---------+ +-----+ +-----+ 261 | User | | Slice | | | | | 262 | App |-->| Control |->| AMF |-->| SMF |--> 263 | Fn | | Function| | | | | 264 +------+ +---------+ +-----+ +-----+ 266 Figure 1: Mapping SFC onto Service Function Execution Points along a 267 Service Function Path 269 4. Background 271 [RFC7665] describes an architecture for the specification, creation 272 and ongoing maintenance of Service Function Chains (SFCs). It 273 includes architectural concepts, principles, and components used in 274 the construction of composite services through deployment of SFCs. 275 In the following, we outline the parts of this SFC architecture 276 relevant for our proposed extension, followed by the challenges with 277 this current framework in the light of our example use case. 279 4.1. Relevant part of SFC architecture 281 SFC Architecture, as defined in [RFC7665], describes architectural 282 components such as Service Function (SF), Classifier, and Service 283 Function Forwarder (SFF). It describes the Service Function Path 284 (SFP) as the logical path of an SFC. Forwarding traffic along such 285 SFP is the responsibility of the SFF. For this, the SFFs in a 286 network maintain the requisite SFP forwarding information. Such SFP 287 forwarding information is associated with a service path identifier 288 (SPI) that is used to uniquely identify an SFP. The service 289 forwarding state is represented by the Service Index (SI) and enables 290 an SFF to identify which SFs of a given SFP should be applied, and in 291 what order. The SFF also has information that allows it to forward 292 packets to the next SFF after applying local service functions. 294 The operational steps to forward traffic are then as follows: Traffic 295 arrives at an SFF from the network. The SFF determines the 296 appropriate SF the traffic should be forwarded to via information 297 contained in the SFC encapsulation. After SF processing, the traffic 298 is returned to the SFF, and, if needed, is forwarded to another SF 299 associated with that SFF. If there is another non-local hop (i.e., 300 to an SF with a different SFF) in the SFP, the SFF further 301 encapsulates the traffic in the appropriate network transport 302 protocol and delivers it to the network for delivery to the next SFF 303 along the path. Related to this forwarding responsibility, an SFF 304 should be able to interact with metadata. 306 4.2. Challenges with current framework 308 As outlined in previous section, the Service Function Path defines an 309 ordered sequence of specific Service Functions instances being used 310 for the interaction between initiator and service functions along the 311 SFP. These service functions are addressed by IP (or any L2/MAC) 312 addresses and defined as next hop information in the network locator 313 maps of traversing SFF nodes. 315 As outlined in our use case, however, the service provider may want 316 to provision SFC nodes based on dynamically spun up service function 317 instances so that these (now virtualized) service functions can be 318 reached in the SFC domain using the SFC underlay layer. 320 Following the original model of SFC, any change in a specific 321 execution point for a specific Service Function along the SFP will 322 require a change of the SFP information (since the new service 323 function execution point likely carries different IP or L2 address 324 information) and possibly even the Next Hop information in SFFs along 325 the SFP. In case the availability of new service function instances 326 is rather dynamic (e.g., through the use of container-based 327 virtualization techniques), the current model and realization of SFC 328 could lead to reducing the flexibility of service providers and 329 increasing the management complexity incurred by the frequent changes 330 of (service) forwarding information in the respective SFF nodes. 331 This is because any change of the SFP (and possibly next hop info) 332 will need to go through suitable management cycles. 334 To address these challenges through a suitable solution, we identify 335 the following requirements: 337 o Relations between Service Execution Points MUST be abstracted so 338 that, from an SFP point of view, the Logical Path never changes. 340 o Deriving the Service Execution Points from the abstract SFP SHOULD 341 be fast and incur minimum delay. 343 o Identification of the Service Execution Points SHOULD not use a 344 combination of Layer 2 or Layer 3 mechanisms. 346 The next section outlines a solution to address the issue, allowing 347 for keeping SFC information (represented in its SFP) intact while 348 addressing the desired flexibility of the service provider. 350 5. Name based operation in SFF 352 5.1. General Idea 354 The general idea is two-pronged. Firstly, we elevate the definition 355 of a Service Function Path onto the level of 'name-based 356 interactions' rather than limiting SFPs to Layer 3 or Layer 2 357 information only. Secondly, we extend the operations of the SFF to 358 allow for forwarding decisions that take into account such name-based 359 interaction while remaining backward compatible to the current SFC 360 architecture, as defined in [RFC7665]. In the following sections, we 361 outline these two components of our solution. 363 If the next hop information in the Network Locator Map (NLM) is 364 described using L2/L3 identifier, the name-based SFF (nSFF) may 365 operate as described for [traditional] SFF, as defined in [RFC7665]. 366 On the other hand, if the next hop information in the NLM is 367 described as a name, then the nSFF operates as described in the 368 following sections. 370 In the following sections, we outline the two components of our 371 solution. 373 5.2. Name-Based Service Function Path (nSFP) 375 The existing SFC framework is defined in [RFC7665]. Section 4 376 outlines that the SFP information is representing path information 377 based on Layer 2 or 3 information, i.e., MAC or IP addresses, causing 378 the aforementioned frequent adaptations in cases of execution point 379 changes. Instead, we introduce the notion of a "name-based service 380 function path (nSFP)". 382 In today's networking terms, any identifier can be treated as a name 383 but we will illustrate the realization of a "Name based SFP" through 384 extended SFF operations (see Section 6) based on URIs as names and 385 HTTP as the protocol of exchanging information. Here, URIs are being 386 used to name for a Service Function along the nSFP. It is to be 387 noted that the Name based SFP approach is not restricted to HTTP (as 388 the protocol) and URIs (as next hop identifier within the SFP). 389 Other identifiers such as an IP address itself can also be used and 390 are interpreted as a 'name' in the nSFP. IP addresses as well as 391 fully qualified domain names forming complex URIs (uniform resource 392 identifiers), such as www.example.com/service_name1, are all captured 393 by the notion of 'name' in this document. 395 Generally, nSFPs are defined as an ordered sequence of the "name" of 396 Service Functions (SF) and a typical name-based Service Function Path 397 may look like: 192.0.x.x -> www.example.com -> www.example2.com/ 398 service1 -> www.example2.com/service2. 400 Our use case in Section 3 can then be represented as an ordered named 401 sequence. An example for a session initiation that involves an 402 authentication procedure, this could look like 192.0.x.x -> 403 smf.example.org/session_initiate -> amf.example.org/auth -> 404 smf.example.org/session_complete -> 192.0.x.x. [Note that this 405 example is only a conceptual one, since the exact nature of any 406 future SBA-based exchange of 5G control plane functions is yet to be 407 defined by standardization bodies such as 3GPP]. 409 In accordance with our use case in Section 3, any of these named 410 services can potentially be realized through more than one replicated 411 SF instances. This leads to make dynamic decision on where to send 412 packets along the SAME service function path information, being 413 provided during the execution of the SFC. Through elevating the SFP 414 onto the notion of name-based interactions, the SFP will remain the 415 same even if those specific execution points change for a specific 416 service interaction. 418 The following diagram in Figure 2, describes this name-based SFP 419 concept and the resulting mapping of those named interactions onto 420 (possibly) replicated instances. 422 +---------------------------------------------------------------+ 423 |SERVICE LAYER | 424 | 192.0.x.x --> www.example.com --> www.example2.com --> | 425 | || || | 426 +----------------------||--------------||-----------------------+ 427 || || 428 || || 429 +----------------------||--------------||-----------------------+ 430 | Underlay network \/ \/ | 431 | +--+ +--+ +--+ +--+ +--+ +--+ | 432 | | | | | | | | | | | | | | 433 | +--+ +--+ +--+ +--+ +--+ +--+ | 434 | Compute and Compute and | 435 | storage nodes storage nodes | 436 +---------------------------------------------------------------+ 438 Figure 2: Mapping SFC onto Service Function Execution Points along a 439 Service Function Path based on Virtualized Service Function Instance 441 5.3. Name Based Network Locator Map (nNLM) 443 In order to forward a packet within a name-based SFP, we need to 444 extend the network locator map as defined in [RFC8300] with the 445 ability to consider name relations based on URIs as well as high- 446 level transport protocols such as HTTP for means of SFC packet 447 forwarding. Another example for SFC packet forwarding could be that 448 of CoAP. 450 The extended Network Locator Map or name-based Network Locator Map 451 (nNLM) is shown in Figure 3 as an example for www.example.com being 452 part of the nSFP. Such extended nNLM is stored at each SFF 453 throughout the SFC domain with suitable information populated to the 454 nNLM during the configuration phase. 456 +------+------+---------------------+-----------------------------+ 457 | SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| 458 +------+------+---------------------+-----------------------------+ 459 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 460 | | | | | 461 | 10 | 254 | 198.51.100.10 | GRE | 462 | | | | | 463 | 10 | 253 | www.example.com | HTTP | 464 ----------------------------------------------------------------- 465 | | | | | 466 | 40 | 251 | 198.51.100.15 | GRE | 467 | | | | | 468 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 469 | | | | | 470 | 15 | 212 | Null (end of path) | None | 471 +------+------+---------------------+-----------------------------+ 473 Figure 3: Name-based Network Locator Map 475 Alternatively, the extended network locator map may be defined with 476 implicit name information rather than explicit URIs as in Figure 3. 477 In the example of Figure 4 below, the next hop is represented as a 478 generic HTTP service without a specific URI being identified in the 479 extended network locator map. In this scenario, the SFF forwards the 480 packet based on parsing the HTTP request in order to identify the 481 host name or URI. It retrieves the URI and may apply policy 482 information to determine the destination host/service. 484 +------+------+---------------------+-----------------------------+ 485 | SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| 486 +------+------+---------------------+-----------------------------+ 487 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 488 | | | | | 489 | 10 | 254 | 198.51.100.10 | GRE | 490 | | | | | 491 | 10 | 253 | HTTP Service | HTTP | 492 ----------------------------------------------------------------- 493 | | | | | 494 | 40 | 251 | 198.51.100.15 | GRE | 495 | | | | | 496 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 497 | | | | | 498 | 15 | 212 | Null (end of path) | None | 499 +------+------+---------------------+-----------------------------+ 501 Figure 4: Name-based Network Locator Map with Implicit Name 502 information 504 5.4. Name-based Service Function Forwarder (nSFF) 506 It is desirable to extend the SFF of the SFC underlay to handle nSFPs 507 transparently and without the need to insert any service function 508 into the nSFP. Such extended name-based SFF would then be 509 responsible for forwarding a packet in the SFC domain as per the 510 definition of the (extended) nSFP. 512 In our exemplary realization for an extended SFF, the solution 513 described in this document uses HTTP as the protocol of forwarding 514 SFC packets to the next (name-based) hop in the nSFP. The URI in the 515 HTTP transaction are the names in our nSFP information, which will be 516 used for name based forwarding. 518 Following our reasoning so far, HTTP requests (and more specifically 519 the plain text encoded requests above) are the equivalent of Packets 520 that enter the SFC domain. In the existing SFC framework, typically 521 an IP payload is assumed to be a packet entering the SFC domain. 522 This packet is forwarded to destination nodes using the L2 523 encapsulation. Any layer 2 network can be used as an underlay 524 network. This notion is now extended to packets being possibly part 525 of a entire higher layer application, such as HTTP requests. The 526 handling of any intermediate layers such as TCP, IP is left to the 527 realization of the (extended) SFF operations towards the next (named) 528 hop. For this, we will first outline the general lifecycle of an SFC 529 packet in the following subsection, followed by two examples for 530 determining next hop information in Section 6.2.3, finalized by a 531 layered view on the realization of the nSFF in Section 6.2.4. 533 5.5. High Level Architecture 535 +----------+ 536 | SF1 | +--------+ +------+ 537 | instance |\ | NR | | SF2 | 538 +----------+ \ +--------+ +------+ 539 \ || || 540 +------------+ \ +-------+ +---------+ +---------+ +-------+ 541 | Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 | 542 +------------+ +-------+ +---------+ +---------+ +-------+ 543 || 544 +----------+ 545 | Boundary | 546 | node | 547 +----------+ 549 Figure 5: High-level architecture 551 The high-level architecture for name based operation shown in 552 Figure 5 is very similar to the SFC architecture, as described in 553 [RFC7665]. Two new functions are introduced, as shown in the above 554 diagram, namely the name-based Service Function Forwarder (nSFF) and 555 the Name Resolver (NR). 557 nSFF (name-based Service Function Forwarder) is an extension of the 558 existing SFF and is capable of processing SFC packets based on name- 559 based network locator map (nNLM) information, determining the next 560 SF, where the packet should be forwarded and the required transport 561 encapsulation. Like standard SFF operation, it adds transport 562 encapsulation to the SFC packet and forwards it. 564 The Name Resolver is a new functional component, capable of 565 identifying the execution end points, where a "named SF" is running, 566 triggered by suitable resolution requests sent by the nSFF. Though 567 this is similar to DNS function, but it is not same. It does not use 568 DNS protocols or data records. A new procedure to determine the 569 suitable routing/forwarding information towards the Nsff (name-based 570 SFF) serving the next hop of the SFP (Service Function Path) is used. 571 The details is described later. 573 The other functional components such as Classifier, SF are same as 574 described in SFC architecture, as defined in [RFC7665], while the 575 Forwarders shown in the above diagram are traditional Layer 2 576 switches. 578 5.6. Operational Steps 580 In the proposed solution, the operations are realized by the name- 581 based SFF, called nSFF. We utilize the high-level architecture in 582 Figure 5 to describe the traversal between two service function 583 instances of an nSFP-based transactions in an example chain of : 584 192.0.x.x -> SF1 (www.example.com) -> SF2 (www.example2.com) -> SF3 585 -> ... Service Function 3 (SF3)is assumed to be a classical Service 586 Function, hence existing SFC mechanisms can be used to reach it and 587 will not be considered in this example. 589 According to the SFC lifecycle, as defined in [RFC7665], based on our 590 example chain above, the traffic originates from a Classifier or 591 another SFF on the left. The traffic is processed by the incoming 592 nSFF1 (on the left side) through the following steps. The traffic 593 exits at nSFF2. 595 o Step 1: At nSFF1 the following nNLM is assumed 597 +------+------+---------------------+----------------------------+ 598 | SPI | SI | Next Hop(s) | Transport Encapsulation(TE)| 599 +------+------+---------------------+----------------------------+ 600 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 601 | | | | | 602 | 10 | 254 | 198.51.100.10 | GRE | 603 | | | | | 604 | 10 | 253 | www.example.com | HTTP | 605 | | | | | 606 | 10 | 252 | www.example2.com | HTTP | 607 | | | | | 608 | 40 | 251 | 198.51.100.15 | GRE | 609 | | | | | 610 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 611 | | | | | 612 | 15 | 212 | Null (end of path) | None | 613 +------+------+---------------------+----------------------------+ 615 Figure 6: nNLM at nSFF1 617 o Step 2: nSFF1 removes the previous transport encapsulation (TE) 618 for any traffic originating from another SFF or classifier 619 (traffic from an SF instance does not carry any TE and is 620 therefore directly processed at the nSFF). 622 o Step 3: nSFF1 then processes the Network Service Header (NSH) 623 information, as defined in [RFC8300], to identify the next SF at 624 the nSFP level by mapping the NSH information to the appropriate 625 entry in its nNLM (see Figure 6) based on the provided SPI/SI 626 information in the NSH (see Section 4) in order to determine the 627 name-based identifier of the next hop SF. With such nNLM in mind, 628 the nSFF searches the map for SPI = 10 and SI = 253. It 629 identifies the next hop as = www.example.com and HTTP as the 630 protocol to be used. Given the next hop resides locally, the SFC 631 packet is forwarded to the SF1 instance of www.example.com. Note 632 that the next hop could also be identified from the provided HTTP 633 request, if the next hop information was identified as a generic 634 HTTP service, as defined in Section 5.3. 636 o Step 4: The SF1 instance then processes the received SFC packet 637 according to its service semantics and modifies the NSH by setting 638 SPI = 10, SI = 252 for forwarding the packet along the SFP. It 639 then forwards the SFC packet to its local nSFF, i.e., nSFF1. 641 o Step 5: nSSF1 processes the NSH of the SFC packet again, now with 642 the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It 643 retrieves the next hop information from its nNLM in Figure 6, to 644 be www.example2.com. Due to this SF not being locally available, 645 the nSFF consults any locally available information regarding 646 routing/forwarding towards a suitable nSFF that can serve this 647 next hop. 649 o Step 6: If such information exists, the Packet (plus the NSH 650 information) is marked to be sent towards the nSFF serving the 651 next hop based on such information in step 8. 653 o Step 7: If such information does not exist, nSFF1 consults the 654 Name Resolver (NR) to determine the suitable routing/forwarding 655 information towards the identified nSFF serving the next hop of 656 the SFP. For future SFC packets towards this next hop, such 657 resolved information may be locally cached, avoiding to contact 658 the Name Resolver for every SFC packet forwarding. The packet is 659 now marked to be sent via the network in step 8. 661 o Step 8: Utilizing the forwarding information determined in steps 6 662 or 7, nSFF1 adds the suitable transport encapsulation (TE) for the 663 SFC packet before forwarding via the forwarders in the network 664 towards the next nSFF22. 666 o Step 9: When the Packet (+NSH+TE) arrives at the outgoing nSFF2, 667 i.e., the nSFF serving the identified next hop of the SFP, removes 668 the TE and processes the NSH to identify the next hop information. 669 At nSFF2 the nNLM in Figure 7 is assumed. Based on this nNLM and 670 NSH information where SPI = 10 and SI = 252, nSFF2 identifies the 671 next SF as www.example2.com. 673 +------+------+---------------------+-----------------------------+ 674 | SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| 675 +------+------+---------------------+-----------------------------+ 676 | | | | | 677 | 10 | 252 | www.example2.com | HTTP | 678 | | | | | 679 | 40 | 251 | 198.51.100.15 | GRE | 680 | | | | | 681 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 682 | | | | | 683 | 15 | 212 | Null (end of path) | None | 684 +------+------+---------------------+-----------------------------+ 686 Figure 7: nNLM at SFF2 688 o Step 10: If the next hop is locally registered at the nSFF, it 689 forwards the packet (+NSH) to the service function instance, using 690 suitable IP/MAC methods for doing so. 692 o Step 11: Otherwise, the outgoing nSFF adds a new TE information to 693 the packet and forwards the packet (+NSH+TE) to the next SFF or 694 boundary node, as shown in Figure 7. 696 6. nSFF Forwarding Operations 698 This section outlines the realization of various nSFF forwarding 699 operations in Section 5.6. Although the operations in Section 5 700 utilize the notion of name-based transactions in general, we 701 exemplify the operations here in Section 5 specifically for HTTP- 702 based transactions to ground our description into a specific protocol 703 for such name-based transaction. We will refer to the various steps 704 in each of the following sub-sections. 706 6.1. nSFF Protocol Layers 708 Figure 8 shows the protocol layers, based on the high-level 709 architecture in Figure 5. 711 +-------+ +------+----+ +----+-----+ 712 |App | | | | +--------+ | | | 713 |HTTP | |--------> | | NR | |nSFF----->|-- 714 |TCP |->| TCP |nSFF| +---/\---+ | | TCP | | 715 |IP | | IP | | || | | IP | | 716 +-------+ +------+----+ +---------+ +---------+ +----------+ | 717 | L2 | | L2 |->|Forwarder|-->|Forwarder|-->| L2 | | 718 +-------+ +------+----+ +---------+ +---------+ +----------+ | 719 SF1 nSFF1 nSFF2 | 720 +-------+ | 721 | App |/ | 722 | HTTP | -----------+ 723 | TCP |\ 724 | IP | 725 | L2 | 726 +-------+ 727 SF2 729 Figure 8: Protocol layers 731 The nSFF component here is shown as implementing a full incoming/ 732 outgoing TCP/IP protocol stack towards the local service functions, 733 while implementing the nSFF-NR and nSFF-nSFF protocols based on the 734 descriptions in Section 6.2.3. 736 For the exchange of HTTP-based service function transactions, the 737 nSFF terminates incoming TCP connections from as well as outgoing TCP 738 connections to local SFs, e.g., the TCP connection from SF1 739 terminates at nSFF1, and nSFF1 may store the connection information, 740 such as socket information. It also maintains the mapping 741 information for the HTTP request such as originating SF, destination 742 SF and socket ID. nSFF1 may implement sending keep-alive messages 743 over the socket to maintain the connection to SF1. Upon arrival of 744 an HTTP request from SF1, nSFF1 extracts the HTTP Request and 745 forwards it towards the next node, as outlined in Section 6.2. Any 746 returning response is mapped onto the suitable open socket (for the 747 original request) and send towards SF1. 749 At the outgoing nSFF2, the destination SF2/Host is identified from 750 the HTTP request message. If no TCP connection exists to the SF2, a 751 new TCP connection is opened towards the destination SF2 and the HTTP 752 request is sent over said TCP connection. The nSFF2 may also save 753 the TCP connection information (such as socket information) and 754 maintain the mapping of the socket information to the destination 755 SF2. When an HTTP response is received from SF2 over the TCP 756 connection, nSFF2 extracts the HTTP response, which is forwarded to 757 the next node. nSFF2 may maintain the TCP connection through keep- 758 alive messages. 760 6.2. nSFF Operations 762 In this section, we present three key aspects of operations for the 763 realization of the steps in Section 5.6, namely (i) the registration 764 of local SFs (for step 3 in Section 5.6), (ii) the forwarding of SFC 765 packets to and from local SFs (for step 3 and 4 as well as 10 in 766 Section 5.6), (iii) the forwarding to a remote SF (for steps 5, 6 and 767 7 in Section 5.6) and to the NR as well as (iv) for the lookup of a 768 suitable remote SF (for step 7 in Section 5.6). We also cover 769 aspects of maintaining local lookup information for reducing lookup 770 latency and others issues. 772 6.2.1. Forwarding between nSFFs and nSFF-NR 774 Forwarding between the distributed nSFFs as well as between nSFF and 775 NR is realized over the operator network via a path-based approach. 776 A path-based approach utilizes path information provided by the 777 source of the packet for forwarding said packet in the network. This 778 is similar to segment routing albeit differing in the type of 779 information provided for such source-based forwarding, as described 780 in this section. In this approach, the forwarding information to a 781 remote nSFF or the NR is defined as a 'path identifier' (pathID) of a 782 defined length where said "Length" field indicates the full pathID 783 length. The payload of the packet is defined by the various 784 operations outlined in the following sub-sections, resulting in an 785 overall packet being transmitted. With this, the generic forwarding 786 format (GFF) for transport over the operator network is defined in 787 Figure 9 with the length field defining the length of the pathID 788 provided. 790 +---------+-----------------+------------------------//------------+ 791 | | | // | 792 | Length | Path ID | Payload // | 793 |(12 bit) | | // | 794 +---------+-----------------+--------------------//----------------+ 796 Figure 9: Generic Forwarding Format(GFF) 798 o Length (12 bits): Defines the length of the pathID, i.e., up to 799 4096 bits 801 o Path ID (): Variable length field, Bit field derived from IPv6 802 source and destination address 804 For the pathID information, solutions such as those in [Reed2016] can 805 be used. Here, the IPv6 source and destination addresses are used to 806 realize a so-called path-based forwarding from the incoming to the 807 outgoing nSFF or the NR. The forwarders in Figure 8 are realized via 808 SDN (software-defined networking) switches, implementing an AND/CMP 809 operation based on arbitrary wildcard matching over the IPv6 source 810 and destination addresses, as outlined in [Reed2016]. Note that in 811 the case of using IPv6 address information for path-based forwarding, 812 the step of removing the transport encapsulation at the outgoing nSFF 813 in Figure 8 is realized by utilizing the provided (existing) IP 814 header (which was used for the purpose of the path-based forwarding 815 in [Reed2016]) for the purpose of next hop forwarding, such as that 816 of IP-based routing. As described in step 8 of the extended nSFF 817 operations, this forwarding information is used as traffic 818 encapsulation. With the forwarding information utilizing existing 819 IPv6 information, IP headers are utilized as TE in this case. The 820 next hop nSFF (see Figure 8) will restore the IP header of the packet 821 with the relevant IP information used to forward the SFC packet to 822 SF2 or it will create a suitable TE (Transport Encapsulation) 823 information to forward the information to another nSFF or boundary 824 node. Forwarding operations at the intermediary forwarders, i.e., 825 SDN switches, examine the pathID information through a flow matching 826 rule in which a specific switch-local output port is represented 827 through the specific assigned bit position in the pathID. Upon a 828 positive match in said rule, the packet is forwarded on said output 829 port. 831 Alternatively, the solution in 832 [I-D.ietf-bier-multicast-http-response] suggests using a so-called 833 BIER (Binary Indexed Explicit Replication) underlay. Here, the nSFF 834 would be realized at the ingress to the BIER underlay, injecting the 835 SFC packet (plus the NSH) header with BIER-based traffic 836 encapsulation into the BIER underlay with each of the forwarders in 837 Figure 8 being realized as a so-called Bit-Forwarding Router (BFR) 838 [RFC8279]. 840 6.2.1.1. Transport Protocol Considerations 842 Given that the proposed solution operates at the 'named transaction' 843 level, particularly for HTTP transactions, forwarding between nSFFs 844 and/or NR SHOULD be implemented via a transport protocol between 845 nSFFs and/or NR in order to provide reliability, segmentation of 846 large GFF packets, and flow control, with the GFF in Figure 9 being 847 the basic forwarding format for this. 849 Note that the nSFFs act as TCP proxies at ingress and egress, thus 850 terminating incoming and initiating outgoing HTTP sessions to SFs. 852 Figure 10 shows the packet format being used for the transmission of 853 data, being adapted from the TCP header. Segmentation of large 854 transactions into single transport protocol packets is realized 855 through maintaining a 'Sequence number'. A 'Checksum' is calculated 856 over a single data packet with the ones-complement TCP checksum 857 calculation being used. The 'Window Size' field indicates the 858 current maximum number of transport packets that are allowed in- 859 flight by the egress nSFF. A data packet is sent without 'Data' 860 field to indicate the end of (e.g., HTTP) transaction. 862 Note that in order to support future named transactions based on 863 other application protocols, such as CoAP, future versions of the 864 transport protocol MAY introduce a 'Type' field that indicates the 865 type of application protocol being used between SF and nSFF with 866 'Type' 0x01 proposed for HTTP. This is being left for future study. 868 | 16 bit | 16 bit | 869 +----------------------------------------------+ 870 | Sequence number | 871 +----------------------------------------------+ 872 | Checksum | Window Size | 873 +----------------------------------------------+ 874 | ... | 875 | Data (Optional) | 876 +----------------------------------------------+ 878 Figure 10: Transport protocol data packet format 880 Given the path-based forwarding being used between nSFFs, the 881 transport protocol between nSFFs utilizes negative acknowledgements 882 from the egress nSFF towards the ingress nSFF. The transport 883 protocol NACK packet carries the number of NACKs as well as the 884 specific sequence numbers being indicated as lost in the 'NACK 885 number' field(s), as shown in Figure 11. 887 | 16 bit | 16 bit | 888 +----------------------------------------------+ 889 | Number of NACKs | + 890 +----------------------------------------------+ 891 | NACK number | 892 +----------------------------------------------+ 893 + ... NACK Number + 894 +----------------------------------------------+ 896 Figure 11: Transport protocol NACK packet format 898 If the indicated number of NACKs in a received NACK packet in non- 899 zero, the ingress nSFF will retransmit all sequence numbers signalled 900 in the packet, while decreasing its congestion window size for future 901 transmissions. 903 If the indicated number of NACKs in a received NACK packet in zero, 904 it will indicate the current congestion window as being successfully 905 (and completely) being transmitted, increasing the congestion window 906 size if smaller than the advertised 'Window Size' in Figure 10. 908 The maintenance of the congestion window is subject to realization at 909 the ingress nSFF and left for further study in nSFF realizations. 911 6.2.2. SF Registration 913 As outlined in step 3 and 10 of Section 5.6, the nSFF needs to 914 determine if the SF derived from the nNLM is locally reachable or 915 whether the packet needs forwarding to a remote SFF. For this, a 916 registration mechanism is provided for such local SF with the local 917 nSFF. Two mechanisms can be used for this: 919 1. SF-initiated: We assume that the SF registers its FQDN to the 920 local nSFF. As local mechanisms, we foresee that either a REST-based 921 interface over the link-local link or configuration of the nSFF 922 (through configuration files or management consoles) can be utilized. 923 Such local registration event leads to the nSFF to register the given 924 FQDN with the NR in combination with a system-unique nSFF identifier 925 that is being used for path computation purposes in the NR. For the 926 registration, the packet format in Figure 12 is used (inserted as the 927 payload in the GFF of Figure 9 with the pathID towards the NR). 929 +---------+-----------------+------------------+ 930 | | | | 931 | R/D | hash(FQDN) | nSFF_ID | 932 | (1 bit) | (16 bit) | (8 bit) | 933 +---------+-----------------+------------------+ 935 Figure 12: Registration packet format 937 o R/D: 1 bit length (0 for Register, 1 for De-register) 939 o Hash(FQDN): 16 bit length for a hash over the FQDN of the SF 941 o nSFF_ID: 8 bit for a system-unique identifier for the SFF related 942 to the SF. 944 We assume that the pathID towards the NR is known to the nSFF through 945 configuration means. 947 The NR maintains an internal table that associates the hash(FQDN), 948 the nSFF_id information as well as the pathID information being used 949 for communication between nSFF and NR. The nSFF locally maintains a 950 mapping of registered FQDNs to IP addresses, for the latter using 951 link-local private IP addresses. 953 2. Orchestration-based: in this mechanism, we assume that SFC to be 954 orchestrated and the chain being provided through an orchestration 955 template with FQDN information associated to a compute/storage 956 resource that is being deployed by the orchestrator. We also assume 957 knowledge at the orchestrator of the resource topology. Based on 958 this, the orchestrator can now use the same REST-based protocol 959 defined in option 1 to instruct the NR to register the given FQDN, as 960 provided in the template, at the nSFF it has identified as being the 961 locally servicing nSFF, provided as the system-unique nSFF 962 identifier. 964 6.2.3. Local SF Forwarding 966 There are two cases of local SF forwarding, namely the SF sending an 967 SFC packet to the local nSFF (incoming requests) or the nSFF sending 968 a packet to the SF (outgoing requests) as part of steps 3 and 10 in 969 Section 5.6. In the following, we outline the operation for HTTP as 970 an example named transaction. 972 As shown in Figure 8, incoming HTTP requests from SFs are extracted 973 by terminating the incoming TCP connection at their local nSFFs at 974 the TCP level. The nSFF MUST maintain a mapping of open TCP sockets 975 to HTTP requests (utilizing the URI of the request) for HTTP response 976 association. 978 For outgoing HTTP requests, the nSFF utilizes the maintained mapping 979 of locally registered FQDNs to link-local IP addresses (see 980 Section 6.2.2 option 1). Hence, upon receiving an SFC packet from a 981 remote nSFF (in step 9 of Section 5.6), the nSFF determines the local 982 existence of the SF through the registration mechanisms in 983 Section 6.2.2. If said SF does exist locally, the HTTP (+NSH) 984 packet, after stripping the TE, is sent to the local SF as step 10 in 985 Section 5.6 via a TCP-level connection. Outgoing nSFF SHOULD keep 986 TCP connections open to local SFs for improving SFC packet delivery 987 in subsequent transactions. 989 6.2.4. Handling of HTTP responses 991 When executing step 3 and 10 in Section 5.6, the SFC packet will be 992 delivered to the locally registered next hop. As part of the HTTP 993 protocol, responses to the HTTP request will need to be delivered on 994 the return path to the originating nSFF (i.e., the previous hop). 995 For this, the nSFF maintains a list of link-local connection 996 information, e.g., sockets to the local SF and the pathID on which 997 the request was received. Once receiving the response, nSFF consults 998 the table to determine the pathID of the original request, forming a 999 suitable GFF-based packet to be returned to the previous nSFF. 1001 When receiving the HTTP response at the previous nSFF, the nSFF 1002 consults the table of (locally) open sockets to determine the 1003 suitable local SF connection, mapping the received HTTP response URI 1004 to the stored request URI. Utilizing the found socket, the HTTP 1005 response is forwarded to the locally registered SF. 1007 6.2.5. Remote SF Forwarding 1009 In steps 5, 6, 7, and 8 of Section 5.6, an SFC packet is forwarded to 1010 a remote nSFF based on the nNLM information for the next hop of the 1011 nSFP. Section 6.2.5.1 handles the case of suitable forwarding 1012 information to the remote nSFF not existing, therefore consulting the 1013 NR to obtain suitable information, while Section 6.2.5.2 describes 1014 the maintenance of forwarding information at the local nSFF, while 1015 Section 6.2.5.3 describes the update of stale forwarding information. 1016 Note that the forwarding described in Section 6.2.1 is used for the 1017 actual forwarding to the various nSFF components. Ultimately, 1018 Section 6.2.5.4 describes the forwarding to the remote nSFF via the 1019 forwarder network. 1021 6.2.5.1. Remote SF Discovery 1023 The nSFF communicates with the NR for two purposes, namely the 1024 registration and discovery of FQDNs. The packet format for the 1025 former was shown in Figure 10 in Section 6.2.2, while Figure 13 1026 outlines the packet format for the discovery request. 1028 +--------------+-------------+ +--------+-----------------//--------+ 1029 | | | | | // | 1030 | hash(FQDN) | nSFF_ID | | Length | pathID // | 1031 | (16 bit) | (8 bit) | | (4 bit)| // | 1032 +--------------+-------------+ +--------+-------------//------------+ 1033 Path Request Path Response 1035 Figure 13: Discovery packet format 1037 For Path Request: 1039 o Hash(FQDN): 16 bit length for a hash over the FQDN of the SF 1041 o nSFF_ID: 8 bit for a system-unique identifier for the SFF related 1042 to the SF 1044 For Path Response: 1046 o Length (4 bits): Defines the length of the pathID 1048 o Path ID (): Variable length field, Bit field derived from IPv6 1049 source and destination address 1051 A path to a specific FQDN is requested by sending a hash of the FQDN 1052 to the NR together with its nSFF_id, receiving as a response a pathID 1053 with a length identifier. The NR SHOULD maintain a table of 1054 discovery requests that map discovered (hash of) FQDN to the nSFF_id 1055 that requested it and the pathID that is being calculated as a result 1056 of the discovery request. 1058 The discovery request for an FQDN that has not previously been served 1059 at the nSFF (or for an FQDN whose pathID information has been flushed 1060 as a result of the update operations in Section 6.2.5.3), results in 1061 an initial latency incurred by this discovery through the NR, while 1062 any SFC packet sent over the same SFP in a subsequent transaction 1063 will utilize the nSFF local mapping table. Such initial latency can 1064 be avoided by pre-populating the FQDN-pathID mapping proactively as 1065 part of the overall orchestration procedure, e.g., alongside the 1066 distribution of the nNLM information to the nSFF. 1068 6.2.5.2. Maintaining Forwarding Information at Local nSFF 1070 Each nSFF MUST maintain an internal table that maps the (hash of the) 1071 FQDN information to a suitable pathID information. As outlined in 1072 step 7 of Section 5.6, if a suitable entry does not exist for a given 1073 FQDN, the pathID information is requested with the operations in 1074 Section 6.2.5.1 and the suitable entry is locally created upon 1075 receiving a reply with the forwarding operation being executed as 1076 described in Section 6.2.1. 1078 If such entry does exist (i.e., step 6 of Section 5.6) the pathID is 1079 locally retrieved and used for the forwarding operation in 1080 Section 6.2.1. 1082 6.2.5.3. Updating Forwarding Information at nSFF 1084 The forwarding information maintained at each nSFF (see 1085 Section 6.2.5.2) might need to be updated for three reasons: 1087 o An existing SF is no longer reachable: In this case, the nSFF with 1088 which the SF is locally registered, de-registers the SF explicitly 1089 at the NR by sending the packet in Figure 10 with the hashed FQDN 1090 and the R/D bit set to 1 (for de-register). 1092 o Another SF instance has become reachable in the network (and 1093 therefore might provide a better alternative to the existing SF): 1094 in this case, the NR has received another packet with format 1095 defined in Figure 11 but a different nSFF_id value. 1097 o Links along paths might no longer be reachable: the NR might use 1098 suitable southbound interface to transport networks to detect link 1099 failures, which it associates to the appropriate pathID bit 1100 position. 1102 For this purpose, the packet format in Figure 14 is sent from the NR 1103 to all affected nSFFs, using the generic format in Figure 9. 1105 +---------+-----------------+--------------//----+ 1106 | | | // | 1107 | Type | #IDs | IDs // | 1108 | (1 bit) | (8 bit) | // | 1109 +---------+-----------------+----------//--------+ 1111 Figure 14: Path update format 1113 o Type: 1 bit length (0 for Nsff ID, 1 for Link ID) 1114 o #IDs: 8 bit length for number of IDs in the list 1116 o IDs: List of IDs (Nsff ID or Link ID) 1118 The pathID to the affected nSFFs is computed as the binary OR over 1119 all pathIDs to those nSFF_ids affected where the pathID information 1120 to the affected nSFF_id values is determined from the NR-local table 1121 maintained in the registration/deregistration operation of 1122 Section 6.2.2. 1124 The pathID may include the type of information being updated (e.g., 1125 node identifiers of leaf nodes or link identifiers for removed 1126 links). The node identifier itself may be a special identifier to 1127 signal "ALL NODES" as being affected. The node identifier may signal 1128 changes to the network that are substantial (e.g., parallel link 1129 failures). The node identifier may trigger (e.g., recommend) purging 1130 of the entire path table (e.g., rather than the selective removal of 1131 a few nodes only). 1133 It will include the information according to the type. The included 1134 information may also be related to the type and length information 1135 for the number of identifiers being provided. 1137 In case 1 and 2, the Type bit is set to 1 (type nSFF_id) and the 1138 affected nSFFs are determined by those nSFFs that have previously 1139 sent SF discovery requests, utilizing the optional table mapping 1140 previously registered FQDNs to nSFF_id values. If no table mapping 1141 the (hash of) FQDN to nSFF_id is maintained, the update is sent to 1142 all nSFFs. Upon receiving the path update at the affected nSFF, all 1143 appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) 1144 identifiers provided will be removed, leading to a new NR discovery 1145 request at the next remote nSFF forwarding to the appropriate FQDN. 1147 In case 3, the Type bit is set to 0 (type linkID) and the affected 1148 nSFFs are determined by those nSFFs whose discovery requests have 1149 previously resulted in pathIDs which include the affected link, 1150 utilizing the optional table mapping previously registered FQDNs to 1151 pathID values (see Section 6.2.5.1). Upon receiving the node 1152 identifier information in the path update, the affected nSFF will 1153 check its internal table that maps FQDNs to pathIDs to determine 1154 those pathIDs affected by the link problems and remove path 1155 information that includes the received node identifier(s). For this, 1156 the pathID entries of said table are checked against the linkID 1157 values provided in the ID entry of the path update through a binary 1158 AND/CMP operation to check the inclusion of the link in the pathIDs 1159 to the FQDNs. If any pathID is affected, the FQDN-pathID entry is 1160 removed, leading to a new NR discovery request at the next remote 1161 nSFF forwarding to the appropriate FQDN. 1163 6.2.5.4. Forwarding to remote nSFF 1165 Once step 5, 6, and 7 in Section 5.6 are being executed, step 8 1166 finally sends the SFC packet to the remote nSFF, utilizing the pathID 1167 returned in the discovery request (Section 6.2.5.1) or retrieved from 1168 the local pathID mapping table. The SFC packet is placed in the 1169 payload of the generic forwarding format in Figure 9 together with 1170 the pathID and the nSFF eventually executes the forwarding operations 1171 in Section 6.2.1. 1173 7. IANA Considerations 1175 This document requests no IANA actions. 1177 8. Security Considerations 1179 The operations in Sections 5 and 6 describes the forwarding of SFC 1180 packets between named SFs based on URIs exchanged in HTTP messages. 1181 For security considerations, TLS is sufficient between originating 1182 node and Nsff, Nsff to Nsff, Nsff to destination. TLS handshake 1183 allows to determine the FQDN, which in turn is enough for the service 1184 routing decision. Supporting TLS also allows the possibility of 1185 HTTPS based transactions. 1187 9. Acknowledgement 1189 The authors would like to thank Dirk von Hugo and Andrew Malis for 1190 their reviews and valuable comments. We would also like to thank 1191 Joel Halpern, the chair of the SFC WG, and Adrian Farrel for guiding 1192 us through the IETF Independent Submission Editor (ISE) path. 1194 10. References 1196 10.1. Normative References 1198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1199 Requirement Levels", BCP 14, RFC 2119, 1200 DOI 10.17487/RFC2119, March 1997, 1201 . 1203 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1204 Chaining (SFC) Architecture", RFC 7665, 1205 DOI 10.17487/RFC7665, October 2015, 1206 . 1208 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1209 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1210 May 2017, . 1212 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1213 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1214 Explicit Replication (BIER)", RFC 8279, 1215 DOI 10.17487/RFC8279, November 2017, 1216 . 1218 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1219 "Network Service Header (NSH)", RFC 8300, 1220 DOI 10.17487/RFC8300, January 2018, 1221 . 1223 10.2. Informative References 1225 [_3GPP_SBA] 1226 3GPP, "Technical Realization of Service Based 1227 Architecture", 3GPP TS 29.500 0.4.0, January 2018, 1228 . 1230 [_3GPP_SBA_ENHANCEMENT] 1231 3GPP, "New SID for Enhancements to the Service-Based 5G 1232 System Architecture", 3GPP S2-182904 , February 2018, . 1236 [I-D.ietf-bier-multicast-http-response] 1237 Purkayastha, D., Rahman, A., Trossen, D., and T. Eckert, 1238 "Applicability of BIER Multicast Overlay for Adaptive 1239 Streaming Services", draft-ietf-bier-multicast-http- 1240 response-00 (work in progress), February 2019. 1242 [Reed2016] 1243 Reed, M., Al-Naday, M., Thomas, N., Trossen, D., and S. 1244 Spirou, "Stateless multicast switching in software defined 1245 networks", ICC 2016, 2016, 1246 . 1248 [Schlinker2017] 1249 Schlinker, B., Kim, H., Cui, T., Katz-Bassett, E., 1250 Madhyastha, Harsha., Cunha, I., Quinn, J., Hassan, S., 1251 Lapukhov, P., and H. Zeng, "Engineering Egress with Edge 1252 Fabric, Steering Oceans of Content to the World", ACM 1253 SIGCOMM 2017, 2017, . 1256 Authors' Addresses 1258 Dirk Trossen 1259 InterDigital Europe, Ltd 1260 64 Great Eastern Street, 1st Floor 1261 London EC2A 3QR 1262 United Kingdom 1264 Email: Dirk.Trossen@InterDigital.com 1266 Debashish Purkayastha 1267 InterDigital Communications, LLC 1268 1001 E Hector St 1269 Conshohocken 1270 USA 1272 Email: Debashish.Purkayastha@InterDigital.com 1274 Akbar Rahman 1275 InterDigital Communications, LLC 1276 1000 Sherbrooke Street West 1277 Montreal 1278 Canada 1280 Email: Akbar.Rahman@InterDigital.com