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