idnits 2.17.1 draft-ietf-forces-lfb-subsidiary-management-00.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 (February 25, 2015) is 3348 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 321 -- Looks like a reference, but probably isn't: '16' on line 321 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ForCES WG B. Khasnabish 3 Internet-Draft ZTE TX, Inc. 4 Intended status: Standards Track E. Haleplidis 5 Expires: August 29, 2015 University of Patras 6 J. Hadi Salim, Ed. 7 Mojatatu Networks 8 February 25, 2015 10 IETF ForCES Logical Function Block (LFB) Subsidiary Management 11 draft-ietf-forces-lfb-subsidiary-management-00 13 Abstract 15 Deployment experience has demonstrated the value of using the 16 Forwarding and Control Element Separation (ForCES) architecture to 17 manage resources other than packet forwarding. In that spirit, the 18 Forwarding Element Manager (FEM) is modelled by creating a Logical 19 Functional Block (LFB) to represent its functionality. We refer to 20 this LFB as the FE Configuration (FEC) LFB. A Control Element (CE) 21 that controls a Forwarding Element's (FE) resources can also manage 22 its configuration via the FEC LFB. This document introduces the FEC 23 LFB, an LFB that specifies the configuration parameters of an FE. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 29, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 61 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. FE integration into an NE . . . . . . . . . . . . . . . . 6 64 2.2. CE associations . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. New LFB class installation . . . . . . . . . . . . . . . 7 66 3. Applicability statement . . . . . . . . . . . . . . . . . . . 7 67 3.1. FE Integrated . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. Virtual FEs . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3. FEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. FEC Library . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Frame Definitions . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Datatype Definitions . . . . . . . . . . . . . . . . . . 8 73 4.3. Metadata Definitions . . . . . . . . . . . . . . . . . . 8 74 4.4. FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 9 76 4.4.2. Components . . . . . . . . . . . . . . . . . . . . . 9 77 4.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 9 78 4.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 9 79 5. XML for FEC LFB . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 13 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 86 9.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 15 88 A.1. Use of Virtualized ForCES Elements . . . . . . . . . . . 15 89 A.1.1. Use of Virtualized CEs . . . . . . . . . . . . . . . 15 90 A.1.2. Use of Virtualized FEs . . . . . . . . . . . . . . . 15 91 A.1.3. Generic Lifecycle of Physical/Virtual Elements . . . 15 92 A.2. Potential Scenarios . . . . . . . . . . . . . . . . . . . 16 93 A.2.1. Recovery from FE failure . . . . . . . . . . . . . . 16 94 A.2.2. Recovery from CE failure . . . . . . . . . . . . . . 18 95 A.2.3. Load Balancing . . . . . . . . . . . . . . . . . . . 19 96 A.2.4. Orchestration . . . . . . . . . . . . . . . . . . . . 19 97 A.2.5. Generic LFB Lifecycle Management . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 Deployment experience has demonstrated the value of using the 103 Forwarding and Control Element Separation (ForCES) architecture to 104 manage resources other than packet forwarding. In that spirit, the 105 Forwarding Element Manager (FEM) is modelled by creating a Logical 106 Functional Block (LFB) to represent its functionality. We refer to 107 this LFB as the FE Configuration (FEC) LFB. A Control Element (CE) 108 that controls a Forwarding Element's (FE) resources can also manage 109 its configuration via the FEC LFB. This document introduces the FEC 110 LFB, an LFB that specifies the configuration parameters of an FE. 112 On a running FE, a CE application may update an FE's runtime 113 configuration via the FEC LFB. 115 ForCES Network Element 116 +-------------------------------------+ 117 | +---------------------+ | 118 | | Control Application | | 119 | +--+--------------+---+ | 120 | | | | 121 | | | | 122 -------------- Fc | -----------+--+ +-----+------+ | 123 | CE Manager |---------+-| CE 1 |------| CE 2 | | 124 -------------- | | | Fr | | | 125 | | +-+---------+-+ +------------+ | 126 | Fl | | | Fp/Ff / | 127 | | | +--------+ / | 128 | | |Fp/Ff |/ | 129 | | | | | 130 | | | Fp/Ff /|----+ | 131 | | | /--------/ | | 132 -------------- Ff | ---+---------- -------------- | 133 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 134 -------------- | | |------| | | 135 | -------------- -------------- | 136 | | | | | | | | | | 137 ----+--+--+--+----------+--+--+--+----- 138 | | | | | | | | 139 | | | | | | | | 140 Fi/f Fi/f 142 Fp: CE-FE interface 143 Fc: Interface between the CE Manager and a CE 144 Ff: Interface between the FE Manager and an FE 145 Fl: Interface between the CE Manager and the FE Manager 146 Fi/f: FE external interface 148 Figure 1: ForCES Architectural Diagram 150 Figure 1 shows a control application manipulating, at runtime, FE 151 config via the FEC LFB control. The above illustration is derived 152 from Figure 1 in [RFC3746] with modifications showing the messaging 153 for Ff (FEM to FE interface) going via the standard Fp plane. This 154 is merely to demonstrate that the messaging is happening via the 155 traditional Fp interface to the FEM/FEC; it does not however suggest 156 moving away from the Ff interface. 158 The FEC LFB describes the configuration parameters of an FE, namely, 159 the FEID, the FE IP address(es), the CEs it should be associated 160 with, as well as the LFBs that it supports. 162 This document assumes that FEs are already booted. The FE's 163 configuration can then be updated at runtime via the FEC LFB for 164 runtime config purposes. This document does not specify or 165 standardize the FEM-FE (Ff) interface as depicted in [RFC3746]. This 166 document describes a mechanism with which a CE can instruct the FEC 167 for FE management using ForCES. 169 In the case where we have a pool of unused packet processing 170 resources that can be utilized as FEs, the FEC can be utilized to 171 instruct the FE resource to join the Network Element cluster. The 172 initiation would involve control of the creation, configuration, and 173 resource assignment of FEs so as to be part of an NE. Appendix A 174 describes how a resource pool of virtual machines could be initiated 175 as basic CEs or FEs via an orchestration system and subsequently 176 initiated into being part of an FE via the FEM. Again, it should be 177 emphasized that the pools of FEs and CEs are already booted up by 178 some resource owner, e.g. an FEM or an Element Management System 179 (EMS). Subsidiary management provides the LFB library necessary, to 180 manage and configure at runtime, these FEs to disconnect from the 181 "resource pool CE" and join one or more CEs in the running NE. 183 This work item makes no assumption of whether FE resources are 184 physical or virtual. In fact, the LFB library provided here is 185 applicable to both. Thus it can also be useful in addressing control 186 of virtual FEs where individual FEM Managers can be addressed to 187 control the creation, configuration, and resource assignment of such 188 virtual FEs within a physical FE. 190 1.1. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 1.2. Definitions 198 This document follows the terminology defined by [RFC3654], 199 [RFC3746], [RFC5810] and [RFC5812]. In particular, the reader is 200 expected to be familiar with the following terms: 202 o Logical Functional Block (LFB) 204 o Forwarding Element (FE) 206 o Control Element (CE) 208 o ForCES Network Element (NE) 209 o FE Manager (FEM) 211 o CE Manager 213 o ForCES Protocol 215 o ForCES Protocol Layer (ForCES PL) 217 o ForCES Protocol Transport Mapping Layer (ForCES TML) 219 2. Use cases 221 In this section we present sample use cases to illustrate the need 222 and usefulness of the FEC LFB. 224 All use cases assume that an FEs and CEs have already been 225 bootstrapped and instantiated but have not joined the NE. These FEs 226 and CEs belong to a pool of untapped resources. 228 2.1. FE integration into an NE 230 The CE may request, for reasons such as performance, redundancy, 231 load-sharing or new functionality request, to incorporate a new FE in 232 the NE. The CE would be required to specify the following 233 parameters. Firstly the FEID in order for the new FE to be uniquely 234 identified within the NE. Second the FE IP address to bind to, IPv4 235 or IPv6. Thirdly the LFBs to be instantiated within the FE, by means 236 of providing the LFB class, LFB version and LFB name. Finally the 237 CEs that the new FE should associate within the NE as soon as it is 238 integrated within the NE. This includes the CE IDs as well as their 239 corresponding CE IP addresses. 241 2.2. CE associations 243 A CE may request for redundancy reasons that an FE to be associated 244 to another CE as a backup at runtime. To achieve this goal, the 245 master CE specifies the CEID of the new backup CE (to be uniquely 246 identified within the NE) and the CE's IP address (IPv4 or IPv6, or 247 IP addresses should the CE support multiple interfaces). 249 The CE will configure all FEC LFBs to the FEs within the NE of the CE 250 ID and CE IP addresses in order for the FEs to perform the necessary 251 actions ordered by the CE and described by [RFC7121]. 253 the master CE, e.g. detecting a malfunctioning CE, could remove a 254 backup CE from the FE. 256 2.3. New LFB class installation 258 A CE can learn via the capability of FEC LFB whether an FE is capable 259 of loading new LFB classes. Provided that the FE supports new LFB 260 class loading, the CE can request a new LFB to be installed and 261 supported by the FE. 263 To load an LFB class on an FE, the CE will have to provide the LFB 264 class and the LFB class version. There are optional fields which may 265 be need to be described, depending on the implementation (out of 266 scope for this document). Example: 268 location of the LFB Class to be installed and/or mechanism to 269 download it. The exact detail of the location semantics is 270 implementation specific and out of scope of this document. 272 Parameters needed by the LFB class module to allow for its 273 initialization 275 3. Applicability statement 277 Examples of FEC usage are the following, but not limiting, three 278 usage scenarios. These scenarios are not implementation details, but 279 rather depict how the FEC class can be used to achieve the intended 280 subsidiary mechanism for manipulating the configuration of FEs. 282 3.1. FE Integrated 284 Only one instance of the FEC class can exist and is directly related 285 to the FE. The configuration parameters pertain to the parent FE. 287 3.2. Virtual FEs 289 In the case of the FE software that has hierarchical virtual FEs, 290 multiple instances of the FEC class can exist, one per each virtual 291 FE. 293 3.3. FEM 295 The third scenario, pertains to FEC LFB implementation as FE Manager 296 paremeters. In such a case, the FE configurations are locally and 297 logically centralized by the FE manager. The FE manager may hold 298 multiple instances of the FEC class in the FEM, one per each FE. 299 Using the ForCES protocol a CE, through the Fp interface, or a CE 300 Manager via the Fl interface, will instruct the FEM to change the 301 configuration of the FEs. The FEM may hold more information 302 pertaining the NE, such as the topology and chaining of FEs which the 303 CE would require to alter, along with the FE changes. In such a case 304 the Ff interface is out of scope. 306 4. FEC Library 308 4.1. Frame Definitions 310 This LFB does not define any frames 312 4.2. Datatype Definitions 314 This library defines the following datatypes. 316 +----------+-----------------------------------------+--------------+ 317 | DataType | Type | Synopsis | 318 | Name | | | 319 +----------+-----------------------------------------+--------------+ 320 | IPs | A Struct of 2 components. IPv4 | A struct | 321 | | (byte[4]) and IPv6 (byte[16]) | that defines | 322 | | addresses. | an IPv4 and | 323 | | | an IPv6 | 324 | | | address | 325 | LFBDefs | A Struct that contains three | A struct | 326 | | components. The LFB Class ID (uint32), | that defines | 327 | | the LFB version (string) and optional | basic LFB | 328 | | the LFB name (string) and the location | definitions | 329 | | of the LFB where it will be retrieved | | 330 | | from. | | 331 | CEParams | A Struct that contains two components. | A struct | 332 | | A CE's ID (uint32) and the CE's IPs | that defines | 333 | | (array of IPs) | CE | 334 | | | parameters. | 335 +----------+-----------------------------------------+--------------+ 337 FEM Data Types 339 4.3. Metadata Definitions 341 This LFB does not define any metadata definition 343 4.4. FEC 345 The FE Configuration LFB is an LFB that standardizes configuration of 346 the FE parameters. 348 4.4.1. Data Handling 350 The FEC LFB does not handle any packets. It's function is to provide 351 the configuration parameters to the CE to be updated at runtime. 353 4.4.2. Components 355 This LFB has four components specified. The FEID, a uint32 component 356 that defines the ID of the FE. The FEIP, a table of IP address, and 357 each row is a struct of an IPv4 and an IPv6 address. The LFB 358 Parameters, a table of LFBs, each row a struct of LFB Class ID, LFB 359 Version and optional LFB name and location. Finally the CEs, a table 360 of CE parameters, each row a struct of a CE ID and a table of CE IPs. 362 4.4.3. Capabilities 364 This capability specifies whether this FE supports dynamic loading of 365 new LFBs. 367 4.4.4. Events 369 This LFB has five events specified. These events notify the CE 370 whether the FEID has been changed, an entry of the FEIP table has 371 been created or changed and an entry of the CE information added or 372 deleted. The event reports are the respective data that has been 373 modified. 375 5. XML for FEC LFB 377 378 380 381 382 IPs 383 IP definition 384 385 386 FEIPv4 387 The FEs IPv4 388 byte[4] 389 390 391 FEIPv6 392 The FEs IPv6 393 byte[16] 394 395 397 398 399 LFBDefs 400 LFB parameters inside the FE 401 402 403 LFBClassID 404 The LFB Class ID 405 uint32 406 407 408 LFBVersion 409 The Version of the LFB 410 string 411 412 413 LFBName 414 The name of the LFB 415 416 string 417 418 419 LFBLocation 420 The location of the LFB to be retrieved 421 from 422 423 string 424 425 426 427 428 CEParams 429 CE parameters 430 431 432 CEID 433 The CE ID 434 uint32 435 436 437 CEIP 438 The CEIP 439 440 IPs 441 442 443 444 446 447 448 449 FEC 450 Forwarding Element Configuration 451 1.0 452 453 454 FEID 455 The FEID 456 uint32 457 458 459 FEIP 460 The FE's IP 461 462 IPs 463 464 465 466 LFBparameters 467 The LFBs in this FE 468 469 LFBDefs 470 471 472 473 CEs 474 The CEs that should be associated with this 475 FE 476 477 CEParams 478 479 480 481 482 483 DynamicLFBLoading 484 This capability specifies whether this FE supports 485 dynamic loading of new LFBs 486 boolean 487 488 489 490 491 IDChanged 492 The FE ID has been changed 493 494 FEID 495 496 497 498 499 FEID 500 501 502 503 504 FEIPChanged 505 An IP of the FE has been changed 506 507 FEIP 508 509 510 511 512 FEIP 513 _FEIPsrowid_ 514 515 516 517 518 FEIPCreated 519 An FEIP has been deleted 520 521 FEIP 522 523 524 525 526 FEIP 527 _FEIPsrowid_ 528 529 530 531 532 CEAdded 533 An CE has been added 534 535 CEs 536 537 538 539 540 CEs 541 543 544 545 546 CEDeleted 547 An CE has been added 548 549 CEs 550 551 552 553 554 CEs 555 556 557 558 559 560 561 563 Figure 2: FEM XML LFB library 565 6. Security Considerations 567 Security considerations for ForCES LFB subsidiary management will be 568 added in a future version of this daft. 570 7. IANA Considerations 572 7.1. LFB Class Names and LFB Class Identifiers 574 LFB classes defined by this document belong to LFBs defined by 575 Standards Track RFCs. According to IANA, the registration procedure 576 is Standards Action for the range 0 to 65535 and First Come First 577 Served with any publicly available specification for over 65535. 578 This specification includes the following LFB class names and LFB 579 class identifiers: 581 +------------+---------+---------+----------------------+-----------+ 582 | LFB Class | LFB | LFB | Description | Reference | 583 | Identifier | Class | Version | | | 584 | | Name | | | | 585 +------------+---------+---------+----------------------+-----------+ 586 | 21 | FEC | 1.0 | An FEC LFB to | This | 587 | | | | standardize creation | document | 588 | | | | of ForCES Network | | 589 | | | | Elements | | 590 +------------+---------+---------+----------------------+-----------+ 592 Logical Functional Block (LFB) Class Names and Class Identifiers 594 8. Acknowledgments 596 The authors would like to thank DJ, Joel, ChuanhuangLi, and many 597 others for their discussions and support. 599 9. References 601 9.1. Normative References 603 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 604 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 605 Control Element Separation (ForCES) Protocol 606 Specification", RFC 5810, March 2010. 608 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 609 Element Separation (ForCES) Forwarding Element Model", RFC 610 5812, March 2010. 612 [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, 613 "High Availability within a Forwarding and Control Element 614 Separation (ForCES) Network Element", RFC 7121, February 615 2014. 617 9.2. Informative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 623 of IP Control and Forwarding", RFC 3654, November 2003. 625 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 626 "Forwarding and Control Element Separation (ForCES) 627 Framework", RFC 3746, April 2004. 629 Appendix A. Appendix 631 A.1. Use of Virtualized ForCES Elements 633 Virtualization of ForCES Elements allows efficient, scalable, and 634 robust utilization of network control and transmission resources. 635 Virtualization has been discussed (and deployed) widely in the 636 Computing Industry (e.g., server) in the context of efficient 637 utilization of server resources. 639 As mentioned before, the currently existing techniques and solutions 640 may be either slow or not directly applicable to ForCES LFB 641 subsidiary management. 643 A.1.1. Use of Virtualized CEs 645 In this section we discuss the use of virtualized ForCES control 646 elements (CEs). The resulting operating entities in virtualized 647 environment are Virtual CEs of VCEs. The CE Visor (CEV) has the 648 visibility to all of the VCEs in a domain, and can assign one of the 649 VCEs as primary Master-VCE and another as secondary Master-VCE. CEV 650 can dynamically manage the role of primary and secondary master-VCEs 651 from a pool of VCEs. 653 A.1.2. Use of Virtualized FEs 655 In this section we discuss the use of virtualized ForCES forwarding 656 elements (FEs). The resulting operating entities in virtualized 657 environment are Virtual FEs of VFEs. The FE Visor (FEV) has the 658 visibility to all of the VFEs in a domain, and can assign one of the 659 VFEs as primary Master-VFE and another as secondary Master-VFE. FEV 660 can dynamically manage the role of primary and secondary master-VFEs 661 from a pool of VFEs. 663 A.1.3. Generic Lifecycle of Physical/Virtual Elements 665 The generic lifecycle of physical/virtual elements including NEs, 666 FEs, VNEs, VCEs, VFEs, etc. consists of the following FOUR states: 668 o (a)Instantiation -- This refers to instantiation of CEs and FEs. 670 o (b) Association -- This refers to associating FEs to the CEs 672 o (c) Activation -- This refers to activation of CEs and FEs for 673 normal operation. This state may include monitoring as well with 674 an objective to satisfy both scaling and reliability requirements. 676 o (d) Release -- This refers to releasing resources (both physical 677 and virtual elements) to the pool of available (that is un- 678 assigned) elements, and reporting this to the appropriate (CE or 679 FE) manager. It may be required to cleanse the physical/virtual 680 elements before releasing in order to prevent harvesting of data/ 681 information by the the next user of the CEs/FEs. The details of 682 the cleansing operation is out of scope of this draft. 684 Figure 1 shows physical/virtual elements states and their transition. 686 o--------------o o--------------o 687 | | | | 688 |Instantiation +----------------->| Association | 689 | | | | 690 o--------------o o------+-------o 691 ^ | 692 | | 693 | | 694 | | 695 | | 696 o------+-------o o------V-------o 697 | | | | 698 | Release |<-----------------+ Activation | 699 | | | | 700 o--------------o o--------------o 702 Figure 1: Physical/Virtual Elements States and their Transition 704 A.2. Potential Scenarios 706 In this section we discuss a few potential scenarios that can utilize 707 ForCES LFB subsidiary management for efficient and robust operation 708 of networks without using excessive additional resources. 710 A.2.1. Recovery from FE failure 712 In this section we discuss how virtualization of FEs can be used for 713 efficient recovery from FE failure(s). An FE can initially boot 714 using a default Association and Configuration. The Association and 715 Configuration can be updated at runtime via an FE-Visor or FEC LFB 716 for runtime configuration purposes. This can be achieved, for 717 example, by adding a new CE and its associated IP address. A CE can 718 initially boot using a default Configuration and State(s). The 719 Configuration and State(s) can be updated at runtime via a CE-Visor 720 or a similar CE Configuration (CEC) LFB to satisfy the runtime 721 requirements. 723 .--------------. 724 [Apps/ | | 725 Service]--|Orchestration | 726 | | 727 .--------------. 728 | | .--------. 729 .-----------. | | | | 730 | |---| |---------------------------| | 731 |Controller | | | 732 | | | | 733 .-|-----|---. |Hyper- | 734 | | |Visor | 735 4 2 | | 736 | | | | 737 | CEy CEw .... CE? | | 738 | | \ /\ | | 739 | | \----/--\-------------------------------|----| | 740 | | / \ | .-|-. | 741 | FEM-----/ \-----------------------------|--| | | 742 .-->(FEz)<-----------------3----------------------|--|FEx| | 743 | .---. | 744 (1)----->| | 745 .--------. 747 Figure 2: Sequence of Events in FEM for Recovery from FE Failure 749 Note: 1.(Hyervisor) Boots up FEx, and connects to CEy and CEw, 2. 750 Boot a VM of Type FE 3. FEx Boots FEz, and Connects to CEy, 751 4.Connect to CEw 753 As described in Figure 2, the following is a sequence of events in 754 FEM (an example). 756 o Step-1: Hypervisor boots up with FEx that connects to CEy and CEw. 758 o Step-2: The Controller (attached to CEy) instructs FEx to boot an 759 FE-type VM. 761 o Step-3: FEx boots FEz and instructs it to connect to CEy 763 o Step-4: The Controller (attached to FEz) instructs FEz to also 764 connect to CEw. This is essentially the "Association" part of 765 Association and Configuration, as discussed earlier. 767 o Step-5: The Controller (attached to FEz) instructs FEz to increase 768 its Syslog debug level. This is essentially the "Configuration" 769 part of Association and Configuration, as discussed earlier. 771 Note that the 4th (FEM part of the charter) and 5th steps are what we 772 would like to achieve here. In addition, the FEVM may not need to be 773 aware which Virtual FEs are in one Virtual NE, it only needs know of 774 the information about a Virtual FE in the physical FE. CE Manager 775 may need to have visibility to all Virtual NEs. The component "NE" 776 of the LFB may be considered as Virtual NE as well. 778 A.2.2. Recovery from CE failure 780 In this section we discuss how virtualization of CEs can be used for 781 efficient recovery from CE failure(s). 783 A CE can initially boot using a default Association, State, and 784 Configuration. The Association and Configuration can be updated at 785 runtime via a CE-Visor or FEC-LFB for runtime configuration purposes, 786 for example, by adding a new CE and its associated IP address. 788 An FE can initially boot using a default Configuration, Association, 789 with a CE, and State. The Configuration, Association can be updated 790 at runtime via a FE-Visor or FEC LFB to satisfy runtime requirements. 791 The sequence of events, an example, can be as follows. 793 o Step-1: The CEx is Active with CEy as its Standby with Standby- 794 Active or Active-Active setup. 796 o Step-2: The CEx controls FEy and FEw with both FEy and FEw having 797 Standby control links to CEy, with Standby-Active or Active-Active 798 setup. Note that CEx and CEy are controlled, assigned, by CE- 799 visor, and may have a common, virtual, IP address. 801 o Step-3: The Controller is fully aware of the status of all of the 802 CEs, physical and virtual; When CEx fails, its states are fully 803 transferred (may already be synced) to CEy. 805 o Step-4: The Standby links from CEy to FEy and FEw become fully 806 active, and the control, of FEy and FEw, is fully transferred from 807 CEx and CEy. 809 o Step-5: A graceful-smooth failover of CEx to CEy is now 810 successfully complete, and SysLog debug level for CEy is 811 increased.. 813 As discussed earlier, the last two steps are concerned with 814 Subsidiary management. Although we discuss the recovery method by 815 using virtualization of CEs, the role of FEVM in the recovery process 816 will be described further later. 818 A.2.3. Load Balancing 820 In this section we discuss efficient load balancing of both CE and FE 821 in virtualized environment. 823 A.2.4. Orchestration 825 In this section we discuss efficient Orchestration of both CE and FE 826 in virtualized multi-admin-domain environment. 828 A.2.5. Generic LFB Lifecycle Management 830 In this section we discuss generic lifecycle management of 831 subsidiaries of LFBs in virtualized environment(s). The typical 832 management activities in the life of FE/CE are discussed in the 833 following sub-sections. 835 A.2.5.1. Booting a CE/FE 837 When an entity needs to boot a CE/FE, if this is a VM, some 838 orchestration would scheme/plan to do this. In case of ForCES, we 839 have a control App that boots a CE or an FE via a management FE. So 840 here we have a management plane details that is described either in 841 FEM or other LFB. 843 A.2.5.2. Bootstrapping the Configuration 845 The FE, e.g., the VM which has just been booted, as described in the 846 previous sub-section, needs initial bootstrap configuration (e.g., 847 what CEs to connect to etc). This clearly falls in the FEC LFB 848 domain. 850 A.2.5.3. Runtime Management 852 At runtime of the FE, for example, the management could introduce a 853 new CE for the FE to associate with; it may also be for an FE to 854 dissociate from a CE, and so on. 856 Authors' Addresses 857 Bhumip Khasnabish 858 ZTE TX, Inc. 859 55 Madison Avenue, Suite 160 860 Morristown, New Jersey 07960 861 USA 863 Phone: +001-781-752-8003 864 Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com 865 URI: http://tinyurl.com/bhumip/ 867 Evangelos Haleplidis 868 University of Patras 869 Department of Electrical and Computer Engineering 870 Patras 26500 871 Greece 873 Email: ehalep@ece.upatras.gr 875 Jamal Hadi Salim (editor) 876 Mojatatu Networks 877 Suite 400, 303 Moodie Dr. 878 Ottawa, Ontario K2H 9R4 879 Canada 881 Email: hadi@mojatatu.com