idnits 2.17.1 draft-barkai-lisp-nfv-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 41 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 has text resembling RFC 2119 boilerplate text. -- The document date (July 02, 2013) is 3950 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6830' is defined on line 639, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group S. Barkai 3 Internet-Draft ConteXtream Inc. 4 Intended status: Experimental D. Farinacci 5 Expires: January 03, 2014 6 D. Meyer 8 F. Maino 9 V. Ermagan 10 Cisco Systems 11 July 02, 2013 13 LISP Based FlowMapping for Scaling NFV 14 draft-barkai-lisp-nfv-02 16 Abstract 18 This draft describes an RFC 6830 Locator ID Separation Protocol 19 (LISP) based distributed flow-mapping-fabric for dynamic scaling of 20 virtualized network functions (NFV). Network functions such as 21 subscriber-management, content-optimization, security and quality of 22 service, are typically delivered using proprietary hardware 23 appliances embedded into the network as turn-key service-nodes or 24 service-blades within routers. Next generation network functions are 25 being implemented as pure software instances running on standard 26 servers - unbundled virtualized components of capacity and 27 functionality. LISP-SDN based flow-mapping, dynamically assembles 28 these components to whole solutions by steering the right traffic in 29 the right sequence to the right virtual function instance. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119] 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 03, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Connectivity Model . . . . . . . . . . . . . . . . . . . . . 4 74 4. Flow-Mapping Elements . . . . . . . . . . . . . . . . . . . . 7 75 5. Day-in-life of a Mapped Flow . . . . . . . . . . . . . . . . 8 76 5.1. XTR Flow Edge . . . . . . . . . . . . . . . . . . . . . . 9 77 5.2. Map Resolvers-Servers . . . . . . . . . . . . . . . . . . 11 78 5.3. XTRs-Mappers Scaling . . . . . . . . . . . . . . . . . . 11 79 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 80 7. QOS and Echo Measurements . . . . . . . . . . . . . . . . . . 14 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 This draft describes an RFC 6830 Locator ID Separation Protocol 90 (LISP) based distributed flow-mapping-fabric for dynamic scaling of 91 virtualized network functions (NFV).[RFC6830]Network functions such 92 as subscriber-management, content-optimization, security and quality 93 of service, are typically delivered using proprietary hardware 94 appliances embedded into the network as turn-key service-nodes or 95 service-blades within routers. 97 This monolithic service delivery method increases the complexity of 98 service roll-out and capacity planning, limits providers' choices, 99 and slows down revenue generating service innovation. Next 100 generation network functions are being implemented as pure software 101 instances running on standard servers - unbundled ("googlized") 102 virtualized components of capacity and functionality. Such a 103 component based model opens up service provider networks to the 104 savings of elasticity and open architecture driven innovation. 105 However this model also presents the network with the new challenges 106 of assembling components, developed by 3rd parties, into whole 107 solutions, by forwarding the right traffic to the right function- 108 block at the right sequence. 110 While this is possible, to some extent, by traditional virtual 111 networking - virtual bridges(vBridges) and virtual-routing-forwarding 112 (VRF) - these mechanisms are relatively static and require complex 113 and intensive configuration of network interfaces, while elastic 114 components are not network topology bound. Software-defined- 115 networks, (SDN) flow based models are much more dynamically 116 programmable but are also very centralized and hence have limited 117 scale and resiliency. By enhancing SDN models with RFC6830 overlay 118 model, as this specification suggests, we offer a best fit to dynamic 119 assembly of virtualized network functions in the service-providers 120 data-centers and distribution-centers. 122 2. Terminology 124 The following terms are used to describe a LISP based implementation 125 of Software-Defined Flow-Mapping-Fabric for NFV: 127 o LISP-SDN - is an enhancement to the basic SDN model of (1) hop-to- 128 hop (2) push-down flow-commands (3) by concentrated-controller.. 129 to a LISP based architecture of (1) distributed-overlay e.g. SDN 130 over IP (2) based on a pull-publish-subscribe actions from xTR- 131 edges up.. (3) to a global mapping service. A mapping service 132 scaled by and connected over the IP underlay network. 134 o Virtualized Network Function (VNF) - is a process instance with an 135 EID and RLOC that performs a defined set of inline network 136 functions. a VNF can be software on a virtual-machine (VM) 137 performing a function like multimedia signaling, mobility 138 management, content caching or streaming, security, filtering, 139 optimization, etc. A VNF class type and VNF instance capacity, 140 load, and location are attributes that can be resolved by the 141 LISP-SDN mapping service. 143 o Client-Flow - is a sequence of packets that corresponds to a 144 specific communication thread or network conversation between a 145 client application and a network service. Client-flows are 146 typically processed by various in-network functions either as the 147 end service side to the network conversation, or as middle-box 148 functionality. 150 o SDN-xTR - is a LISP xTR element that classifies traffic into 151 application flows, maps, encapsulates, and decapsulates flows in 152 order to emerge a flow-mapping solution - along with a collection 153 of the SDN-xTR elements, and the LISP-SDN mapping service. 155 o SDN-Overlay - is the network formed by the collection of inter- 156 connected SDN-xTR 158 o SDN-Underlay - is the IPvN network connecting SDN-xTRs 160 o SDN-Outerlay (interim name)- is the collection of networks and 161 interfaces aggregated by the various SDN-xTRs connecting VNFs and 162 Client-flows coming from access networks or the Internet. 164 o Flow-Rule - is a set of pattern tuples that match any part of a 165 packet header and is used to classify packets into flows as well 166 as trigger forwarding actions such as encapsulation / 167 decapsulation, network address translation (NAT), etc. We 168 differentiate between exact-match rules (many) which include an 169 exact set of tuple bits, and best match rules (fewer) which 170 contain both tuple bits and wild-cards "*". 172 o Virtual IP (VIP) - is an IP address or EID that identifies a 173 function rather then a specific destination. For example all the 174 encapsulated client-flow traffic sent from a base-station eNodeBs 175 over a transport network, can have as destination a VIP which 176 represents in a given LISP-SDN solution, the function mobile- 177 gateway or PGW, and not any specific destination. 179 o Flow-Affinity - is the association between a client-flow and a VNF 180 instance. VNF logic will typically create long-lived (minutes) in 181 memory states in order to perform its functions. Therefore once 182 an affinity is established it is best to keep it for as long as 183 possible in order not to stress or break the VNF application. 185 3. Connectivity Model 187 The basic connectivity model used to assemble VNFs into whole 188 solution is the flow-mapping-fabric. Unlike topological forwarding 189 which is based on source-subnet >> routed hop by hop >> destination- 190 subnet, a flow-mapping-fabric maps, forwards and "patches" flows by 191 identity directly to the end systems. The identities used for the 192 flow-mapping-fabric are those associated with the client-flows e.g. 194 Subscriber ID, phone number, TCP port, etc. and those associated with 195 the VNF e.g. the type, location, physical address, etc. the flow- 196 mapping-fabric is implemented as a LISP-SDN overlay, over in-place IP 197 underlay, assembling outerlay flows into solutions. Bellow are basic 198 assumptions regarding the Underlay, Outerlay, and Overlay in the 199 solution: 201 o The underlying physical network is assumed to be topology based 202 and implemented using standard bridging and routing. Conventional 203 design principles are applied in order to achieve both capacity 204 and availability of connectivity. Typical examples of underlays 205 include spine-leaf switching for clustering server racks, and, 206 core-edge routing inter-connecting server clusters across points 207 of presence. Edge networks are also used to connect to access 208 networks and Internet. 210 o The flow-mapping-fabric maps outerlay client-flows to VNFs. This 211 enables assembly, scaling, balanced high-utilization, massive 212 concurrency, and hence, performance of NFVs. By mapping each 213 client-flow to the correct functional instance the system engages 214 as many VNF components as are available, scaled within and across 215 data-centers. Applied recursively client-flow mapping can chain a 216 sequence of VNF components to make up an end-to-end service. 218 o The overlay network is based on location-identity-separation and 219 forms a virtualization indirection ring around spines and cores. 220 The overlay edges aggregate outerlay client-flows and VNFs. 221 Outerlay flows are classified, mapped, and encapsulated over the 222 edge through the underlay interfaces and are transported to the 223 right identity's locations. 225 POP3 POP4 226 \ / \ / 227 EdgeR -- EdgeRouter 228 | | 229 Access ... | Core | ... Internet 230 | | 231 EdgeR -- EdgeR 232 / \ 233 / \ 234 ^ Spine1 Spine2 ... Spine5 235 | / \ / \ __/ / .. | 236 | | \/ | __/ / | 237 P | /\ || / | 238 O Leaf1 Leaf2 ... Leaf300 239 P |-PC1 |-PC1 240 1 |-PC2 |-PC2 241 | |.. |.. 242 | |-PC40 |-PC40 243 v 245 Core-Edge Spine-Leaf Underlays 247 v << FunctionA FunctionB .. FunctionN 248 v 249 Recursion Instance1..i Instance1..j Instance1..k 250 v | | | | | | | | | | | | 251 v | | | | | | | | | | | | 252 SubsFlow1 o o o o - - -+ o o o - - -o o o o 253 | | | | | | | | | | | | 254 SubsFlow2 o + o o - - -o o o o - - -o o o o 255 | | | | | | | | | | | | 256 . ... ... ... 257 . ... ... ... 258 . ... ... ... 259 | | | | | | | | | | | | 260 SubsFlowM o o o o - - -o o o o - - -+ o o o 261 | | | | | | | | | | | | 263 Flow-Mapping-Fabric 265 Virtualized Network Functions: Data-Center A 266 | | | | | | | | | 267 OuterLay OuterLay OuterLay 268 \ | / \ | / \ | / 269 Mux Mux Mux 270 | | | 271 XTR XTR XTR 272 || || || 273 A =============================== 274 c || || 275 c \ _|| ||_ / 276 e -XTR_ | | _XTR- Internetwork flows 277 s / || IPvN || \ 278 s \ _|| Underlay ||_ / 279 -XTR_ | | _XTR- Internetwork flows 280 F / || || \ 281 l || || 282 o =============================== 283 w || || || 284 s XTR XTR XTR 285 | | | 286 Mux Mux Mux 287 / | \ / | \ / | \ 288 OuterLay OuterLay OuterLay 289 | | | | | | | | | 290 Virtualized Network Functions: Distribution-Center B 292 NFV Outerlay, LISP-SDN Overlay, IP Underlay 294 4. Flow-Mapping Elements 296 In order to implement NFV Flow-Mapping-Fabric using LISP-SDN We use 297 the following components and capabilities: 299 1. Flow-Switching: is a component within an SDN-xTR and contains a 300 set of n-tuple flow-rules matched against each packet in order to 301 separate it to (LOCALLY defined) sequences representing flows. 302 Flows are either Encapsulated into the Overlay, decapsulated to 303 the Outerlay, or forwarded to SDN-xTR Control Agents. 305 2. Control-Agents: are software processes running in SDN-xTRs and 306 are invoked for each flow where an exact match was not present in 307 the Flow-Switching. The default "catch-all" Flow-Handler maps IP 308 flows to locations and gateways based on RFC 6830. Protocol and 309 application specific handlers can be loaded into the SDN-xTR for 310 handling specific mapping and AFFINITY requirements of network 311 functions. Examples of such protocols and applications can be 312 SIP, GTP, S1X etc. 314 3. Global-Mapping: is how GLOBALLY significant key-value mappings is 315 translated to LOCALLY defines flow masks and encapsulation 316 actions. Examples of such mappings include: Map a functional 317 instance ID to a function class ID; map subscriber-application ID 318 to virtual function instance ID; map instance ID to location; 319 instance to health, load, tenant; etc. 321 Orchestration Authorization OSS/BSS 322 Mappings Mappings Mappings 323 v v v 324 (Class-Instance) (3A, ACL) (Subs-Service) 325 v v v 326 _________________________________ 327 | | 328 | LISP-MAP | 329 |_________________________________| 331 ^ ^ ^ 332 Runtime Mappings(location, affinity, load) 333 ^ ^ ^ 334 ^ ------- ------- ------- 335 | | Mapper| | Mapper| | Mapper| 336 | |-------| |-------| |-------| 337 X |Agents | |Agents | |Agents | 338 | |-------| |-------| |-------| 339 v | FlowX | | FlowX | | FlowX | 340 ------- ------- ------- 342 Identity-Location Overlay 344 5. Day-in-life of a Mapped Flow 346 Let us walk through detailed steps of the use of RFC6830 and LISP 347 architecture in order to perform resource virtualization and flow 348 assignment to virtual function instances. 350 At a high level, when a client-flow packet first arrives at a SDN-xTR 351 on the edge of the LISP overlay, the SDN-xTR must decide on a VNF 352 instance that is best suited to service this flow, assign this flow 353 to the selected VNF, and encapsulate this flow to the RLOC of the 354 selected virtual function instance. 356 To select the best suited VNF instance, the SDN-xTR queries the 357 Mapping System with the extracted identity parameters, both the 358 client and the function EIDs, and receives the list of all VNF 359 instances that represent that Function along with their RLOC and 360 health-load attributes. The SDN-xTR runs local algorithms on the 361 returned set to select the best suited virtual function instance. 363 Once selected, the SDN-xTR stores (registers) the assignment of this 364 flow to the associated VNF instance in the Mapping System. This 365 assignment is referred to as the Affinity for this flow. The SDN-xTR 366 also programs an exact match flow rule in its data-plane, so future 367 packets from this flow will be mapped to the same EID-RLOC. 369 In the following subsections We describe this process in more detail. 371 5.1. XTR Flow Edge 373 SDN-xTR locations define the boundary of the virtual network. For 374 the purpose of LISP-SDN flow-mapping-fabric We refer to the bellow 375 SDN-XTR generic reference architecture. Actual vendor 376 implementations may vary, but most likely will include similar 377 components and structure. The SDN-XTR includes: 379 o Mux-DeMux: Interfaces to the Underlay and Outerlay 381 o Flow-Rules: Patterns-Actions, Exact / Best Match, Encap-Decap 383 o Control-Agents: Application specific flow-handlers registered in 384 the Flow-Rules 386 _______________________________________________ 387 | Control Agents per Virtualized App | 388 | O O O O O O O | 389 | ___________________________________ | 390 | | 0101010*01* action (best match) | | 391 | | ... (100s) | | 392 | | 010100101010 action (exact match) | | 393 | |____________... (100Ks)____________| | 394 |_______________________________________________| 395 | SDN-XTR defines the Overlay | 396 Outer-Lay Underlay 397 VNFs and Client-Flows Other SDN-XTR-RLOCs 399 SDN-XTR Reference Architecture 401 SDN-XTR Flow Switching works as follows: 403 1. For traffic from the Outerlay of THIS xTR that has an exact match 404 of all the source-dest-tags.. n-tuples, the packets are processed 405 by rule actions including encapsulation to the RLOC of the xTR 406 which aggregates the relevant function instance to which this 407 flow is mapped to. 409 2. For traffic from the Underlay that has an exact match of all the 410 source-dest-tags.. n-tuples, the packets are processed by rule 411 actions including decapsulation and forwarding to the Outerlay of 412 THIS xTR. 414 3. Traffic from the Outer-Lay or Underlay that does NOT have an 415 exact match of all the source-dest-tags.. tuples required for 416 normal forwarding, packets are forwarded to the control agent 417 registered in the best-matching rule. 419 SDN-XTR Control Agents work as follows: 421 1. Mapping agent type and application scope is defined by the best 422 match entries that point to it. Control agents will typically 423 self-register in the flow-switch. XTR control-agents can 424 register to an existing best-match rule, or instantiate a new 425 one. 427 2. Typical rule-patterns are pattern-scoped by an agent 428 registration, and can include: protocol or service type header 429 indications; specific virtual IP addresses (VIP) that represent a 430 service and not a specific destination; a specific source and 431 wild-card destination; or vice versa. 433 3. Mapping agents work with the LISP-SDN mapping service in order to 434 establish a global context and local considerations for mapping 435 decision. The goal of the agents' decision is ultimately to 436 provision the correct exact-match rule and actions that will 437 offload the flow-packets to flow-switching described above. 439 The SDN-xTR control agents query the LISP-SDN Mapping System with the 440 flow attributes including the destination VIP, as followes: 442 Mapping System Lookup: Map-Request (Client identity, Function-EID) 444 Two outcomes are possible based on whether an affinity already exists 445 for this flow (flow has already been assigned to a virtual function 446 instance): 448 o Outcome A: 450 * If an affinity already exists in the Mapping System, the 451 Mapping System returns the locator address (RLOC) associated 452 with the Function-Instance-EID that the (Client-EID, Function- 453 EID) is mapped to. 455 * Map-Reply: ( (Client-EID, Function-EID) -> Function-Instance- 456 RLOC ) 458 * In this case the Mapping System also subscribes the SDN-xTR to 459 the Function-Instance-EID, and to the (Client-EID, Function- 460 EID) flow in order to receive updates in case of changes on 461 these entries. Examples of these changes are change of RLOC 462 for the Function-Instance-EID (specially if this is a virtual 463 application), or change of affinity for (Client-EID, Function- 464 EID) to another Function-Instance-EID. 466 * After receiving the Map-Reply form the Mapping System, the SDN- 467 xTR programs an exact match for the flow in the xTR data-plane. 469 o Outcome B: 471 * If there is no affinity previously stored, the Mapping System 472 returns a list of Records, including one Record per each 473 instance of the Function-EID, with their associated RLOCs and 474 flags (weight, priority). 476 * Map-Reply: (client EID, Function-Instance-Record 1, Function- 477 Instance-Record 2...) 479 * the SDN-xTR then selects the best suited Function-Instance-EID 480 for this flow based on local algorithms, and registers the 481 affinity in the Mapping System. The Mapping System stores the 482 affinity and subscribes the SDN-xTR to the affinity and to the 483 Function-Instance-EID in the affinity, so that SDN-xTR would 484 receive updates if any of these changes. 486 * Map-Register ( (Client-EID, Function-EID) -> Function-Instance- 487 EID) 489 o Note: An SDN-xTR must be able to query for the list of App- 490 Instance-Records even if an affinity already exists. For this 491 purpose a flag is required in the Map-Request to indicate whether 492 xTR wants this info or not. We can overload the M bit in Map- 493 Request, or allocate a new bit for this. 495 5.2. Map Resolvers-Servers 497 5.3. XTRs-Mappers Scaling 499 6. Message Formats 501 This section specifies the packet formats used throughout the flow- 502 mapping process explained above. 504 A Map-Request is used with a 2-Tuple Src/Dst LCAF to query the 505 Mapping System for the affinity or list of virtual function instance 506 records for this flow. 508 0 1 2 3 509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Nonce . . . | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | . . . Nonce | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Source-EID-AFI | Source EID Address ... | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Reserved | EID mask-len | EID-prefix-AFI = 16387 | 522 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | | Rsvd1 | Flags | Type = 12 | Rsvd2 | 524 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | | 4 + n | Reserved | 526 L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 C | Source-ML | Dest-ML | AFI = x | 528 A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 F | Source-Prefix ... | 530 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | AFI = x | Destination-Prefix ... | 532 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Where: 535 Source-Prefix = Client-EID 536 Destination-Prefix = App-EID 538 LISP Map-Request with 2-Tuple Src/Dst LCAF 540 In order to specify a 5 tuple flow, rather than just a two tuple 541 source and destination, the combination of LCAF type 12 and LCAF type 542 4 must be used. 544 If an affinity exists in the Mapping System, meaning that the flow is 545 already assigned to a virtual function instance, then the RLOC of 546 that Function-Instance must be returned by the Mapping System. A 547 Map-Reply with a 2-Tuple Src/Dst Lcaf can be used for this. 549 0 1 2 3 550 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 |Type=2 |P|E|S| Reserved | Record Count | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Nonce . . . | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | . . . Nonce | 557 +---->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | Record TTL | 559 R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 e | Locator Count | EID mask-len | ACT |A| Reserved | 561 c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 o | Rsvd | Map-Version Number | EID-prefix-AFI = 16387 | 563 r +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 d | | Rsvd1 | Flags | Type = 12 | Rsvd2 | 565 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | | | 4 + n | Reserved | 567 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | C | Source-ML | Dest-ML | AFI = x | 569 | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | F | Source-Prefix ... | 571 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | | | AFI = x | Destination-Prefix ... | 573 | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | /| Priority | Weight | M Priority | M Weight | 575 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | o | Unused Flags |L|p|R| Loc-AFI | 577 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | \| Locator | 579 +---->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Map-Reply containing 2-Tuple LCAF and Associated Function-Instance- 582 RLOC 584 If no affinity exists, the Mapping System returns a list of records, 585 including one record per each Function-Instance for the flow's 586 Function-EID. A LISP Map-Reply can be used for this purpose with a 587 2-Tuple Src/Dst LCAF as the EID prefix in each Record. 589 If it is desired to return tuples of (Function-Instance-EID -> RLOC) 590 per each record, a new LCAF, introduced as below, could be used. 592 0 1 2 3 593 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | AFI = 16387 | Rsvd1 | Flags | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type = 14 | Rsvd2 | 4 + n | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | EID-ML | RSVD3 | EID-AFI = x | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | EID-Prefix ... | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | RLOC-AFI = x | Locator Address ... | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 EID-RLOC LCAF: 608 In which, for the purpose of NFV, EID prefix will be used to specify 609 Function-Instance-EID, and Locator address is the RLOC associated 610 with that Funstion-Instance-EID. This LCAF can be used in place of 611 the Loc-AFI in the Map-Reply Message above to include a list of 612 (Function-Instance-EID,RLOC) for every (Client-EID, Function-EID) in 613 the Map-Reply. 615 Finally to store the affinity of the flow in the Mapping System a 616 Map-Register can be used where EID AFI is filled with a LCAF type 12 617 (2-Tuple Src/Dst LCAF), and Loc-AFI is filled with the AFI of the 618 Function-Instance-EID, and the Locator is filled with the Function- 619 Instance-EID. This way, a query on the flow 2-Tuple returns the 620 Function-Instance-EID that the flow is assigned to. 622 7. QOS and Echo Measurements 624 8. Security Considerations 626 there are no security considerations related with this memo. 628 9. IANA Considerations 630 there are no IANA considerations related with this memo. 632 10. Acknowledgements 634 11. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 640 Locator/ID Separation Protocol (LISP)", RFC 6830, January 641 2013. 643 Authors' Addresses 644 Sharon Barkai 645 ConteXtream Inc. 646 California 647 USA 649 Email: sbarkai@gmail.com 651 Dino Farinacci 652 California 653 USA 655 Email: farinacci@gmail.com 657 David Meyer 658 California 659 USA 661 Email: dmm@1-4-5.net 663 Fabio Maino 664 Cisco Systems 665 California 666 USA 668 Email: fmaino@cisco.com 670 Vina Ermagan 671 Cisco Systems 672 California 673 USA 675 Email: vermagan@cisco.com