IETF ForCES Logical Function Block (LFB) Subsidiary Management

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 Subsidiary Mechanism (SM) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM 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 SM LFB.

shows a control application manipulating, at runtime, FE config via the SM LFB control. It would appear that that control application is playing the part of the FE Manager thus appears as the messaging for Ff (FEM to FE interface) going via the standard Fp plane. However the SM LFB describes a subset of the operations that can be performed over Ff; it does not suggest moving away from the Ff interface. The SM LFB describes the configuration parameters of an FE, namely the LFB classes it should load, the CEs it should be associated with as well the respective CE IP addresses. Additionally the SM LFB provides a general purpose attribute definition to describe config information, as well as the ability to manipulate debug logging mechanism. This document assumes that FEs are already booted. The FE's configuration can then be updated at runtime via the SM LFB for runtime config purposes. This document does not specify or standardize the FEM-FE (Ff) interface as depicted in . This document describes a mechanism with which a CE can instruct the SM for FE management using ForCES. 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 .

This document follows the terminology defined by , , and . In particular, the reader is expected to be familiar with the following terms: Logical Functional Block (LFB) Forwarding Element (FE) Control Element (CE) ForCES Network Element (NE) FE Manager (FEM) CE Manager ForCES Protocol ForCES Protocol Layer (ForCES PL) ForCES Protocol Transport Mapping Layer (ForCES TML)

In this section we present sample use cases to illustrate the need and usefulness of the SM LFB. All use cases assume that an FE is already booted up and tied to at least one CE. A control application can delete a CE from an FE's table of CEs which instructs the FE to terminate the connection with that removed CE. Likewise, the control application via the master CE instructs an FE to establish a ForCES association with a new CE by adding a particular CE to the FE's CEs table.

Assume an FE associated to only one CE. At runtime, a CE management application may request for redundancy reasons that an FE to be associated to another CE as a backup. To achieve this goal, the CE management application specifies the CEID of the new backup CE (to be uniquely identified within the NE) and the CE's IP address (IPv4 or IPv6).

Assume an NE cluster that has FEs connected possibly in an active backup setup to multiple CEs. Assume that system analytics discover that the CE is becoming a bottleneck. A new CE could be be booted and some FEs moved to it. To achieve this goal, the CE management application will first ask an FE to connect to a new CE and would then instruct that FE to change its master to the new CE as described in .

Assume a resource pooling setup with multiple FEs belonging to a resource pool all connected to a dormant resource pool CE. An NE system manager by demand could move an FE from the resource pool to a working NE by asking it first to connect to a CE on the working NE and then asking it to disconnect from the resource pool manager CE.

A CE can learn via the capability of SM 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 following parameters: LFB class - The LFB class ID LFB version - The version of the LFB class LFB class name - Optional, the LFB name Parameters - Optional parameters. These parameters are implementation specific, for example in one implementation they may contain the path where the LFB class implementation resides. The parameter are fields which will be need to be described in documentation, depending on the implementation. As an example the location of the LFB Class to be installed and/or mechanism to download it. The exact detail of the location semantics is implementation specific and out of scope of this document. However this LFB library provides a placeholder, namely the SupportedParameters capability, which will host any standardized parameters. This document does not standardize these parameters. It is expected that some future document will perform that task.

The SM LFB library also provides a useful log level manipulation. Experience has proven that the CE may require to increase or decrease the debug levels of parts of the FE, whether that be LFBs or portions of LFBs or generic processing code (all called modules). The module granularity is implementation specific and is not discussed in this document.

Experience has shown that a generic attribute name-value pair is useful for describing config information. This LFB library defines such a generic attribute name-value pair defined as a table of attribute-name values. The attribute name-value pair is implementation specific and at the moment there is nothing to standardize. As an example consider switches which have exactly the same LFB classes and capabilities but needing to be used in different roles. A good example would be a switch which could be used either as Spine or ToR in data-centre setups. An attribute which defines the role could be retrieved from the FE which will then dictate how it is controlled/configured. However, as in the case of LFB class loading parameters this LFB class library provides a placeholder, namely the SupportedArguments capability, which will host any standardized arguments. This document does not standardize these parameters. It is expected that some future document(s) help standardize or define good practise of such attributes.

Examples of SM usage are the following, but not limiting, two usage scenarios. These two, but not limiting, scenarios are not implementation details, but rather depict how the SM class can be used to achieve the intended subsidiary mechanism for manipulating the configuration of FEs.

Only one instance of the SM class can exist and is directly related to the FE.

In the case of the FE software that has hierarchical virtual FEs, multiple instances of the SM class can exist, one per each virtual FE.

This LFB does not define any frames

This library defines the following datatypes. DataType Name Type Synopsis loglevels An enumerated char based atomic datatype. The possible debug log levels. Derived from syslog. LogRowType A struct containing three components. The LogModule (string), the optional ModuleFilename (string) and optional DebugLevel which is one of the enumerated loglevels. The logging module row CERow A Struct that contains three components. The address family of the CE IP (uchar), the CE's IPs (octetstring[16] and the CE's ID (uint32) A struct that defines the CE table row. LCRowtype A Struct that contains four components. The LFB Class ID (uint32), the LFB version (string[8]), the optional LFB Name (string) and optional Parameters (string). The LFB Class Config Definition NameVal A Struct that contains two components. An attribute name (string) and an attribute value (string) Arbitrary Name Value struct

This LFB does not define any metadata definition

The Subsidiary Mechanism LFB is an LFB that standardizes configuration of the FE parameters.

The SM 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 Debug component (ID 1) is a table to support changing of an FE's module debug levels. Changes in an FE's debug table rows will alter the debug level of the corresponding module. The LFBLoad component (ID 2) is a table of LFBs classes that the FE loads. Adding new rows in this table instructs the FE to load new LFB classes, and removing rows will unload them when possible. These two actions will in effect alter the SupportedLFBs capabilities table of FEObject LFB . Each such row MUST provide (and is specified by this library) the LFB Class ID. Optionally the LFB class ID version may be specified, the FE MUST assume that version 1.0 is used when the version is unspecified. The AttributeValues component (ID 3) is the AttributeValues table, a generic attribute-value pair. The CEs (ID 4) is the table of runtime CEs we are asking the FE to be able to connect with. By adding a row in this table, the CE instructs the FE to be able to connect with the specified CE. By doing a delete on this table, the CE instructs the FE to terminate any connection with that CE. How the FE interacts with the new CEs is dependent on the operations discussed in It is worth noting that the generic attribute value pairs, the LFBload parameters and the module information are all strings. To cope with string sizes, a CE application can extract that information from the component properties as defined in

This LFB provides three capabilities. The first, DynamicLFBLoading, specifies whether this FE supports dynamic loading of new LFB classes. The second, SupportedParameters, is a placeholder and will store all the supported parameters for LFB class loading. The final, SupportedAttributes, is also a placeholder and will store all the supported attributes for the attribute-value pair table.

This LFB has four events specified. Two events reflect CE additions and report to the CE whether an entry of the CEs information has been added or deleted. In both cases the event report constitutes the added or deleted row contents. The other two events reflect LFB class loading and notify whether an entry of the LFBLoad table is added or deleted.

loglevels The possible debug log levels. Derived from syslog. char DEB_OFF The logs are totally turned off DEB_EMERG Emergency level DEB_ALERT Alert level DEB_CRIT Critical level DEB_ERR error level DEB_WARNING warning level DEB_NOTICE Notice level DEB_INFO Info level DEB_DEBUG Debug level LogRowtype The logging module row lmodule The LOG Module Name string filename The Module File Name string deblvl debug level loglevels CERow The CE Table Row AddressFamily The address family uchar IFA_AF_INET IPv4 IFA_AF_INET6 IPv6 CEIP CE ip v4 or v6(selected by family) octetstring[16] CEID The CE ID uint32 LCRowtype The LFB Class Config Definition LFBClassID The LFB Class ID uint32 LFBVersion The LFB Class Version string LFBName The LFB Class Name string Parameters Optional parameters such as where the LFB is located string NameVal Arbitrary Name Value struct AttrName The Attribute Name string AttrVal The Attribute Value string SM The Subsidiary Management LFB 1.0 Debug A table to support changing of all debug levels LogRowtype LFBLoad An LFB Class to Load LCRowtype AttributeValues Table of general purpose SM attribute Values NameVal CEs Table of CEs we are asking the FE to associate with CERow DynamicLFBLoading This capability specifies whether this FE supports dynamic loading of new LFBs boolean SupportedParameters This capability contains all the supported parameters string SupportedAttributes This capability contains all the supported attributes names string CEAdded An CE has been added CEs CEs _CEIDsrowid_ CEDeleted An CE has been deleted CEs _CEIDsrowid_ CEs _CEIDsrowid_ LFBLoaded An LFB has been loaded LFBLoad LFBLoad _LFBLoadrowid_ LFBUnloaded An CE has been unloaded LFBLoad _LFBLoadrowid_ LFBLoad _LFBLoadrowid_ ]]>

This document does not alter the ForCES Model or the ForCES Protocol. As such, it has no impact on their security considerations. This document simply defines the operational parameters and capabilities of an LFB that manages subsidiary mechanism for loading LFBs and create new connections between FEs and CEs. This document does not attempt to analyze the security issues that may arise from misuse of the SM LFB. Any such issues, if they exist, and mitigation strategies are for the designers of the particular SM implementation, not the general mechanism.

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 19 SM 1.0 An SM LFB to standardize subsidiary management for ForCES Network Elements This document

The authors would like to thank Damascene Joachimpillai, Joel Halpern, Chuanhuang Li, and many others for their discussions and support. The authors are grateful to Joel Halpern for shepherding this document. The authors would also like to thank Alia Atlas for taking on the role of sponsoring this document.