| ForCES WG | B. Khasnabish |
| Internet-Draft | ZTE TX, Inc. |
| Intended status: Standards Track | E. Haleplidis |
| Expires: August 30, 2015 | University of Patras |
| J. Hadi Salim, Ed. | |
| Mojatatu Networks | |
| February 26, 2015 |
IETF ForCES Logical Function Block (LFB) Subsidiary Management
draft-ietf-forces-lfb-subsidiary-management-00
Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, the Forwarding Element Manager (FEM) is modelled by creating a Logical Functional Block (LFB) to represent its functionality. We refer to this LFB as the FE Configuration (FEC) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the FEC LFB. This document introduces the FEC LFB, an LFB that specifies the configuration parameters of an FE.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, the Forwarding Element Manager (FEM) is modelled by creating a Logical Functional Block (LFB) to represent its functionality. We refer to this LFB as the FE Configuration (FEC) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the FEC LFB. This document introduces the FEC LFB, an LFB that specifies the configuration parameters of an FE.
On a running FE, a CE application may update an FE's runtime configuration via the FEC LFB.
ForCES Network Element
+-------------------------------------+
| +---------------------+ |
| | Control Application | |
| +--+--------------+---+ |
| | | |
| | | |
-------------- Fc | -----------+--+ +-----+------+ |
| CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | |
| | +-+---------+-+ +------------+ |
| Fl | | | Fp/Ff / |
| | | +--------+ / |
| | |Fp/Ff |/ |
| | | | |
| | | Fp/Ff /|----+ |
| | | /--------/ | |
-------------- Ff | ---+---------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
Fp: CE-FE interface
Fc: Interface between the CE Manager and a CE
Ff: Interface between the FE Manager and an FE
Fl: Interface between the CE Manager and the FE Manager
Fi/f: FE external interface
Figure 1: ForCES Architectural Diagram
Figure 1 shows a control application manipulating, at runtime, FE config via the FEC LFB control. The above illustration is derived from Figure 1 in [RFC3746] with modifications showing the messaging for Ff (FEM to FE interface) going via the standard Fp plane. This is merely to demonstrate that the messaging is happening via the traditional Fp interface to the FEM/FEC; it does not however suggest moving away from the Ff interface.
The FEC LFB describes the configuration parameters of an FE, namely, the FEID, the FE IP address(es), the CEs it should be associated with, as well as the LFBs that it supports.
This document assumes that FEs are already booted. The FE's configuration can then be updated at runtime via the FEC LFB for runtime config purposes. This document does not specify or standardize the FEM-FE (Ff) interface as depicted in [RFC3746]. This document describes a mechanism with which a CE can instruct the FEC for FE management using ForCES.
In the case where we have a pool of unused packet processing resources that can be utilized as FEs, the FEC can be utilized to instruct the FE resource to join the Network Element cluster. The initiation would involve control of the creation, configuration, and resource assignment of FEs so as to be part of an NE. Appendix A describes how a resource pool of virtual machines could be initiated as basic CEs or FEs via an orchestration system and subsequently initiated into being part of an FE via the FEM. Again, it should be emphasized that the pools of FEs and CEs are already booted up by some resource owner, e.g. an FEM or an Element Management System (EMS). Subsidiary management provides the LFB library necessary, to manage and configure at runtime, these FEs to disconnect from the "resource pool CE" and join one or more CEs in the running NE.
This work item makes no assumption of whether FE resources are physical or virtual. In fact, the LFB library provided here is applicable to both. Thus it can also be useful in addressing control of virtual FEs where individual FEM Managers can be addressed to control the creation, configuration, and resource assignment of such virtual FEs within a physical FE.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document follows the terminology defined by [RFC3654], [RFC3746], [RFC5810] and [RFC5812]. In particular, the reader is expected to be familiar with the following terms:
In this section we present sample use cases to illustrate the need and usefulness of the FEC LFB.
All use cases assume that an FEs and CEs have already been bootstrapped and instantiated but have not joined the NE. These FEs and CEs belong to a pool of untapped resources.
The CE may request, for reasons such as performance, redundancy, load-sharing or new functionality request, to incorporate a new FE in the NE. The CE would be required to specify the following parameters. Firstly the FEID in order for the new FE to be uniquely identified within the NE. Second the FE IP address to bind to, IPv4 or IPv6. Thirdly the LFBs to be instantiated within the FE, by means of providing the LFB class, LFB version and LFB name. Finally the CEs that the new FE should associate within the NE as soon as it is integrated within the NE. This includes the CE IDs as well as their corresponding CE IP addresses.
A CE may request for redundancy reasons that an FE to be associated to another CE as a backup at runtime. To achieve this goal, the master CE specifies the CEID of the new backup CE (to be uniquely identified within the NE) and the CE's IP address (IPv4 or IPv6, or IP addresses should the CE support multiple interfaces).
The CE will configure all FEC LFBs to the FEs within the NE of the CE ID and CE IP addresses in order for the FEs to perform the necessary actions ordered by the CE and described by [RFC7121].
the master CE, e.g. detecting a malfunctioning CE, could remove a backup CE from the FE.
A CE can learn via the capability of FEC LFB whether an FE is capable of loading new LFB classes. Provided that the FE supports new LFB class loading, the CE can request a new LFB to be installed and supported by the FE.
To load an LFB class on an FE, the CE will have to provide the LFB class and the LFB class version. There are optional fields which may be need to be described, depending on the implementation (out of scope for this document). Example:
Examples of FEC usage are the following, but not limiting, three usage scenarios. These scenarios are not implementation details, but rather depict how the FEC class can be used to achieve the intended subsidiary mechanism for manipulating the configuration of FEs.
Only one instance of the FEC class can exist and is directly related to the FE. The configuration parameters pertain to the parent FE.
In the case of the FE software that has hierarchical virtual FEs, multiple instances of the FEC class can exist, one per each virtual FE.
The third scenario, pertains to FEC LFB implementation as FE Manager paremeters. In such a case, the FE configurations are locally and logically centralized by the FE manager. The FE manager may hold multiple instances of the FEC class in the FEM, one per each FE. Using the ForCES protocol a CE, through the Fp interface, or a CE Manager via the Fl interface, will instruct the FEM to change the configuration of the FEs. The FEM may hold more information pertaining the NE, such as the topology and chaining of FEs which the CE would require to alter, along with the FE changes. In such a case the Ff interface is out of scope.
This LFB does not define any frames
This library defines the following datatypes.
| DataType Name | Type | Synopsis |
|---|---|---|
| IPs | A Struct of 2 components. IPv4 (byte[4]) and IPv6 (byte[16]) addresses. | A struct that defines an IPv4 and an IPv6 address |
| LFBDefs | A Struct that contains three components. The LFB Class ID (uint32), the LFB version (string) and optional the LFB name (string) and the location of the LFB where it will be retrieved from. | A struct that defines basic LFB definitions |
| CEParams | A Struct that contains two components. A CE's ID (uint32) and the CE's IPs (array of IPs) | A struct that defines CE parameters. |
This LFB does not define any metadata definition
The FE Configuration LFB is an LFB that standardizes configuration of the FE parameters.
The FEC LFB does not handle any packets. It's function is to provide the configuration parameters to the CE to be updated at runtime.
This LFB has four components specified. The FEID, a uint32 component that defines the ID of the FE. The FEIP, a table of IP address, and each row is a struct of an IPv4 and an IPv6 address. The LFB Parameters, a table of LFBs, each row a struct of LFB Class ID, LFB Version and optional LFB name and location. Finally the CEs, a table of CE parameters, each row a struct of a CE ID and a table of CE IPs.
This capability specifies whether this FE supports dynamic loading of new LFBs.
This LFB has five events specified. These events notify the CE whether the FEID has been changed, an entry of the FEIP table has been created or changed and an entry of the CE information added or deleted. The event reports are the respective data that has been modified.
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" provides="FEC">
<dataTypeDefs>
<dataTypeDef>
<name>IPs</name>
<synopsis>IP definition</synopsis>
<struct>
<component componentID="1">
<name>FEIPv4</name>
<synopsis>The FEs IPv4</synopsis>
<typeRef>byte[4]</typeRef>
</component>
<component componentID="2">
<name>FEIPv6</name>
<synopsis>The FEs IPv6</synopsis>
<typeRef>byte[16]</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LFBDefs</name>
<synopsis>LFB parameters inside the FE</synopsis>
<struct>
<component componentID="1">
<name>LFBClassID</name>
<synopsis>The LFB Class ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>LFBVersion</name>
<synopsis>The Version of the LFB</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="3">
<name>LFBName</name>
<synopsis>The name of the LFB</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
<component componentID="4">
<name>LFBLocation</name>
<synopsis>The location of the LFB to be retrieved
from</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>CEParams</name>
<synopsis>CE parameters</synopsis>
<struct>
<component componentID="1">
<name>CEID</name>
<synopsis>The CE ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>CEIP</name>
<synopsis>The CEIP</synopsis>
<array>
<typeRef>IPs</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="21">
<name>FEC</name>
<synopsis>Forwarding Element Configuration</synopsis>
<version>1.0</version>
<components>
<component componentID="1" access="read-write">
<name>FEID</name>
<synopsis>The FEID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2" access="read-write">
<name>FEIP</name>
<synopsis>The FE's IP</synopsis>
<array>
<typeRef>IPs</typeRef>
</array>
</component>
<component componentID="3" access="read-write">
<name>LFBparameters</name>
<synopsis>The LFBs in this FE</synopsis>
<array>
<typeRef>LFBDefs</typeRef>
</array>
</component>
<component componentID="4" access="read-write">
<name>CEs</name>
<synopsis>The CEs that should be associated with this
FE</synopsis>
<array>
<typeRef>CEParams</typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="10">
<name>DynamicLFBLoading</name>
<synopsis>This capability specifies whether this FE supports
dynamic loading of new LFBs</synopsis>
<typeRef>boolean</typeRef>
</capability>
</capabilities>
<events baseID="20">
<event eventID="1">
<name>IDChanged</name>
<synopsis>The FE ID has been changed</synopsis>
<eventTarget>
<eventField>FEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>FEID</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>FEIPChanged</name>
<synopsis>An IP of the FE has been changed</synopsis>
<eventTarget>
<eventField>FEIP</eventField>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>FEIP</eventField>
<eventSubscript>_FEIPsrowid_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>FEIPCreated</name>
<synopsis>An FEIP has been deleted</synopsis>
<eventTarget>
<eventField>FEIP</eventField>
</eventTarget>
<eventDeleted/>
<eventReports>
<eventReport>
<eventField>FEIP</eventField>
<eventSubscript>_FEIPsrowid_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="4">
<name>CEAdded</name>
<synopsis>An CE has been added</synopsis>
<eventTarget>
<eventField>CEs</eventField>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>CEs</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="5">
<name>CEDeleted</name>
<synopsis>An CE has been added</synopsis>
<eventTarget>
<eventField>CEs</eventField>
</eventTarget>
<eventDeleted/>
<eventReports>
<eventReport>
<eventField>CEs</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Figure 2: FEM XML LFB library
Security considerations for ForCES LFB subsidiary management will be added in a future version of this daft.
LFB classes defined by this document belong to LFBs defined by Standards Track RFCs. According to IANA, the registration procedure is Standards Action for the range 0 to 65535 and First Come First Served with any publicly available specification for over 65535. This specification includes the following LFB class names and LFB class identifiers:
| LFB Class Identifier | LFB Class Name | LFB Version | Description | Reference |
|---|---|---|---|---|
| 21 | FEC | 1.0 | An FEC LFB to standardize creation of ForCES Network Elements | This document |
The authors would like to thank DJ, Joel, ChuanhuangLi, and many others for their discussions and support.
| [RFC5810] | Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R. and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. |
| [RFC5812] | Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010. |
| [RFC7121] | Ogawa, K., Wang, W., Haleplidis, E. and J. Hadi Salim, "High Availability within a Forwarding and Control Element Separation (ForCES) Network Element", RFC 7121, February 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3654] | Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003. |
| [RFC3746] | Yang, L., Dantu, R., Anderson, T. and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. |
Virtualization of ForCES Elements allows efficient, scalable, and robust utilization of network control and transmission resources. Virtualization has been discussed (and deployed) widely in the Computing Industry (e.g., server) in the context of efficient utilization of server resources.
As mentioned before, the currently existing techniques and solutions may be either slow or not directly applicable to ForCES LFB subsidiary management.
In this section we discuss the use of virtualized ForCES control elements (CEs). The resulting operating entities in virtualized environment are Virtual CEs of VCEs. The CE Visor (CEV) has the visibility to all of the VCEs in a domain, and can assign one of the VCEs as primary Master-VCE and another as secondary Master-VCE. CEV can dynamically manage the role of primary and secondary master-VCEs from a pool of VCEs.
In this section we discuss the use of virtualized ForCES forwarding elements (FEs). The resulting operating entities in virtualized environment are Virtual FEs of VFEs. The FE Visor (FEV) has the visibility to all of the VFEs in a domain, and can assign one of the VFEs as primary Master-VFE and another as secondary Master-VFE. FEV can dynamically manage the role of primary and secondary master-VFEs from a pool of VFEs.
The generic lifecycle of physical/virtual elements including NEs, FEs, VNEs, VCEs, VFEs, etc. consists of the following FOUR states:
Figure 1 shows physical/virtual elements states and their transition.
o--------------o o--------------o
| | | |
|Instantiation +----------------->| Association |
| | | |
o--------------o o------+-------o
^ |
| |
| |
| |
| |
o------+-------o o------V-------o
| | | |
| Release |<-----------------+ Activation |
| | | |
o--------------o o--------------o
Figure 1: Physical/Virtual Elements States and their Transition
In this section we discuss a few potential scenarios that can utilize ForCES LFB subsidiary management for efficient and robust operation of networks without using excessive additional resources.
In this section we discuss how virtualization of FEs can be used for efficient recovery from FE failure(s). An FE can initially boot using a default Association and Configuration. The Association and Configuration can be updated at runtime via an FE-Visor or FEC LFB for runtime configuration purposes. This can be achieved, for example, by adding a new CE and its associated IP address. A CE can initially boot using a default Configuration and State(s). The Configuration and State(s) can be updated at runtime via a CE-Visor or a similar CE Configuration (CEC) LFB to satisfy the runtime requirements.
.--------------.
[Apps/ | |
Service]--|Orchestration |
| |
.--------------.
| | .--------.
.-----------. | | | |
| |---| |---------------------------| |
|Controller | | |
| | | |
.-|-----|---. |Hyper- |
| | |Visor |
4 2 | |
| | | |
| CEy CEw .... CE? | |
| | \ /\ | |
| | \----/--\-------------------------------|----| |
| | / \ | .-|-. |
| FEM-----/ \-----------------------------|--| | |
.-->(FEz)<-----------------3----------------------|--|FEx| |
| .---. |
(1)----->| |
.--------.
Figure 2: Sequence of Events in FEM for Recovery from FE Failure
Note: 1.(Hyervisor) Boots up FEx, and connects to CEy and CEw, 2. Boot a VM of Type FE 3. FEx Boots FEz, and Connects to CEy, 4.Connect to CEw
As described in Figure 2, the following is a sequence of events in FEM (an example).
Note that the 4th (FEM part of the charter) and 5th steps are what we would like to achieve here. In addition, the FEVM may not need to be aware which Virtual FEs are in one Virtual NE, it only needs know of the information about a Virtual FE in the physical FE. CE Manager may need to have visibility to all Virtual NEs. The component "NE" of the LFB may be considered as Virtual NE as well.
In this section we discuss how virtualization of CEs can be used for efficient recovery from CE failure(s).
A CE can initially boot using a default Association, State, and Configuration. The Association and Configuration can be updated at runtime via a CE-Visor or FEC-LFB for runtime configuration purposes, for example, by adding a new CE and its associated IP address.
An FE can initially boot using a default Configuration, Association, with a CE, and State. The Configuration, Association can be updated at runtime via a FE-Visor or FEC LFB to satisfy runtime requirements. The sequence of events, an example, can be as follows.
As discussed earlier, the last two steps are concerned with Subsidiary management. Although we discuss the recovery method by using virtualization of CEs, the role of FEVM in the recovery process will be described further later.
In this section we discuss efficient load balancing of both CE and FE in virtualized environment.
In this section we discuss efficient Orchestration of both CE and FE in virtualized multi-admin-domain environment.
In this section we discuss generic lifecycle management of subsidiaries of LFBs in virtualized environment(s). The typical management activities in the life of FE/CE are discussed in the following sub-sections.
When an entity needs to boot a CE/FE, if this is a VM, some orchestration would scheme/plan to do this. In case of ForCES, we have a control App that boots a CE or an FE via a management FE. So here we have a management plane details that is described either in FEM or other LFB.
The FE, e.g., the VM which has just been booted, as described in the previous sub-section, needs initial bootstrap configuration (e.g., what CEs to connect to etc). This clearly falls in the FEC LFB domain.
At runtime of the FE, for example, the management could introduce a new CE for the FE to associate with; it may also be for an FE to dissociate from a CE, and so on.