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