idnits 2.17.1 draft-ietf-forces-lfb-subsidiary-management-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 : ---------------------------------------------------------------------------- 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 date (August 31, 2015) is 3162 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: '16' on line 359 -- Looks like a reference, but probably isn't: '8' on line 364 -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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: March 3, 2016 University of Patras 6 J. Hadi Salim, Ed. 7 Mojatatu Networks 8 August 31, 2015 10 IETF ForCES Logical Function Block (LFB) Subsidiary Management 11 draft-ietf-forces-lfb-subsidiary-management-02 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 Subsidiary Mechanism (SM) LFB. A Control Element 21 (CE) that controls a Forwarding Element's (FE) resources can also 22 manage its configuration via the SM LFB. This document introduces 23 the SM LFB class, an LFB class that specifies the configuration 24 parameters of an FE. The configuration parameters include new LFB 25 class loading, CE associations as well as to provide manipulation of 26 debug mechanisms along with a general purpose attribute definition to 27 describe config information. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 3, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 65 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.1. High Availability . . . . . . . . . . . . . . . . . . . . 6 68 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.3. Adding New Resources To An NE . . . . . . . . . . . . . . 6 70 2.4. New LFB class installation . . . . . . . . . . . . . . . 6 71 2.5. Logging Mechanism . . . . . . . . . . . . . . . . . . . . 7 72 2.6. General Purpose Attribute Definition . . . . . . . . . . 7 73 3. Applicability statement . . . . . . . . . . . . . . . . . . . 8 74 3.1. FE Integrated . . . . . . . . . . . . . . . . . . . . . . 8 75 3.2. Virtual FEs . . . . . . . . . . . . . . . . . . . . . . . 8 76 4. SM Library . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.1. Frame Definitions . . . . . . . . . . . . . . . . . . . . 8 78 4.2. Datatype Definitions . . . . . . . . . . . . . . . . . . 8 79 4.3. Metadata Definitions . . . . . . . . . . . . . . . . . . 9 80 4.4. SM . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 9 82 4.4.2. Components . . . . . . . . . . . . . . . . . . . . . 10 83 4.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 10 84 4.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 10 85 5. XML for SM LFB . . . . . . . . . . . . . . . . . . . . . . . 11 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 17 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 92 9.2. Informative References . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 Deployment experience has demonstrated the value of using the 98 Forwarding and Control Element Separation (ForCES) architecture to 99 manage resources other than packet forwarding. In that spirit, the 100 Forwarding Element Manager (FEM) is modelled by creating a Logical 101 Functional Block (LFB) to represent its functionality. We refer to 102 this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element 103 (CE) that controls a Forwarding Element's (FE) resources can also 104 manage its configuration via the SM LFB. This document introduces 105 the SM LFB class, an LFB that specifies the configuration parameters 106 of an FE. 108 On a running FE, a CE application may update an FE's runtime 109 configuration via the SM LFB instance. 111 ForCES Network Element 112 +-------------------------------------+ 113 | +---------------------+ | 114 | | Control Application | | 115 | +--+--------------+---+ | 116 | | | | 117 | | | | 118 -------------- Fc | -----------+--+ +-----+------+ | 119 | CE Manager |---------+-| CE 1 |------| CE 2 | | 120 -------------- | | | Fr | | | 121 | | +-+---------+-+ +------------+ | 122 | Fl | | | Fp / | 123 | | | +--------+ / | 124 | | | Fp |/ | 125 | | | | | 126 | | | Fp /|----+ | 127 | | | /--------/ | | 128 -------------- Ff | ---+---------- -------------- | 129 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 130 -------------- | | |------| | | 131 | -------------- -------------- | 132 | | | | | | | | | | 133 ----+--+--+--+----------+--+--+--+----- 134 | | | | | | | | 135 | | | | | | | | 136 Fi/f Fi/f 138 Fp: CE-FE interface 139 Fr: CE-CE interface 140 Fc: Interface between the CE Manager and a CE 141 Ff: Interface between the FE Manager and an FE 142 Fl: Interface between the CE Manager and the FE Manager 143 Fi/f: FE external interface 145 Figure 1: ForCES Architectural Diagram 147 Figure 1 shows a control application manipulating, at runtime, FE 148 config via the SM LFB control. It would appear that that control 149 application is playing the part of the FE Manager thus appears as the 150 messaging for Ff (FEM to FE interface) going via the standard Fp 151 plane. However the SM LFB describes a subset of the operations that 152 can be performed over Ff; it does not suggest moving away from the Ff 153 interface. 155 The SM LFB class describes the configuration parameters of an FE, 156 namely the LFB classes it should load, the CEs it should be 157 associated with as well the respective CE IP addresses. Additionally 158 the SM LFB provides a general purpose attribute definition to 159 describe config information, as well as the ability to manipulate 160 debug logging mechanism. 162 This document assumes that FEs are already booted. The FE's 163 configuration can then be updated at runtime via the SM 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 SM 167 for FE management using ForCES. 169 This work item makes no assumption of whether FE resources are 170 physical or virtual. In fact, the LFB library provided here is 171 applicable to both. Thus it can also be useful in addressing control 172 of virtual FEs where individual FEM Managers can be addressed to 173 control the creation, configuration, and resource assignment of such 174 virtual FEs within a physical FE. 176 1.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 1.2. Definitions 184 This document follows the terminology defined by [RFC3654], 185 [RFC3746], [RFC5810] and [RFC5812]. In particular, the reader is 186 expected to be familiar with the following terms: 188 o Logical Functional Block (LFB) 190 o Forwarding Element (FE) 192 o Control Element (CE) 194 o ForCES Network Element (NE) 196 o FE Manager (FEM) 198 o CE Manager 200 o ForCES Protocol 202 o ForCES Protocol Layer (ForCES PL) 204 o ForCES Protocol Transport Mapping Layer (ForCES TML) 206 2. Use cases 208 In this section we present sample use cases to illustrate the need 209 and usefulness of the SM LFB. 211 All use cases assume that an FE is already booted up and tied to at 212 least one CE. A control application can delete a CE from an FE's 213 table of CEs which instructs the FE to terminate the connection with 214 that removed CE. Likewise, the control application via the master CE 215 instructs an FE to establish a ForCES association with a new CE by 216 adding a particular CE to the FE's CEs table. 218 2.1. High Availability 220 Assume an FE associated to only one CE. At runtime, a CE management 221 application may request for redundancy reasons that an FE to be 222 associated to another CE as a backup. To achieve this goal, the CE 223 management application specifies the CEID of the new backup CE (to be 224 uniquely identified within the NE) and the CE's IP address (IPv4 or 225 IPv6). 227 2.2. Scalability 229 Assume an NE cluster that has FEs connected possibly in an active 230 backup setup to multiple CEs. Assume that system analytics discover 231 that the CE is becoming a bottleneck. A new CE could be booted and 232 some FEs moved to it. To achieve this goal, the CE management 233 application will first ask an FE to connect to a new CE and would 234 then instruct that FE to change its master to the new CE as described 235 in [RFC7121]. 237 2.3. Adding New Resources To An NE 239 Assume a resource pooling setup with multiple FEs belonging to a 240 resource pool all connected to a dormant resource pool CE. An NE 241 system manager by demand could move an FE from the resource pool to a 242 working NE by asking it first to connect to a CE on the working NE 243 and then asking it to disconnect from the resource pool manager CE. 245 2.4. New LFB class installation 247 A CE can learn, via the DynamicLFBLoading capability of the SM LFB, 248 whether an FE is capable of loading new LFB classes. Provided that 249 the FE supports new LFB class loading, the CE can request a new LFB 250 to be installed and supported by the FE. 252 To load an LFB class on an FE, the CE will have to provide the 253 following parameters: 255 LFB class - The LFB class ID 257 LFB version - The version of the LFB class 259 LFB class name - Optional, the LFB name 261 Parameters - Optional parameters. These parameters are 262 implementation specific, for example in one implementation they 263 may contain the path where the LFB class implementation resides. 265 The parameter are fields which will be need to be described in 266 documentation, depending on the implementation. As an example the 267 location of the LFB Class to be installed and/or mechanism to 268 download it. The exact detail of the location semantics is 269 implementation specific and out of scope of this document. However 270 this LFB library provides a placeholder, namely the 271 SupportedParameters capability, which will host any standardized 272 parameters. 274 This document does not standardize these parameters. It is expected 275 that some future document will perform that task. These parameters 276 are placeholders for future use, in order not to redefine the LFB 277 class versions each time. They are simple strings that define the 278 parameters supported by the LFB. The CE is expected to read this 279 capability in order to understand the parameters it can use. 281 2.5. Logging Mechanism 283 The SM LFB class also provides a useful log level manipulation. 284 Experience has proven that the CE may require to increase or decrease 285 the debug levels of parts of the FE, whether that be LFBs or portions 286 of LFBs or generic processing code (all called modules). The module 287 granularity is implementation specific and is not discussed in this 288 document. The debug levels are derived from 289 defined in [RFC3164]. 292 2.6. General Purpose Attribute Definition 294 Experience has shown that a generic attribute name-value pair is 295 useful for describing config information. This LFB class defines 296 such a generic attribute name-value pair defined as a table of 297 attribute-name values. The attribute name-value pair is 298 implementation specific and at the moment there is nothing to 299 standardize. As an example consider switches which have exactly the 300 same LFB classes and capabilities but needing to be used in different 301 roles. A good example would be a switch which could be used either 302 as Spine or ToR in data-centre setups. An attribute which defines 303 the role could be retrieved from the FE which will then dictate how 304 it is controlled/configured. However, as in the case of LFB class 305 loading parameters this LFB class library provides a placeholder, 306 namely the SupportedArguments capability, which will host any 307 standardized arguments. This document does not standardize these 308 parameters. It is expected that some future document(s) help 309 standardize or define good practise of such attributes. It is 310 expected that the CE read this capability in order to know what the 311 attributes it can use. 313 3. Applicability statement 315 Examples of SM usage are the following, but not limiting, two usage 316 scenarios. These two, but not limiting, scenarios are not 317 implementation details, but rather depict how the SM class can be 318 used to achieve the intended subsidiary mechanism for manipulating 319 the configuration of FEs. 321 3.1. FE Integrated 323 Only one instance of the SM LFB class can exist and is directly 324 related to the FE. 326 3.2. Virtual FEs 328 In the case of the FE software that has hierarchical virtual FEs, 329 multiple instances of the SM LFB class can exist, one per each 330 virtual FE. 332 4. SM Library 334 4.1. Frame Definitions 336 This LFB class does not define any frames 338 4.2. Datatype Definitions 340 This library defines the following datatypes. 342 +------------+--------------------------------------+---------------+ 343 | DataType | Type | Synopsis | 344 | Name | | | 345 +------------+--------------------------------------+---------------+ 346 | loglevels | An enumerated char based atomic | The possible | 347 | | datatype. | debug log | 348 | | | levels. | 349 | | | Derived from | 350 | | | syslog. | 351 | LogRowType | A struct containing three | The logging | 352 | | components. The LogModule (string), | module row | 353 | | the optional ModuleFilename (string) | | 354 | | and optional DebugLevel which is one | | 355 | | of the enumerated loglevels. | | 356 | CERow | A Struct that contains three | A struct that | 357 | | components. The address family of | defines the | 358 | | the CE IP (uchar), the CE's IPs | CE table row. | 359 | | (octetstring[16] and the CE's ID | | 360 | | (uint32) | | 361 | LCRowtype | A Struct that contains four | The LFB Class | 362 | | components. The LFB Class ID | Config | 363 | | (uint32), the LFB version | Definition | 364 | | (string[8]), the optional LFB Name | | 365 | | (string) and optional Parameters | | 366 | | (string). | | 367 | NameVal | A Struct that contains two | Arbitrary | 368 | | components. An attribute name | Name Value | 369 | | (string) and an attribute value | struct | 370 | | (string) | | 371 +------------+--------------------------------------+---------------+ 373 FEM Data Types 375 4.3. Metadata Definitions 377 This LFB does not define any metadata definition 379 4.4. SM 381 The Subsidiary Mechanism LFB is an LFB that standardizes 382 configuration of the FE parameters. 384 4.4.1. Data Handling 386 The SM LFB does not handle any packets. It's function is to provide 387 the configuration parameters to the CE to be updated at runtime. 389 4.4.2. Components 391 This LFB class has four components specified. 393 The Debug component (ID 1) is a table to support changing of an FE's 394 module debug levels. Changes in an FE's debug table rows will alter 395 the debug level of the corresponding module. 397 The LFBLoad component (ID 2) is a table of LFBs classes that the FE 398 loads. Adding new rows in this table instructs the FE to load new 399 LFB classes, and removing rows will unload them when possible. These 400 two actions will in effect alter the SupportedLFBs capabilities table 401 of FEObject LFB [RFC5812]. Each such row MUST provide (and is 402 specified by this library) the LFB Class ID. Optionally the LFB 403 class ID version may be specified, the FE MUST assume that version 404 1.0 is used when the version is unspecified. 406 The AttributeValues component (ID 3) is the AttributeValues table, a 407 generic attribute-value pair. 409 The CEs (ID 4) is the table of runtime CEs we are asking the FE to be 410 able to connect with. By adding a row in this table, the CE 411 instructs the FE to be able to connect with the specified CE. By 412 doing a delete on this table, the CE instructs the FE to terminate 413 any connection with that CE. How the FE interacts with the new CEs 414 is dependent on the operations discussed in [RFC7121] 416 It is worth noting that the generic attribute value pairs, the 417 LFBload parameters and the module information are all strings. To 418 cope with string sizes, a CE application can extract that information 419 from the component properties as defined in [RFC5812] 421 4.4.3. Capabilities 423 This LFB provides three capabilities. The first, DynamicLFBLoading, 424 specifies whether this FE supports dynamic loading of new LFB 425 classes. The second, SupportedParameters, is a placeholder and will 426 store all the supported parameters for LFB class loading. The final, 427 SupportedAttributes, is also a placeholder and will store all the 428 supported attributes for the attribute-value pair table. 430 4.4.4. Events 432 This LFB has four events specified. 434 Two events reflect CE additions and report to the CE whether an entry 435 of the CEs information has been added or deleted. In both cases the 436 event report constitutes the added or deleted row contents. 438 The other two events reflect LFB class loading and notify whether an 439 entry of the LFBLoad table is added or deleted. 441 5. XML for SM LFB 443 445 446 447 448 loglevels 449 The possible debug log levels. Derived from syslog. 450 451 452 char 453 454 455 DEB_OFF 456 The logs are totally turned off 457 458 459 DEB_EMERG 460 Emergency level 461 462 463 DEB_ALERT 464 Alert level 465 466 467 DEB_CRIT 468 Critical level 469 470 471 DEB_ERR 472 error level 473 474 475 DEB_WARNING 476 warning level 477 478 479 DEB_NOTICE 480 Notice level 481 482 483 DEB_INFO 484 Info level 485 486 487 DEB_DEBUG 488 Debug level 489 490 491 492 493 494 LogRowtype 495 The logging module row 496 497 498 lmodule 499 The LOG Module Name 500 string 501 502 503 filename 504 The Module File Name 505 506 string 507 508 509 deblvl 510 debug level 511 512 loglevels 513 514 515 516 517 CERow 518 The CE Table Row 519 520 521 AddressFamily 522 The address family 523 524 uchar 525 526 527 IFA_AF_INET 528 IPv4 529 530 531 IFA_AF_INET6 532 IPv6 533 535 536 537 538 539 CEIP 540 CE ip v4 or v6(selected by family) 541 octetstring[16] 542 543 544 CEID 545 The CE ID 546 547 uint32 548 549 550 551 552 LCRowtype 553 The LFB Class Config Definition 554 555 556 LFBClassID 557 The LFB Class ID 558 uint32 559 560 561 LFBVersion 562 The LFB Class Version 563 564 string 565 566 567 LFBName 568 The LFB Class Name 569 570 string 571 572 573 Parameters 574 Optional parameters such as where the LFB is 575 located 576 577 string 578 579 580 581 582 NameVal 583 Arbitrary Name Value struct 584 585 586 AttrName 587 The Attribute Name 588 string 589 590 591 AttrVal 592 The Attribute Value 593 string 594 595 596 597 598 599 600 SM 601 602 The Subsidiary Management LFB 603 604 1.0 605 606 607 Debug 608 A table to support changing of all debug levels 609 610 611 LogRowtype 612 613 614 615 LFBLoad 616 An LFB Class to Load 617 618 LCRowtype 619 620 621 622 AttributeValues 623 Table of general purpose SM attribute Values 624 625 626 NameVal 627 628 629 630 CEs 631 Table of CEs we are asking the FE to associate 632 with 633 634 CERow 635 636 637 638 639 640 641 DynamicLFBLoading 642 This capability specifies whether this FE supports 643 dynamic loading of new LFBs 644 boolean 645 646 647 SupportedParameters 648 This capability contains all the supported 649 parameters 650 651 string 652 653 654 655 SupportedAttributes 656 This capability contains all the supported 657 attributes names 658 659 string 660 661 662 663 664 665 CEAdded 666 An CE has been added 667 668 CEs 669 670 671 672 673 CEs 674 _CEIDsrowid_ 675 676 677 678 679 CEDeleted 680 An CE has been deleted 681 682 CEs 683 _CEIDsrowid_ 684 685 686 687 688 CEs 689 _CEIDsrowid_ 690 691 692 693 694 LFBLoaded 695 An LFB has been loaded 696 697 LFBLoad 698 699 700 701 702 LFBLoad 703 _LFBLoadrowid_ 704 705 706 707 708 LFBUnloaded 709 An CE has been unloaded 710 711 LFBLoad 712 _LFBLoadrowid_ 713 714 715 716 717 LFBLoad 718 _LFBLoadrowid_ 719 720 721 722 723 724 725 726 Figure 2: FEM XML LFB library 728 6. Security Considerations 730 This document does not alter the ForCES Model [RFC5812] or the ForCES 731 Protocol [RFC5810]. As such, it has no impact on their security 732 considerations. This document simply defines the operational 733 parameters and capabilities of an LFB that manages subsidiary 734 mechanism for loading LFBs and create new connections between FEs and 735 CEs. 737 On the issue of trust, a designer should take into account that the 738 CE that creating new connections to CEs is either: 740 o The FE manager which is the one responsible for managing the FEs 742 o An already associated CE 744 In both these cases, the entity making the connections should already 745 be trusted to perform such activities. If the entity making the 746 connections is faulty, rogue or hacked, there is no way for the FE to 747 know and will perform any action that the CE requests. Therefore, 748 this document does not attempt to analyze the security issues that 749 may arise from misuse of the SM LFB. Any such issues, if they exist, 750 and mitigation strategies are for the designers of the particular SM 751 implementation, not the general mechanism. 753 The reader is also referred to the ForCES framework [RFC3746] 754 document, particular section 8, for an analysis of potential threats 755 introduced by ForCES and how the ForCES architecture addresses them. 757 7. IANA Considerations 759 7.1. LFB Class Names and LFB Class Identifiers 761 LFB classes defined by this document belong to LFBs defined by 762 Standards Track RFCs. According to IANA, the registration procedure 763 is Standards Action for the range 0 to 65535 and First Come First 764 Served with any publicly available specification for over 65535. 765 This specification includes the following LFB class names and LFB 766 class identifiers: 768 +------------+-------+---------+------------------------+-----------+ 769 | LFB Class | LFB | LFB | Description | Reference | 770 | Identifier | Class | Version | | | 771 | | Name | | | | 772 +------------+-------+---------+------------------------+-----------+ 773 | 19 | SM | 1.0 | An SM LFB to | This | 774 | | | | standardize subsidiary | document | 775 | | | | management for ForCES | | 776 | | | | Network Elements | | 777 +------------+-------+---------+------------------------+-----------+ 779 Logical Functional Block (LFB) Class Names and Class Identifiers 781 8. Acknowledgments 783 The authors would like to thank Damascene Joachimpillai, Joel 784 Halpern, Chuanhuang Li, and many others for their discussions and 785 support. 787 The authors are grateful to Joel Halpern for shepherding this 788 document. The authors would also like to thank Alia Atlas for taking 789 on the role of sponsoring this document. Finally Juergen 790 Schoenwaelder for his operational directorate's review and Alexey 791 Melnikov for his security review. 793 9. References 795 9.1. Normative References 797 [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., 798 Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and 799 J. Halpern, "Forwarding and Control Element Separation 800 (ForCES) Protocol Specification", RFC 5810, 801 DOI 10.17487/RFC5810, March 2010, 802 . 804 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 805 Element Separation (ForCES) Forwarding Element Model", 806 RFC 5812, DOI 10.17487/RFC5812, March 2010, 807 . 809 [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, 810 "High Availability within a Forwarding and Control Element 811 Separation (ForCES) Network Element", RFC 7121, 812 DOI 10.17487/RFC7121, February 2014, 813 . 815 9.2. Informative References 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, 819 DOI 10.17487/RFC2119, March 1997, 820 . 822 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 823 DOI 10.17487/RFC3164, August 2001, 824 . 826 [RFC3654] Khosravi, H., Ed. and T. Anderson, Ed., "Requirements for 827 Separation of IP Control and Forwarding", RFC 3654, 828 DOI 10.17487/RFC3654, November 2003, 829 . 831 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 832 "Forwarding and Control Element Separation (ForCES) 833 Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, 834 . 836 Authors' Addresses 838 Bhumip Khasnabish 839 ZTE TX, Inc. 840 55 Madison Avenue, Suite 160 841 Morristown, New Jersey 07960 842 USA 844 Phone: +001-781-752-8003 845 Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com 846 URI: http://tinyurl.com/bhumip/ 848 Evangelos Haleplidis 849 University of Patras 850 Department of Electrical and Computer Engineering 851 Patras 26500 852 Greece 854 Email: ehalep@ece.upatras.gr 855 Jamal Hadi Salim (editor) 856 Mojatatu Networks 857 Suite 200, 15 Fitzgerald Rd, 858 Ottawa, Ontario K2H 9G1 859 Canada 861 Email: hadi@mojatatu.com