idnits 2.17.1 draft-haleplidis-forces-virtualization-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 : ---------------------------------------------------------------------------- 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 seems to have RFC 2119 boilerplate text. -- The document date (October 23, 2012) is 4195 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Haleplidis 3 Internet-Draft O. Koufopavlou 4 Intended status: Informational S. Denazis 5 Expires: April 26, 2013 University of Patras 6 October 23, 2012 8 Virtualization of the Forwarding Plane Devices with ForCES 9 draft-haleplidis-forces-virtualization-01 11 Abstract 13 Forwarding and Control Element Separation (ForCES) defines an 14 architectural framework and associated protocols to standardize 15 information exchange between the control plane and the forwarding 16 plane in a ForCES Network Element (ForCES NE). RFC5812 has defined 17 the ForCES Model provides a formal way to represent the capabilities, 18 state, and configuration of forwarding elements within the context of 19 the ForCES protocol, so that control elements (CEs) can control the 20 FEs accordingly. More specifically, the model describes the logical 21 functions that are present in an FE, what capabilities these 22 functions support, and how these functions are or can be 23 interconnected. 25 The ForCES model provides the necessary abstractions to natively 26 support virtualization of the forwarding plane. This documents 27 describes a formal approach to model the necessary parameters 28 required for defining and managing virtual network forwarding planes 29 to create virtual network elements. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 26, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Virtualization . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Virtualization Base Types . . . . . . . . . . . . . . . . . . 8 70 4.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . . 8 73 5. Virtualization LFBs . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. vFE . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 9 76 5.1.2. Components . . . . . . . . . . . . . . . . . . . . . . 9 77 5.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . . 9 78 5.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. XML for Virtual LFB library . . . . . . . . . . . . . . . . . 10 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Terminology and Conventions 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 1.2. Definitions 98 This document follows the terminology defined by the ForCES Model in 99 [RFC5812]. The required definitions are repeated below for clarity. 101 FE Model - The FE model is designed to model the logical 102 processing functions of an FE. The FE model proposed in this 103 document includes three components; the LFB modeling of individual 104 Logical Functional Block (LFB model), the logical interconnection 105 between LFBs (LFB topology), and the FE-level attributes, 106 including FE capabilities. The FE model provides the basis to 107 define the information elements exchanged between the CE and the 108 FE in the ForCES protocol [RFC5810]. 110 LFB (Logical Functional Block) Class (or type) - A template that 111 represents a fine-grained, logically separable aspect of FE 112 processing. Most LFBs relate to packet processing in the data 113 path. LFB classes are the basic building blocks of the FE model. 115 LFB Instance - As a packet flows through an FE along a data path, 116 it flows through one or multiple LFB instances, where each LFB is 117 an instance of a specific LFB class. Multiple instances of the 118 same LFB class can be present in an FE's data path. Note that we 119 often refer to LFBs without distinguishing between an LFB class 120 and LFB instance when we believe the implied reference is obvious 121 for the given context. 123 LFB Model - The LFB model describes the content and structures in 124 an LFB, plus the associated data definition. XML is used to 125 provide a formal definition of the necessary structures for the 126 modeling. Four types of information are defined in the LFB model. 127 The core part of the LFB model is the LFB class definitions; the 128 other three types of information define constructs associated with 129 and used by the class definition. These are reusable data types, 130 supported frame (packet) formats, and metadata. 132 Element - Element is generally used in this document in accordance 133 with the XML usage of the term. It refers to an XML tagged part 134 of an XML document. For a precise definition, please see the full 135 set of XML specifications from the W3C. This term is included in 136 this list for completeness because the ForCES formal model uses 137 XML. 139 Attribute - Attribute is used in the ForCES formal modeling in 140 accordance with standard XML usage of the term, i.e., to provide 141 attribute information included in an XML tag. 143 LFB Metadata - Metadata is used to communicate per-packet state 144 from one LFB to another, but is not sent across the network. The 145 FE model defines how such metadata is identified, produced, and 146 consumed by the LFBs, but not how the per-packet state is 147 implemented within actual hardware. Metadata is sent between the 148 FE and the CE on redirect packets. 150 ForCES Component - A ForCES Component is a well-defined, uniquely 151 identifiable and addressable ForCES model building block. A 152 component has a 32-bit ID, name, type, and an optional synopsis 153 description. These are often referred to simply as components. 154 LFB Component - An LFB component is a ForCES component that 155 defines the Operational parameters of the LFBs that must be 156 visible to the CEs. 158 LFB Class Library - The LFB class library is a set of LFB classes 159 that has been identified as the most common functions found in 160 most FEs and hence should be defined first by the ForCES Working 161 Group. 163 2. Introduction 165 Forwarding plane virtualization is one key ingerdient in creating a 166 fully virtualized environment for data centers. One of the main 167 requirements for virtualizing the forwarding plane is to create a 168 complete set of abstractions that can be mapped to the physical 169 devices. The ForCES Model [RFC5812] is such and abstraction as it 170 presents a formal way to describe the Forwarding Plane's datapath 171 with Logical Function Blocks (LFBs) using XML. This documents 172 describes a formal approach to model the necessary parameters 173 required for defining and managing a virtual network forwarding 174 plane. Control Elements virtual or physical can be associated with 175 ForCES protocol to the virtual FEs and create a virtual network 176 element. 178 3. Virtualization 180 LFBs are abstraction of the forwarding plane therefore they can be 181 also used as abstractions of the virtual forwarding plane as well. 183 How a device is exactly virtualized is out of scope of this document 184 and is considered implementation specific. However an example is 185 shown in Figure 1 where disctinct and isolated topologies of LFB 186 instances inside an FE can be virtualiza a physical FE. 188 +-------------------------------------------------------------+ 189 | | 190 | +---------------------------------------------------------+ | 191 | | +----+ +----------+ +-----+ +-----+ +----+ | | 192 ---|--->|Port|--->|Classifier|--->|Meter|--->|Queue|--->|Port|---|--> 193 | | |In.1| |Instance 1| |In.1 | |In.1 | |In.2| | | 194 | | +----+ +----------+ +-----+ +-----+ +----+ | | 195 | +---------------------------------------------------------+ | 196 | Virtual FE 1 | 197 | | 198 | +---------------------------------------------------------+ | 199 | | +----+ +----------+ +-----+ +----+ | | 200 ---|--->|Port|--->|Classifier|-------------->|Queue|--->|Port|---|--> 201 | | |In.3| |Instance 2| |In.2 | |In.4| | | 202 | | +----+ +----------+ +-----+ +----+ | | 203 | +---------------------------------------------------------+ | 204 | Virtual FE 2 | 205 | | 206 +-------------------------------------------------------------+ 207 Physical FE 209 Figure 1: Isolated LFB instances 211 This document focuses on the definition of an LFB that will allow a 212 CE to deploy and manage virtual FEs. In this approach we try to 213 define parameters of a Virtual Network Element Manager (VNEM), what 214 is commonly called a hypervisor therefore treating it as an FE, in 215 order to be managed by a virtual management software, in this case a 216 CE. 218 The VNEM in the ForCES model can be a joined Control Element Manager 219 and a Forwarding Element Manager which defines which CEs or vCEs 220 connect to which FEs or vFEs. What is required therefore of this 221 document is a way to define resource allocation to a vFE and the 222 topology of the FE or vFEs. This document introduces a new LFB, 223 called vFE which contains the following details for one tenant of the 224 network: 226 1. TenantID 228 2. FEs and resource allocation per FE. 230 3. FETopology 232 It is expected that there is one instance of the vFE LFB per tenant. 234 +-----------------+ 235 | Virtual Network | 236 | Management (CE) | 237 +-----------------+ 238 /\ 239 | ForCES 240 | Protocol 241 \/ 242 +----+ CE/CEM +-----------------+ 243 | CE | <-------> | | 244 +----+ Interface | | 245 | Virtual | 246 +----+ CE/CEM | Network Element | 247 | CE | <-------> | Manager (FE) | 248 +----+ Interface | | 249 /\ +-----------------+ 250 | /\ /\ 251 | ForCES | FE/FEM | 252 | Protocol | Interface | 253 | \/ \/ 254 | +----+ +----+ 255 +------------->| FE | | FE | 256 +----+ +----+ 258 Figure 2: Virtual Network Elements 260 The Virtual Network Management is able to describe and instantiate FE 261 topologies and assign CEs to control them. The CEs will be able to 262 be configured via the CE/CEM interface and the FEs by the FE/FEM 263 interface 265 4. Virtualization Base Types 267 4.1. Frame Types 269 No frame types has been defined in this library. 271 4.2. Data Types 273 TBD 275 4.3. MetaData Types 277 No metadata types have been defined in this library. 279 5. Virtualization LFBs 281 5.1. vFE 283 The vFE LFB holds information regarding a tenant in a virtual network 284 device 286 5.1.1. Data Handling 288 The vFE LFB does not handle any data. It is similar to the core 289 LFBs, FEObject and FEProtocolObject. It is expected to be one vFE 290 LFB per tenant. 292 5.1.2. Components 294 The following components have been defined for this FE: 296 1. FETopology - The Topology of the FEs. From a FE, To an FE, via 297 port and the link allocation between them. 299 2. FEs - The FEs supported by this vFE 301 3. CEs - The CEs, master and backup to control the FEs. 303 4. TenantID - The tenant ID for this vFE. 305 5.1.3. Capabilities 307 The following two capabilities have been defined: 309 1. ModifiableFETopology - Whether the FE topology is modifiable. 311 2. SupportedFEs - The FEs that are supported by this topology. 313 5.1.4. Events 315 This LFB has no events specified. 317 6. XML for Virtual LFB library 319 320 324 325 326 327 PercentageType 328 A datatype that defines a percentage 329 330 331 uchar 332 333 334 335 336 337 338 FEAdjacencyLimitType 339 Describing the Adjacent FE 340 341 342 NeighborLFB 343 FE ID for that FE 344 uint32 345 346 347 ViaPorts 348 the ports on which we can connect 349 350 351 string 352 353 354 355 356 357 SupportedFEType 358 Table entry for supported FEs 359 360 361 FEName 362 The name of a supported FE 363 string 365 366 367 FEID 368 The id of a supported FE 369 uint32 370 371 372 CanOccurAfters 373 List of FEs that this FE class can follow 374 375 376 377 FEAdjacencyLimitType 378 379 380 381 CanOccurBefores 382 List of FEs that this FE class can follow 383 384 385 386 FEAdjacencyLimitType 387 388 389 390 391 392 FELinkTYpe 393 Link between two FEs 394 395 396 FromFEID 397 FE source 398 uint32 399 400 401 ToFEID 402 FE destination 403 uint32 404 405 406 ViaPorts 407 The interfaces on which the FEs connect 408 409 410 string 411 412 413 414 LinkAllocation 415 Percentage of allowed Link usage 416 PercentageType 417 418 419 420 421 FEType 422 An FE inside a virtual forwarding element topology 423 424 425 426 FEID 427 ID of the FE 428 uint32 429 430 431 ResourceAllocation 432 Resource Allocation for this FE 433 434 435 436 Storage 437 Storage allocation of this FE 438 439 440 PercentageType 441 442 443 Memory 444 Memory allocation of this FE 445 446 447 PercentageType 448 449 450 Compuutation 451 Computation allocation of this FE 452 453 454 PercentageType 455 456 457 Bandwidth 458 Bandwidth allocation of this FE 459 460 461 PercentageType 462 463 464 465 466 467 468 469 470 vFE 471 Core LFB:FE Object 472 1.0 473 474 475 FETopology 476 The table of known topologies 477 478 FELinkTYpe 479 480 481 482 FEs 483 table of FEs 484 485 FEType 486 487 488 489 CEs 490 table of CEs 491 492 493 494 CEID 495 The CEID 496 uint32 497 498 499 CEType 500 Master or backup 501 502 uchar 503 504 505 Master 506 This CE is the master 507 508 509 510 Backup 511 This CE is a backup 512 513 514 515 516 517 518 519 520 521 TenantID 522 The tenant ID of this virtual topology of 523 FEs 524 uint32 525 526 527 528 529 ModifiableFETopology 530 Whether Modifiable FE topology is supported 531 532 boolean 533 534 535 SupportedFEs 536 List of all supported FEs 537 538 uint32 539 540 541 542 543 544 546 Figure 3: Parallel LFB library 548 7. Acknowledgements 550 TBD 552 8. IANA Considerations 554 This memo includes no request to IANA. 556 9. Security Considerations 557 10. References 559 10.1. Normative References 561 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 562 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 563 Control Element Separation (ForCES) Protocol 564 Specification", RFC 5810, March 2010. 566 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 567 Element Separation (ForCES) Forwarding Element Model", 568 RFC 5812, March 2010. 570 10.2. Informative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 Authors' Addresses 577 Evangelos Haleplidis 578 University of Patras 579 Department of Electrical and Computer Engineering 580 Patras, 26500 581 Greece 583 Email: ehalep@ece.upatras.gr 585 Odysseas Koufopavlou 586 University of Patras 587 Department of Electrical and Computer Engineering 588 Patras, 26500 589 Greece 591 Email: odysseas@ece.upatras.gr 593 Spyros Denazis 594 University of Patras 595 Department of Electrical and Computer Engineering 596 Patras, 26500 597 Greece 599 Email: sdena@upatras.gr