IETF ForCES Logical Function Block (LFB) Subsidiary Management

This document discusses ForCES Logical Function Block (LFB) Subsidiary Management (SM). Note that LFB SM is useful for introducing and supporting virtualization of ForCES Network Element (NE) including control Element (CE) and Network Element (NE). Deployment experience has demonstrated the value of using ForCES to control the Forwarding Element Manager (FEM) by creating an LFB to represent its function using the same encoding rules as for any other LFB. This allows it to be controlled by the same Control Element (CE). This work item assumes the presence of an initially booted FE whose configuration could then be updated at runtime via an FEM LFB for runtime config purposes (e.g., by adding a new CE and its associated IP address). This work item 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. This work would result in a standards track LFB FEM library RFC.

The scope of this document is discussion (and standardization) of utilizing virtualized NEs (VNEs)for virtual CEs (VCEs) and virtual FEs (VFEs). The currently existing techniques and solutions may be either slow or not directly applicable to ForCES LFB subsidiary management.

API: Application Programming Interface CE: Control Element CEM: CE Manager CEV: CE Visor FE: Forwarding Element FEM: FE Manager FEV: FE Visor ForCES: Forwarding and Control Element Separation LFB: Logical Functional Block NE: Network Element PL: Protocol Layer SFC: Service Function Chaining VCE: Virtual CE VFE: Virtual FE VNE: Virtual NE

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 . The following definitions are taken from , and . They are repeated here for convenience as needed, but the normative definitions are found in the referenced RFCs: Logical Functional Block (LFB) -- A template that represents a fine-grained, logically separate aspects of FE processing. Forwarding Element (FE) - A logical entity that implements the ForCES Protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed by a CE via the ForCES Protocol. Control Element (CE) - A logical entity that implements the ForCES Protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols. ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. An NE usually hides its internal organization from external entities and represents a single point of management to entities outside the NE. FE Manager (FEM) - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) an FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. ForCES Protocol -- The protocol used for communication communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. ForCES Protocol Layer (ForCES PL) -- A layer in the ForCES protocol architecture that defines the ForCES protocol messages, the protocol state transfer scheme, and the ForCES protocol architecture itself (including requirements of ForCES TML as shown below). Specifications of ForCES PL are defined in ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES protocol architecture that specifically addresses the protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like SCTP, IP, TCP, UDP, ATM, Ethernet, etc), and how to achieve and implement reliability, security, etc.

Virtualization of ForCES Elements allows efficient, scalabl, 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 visiblity 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 visiblity 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.

In this section we discuss a few potential scenarios that can utilize ForCES LFB subsidiary management for efficient and robust operation of networks withut using excessive additional resources.

In this section we discuss how virtualization of CEs can be used for efiicient recovery from CE failure(s).

In this section we discuss how virtualization of FEs can be used for efiicient recovery from FE failure(s).

In this section we discuss efficient load balancing of both CE and FE in virtualized environment.

In this section we discuss how LFB subsidiary management can contribute to the robust/scalable implementation of Service Function Chaining (SFC).

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 whihc has just been booted, as described in teh previous sub-section, needs initial bootstrap configuration (e.g., what CEs to connect to etc). This clearly falls in the FEM 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.

TBD.

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 the LFB name (string) 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. FEParams A Struct that contains four components. An FE's ID (uint32), the FE's IPs (array of IPs), the LFBs this FE supports (array of LFBDefs) and the CEs this FE is part of (array of CEParams). A struct that defines the FE parameters.

This LFB does not define any metadata definition

The LFB is an LFB that standardizes and assists creation of NEs.

The FEM LFB does not handle any packets. It's function is to subsidize creation of NEs. A CE or a CEM will request from the FEM the creation of the NE, it will provide the requirements, e.g. FEs, LFBs in FEs etc..., and depending on the implementation the FEM may create these FE instances, or if these instances exist, provide the bootstrap information to FEs how and where to connect to the CEs.

This LFB has only one component specified. The NEs component, is a component that contains all the Network Elements this FEM is responsible for maintaining. It is a table and each row is a struct of the NEID, a uint32 and an array of FE parameters.

This LFB has no Capabilities specified.

This LFB has three events specified. These events notify the CE whether an NE has been added, deleted or changed. The event report is the NEs row that created the event.

IPs IP definition FEIPv4 The FEs IPv4 byte[4] FEIPv6 The FEs IPv6 byte[16] LFBDefs LFB parameters inside the FE LFBClassID The LFB CLass ID uint32 LFBVersion The Version of the LFB string LFBName The name of the LFB string CEParams CE parameters CEID The CE ID uint32 CEIP The CEIP IPs FEParams FE parameters FEID The FEID uint32 FEIP The FE's IP IPs LFBparameters The LFBs in this FE LFBDefs CEs The CEs that should be associated with this FE CEParams FEM The Forwarding Element Manager LFB 1.0 NEs All the Network Elements this FEM is responsible for maintaining NEID ID of the Network Element uint32 FEs FEs in the Network Element FEParams NEchanged The NE definition has changed NEs NEs _NEsrowid_ NEcreated An NE has been created NEs NEs _NEsrowid_ NEdeleted An NE has been deleted NEs NEs _NEsrowid_ ]]>

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 FEM 1.0 An FEM LFB to standardize creation of ForCES Network Elements This document

The authors would like to thank DJ, Joel, and many others for their discussions and support.