idnits 2.17.1 draft-khalili-sfc-optimized-chaining-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (August 30, 2019) is 1673 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 210 == Missing Reference: 'K' is mentioned on line 210, but not defined Summary: 3 errors (**), 0 flaws (~~), 5 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: March 2, 2020 Huawei ERC, Munich, Germany 6 D. Purkayastha 7 A. Rahman 8 D. Trossen 9 InterDigital Communications, LLC 10 August 30, 2019 12 Optimized Service Function Chaining 13 draft-khalili-sfc-optimized-chaining-03 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 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 We showed in [khalili2018] that applying such aggregation at core can 187 radically simplify procedures such as flow setup and mobility 188 management: as the core switches are proactively configured, 189 providing connectivity among all edge switches, the individual flows 190 can be processed at the ingress edge switches, from where they are 191 forwarded through pre-configured fabric pipes to the egress edge 192 switches. This minimizes the set of switches to be updated for new 193 user initiated, or mobile, flows to a constant number, providing 194 guarantees on latency requirements (e.g. below 10ms in large 195 settings) while still supporting fine-grained flow management. In 196 this draft, we extend the context to service function chaining 197 procedure. 199 2.1.1 Example 201 Consider a simple network with an ingress (classifier) and an egress 202 node, two transport switches/routers C1 and C2, and two service 203 function forwarders, SFF1 and SFF2 (as depicted in Figure 1). Service 204 functions SF1 and SF2 are attached to SFF1 and SF3 and SF4 are 205 attached to SFF2. In this example, we assume that edge nodes are 206 SFF1, SFF2, and the egress node. 208 The ASC algorithm proposed in [Khalili2016] assigns to an edge node 209 in the network an ID of the form (v(1), v(2), ..., v(K)), where v(j), 210 j\in[1, K], being 1 if there is a path crossing link j that ends in 211 the corresponding edge node, and 0 otherwise. K is the size of IDs 212 assigned to edge nodes and is an output of the algorithm. 214 Applying ASC algorithm to our example, we have: 216 IDSFF1 = (0, 1, 1, 0, 0), 218 IDSFF2 = (1, 0, 0, 1, 0), 220 IDEgress = (1, 0, 0, 0, 1). 222 Assuming that the destination-edge IDs are embedded in the header of 223 the packets, e.g. via encapsulation, the forwarding rules at C1 and 224 C2 can be aggregated by matching on bits of these IDs: 226 At C1: if 1st bit is 1, forward over port 3; if 2nd bit is 1, 227 forward over port 2. 229 At C2: if 3rd bit is 1, forward over port 1, if 4th bit is 1, 230 forward over port 2, if 5th bit is 1, forward over port 3. 232 Note from this example that each edge node has a unique ID and that 233 we put no limitation on how SFCs are defined. 235 _ _ _ _ _ _ _ _ _ _ _ _ _ _ 236 | | | | | | | | 237 |classifier|-----1-| C1 |-3-------1-| C2 |-3------|Egress| 238 |_ _ _ _ _ | |_ _ _| |_ _ _| |_ _ _ | 239 | | 240 2 2 241 | | 242 _|_ _|_ 243 | | | | 244 |SFF1| |SFF2| 245 | _ _| | _ _| 246 / \ / \ 247 / \ / \ 248 _/_ _\_ _/_ _\_ 249 |SF1| |SF2| |SF3| |SF4| 250 |_ _| |_ _| |_ _| |_ _| 252 Figure 1: A simple topology with two SFFs and two transport 253 switches/routers. 255 2.2 SRR 257 In [Purka2018], an extension to the Service Function Chaining (SFC) 258 concept is being proposed for a flexible chaining of service 259 functions in an SFC environment, where a number of virtual instances 260 for a single service function might exist. Hence, instead of 261 explicitly (re-)chaining a given SFC in order to utilize a new 262 virtual instance for an existing SF, a special service function 263 called SRR (service request routing) is utilized to direct the 264 requests via a URL-based abstraction (here, www.foo.com) for the SF 265 address. As a first step, the work in [Purka2018] proposes to extend 266 the notion of the service function path (SFP) to include such URLs in 267 addition to already defined Ethernet or IP addresses. This is shown 268 in Figure 2. Here the SFP includes the URLs of the service functions 269 1 to N (i.e., www.foo.com to www.fooN.com) as well as link-local IP 270 addresses being used for forwarding at the local access (here shown 271 as simple 192.168.x.x IP addresses). The creation of a suitable SFP 272 is assumed to be part of an orchestration process, which is not 273 within the scope of the SFC framework per se. 275 The SRR service function in Figure 2 can be further divided into sub- 276 functions for realizing the dynamic chaining capabilities, as shown 277 in [Purka2018]. Here, the service functions (such as clients and SF1 278 in Figure 2) communicate with local NAPs (network attachment points), 279 while the latter communicate with the PCE (path computation element) 280 to realize the IP and HTTP-level communication. In this case, the 281 incoming NAP is denoted as the client NAP (cNAP) and the outgoing NAP 282 as server NAP (sNAP). The Layer 2 transport is realized via the tSFF1 283 function (transport-derived service function forwarder). Here we 284 assume that each service function is connected to an own NAP (via 285 link-local IP communication) although one or more service functions 286 could also reside at a single NAP. 288 +--------+ 289 | | 290 |-------------------|-------------+ SRR + <-------------| 291 | | | | | 292 | | +---/|\--+ | 293 | | | | 294 +--\|/--+ +----+ +-\|/-+ +----+ +--+--+ +----+ +--+--+ 295 | | | | | | | | | | | | | | 296 +Client +-->+SRR +-->+ SF1 +-->+SRR +-->+ SF2 +-->+SRR |-->| SFn | 297 | | | | | | | | | | | | | | 298 +-------+ +----+ +-----+ +----+ +-----+ +----+ +-----+ 300 Figure 2: Dynamic Chaining SFC, as proposed in [Purka2018]. SFP: 301 192.168.x.x -> www.foo.com -> 192.168.x.x -> www.foo2.com -> ... -> 302 www.fooN.com 304 As presented in [Purka2018], the hierarchical addressing presented in 305 Section 3.1.1 can be utilized for the realization of said tSFF1, 306 while other realizations could utilize SDN-based transport networks 307 or a BIER routing layer [RFC8279]. With this, the SRR service 308 function is placed in-between specific tSFFs (the three 309 aforementioned ones) and general service functions to be chained. 311 3 Optimized SFC Chaining 313 3.1 Utilizing Transport-derived SFFs 315 Our model retains the architectural behavior of the SFC architecture 316 of [RFC7665]. Yet, the SFC and the transport encapsulation are merged 317 into the transport header. Thus everything, both transport and 318 service plane forwarding, is happening based on transport 319 encapsulation bits. The model builds on the edge node classification 320 presented in Section 2.1 and comes in two flavors. The first one 321 (Section 3.1.1) treats SFFs as edge nodes. The second one (Section 322 3.1.2) assigns fictitious edge nodes to entire service chains. In 323 both cases, the key points are how we identify the service chains, 324 and related to that, how we embed these identifiers into the 325 available address space. 327 3.1.1 Hierarchical addressing for service chaining 329 This approach treats SFFs as edge nodes. The set of SFFs, as points 330 of attachment of SFs, is normally static, known in advance in a 331 network. In that sense, SFFs do not impose any stronger requirements 332 than edge nodes, so the approach presented next looks viable. 334 The hierarchical service chain addressing works with the address 335 structure (IDSFF.IDSF.SPI), in which IDSFF identifies an SFF in the 336 network, IDSF identifies an SF attached to that SFF, while SPI is the 337 Service Path Identifier as defined in [RFC8300]. Note that SFs can be 338 attached to multiple SFFs, i.e. the approach is not limiting in this 339 sense. It is rather obvious that multiple SFs can be attached to a 340 single SFF. 342 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 343 | | / \ | | / \ | | / \ 344 |classifier|----| net |----|SFF1|----| net |----|SFF2|----| net | 345 |_ _ _ _ _ | \_ _/ |_ _ | \_ _/ |_ _ | \_ _/ 346 / \ / \ 347 / \ / \ 348 _/_ _\_ _/_ _\_ 349 |SF1| |SF2| |SF3| |SF4| 350 |_ _| |_ _| |_ _| |_ _| 352 Figure 3: a service chain of SF1-SF2-SF3 is considered in this 353 example. 355 See Figure 3 for an example. Assume that the edge nodes in the shown 356 network are SFF1 and SFF2 (with possibly many other nodes which are 357 not shown), while the service functions SF1, ..., SF4 are considered 358 end nodes, i.e. they are not edge nodes as such do not underlie 359 classification. (Note that this will be changed in Section 3.1.2.). 360 Assume that the classification yields the locators (IDs) IDSFF1 and 361 IDSFF2 for SFF1, respectively SFF2, and that SPI is assigned to the 362 service path. The service chain SF1-SF2-SF3 can operate as follows. 364 The classifier first adds the outer transport header with the 365 destination address (IDSFF1.IDSF1.SPI). The network uses the IDSFF1 366 bitfield to route the packet to SFF1. SFF1 uses the middle part of 367 the address, IDSF1, to deliver the packet to SF1. SF1, being SFC- 368 aware, strips off the transport header and saves it, then processes 369 the packet and, after restoring the saved transport header, sends it 370 back to SFF1. SFF1 changes the transport header destination address 371 to (IDSFF1.IDSF2.SPI) and forwards the packet to SF2. SF2 performs 372 similar steps as SF1 and returns the packet to SFF1. SFF1 changes the 373 transport header to (IDSFF2.IDSF3.SPI) and sends the packet towards 374 SFF2. (In an SDN network, switches can manipulate with the headers by 375 means of suitable flow rules, which should match on the (IDSF.SPI) 376 fraction of the destination address. A second pass through the SDN 377 processing stack will select the appropriate port to send the packet 378 towards SFF2.). SFF2 performs the very same sequence of steps to 379 deliver the packet to the correct SF and then further to the 380 network. 382 Note the role of the (SPI) part of the address. It serves to 383 differentiate between different service chains that pass a single SF. 384 For example, if in addition to SF1-SF3 there is a service chain SF1- 385 SF5, where SF5 is attached to SFF3, SFF1 will use the (SPI) to 386 forward packets coming from SF1. For chains such as SF1-SF2-SF1 and 387 SF1-SF2-SF2, where a specific SF is visited multiple times, SI 388 (Service Index as defined in [RFC8300]) must be included in the 389 address. SFFs should then match on (IDSF2.SPI.SI) part of the address 390 to determine appropriate action after receiving the packet back from 391 an SF. (Note that SI should be modified after being processed by an 392 SF, either by the SF or by the SFF). 394 3.1.2 Edge classification and service chains 396 Continuing with the classification discussion from Section 3.1.1, let 397 us assign a fictitious edge node to a service chain under 398 consideration. More precisely, let us assign one such node to every 399 subsequence of the chain that starts at each possible position in the 400 chain and goes until its end. For example, for a chain SF1-SF2-SF3, 401 define three such nodes for sub-chains SF1-SF2-SF3, SF2-SF3 and SF3. 402 Let locators of these fictitious edge nodes be the SFs that start the 403 corresponding sub-chains. So, in the example, the locators are SF1, 404 SF2 and SF3. If we had another chain that goes over SF1, then we 405 would simply add another node, say SF1', and attach it to SFF1, next 406 to SF1. This is to indicate that we need a distinct locator for each 407 chain that goes over SF1. So we now have the starting network and 408 additional imaginary edge nodes which topologically coincide with 409 existing service functions but require additional, separate 410 classification vectors. 412 Assume that, after the classification as described in Section 3.1.1, 413 we generate locators (classification vectors) IDSF1, IDSF2 and IDSF3 414 for the chain SF1-SF2-SF3 and setup rules (e.g. OpenFlow compliant) 415 that: 417 At SFF1: 419 Forward to SF1 packets with destination IDSF1, that come from 420 the network. 422 Replace IDSF1 with IDSF2 and then forward to SF2 packet that 423 arrive from SF1. 425 Replace IDSF2 with IDSF3 and then forward to SFF2. 427 At SFF2: 429 Forward to SF3 packets with destination IDSF3 that come from the 430 network. 432 We can distinguish between the packets that are received from the 433 network and those received from SFs by using the inport information. 435 3.2 Pre-Warming SFP Information for SRR-based Chaining 437 One issue when chaining service functions utilizing the SRR function 438 is the initial delay incurred through the necessary path computation 439 for a new service segment along the overall service function path. 440 For instance, when the service function 'client' residing at the 441 first SRR in Figure 2 issues a request to foo.com, i.e., the URL for 442 the second service function, the NAP sub-function will trigger a PCE 443 request for path resolution within the Layer 2 transport network. 444 Such PCE request incurs said delay for the initial request while all 445 subsequent requests along the same path are likely going to use 446 locally cached information at the SRR function (we here assume but do 447 not detail suitable path information update procedures being 448 implemented by the SRR sub-functions in case of path changes to 449 another service function). 451 It is reasonable to assume that SFPs can be established across the 452 realm of more than one PCE, e.g., each administering one 453 administrative domain. However, in the case of a single PCE across a 454 number of SRR functions, Figure 2 can be redrawn as follows. 456 +--------+ 457 -----------| SRR |------------- 458 | +--------+ | 459 | | | 460 | | | 461 +------+ +------+ +-----+ +-----+ 462 | SF1 | | SF2 |----| SRR |---| SFn | 463 +------+ +------+ +-----+ +-----+ 464 | | 465 +-------------------|-------------|---------+ 466 | | | | 467 +-------+ | +-------+ +--------+ +--------+ | 468 |Client |-----| NAP1 | | NAP2 | | NAP3 | | 469 +-------+ | +-------+ +--------+ +--------+ | 470 | \ | / | 471 | \ | / | 472 | \ +-------+ / | 473 | \-------| tSFF1 |---- | 474 | +-------+ | 475 | | | 476 | | | 477 | +-------+ | 478 | | PCE | | 479 | +-------+ | 480 +-------------------------------------------+ 482 Figure 4. Decomposed Dynamic Chaining SFC across two or more SFCs. 484 Here, two SRR functions utilize the same PCE, e.g., within a single 485 transport network. In this case, we propose to reduce such initial 486 chaining delay by virtue of a 'pre-warming' of the SRR sub-functions, 487 specifically the incoming NAP at the suitable SRR along the SFP. For 488 this, we require a communication of the NSH and therefore the SFP 489 information to the PCE - such communication is subject to a 490 standardized protocol based on a trigger that led to the formation of 491 said SFP, as shown in Figure 4. Once such SFP information has been 492 received by the PCE, it then executes the following procedure. 494 FOR ALL SF requests routed via an SRR served by the PCE: 496 1. Determine the incoming NAP of the first SF request, e.g., 497 192.168.x.x in Figure 2. 499 2. Determine the outgoing NAP of the service endpoint address at 500 the outgoing SF, e.g., www.foo.com in Figure 2. 502 3. Compute path between incoming NAP and outgoing NAP - path 503 computation might include a policy constraint, such as shortest 504 path or shortest delay. 506 4. Deliver path information to incoming NAP. 508 END FOR 510 Figure 5 outlines the messages being exchanged between the joint PCE 511 and the various NAPs of the SRR function. The exact nature of the 512 messages is subject to standardization and not shown at this stage of 513 the draft. 515 Trigger PCE NAP1 NAP2 NAP3 516 | | | | | 517 | |<----a----| | | 518 | |<-----------a---------| | 519 | |<-----------------------a-------| 520 | | | | | 521 --b-->|\ | | | | 522 | c | | | | 523 |/ | | | | 524 |------d----->|\ | | | 525 | | e | | | 526 | |/ | | | 527 | |----f---->| | | 528 | |------------f-------->| | 529 | |--------------------------f---->| 530 | | | | | 532 Figure 5. Message Sequence Chart Resulting in Pre-Warming of Routing 533 Entries. a) subscribe to pre-warming information, b)initiate service 534 chaining based on external mgmt. trigger, c) compute SFP, d) send 535 SFP, e) map SFP information onto paths from incoming to ongoing NAPs, 536 f) push path information with forwarding/path identifier and URL. 538 4 Applicability 540 This draft investigates whether transport encapsulation can be used 541 for service function chaining. The main message it delivers is that 542 this seems possible. This was demonstrated on an example of 543 underlying SDN network. However, we are not normative here with 544 respect to what transport encapsulation and which bits thereof are 545 used for service function chaining, i.e. which existing transport 546 encapsulations give us the needed features (e.g. said assignment of 547 transport identifiers and their handling at transport nodes) to 548 successfully incorporate service chaining. This will be a subject of 549 future investigations. 551 5 Discussion 553 Transport-derived SFC forwarding is related to a number of 554 advantages. In particular, easier deployment of service chaining, as 555 SFs and SFFs in a transport-derived chaining do not have to be SFC 556 encapsulation aware. Moreover, the transport network configuration 557 and service chaining can be optimized to reduce initial request 558 latency. 560 For the SDN-based solution, the transport network was pre-configured, 561 to provide communication among the edge nodes. It performs as an 562 fabric switch that transfers a packet received on one port to another 563 port. To serve a chain, we therefore need to only provide 564 policy/mapping information at edge nodes (e.g. SFFs in the solution 565 proposed in Section 3.1.1), reducing the initial request latency. 566 Pre-warming approaches, as explained in Section 3.2, can be applied 567 to further reduce this latency when SRR-based chaining is used. 569 Furthermore, in this draft, we assume that the SFP for a packet is 570 already known (e.g. decided by the central controller in an SDN 571 setting) and hence the question is how to realize such path. Our 572 solutions however can be extended to a more general setting, where 573 the SFP is not known 'a priori' but decided step by step by SFFs 574 along the path. The policy is therefore performed in a distributed 575 manner. [Despotovic19] has provided some insight to such system and 576 possible benefits. 578 6 Informative References 580 [RFC7498] P. Quinn, et al., "Problem Statement for Service 581 Function Chaining", RFC 7498 (INFORMATIONAL), April 582 2015. 584 [RFC7665] Joel Halpern, et al., "Service Function Chaining 585 (SFC) Architecture", RFC 7665 (INFORMATIONAL), 586 October 2015. 588 [RFC8300] P. Quinn, et al., "Network Service Header", RFC 8300, 589 January 2018. 591 [Guichard2018] J. Guichard, et al., "Network Service Header (NSH) MD 592 Type 1: Context Header Allocation (Data Center)", 593 IETF draft, draft-ietf-sfc-nsh-dc-allocation-02 (work 594 in progress), September 2018. 596 [Khalili2016] R. Khalili, et al., "Reducing State of OpenFlow 597 Switches in Mobile Core Networks by Flow Rule 598 Aggregation" IEEE ICCCN 2016. 600 [khalili2018] R. Khalili, et al., "Flow setup latency in SDN 601 networks", at IEEE Journal on Selected Areas in 602 Communications, Volume: 36 , Issue: 12 , Dec. 2018 604 [Purka2018] Purkayastha, e. al., "Alternative Handling of Dynamic 605 Chaining and Service Indirection", IETF draft, draft- 606 purkayastha-sfc-service-indirection-02 (work in 607 progress), March 2018. 609 [RFC8279] IJ. Wijnands, et al., "Multicast using Bit Index 610 Explicit Replication", RFC8279, November 2017 612 [Farrel2019] A. Farrel et al., "An MPLS-Based Forwarding Plane for 613 Service Function Chaining", IETF draft, draft-ietf- 614 mpls-sfc-07 (work in progress), March 2019 616 [TS22.261] 3GPP, "Service requirements for the 5G system; Stage 617 1," 3GPP, Technical Specification (TS) 22.261, 618 September 2017, version 15.2.0. 620 [Despotovic19] Z. Despotovic, et al. "Dynamic and Scalable Control 621 as a Foundation for Future Networks", Book chapter, 622 Emerging Automation Techniques for the Future 623 Internet, p. 208-230, 2019 625 Authors' Addresses 627 Ramin Khalili 628 Huawei ERC 629 Munich, Germany 630 Email: Ramin.khalili@huawei.com 632 Zoran Despotovic 633 Huawei ERC 634 Munich, Germany 635 Email: Zoran.Despotovic@huawei.com 637 Artur Hecker 638 Huawei ERC 639 Munich, Germany 640 Email: Artur.Hecker@huawei.com 642 Debashish Purkayastha 643 InterDigital Communications, LLC 644 Conchoken, USA 645 Email: Debashish.Purkayastha@InterDigital.com 647 Akbar Rahman 648 InterDigital Communications, LLC 649 Montreal, Canada 650 Email: Akbar.Rahman@InterDigital.com 652 Dirk Trossen 653 InterDigital Communications, LLC 654 London, United Kingdom 655 Email: Dirk.Trossen@InterDigital.com