idnits 2.17.1 draft-khalili-sfc-optimized-chaining-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. == There is 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 28, 2019) is 1878 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 147, but not defined -- Looks like a reference, but probably isn't: '1' on line 197 == Missing Reference: 'K' is mentioned on line 197, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-mpls-sfc-05 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG R. Khalili 3 Internet-Draft Z. Despotovic 4 Intended status: Informational A. Hecker 5 Expires: September 1, 2019 Huawei ERC, Munich, Germany 6 D. Purkayastha 7 A. Rahman 8 D. Trossen 9 InterDigital Communications, LLC 10 February 28, 2019 12 Optimized Service Function Chaining 13 draft-khalili-sfc-optimized-chaining-02 15 Abstract 17 This draft investigates possibilities to use so-called 'transport- 18 derived service function forwarders' (tSFFs) that uses existing 19 transport information for explicit service path information. The 20 draft discusses two such possibilities, focusing on realization of 21 efficient chaining over single transport networks. In the first one, 22 the transport network is SDN-based. The second one introduces and 23 explains a specific service request routing (SRR) function to support 24 URL-level routing of service requests. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2 SFC Forwarding Solutions . . . . . . . . . . . . . . . . . . . . 5 66 2.1 Edge classification and network forwarding aggregation . . . 5 67 2.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.2 SRR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3 Optimized SFC Chaining . . . . . . . . . . . . . . . . . . . . . 9 70 3.1 Utilizing Transport-derived SFFs . . . . . . . . . . . . . . 9 71 3.1.1 Hierarchical addressing for service chaining . . . . . . 9 72 3.1.2 Edge classification and service chains . . . . . . . . . 10 73 3.2 Pre-Warming SFP Information for SRR-based Chaining . . . . . 11 74 4 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6 Informative References . . . . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1 Introduction 81 The delivery of end-to-end network services often requires steering 82 traffic through a sequence of individual service functions. 83 Deployment of these functions and particularly creation of a 84 composite service from them, i.e. steering traffic through them, had 85 traditionally been coupled to the underlying network topology and as 86 such awkward to configure and operate [RFC7498]. 88 To remedy the problems identified by [RFC7498], [RFC7665] defines 89 architecture for service function chaining that is topology 90 independent. The architecture is predicated on a service indirection 91 layer composed of architectural elements such as service functions 92 (SF), service function forwarders (SFF), classifiers, etc. SFFs are 93 the key architectural element as they connect the attached SFs and 94 thus create a service plane. 96 [RFC7665] proposes SFC encapsulation as a means for service plane 97 elements to communicate. The SFC encapsulation serves essentially two 98 purposes. It provides path identification in the service plane (which 99 is the primary and mandatory usage of the encapsulation) and serves 100 as a placeholder for metadata transferred among SFs. [RFC8300] 101 defines NSH as a particular realization of the SFC encapsulation. 103 Standalone SFC encapsulation such as NSH is the mainstream SFC 104 forwarding method with the intention to work over multiple transport 105 networks. However, SFC has been identified as a suitable methodology 106 to chain services within single transport networks or, as outlined in 107 [Guichard2018], even in data centers. In such cases, [RFC7665] points 108 at the possibility of utilizing so-called 'transport-derived service 109 function forwarders' (tSFFs) that ignore the SFC encapsulation, using 110 existing transport information for explicit service path 111 information. 113 [Farrel2019] has discussed how the NSH can be logically represented 114 in MPLS label stacks, to enable service function chaining in MPLS 115 networks without relying on NSH header. In this document, we expand 116 on this possibility by focusing on the realization of efficient 117 chaining over SDN and HTTP transport networks. The chaining and the 118 transport network configuration in such setting can be optimized to 119 reduce the initial request latency. This is specifically important in 120 networks with tight latency requirements, such as data centers, and 121 for latency sensitive services such as URLLC, Ultra-Reliable Low- 122 Latency Communication, defined in 5G [TS22.261]. By a careful design, 123 such optimization can be achieved without making the chaining 124 topology dependent, satisfying the requirements specified in 125 [RFC7665]. As also stated in [Farrel2019], the goal here is not to 126 replace NSH header but to demonstrate the benefits of using tSFFs in 127 such transport networks. 129 In our first solution, said transport network is an SDN-based one 130 where we represent the SFP (service function path) through a vector 131 of aggregated flow identifiers. This solution is positioned as a tSFF 132 between two or more SFs with no need for this solution to be SFC 133 encapsulation aware. Hence, it can also be applied in cases where NSH 134 encapsulation is not feasible. In our second solution, we refer to 135 [Purka2018] which uses a specific service request routing (SRR) 136 function to support URL-level routing of service requests. Chaining 137 more than one SRR-connected SFs can be optimized for reducing the 138 initial request latency, while supporting at least three different 139 tSFFs, including the flow aggregation one presented as the first 140 solution. 142 1.1 Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 2 SFC Forwarding Solutions 150 2.1 Edge classification and network forwarding aggregation 152 Assume we are free to choose network locators (routable addresses in 153 the considered network) for edge nodes in a network. Besides, assume 154 that routers (switches in SDN terminology) in that network can 155 forward packets based on wildcard matching on bit-fields in the 156 header. For example, a switch somewhere in the network can forward a 157 packet by following this logic: "the packet should be sent out the 158 port k, because the bits 15, 16, and 17 of the destination address 159 are 1, 0, and 1, respectively." This is possible with SDN deployments 160 compliant e.g. with OpenFlow v1.3 and higher. 162 One can then come up with a multi-level classification of edge nodes, 163 which leads to an assignment of locators to the edge nodes such that 164 for every switch of the network the following holds: 166 The switch has as many forwarding rules as it has ports 168 For switch port k, the rule takes the form: when the destination 169 address of the incoming packet contains a bit-field of a 170 specific form, forward the packet to port k . For example, if 171 the packet has 1 in the bit p of the destination address, 172 forward to port 4. 174 When this is done, the network essentially becomes a fabric that 175 delivers a packet arriving at one of its inports to the appropriate 176 outport. It does that while maintaining the minimum internal state. 177 [Khalili2016] explains details of the approach. In particular, it 178 shows that large networks and networks with particular topologies 179 require a large ID space. With that in mind, [Khalili2016] proposes 180 an approximate method that trades node state for ID (address) space 181 and shows that a small increase of the node state brings a large 182 reduction or the address space (additional forwarding rules that 183 don't follow the above form). It is this approximate method that we 184 refer to in the rest of this section. 186 2.1.1 Example 188 Consider a simple network with an ingress (classifier) and an egress 189 node, two transport switches/routers C1 and C2, and two service 190 function forwarders, SFF1 and SFF2 (as depicted in Figure 1). Service 191 functions SF1 and SF2 are attached to SFF1 and SF3 and SF4 are 192 attached to SFF2. In this example, we assume that edge nodes are 193 SFF1, SFF2, and the egress node. 195 The ASC algorithm proposed in [Khalili2016] assigns to an edge node 196 in the network an ID of the form (v(1), v(2), ..., v(K)), where v(j), 197 j\in[1, K], being 1 if there is a path crossing link j that ends in 198 the corresponding edge node, and 0 otherwise. K is the size of IDs 199 assigned to edge nodes and is an output of the algorithm. 201 Applying ASC algorithm to our example, we have: 203 IDSFF1 = (0, 1, 1, 0, 0), 205 IDSFF2 = (1, 0, 0, 1, 0), 207 IDEgress = (1, 0, 0, 0, 1). 209 Assuming that the destination-edge IDs are embedded in the header of 210 the packets, e.g. via encapsulation, the forwarding rules at C1 and 211 C2 can be aggregated by matching on bits of these IDs: 213 At C1: if 1st bit is 1, forward over port 3; if 2nd bit is 1, 214 forward over port 2. 216 At C2: if 3rd bit is 1, forward over port 1, if 4th bit is 1, 217 forward over port 2, if 5th bit is 1, forward over port 3. 219 Note from this example that each edge node has a unique ID and that 220 we put no limitation on how SFCs are defined. 222 _ _ _ _ _ _ _ _ _ _ _ _ _ _ 223 | | | | | | | | 224 |classifier|-----1-| C1 |-3-------1-| C2 |-3------|Egress| 225 |_ _ _ _ _ | |_ _ _| |_ _ _| |_ _ _ | 226 | | 227 2 2 228 | | 229 _|_ _|_ 230 | | | | 231 |SFF1| |SFF2| 232 | _ _| | _ _| 233 / \ / \ 234 / \ / \ 235 _/_ _\_ _/_ _\_ 236 |SF1| |SF2| |SF3| |SF4| 237 |_ _| |_ _| |_ _| |_ _| 239 Figure 1: A simple topology with two SFFs and two transport 240 switches/routers. 242 2.2 SRR 244 In [Purka2018], an extension to the Service Function Chaining (SFC) 245 concept is being proposed for a flexible chaining of service 246 functions in an SFC environment, where a number of virtual instances 247 for a single service function might exist. Hence, instead of 248 explicitly (re-)chaining a given SFC in order to utilize a new 249 virtual instance for an existing SF, a special service function 250 called SRR (service request routing) is utilized to direct the 251 requests via a URL-based abstraction (here, www.foo.com) for the SF 252 address. As a first step, the work in [Purka2018] proposes to extend 253 the notion of the service function path (SFP) to include such URLs in 254 addition to already defined Ethernet or IP addresses. This is shown 255 in Figure 2. Here the SFP includes the URLs of the service functions 256 1 to N (i.e., www.foo.com to www.fooN.com) as well as link-local IP 257 addresses being used for forwarding at the local access (here shown 258 as simple 192.168.x.x IP addresses). The creation of a suitable SFP 259 is assumed to be part of an orchestration process, which is not 260 within the scope of the SFC framework per se. 262 The SRR service function in Figure 2 can be further divided into sub- 263 functions for realizing the dynamic chaining capabilities, as shown 264 in [Purka2018]. Here, the service functions (such as clients and SF1 265 in Figure 2) communicate with local NAPs (network attachment points), 266 while the latter communicate with the PCE (path computation element) 267 to realize the IP and HTTP-level communication. In this case, the 268 incoming NAP is denoted as the client NAP (cNAP) and the outgoing NAP 269 as server NAP (sNAP). The Layer 2 transport is realized via the tSFF1 270 function (transport-derived service function forwarder). Here we 271 assume that each service function is connected to an own NAP (via 272 link-local IP communication) although one or more service functions 273 could also reside at a single NAP. 275 +--------+ 276 | | 277 |-------------------|-------------+ SRR + <-------------| 278 | | | | | 279 | | +---/|\--+ | 280 | | | | 281 +--\|/--+ +----+ +-\|/-+ +----+ +--+--+ +----+ +--+--+ 282 | | | | | | | | | | | | | | 283 +Client +-->+SRR +-->+ SF1 +-->+SRR +-->+ SF2 +-->+SRR |-->| SFn | 284 | | | | | | | | | | | | | | 285 +-------+ +----+ +-----+ +----+ +-----+ +----+ +-----+ 287 Figure 2: Dynamic Chaining SFC, as proposed in [Purka2018]. SFP: 288 192.168.x.x -> www.foo.com -> 192.168.x.x -> www.foo2.com -> ... -> 289 www.fooN.com 290 As presented in [Purka2018], the hierarchical addressing presented in 291 Section 3.1.1 can be utilized for the realization of said tSFF1, 292 while other realizations could utilize SDN-based transport networks 293 or a BIER routing layer [RFC8279]. With this, the SRR service 294 function is placed in-between specific tSFFs (the three 295 aforementioned ones) and general service functions to be chained. 297 3 Optimized SFC Chaining 299 3.1 Utilizing Transport-derived SFFs 301 Our model retains the architectural behavior of the SFC architecture 302 of [RFC7665]. Yet, the SFC and the transport encapsulation are merged 303 into the transport header. Thus everything, both transport and 304 service plane forwarding, is happening based on transport 305 encapsulation bits. The model builds on the edge node classification 306 presented in Section 2.1 and comes in two flavors. The first one 307 (Section 3.1.1) treats SFFs as edge nodes. The second one (Section 308 3.1.2) assigns fictitious edge nodes to entire service chains. In 309 both cases, the key points are how we identify the service chains, 310 and related to that, how we embed these identifiers into the 311 available address space. 313 3.1.1 Hierarchical addressing for service chaining 315 This approach treats SFFs as edge nodes. The set of SFFs, as points 316 of attachment of SFs, is normally static, known in advance in a 317 network. In that sense, SFFs do not impose any stronger requirements 318 than edge nodes, so the approach presented next looks viable. 320 The hierarchical service chain addressing works with the address 321 structure (IDSFF.IDSF.SPI), in which IDSFF identifies an SFF in the 322 network, IDSF identifies an SF attached to that SFF, while SPI is the 323 Service Path Identifier as defined in [RFC8300]. Note that SFs can be 324 attached to multiple SFFs, i.e. the approach is not limiting in this 325 sense. It is rather obvious that multiple SFs can be attached to a 326 single SFF. 328 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 329 | | / \ | | / \ | | / \ 330 |classifier|----| net |----|SFF1|----| net |----|SFF2|----| net | 331 |_ _ _ _ _ | \_ _/ |_ _ | \_ _/ |_ _ | \_ _/ 332 / \ / \ 333 / \ / \ 334 _/_ _\_ _/_ _\_ 335 |SF1| |SF2| |SF3| |SF4| 336 |_ _| |_ _| |_ _| |_ _| 338 Figure 3: a service chain of SF1-SF2-SF3 is considered in this 339 example. 341 See Figure 3 for an example. Assume that the edge nodes in the shown 342 network are SFF1 and SFF2 (with possibly many other nodes which are 343 not shown), while the service functions SF1, ..., SF4 are considered 344 end nodes, i.e. they are not edge nodes as such do not underlie 345 classification. (Note that this will be changed in Section 3.1.2.). 346 Assume that the classification yields the locators (IDs) IDSFF1 and 347 IDSFF2 for SFF1, respectively SFF2, and that SPI is assigned to the 348 service path. The service chain SF1-SF2-SF3 can operate as follows. 350 The classifier first adds the outer transport header with the 351 destination address (IDSFF1.IDSF1.SPI). The network uses the IDSFF1 352 bitfield to route the packet to SFF1. SFF1 uses the middle part of 353 the address, IDSF1, to deliver the packet to SF1. SF1, being SFC- 354 aware, strips off the transport header and saves it, then processes 355 the packet and, after restoring the saved transport header, sends it 356 back to SFF1. SFF1 changes the transport header destination address 357 to (IDSFF1.IDSF2.SPI) and forwards the packet to SF2. SF2 performs 358 similar steps as SF1 and returns the packet to SFF1. SFF1 changes the 359 transport header to (IDSFF2.IDSF3.SPI) and sends the packet towards 360 SFF2. (In an SDN network, switches can manipulate with the headers by 361 means of suitable flow rules, which should match on the (IDSF.SPI) 362 fraction of the destination address. A second pass through the SDN 363 processing stack will select the appropriate port to send the packet 364 towards SFF2.). SFF2 performs the very same sequence of steps to 365 deliver the packet to the correct SF and then further to the 366 network. 368 Note the role of the (SPI) part of the address. It serves to 369 differentiate between different service chains that pass a single SF. 370 For example, if in addition to SF1-SF3 there is a service chain SF1- 371 SF5, where SF5 is attached to SFF3, SFF1 will use the (SPI) to 372 forward packets coming from SF1. For chains such as SF1-SF2-SF1 and 373 SF1-SF2-SF2, where a specific SF is visited multiple times, SI 374 (Service Index as defined in [RFC8300]) must be included in the 375 address. SFFs should then match on (IDSF2.SPI.SI) part of the address 376 to determine appropriate action after receiving the packet back from 377 an SF. (Note that SI should be modified after being processed by an 378 SF, either by the SF or by the SFF). 380 3.1.2 Edge classification and service chains 382 Continuing with the classification discussion from Section 3.1.1, let 383 us assign a fictitious edge node to a service chain under 384 consideration. More precisely, let us assign one such node to every 385 subsequence of the chain that starts at each possible position in the 386 chain and goes until its end. For example, for a chain SF1-SF2-SF3, 387 define three such nodes for sub-chains SF1-SF2-SF3, SF2-SF3 and SF3. 388 Let locators of these fictitious edge nodes be the SFs that start the 389 corresponding sub-chains. So, in the example, the locators are SF1, 390 SF2 and SF3. If we had another chain that goes over SF1, then we 391 would simply add another node, say SF1', and attach it to SFF1, next 392 to SF1. This is to indicate that we need a distinct locator for each 393 chain that goes over SF1. So we now have the starting network and 394 additional imaginary edge nodes which topologically coincide with 395 existing service functions but require additional, separate 396 classification vectors. 398 Assume that, after the classification as described in Section 3.1.1, 399 we generate locators (classification vectors) IDSF1, IDSF2 and IDSF3 400 for the chain SF1-SF2-SF3 and setup rules (e.g. OpenFlow compliant) 401 that: 403 At SFF1: 405 Forward to SF1 packets with destination IDSF1, that come from 406 the network. 408 Replace IDSF1 with IDSF2 and then forward to SF2 packet that 409 arrive from SF1. 411 Replace IDSF2 with IDSF3 and then forward to SFF2. 413 At SFF2: 415 Forward to SF3 packets with destination IDSF3 that come from the 416 network. 418 We can distinguish between the packets that are received from the 419 network and those received from SFs by using the inport information. 421 3.2 Pre-Warming SFP Information for SRR-based Chaining 423 One issue when chaining service functions utilizing the SRR function 424 is the initial delay incurred through the necessary path computation 425 for a new service segment along the overall service function path. 426 For instance, when the service function 'client' residing at the 427 first SRR in Figure 2 issues a request to foo.com, i.e., the URL for 428 the second service function, the NAP sub-function will trigger a PCE 429 request for path resolution within the Layer 2 transport network. 430 Such PCE request incurs said delay for the initial request while all 431 subsequent requests along the same path are likely going to use 432 locally cached information at the SRR function (we here assume but do 433 not detail suitable path information update procedures being 434 implemented by the SRR sub-functions in case of path changes to 435 another service function). 437 It is reasonable to assume that SFPs can be established across the 438 realm of more than one PCE, e.g., each administering one 439 administrative domain. However, in the case of a single PCE across a 440 number of SRR functions, Figure 2 can be redrawn as follows. 442 +--------+ 443 -----------| SRR |------------- 444 | +--------+ | 445 | | | 446 | | | 447 +------+ +------+ +-----+ +-----+ 448 | SF1 | | SF2 |----| SRR |---| SFn | 449 +------+ +------+ +-----+ +-----+ 450 | | 451 +-------------------|-------------|---------+ 452 | | | | 453 +-------+ | +-------+ +--------+ +--------+ | 454 |Client |-----| NAP1 | | NAP2 | | NAP3 | | 455 +-------+ | +-------+ +--------+ +--------+ | 456 | \ | / | 457 | \ | / | 458 | \ +-------+ / | 459 | \-------| tSFF1 |---- | 460 | +-------+ | 461 | | | 462 | | | 463 | +-------+ | 464 | | PCE | | 465 | +-------+ | 466 +-------------------------------------------+ 468 Figure 4. Decomposed Dynamic Chaining SFC across two or more SFCs. 470 Here, two SRR functions utilize the same PCE, e.g., within a single 471 transport network. In this case, we propose to reduce such initial 472 chaining delay by virtue of a 'pre-warming' of the SRR sub-functions, 473 specifically the incoming NAP at the suitable SRR along the SFP. For 474 this, we require a communication of the NSH and therefore the SFP 475 information to the PCE - such communication is subject to a 476 standardized protocol based on a trigger that led to the formation of 477 said SFP, as shown in Figure 4. Once such SFP information has been 478 received by the PCE, it then executes the following procedure. 480 FOR ALL SF requests routed via an SRR served by the PCE: 482 1. Determine the incoming NAP of the first SF request, e.g., 483 192.168.x.x in Figure 2. 485 2. Determine the outgoing NAP of the service endpoint address at 486 the outgoing SF, e.g., www.foo.com in Figure 2. 488 3. Compute path between incoming NAP and outgoing NAP - path 489 computation might include a policy constraint, such as shortest 490 path or shortest delay. 492 4. Deliver path information to incoming NAP. 494 END FOR 496 Figure 5 outlines the messages being exchanged between the joint PCE 497 and the various NAPs of the SRR function. The exact nature of the 498 messages is subject to standardization and not shown at this stage of 499 the draft. 501 Trigger PCE NAP1 NAP2 NAP3 502 | | | | | 503 | |<----a----| | | 504 | |<-----------a---------| | 505 | |<-----------------------a-------| 506 | | | | | 507 --b-->|\ | | | | 508 | c | | | | 509 |/ | | | | 510 |------d----->|\ | | | 511 | | e | | | 512 | |/ | | | 513 | |----f---->| | | 514 | |------------f-------->| | 515 | |--------------------------f---->| 516 | | | | | 518 Figure 5. Message Sequence Chart Resulting in Pre-Warming of Routing 519 Entries. a) subscribe to pre-warming information, b)initiate service 520 chaining based on external mgmt. trigger, c) compute SFP, d) send 521 SFP, e) map SFP information onto paths from incoming to ongoing NAPs, 522 f) push path information with forwarding/path identifier and URL. 524 4 Applicability 526 This draft investigates whether transport encapsulation can be used 527 for service function chaining. The main message it delivers is that 528 this seems possible. This was demonstrated on an example of 529 underlying SDN network. However, we are not normative here with 530 respect to what transport encapsulation and which bits thereof are 531 used for service function chaining, i.e. which existing transport 532 encapsulations give us the needed features (e.g. said assignment of 533 transport identifiers and their handling at transport nodes) to 534 successfully incorporate service chaining. This will be a subject of 535 future investigations. 537 5 Discussion 539 Transport-derived SFC forwarding is related to a number of 540 advantages. In particular, easier deployment of service chaining, as 541 SFs and SFFs in a transport-derived chaining do not have to be SFC 542 encapsulation aware. Moreover, the transport network configuration 543 and service chaining can be optimized to reduce initial request 544 latency. 546 For the SDN-based solution, the transport network was pre-configured, 547 to provide communication among the edge nodes. It performs as an 548 fabric switch that transfers a packet received on one port to another 549 port. To serve a chain, we therefore need to only provide 550 policy/mapping information at edge nodes (e.g. SFFs in the solution 551 proposed in Section 3.1.1), reducing the initial request latency. 552 Pre-warming approaches, as explained in Section 3.2, can be applied 553 to further reduce this latency when SRR-based chaining is used. 555 Furthermore, in this draft, we assume that the SFP for a packet is 556 already known (e.g. decided by the central controller in an SDN 557 setting) and hence the question is how to realize such path. Our 558 solutions however can be extended to a more general setting, where 559 the SFP is not known 'a priori' but decided step by step by SFFs 560 along the path. The policy is therefore performed in a distributed 561 manner. [Despotovic19] has provided some insight to such system and 562 possible benefits. 564 6 Informative References 566 [RFC7498] P. Quinn, et al., "Problem Statement for Service 567 Function Chaining", RFC 7498 (INFORMATIONAL), April 568 2015. 570 [RFC7665] Joel Halpern, et al., "Service Function Chaining 571 (SFC) Architecture", RFC 7665 (INFORMATIONAL), 572 October 2015. 574 [RFC8300] P. Quinn, et al., "Network Service Header", RFC 8300, 575 January 2018. 577 [Guichard2018] J. Guichard, et al., "Network Service Header (NSH) MD 578 Type 1: Context Header Allocation (Data Center)", 579 IETF draft, draft-ietf-sfc-nsh-dc-allocation-02 (work 580 in progress), September 2018. 582 [Khalili2016] R. Khalili, et al., "Reducing State of OpenFlow 583 Switches in Mobile Core Networks by Flow Rule 584 Aggregation" IEEE ICCCN 2016. 586 [Purka2018] Purkayastha, e. al., "Alternative Handling of Dynamic 587 Chaining and Service Indirection", IETF draft, draft- 588 purkayastha-sfc-service-indirection-02 (work in 589 progress), March 2018. 591 [RFC8279] IJ. Wijnands, et al., "Multicast using Bit Index 592 Explicit Replication", RFC8279, November 2017 594 [Farrel2019] A. Farrel et al., "An MPLS-Based Forwarding Plane for 595 Service Function Chaining", IETF draft, draft-ietf- 596 mpls-sfc-05 (work in progress), February 2019 598 [TS22.261] 3GPP, "Service requirements for the 5G system; Stage 599 1," 3GPP, Technical Specification (TS) 22.261, 600 September 2017, version 15.2.0. 602 [Despotovic19] Z. Despotovic, et al. "Dynamic and Scalable Control 603 as a Foundation for Future Networks", Book chapter, 604 Emerging Automation Techniques for the Future 605 Internet, p. 208-230, 2019 607 Authors' Addresses 609 Ramin Khalili 610 Huawei ERC 611 Munich, Germany 612 Email: Ramin.khalili@huawei.com 614 Zoran Despotovic 615 Huawei ERC 616 Munich, Germany 617 Email: Zoran.Despotovic@huawei.com 619 Artur Hecker 620 Huawei ERC 621 Munich, Germany 622 Email: Artur.Hecker@huawei.com 624 Debashish Purkayastha 625 InterDigital Communications, LLC 626 Conchoken, USA 627 Email: Debashish.Purkayastha@InterDigital.com 629 Akbar Rahman 630 InterDigital Communications, LLC 631 Montreal, Canada 632 Email: Akbar.Rahman@InterDigital.com 634 Dirk Trossen 635 InterDigital Communications, LLC 636 London, United Kingdom 637 Email: Dirk.Trossen@InterDigital.com