draft-ietf-forces-lfb-subsidiary-management-00.txt   rfc7729.txt 
ForCES WG B. Khasnabish Internet Engineering Task Force (IETF) B. Khasnabish
Internet-Draft ZTE TX, Inc. Request for Comments: 7729 ZTE TX, Inc.
Intended status: Standards Track E. Haleplidis Category: Standards Track E. Haleplidis
Expires: August 29, 2015 University of Patras ISSN: 2070-1721 University of Patras
J. Hadi Salim, Ed. J. Hadi Salim, Ed.
Mojatatu Networks Mojatatu Networks
February 25, 2015 December 2015
IETF ForCES Logical Function Block (LFB) Subsidiary Management Forwarding and Control Element Separation (ForCES)
draft-ietf-forces-lfb-subsidiary-management-00 Logical Functional Block (LFB) Subsidiary Management
Abstract Abstract
Deployment experience has demonstrated the value of using the Deployment experience has demonstrated the value of using the
Forwarding and Control Element Separation (ForCES) architecture to Forwarding and Control Element Separation (ForCES) architecture to
manage resources other than packet forwarding. In that spirit, the manage resources other than packet forwarding. In that spirit, the
Forwarding Element Manager (FEM) is modelled by creating a Logical Forwarding Element Manager (FEM) is modeled by creating a Logical
Functional Block (LFB) to represent its functionality. We refer to Functional Block (LFB) to represent its functionality. We refer to
this LFB as the FE Configuration (FEC) LFB. A Control Element (CE) this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element
that controls a Forwarding Element's (FE) resources can also manage (CE) that controls a Forwarding Element's (FE) resources can also
its configuration via the FEC LFB. This document introduces the FEC manage its configuration via the SM LFB. This document introduces
LFB, an LFB that specifies the configuration parameters of an FE. the SM LFB class, an LFB class that specifies the configuration
parameters of an FE. The configuration parameters include new LFB
class loading and CE associations; they also provide manipulation of
debug mechanisms along with a general purpose attribute definition to
describe configuration information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 29, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7729.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. FE integration into an NE . . . . . . . . . . . . . . . . 6 2.1. High Availability . . . . . . . . . . . . . . . . . . . . 6
2.2. CE associations . . . . . . . . . . . . . . . . . . . . . 6 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. New LFB class installation . . . . . . . . . . . . . . . 7 2.3. Adding New Resources to an NE . . . . . . . . . . . . . . 6
3. Applicability statement . . . . . . . . . . . . . . . . . . . 7 2.4. New LFB Class Installation . . . . . . . . . . . . . . . 6
3.1. FE Integrated . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Logging Mechanism . . . . . . . . . . . . . . . . . . . . 7
3.2. Virtual FEs . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. General-Purpose Attribute Definition . . . . . . . . . . 7
3.3. FEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
4. FEC Library . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. FE Integrated . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Virtual FEs . . . . . . . . . . . . . . . . . . . . . . . 8
4. SM Library . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Frame Definitions . . . . . . . . . . . . . . . . . . . . 8 4.1. Frame Definitions . . . . . . . . . . . . . . . . . . . . 8
4.2. Datatype Definitions . . . . . . . . . . . . . . . . . . 8 4.2. Data Type Definitions . . . . . . . . . . . . . . . . . . 9
4.3. Metadata Definitions . . . . . . . . . . . . . . . . . . 8 4.3. Metadata Definitions . . . . . . . . . . . . . . . . . . 9
4.4. FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. SM . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 9 4.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 10
4.4.2. Components . . . . . . . . . . . . . . . . . . . . . 9 4.4.2. Components . . . . . . . . . . . . . . . . . . . . . 10
4.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 9 4.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 10
4.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 11
5. XML for FEC LFB . . . . . . . . . . . . . . . . . . . . . . . 9 5. XML for SM LFB . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 13 7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Use of Virtualized ForCES Elements . . . . . . . . . . . 15
A.1.1. Use of Virtualized CEs . . . . . . . . . . . . . . . 15
A.1.2. Use of Virtualized FEs . . . . . . . . . . . . . . . 15
A.1.3. Generic Lifecycle of Physical/Virtual Elements . . . 15
A.2. Potential Scenarios . . . . . . . . . . . . . . . . . . . 16
A.2.1. Recovery from FE failure . . . . . . . . . . . . . . 16
A.2.2. Recovery from CE failure . . . . . . . . . . . . . . 18
A.2.3. Load Balancing . . . . . . . . . . . . . . . . . . . 19
A.2.4. Orchestration . . . . . . . . . . . . . . . . . . . . 19
A.2.5. Generic LFB Lifecycle Management . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Deployment experience has demonstrated the value of using the Deployment experience has demonstrated the value of using the
Forwarding and Control Element Separation (ForCES) architecture to Forwarding and Control Element Separation (ForCES) architecture to
manage resources other than packet forwarding. In that spirit, the manage resources other than packet forwarding. In that spirit, the
Forwarding Element Manager (FEM) is modelled by creating a Logical Forwarding Element Manager (FEM) is modeled by creating a Logical
Functional Block (LFB) to represent its functionality. We refer to Functional Block (LFB) to represent its functionality. We refer to
this LFB as the FE Configuration (FEC) LFB. A Control Element (CE) this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element
that controls a Forwarding Element's (FE) resources can also manage (CE) that controls a Forwarding Element's (FE) resources can also
its configuration via the FEC LFB. This document introduces the FEC manage its configuration via the SM LFB. This document introduces
LFB, an LFB that specifies the configuration parameters of an FE. the SM LFB class, an LFB that specifies the configuration parameters
of an FE.
On a running FE, a CE application may update an FE's runtime On a running FE, a CE application may update an FE's runtime
configuration via the FEC LFB. configuration via the SM LFB instance.
ForCES Network Element ForCES Network Element
+-------------------------------------+ +-------------------------------------+
| +---------------------+ | | +---------------------+ |
| | Control Application | | | | Control Application | |
| +--+--------------+---+ | | +--+--------------+---+ |
| | | | | | | |
| | | | | | | |
-------------- Fc | -----------+--+ +-----+------+ | -------------- Fc | -----------+--+ +-----+------+ |
| CE Manager |---------+-| CE 1 |------| CE 2 | | | CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | | -------------- | | | Fr | | |
| | +-+---------+-+ +------------+ | | | +-+---------+-+ +------------+ |
| Fl | | | Fp/Ff / | | Fl | | | Fp / |
| | | +--------+ / | | | | +--------+ / |
| | |Fp/Ff |/ | | | | Fp |/ |
| | | | | | | | | |
| | | Fp/Ff /|----+ | | | | Fp /|----+ |
| | | /--------/ | | | | | /--------/ | |
-------------- Ff | ---+---------- -------------- | -------------- Ff | ---+---------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | | | FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | | -------------- | | |------| | |
| -------------- -------------- | | -------------- -------------- |
| | | | | | | | | | | | | | | | | | | |
----+--+--+--+----------+--+--+--+----- ----+--+--+--+----------+--+--+--+-----
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Fi/f Fi/f Fi/f Fi/f
skipping to change at page 4, line 31 skipping to change at page 4, line 31
| | | /--------/ | | | | | /--------/ | |
-------------- Ff | ---+---------- -------------- | -------------- Ff | ---+---------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | | | FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | | -------------- | | |------| | |
| -------------- -------------- | | -------------- -------------- |
| | | | | | | | | | | | | | | | | | | |
----+--+--+--+----------+--+--+--+----- ----+--+--+--+----------+--+--+--+-----
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Fi/f Fi/f Fi/f Fi/f
Fp: CE-FE interface Fp: CE-FE interface
Fr: CE-CE interface
Fc: Interface between the CE Manager and a CE Fc: Interface between the CE Manager and a CE
Ff: Interface between the FE Manager and an FE Ff: Interface between the FE Manager and an FE
Fl: Interface between the CE Manager and the FE Manager Fl: Interface between the CE Manager and the FE Manager
Fi/f: FE external interface Fi/f: FE external interface
Figure 1: ForCES Architectural Diagram Figure 1: ForCES Architectural Diagram
Figure 1 shows a control application manipulating, at runtime, FE Figure 1 shows a control application manipulating, at runtime, FE
config via the FEC LFB control. The above illustration is derived configuration via the SM LFB control. It would appear that this
from Figure 1 in [RFC3746] with modifications showing the messaging control application is playing the part of the FE Manager and thus
for Ff (FEM to FE interface) going via the standard Fp plane. This appears as the messaging for Ff (FEM to FE interface) going via the
is merely to demonstrate that the messaging is happening via the standard Fp plane. However, the SM LFB describes a subset of the
traditional Fp interface to the FEM/FEC; it does not however suggest operations that can be performed over Ff; it does not suggest moving
moving away from the Ff interface. away from the Ff interface.
The FEC LFB describes the configuration parameters of an FE, namely, The SM LFB class describes the configuration parameters of an FE,
the FEID, the FE IP address(es), the CEs it should be associated namely the LFB classes it should load, the CEs it should be
with, as well as the LFBs that it supports. associated with, as well the respective CE IP addresses.
Additionally, the SM LFB provides a general purpose attribute
definition to describe configuration information, as well as the
ability to manipulate the debug logging mechanism.
This document assumes that FEs are already booted. The FE's This document assumes that FEs are already booted. The FE's
configuration can then be updated at runtime via the FEC LFB for configuration can then be updated at runtime via the SM LFB for
runtime config purposes. This document does not specify or runtime configuration purposes. This document does not specify or
standardize the FEM-FE (Ff) interface as depicted in [RFC3746]. This standardize the FEM-FE (Ff) interface as depicted in [RFC3746]. This
document describes a mechanism with which a CE can instruct the FEC document describes a mechanism with which a CE can instruct the SM
for FE management using ForCES. 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 This work item makes no assumption of whether FE resources are
physical or virtual. In fact, the LFB library provided here is physical or virtual. In fact, the LFB library provided here is
applicable to both. Thus it can also be useful in addressing control applicable to both. Thus, it can also be useful in addressing
of virtual FEs where individual FEM Managers can be addressed to control of virtual FEs where individual FEMs can be addressed to
control the creation, configuration, and resource assignment of such control the creation, configuration, and resource assignment of such
virtual FEs within a physical FE. virtual FEs within a physical FE.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Definitions 1.2. Definitions
This document follows the terminology defined by [RFC3654], This document follows the terminology defined by [RFC3654],
[RFC3746], [RFC5810] and [RFC5812]. In particular, the reader is [RFC3746], [RFC5810], and [RFC5812]. In particular, the reader is
expected to be familiar with the following terms: expected to be familiar with the following terms:
o Logical Functional Block (LFB) o Logical Functional Block (LFB)
o Forwarding Element (FE) o Forwarding Element (FE)
o Control Element (CE) o Control Element (CE)
o ForCES Network Element (NE) o ForCES Network Element (NE)
o FE Manager (FEM) o FE Manager (FEM)
o CE Manager o CE Manager
o ForCES Protocol o ForCES Protocol
o ForCES Protocol Layer (ForCES PL) o ForCES Protocol Layer (ForCES PL)
o ForCES Protocol Transport Mapping Layer (ForCES TML) o ForCES Protocol Transport Mapping Layer (ForCES TML)
skipping to change at page 6, line 14 skipping to change at page 6, line 5
o FE Manager (FEM) o FE Manager (FEM)
o CE Manager o CE Manager
o ForCES Protocol o ForCES Protocol
o ForCES Protocol Layer (ForCES PL) o ForCES Protocol Layer (ForCES PL)
o ForCES Protocol Transport Mapping Layer (ForCES TML) o ForCES Protocol Transport Mapping Layer (ForCES TML)
2. Use cases 2. Use Cases
In this section we present sample use cases to illustrate the need In this section, we present sample use cases to illustrate the need
and usefulness of the FEC LFB. and usefulness of the SM LFB.
All use cases assume that an FEs and CEs have already been All use cases assume that an FE is already booted up and tied to at
bootstrapped and instantiated but have not joined the NE. These FEs least one CE. A control application can delete a CE from an FE's
and CEs belong to a pool of untapped resources. 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.
2.1. FE integration into an NE 2.1. High Availability
The CE may request, for reasons such as performance, redundancy, Assume an FE associated to only one CE. At runtime, a CE management
load-sharing or new functionality request, to incorporate a new FE in application may request, for redundancy reasons, that an FE be
the NE. The CE would be required to specify the following associated to another CE as a backup. To achieve this goal, the CE
parameters. Firstly the FEID in order for the new FE to be uniquely management application specifies the Control Element ID (CEID) of the
identified within the NE. Second the FE IP address to bind to, IPv4 new backup CE (to be uniquely identified within the NE) and the CE's
or IPv6. Thirdly the LFBs to be instantiated within the FE, by means IP address (IPv4 or IPv6).
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.
2.2. CE associations 2.2. Scalability
A CE may request for redundancy reasons that an FE to be associated Assume an NE cluster that has FEs connected to multiple CEs, possibly
to another CE as a backup at runtime. To achieve this goal, the in an active backup setup. Assume that system analytics discover
master CE specifies the CEID of the new backup CE (to be uniquely that the CE is becoming a bottleneck. A new CE could be booted and
identified within the NE) and the CE's IP address (IPv4 or IPv6, or some FEs moved to it. To achieve this goal, the CE management
IP addresses should the CE support multiple interfaces). 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 [RFC7121].
The CE will configure all FEC LFBs to the FEs within the NE of the CE 2.3. Adding New Resources to an NE
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 Assume a resource pooling setup with multiple FEs belonging to a
backup CE from the FE. 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.
2.3. New LFB class installation 2.4. New LFB Class Installation
A CE can learn via the capability of FEC LFB whether an FE is capable A CE can learn, via the DynamicLFBLoading capability of the SM LFB,
of loading new LFB classes. Provided that the FE supports new LFB whether an FE is capable of loading new LFB classes. Provided that
class loading, the CE can request a new LFB to be installed and the FE supports new LFB class loading, the CE can request a new LFB
supported by the FE. to be installed and supported by the FE.
To load an LFB class on an FE, the CE will have to provide the LFB To load an LFB class on an FE, the CE will have to provide the
class and the LFB class version. There are optional fields which may following parameters:
be need to be described, depending on the implementation (out of
scope for this document). Example:
location of the LFB Class to be installed and/or mechanism to o LFB class - The LFB class ID
download it. The exact detail of the location semantics is
implementation specific and out of scope of this document.
Parameters needed by the LFB class module to allow for its o LFB version - The version of the LFB class
initialization
3. Applicability statement o LFB class name - Optional, the LFB name
Examples of FEC usage are the following, but not limiting, three o Parameters - Optional parameters. These parameters are
usage scenarios. These scenarios are not implementation details, but implementation specific. For example, in one implementation they
rather depict how the FEC class can be used to achieve the intended may contain the path where the LFB class implementation resides.
subsidiary mechanism for manipulating the configuration of FEs.
The parameters are fields that need to be described in documentation,
depending on the implementation; one example is 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. These parameters
are placeholders for future use, in order not to redefine the LFB
class versions each time. They are simple strings that define the
parameters supported by the LFB. The CE is expected to read this
capability in order to understand the parameters it can use.
2.5. Logging Mechanism
The SM LFB class also provides a useful log-level manipulation.
Experience has proven that the CE may be required to increase or
decrease the debug levels of parts of the FE, whether that be LFBs,
portions of LFBs, or generic processing code (all called "modules").
The module granularity is implementation specific and is not
discussed in this document. The debug levels are derived from the
"syslog Message Severities" registry
<http://www.iana.org/assignments/syslog-parameters> defined in
[RFC3164].
2.6. General-Purpose Attribute Definition
Experience has shown that a generic attribute name-value pair is
useful for describing configuration information. This LFB class
defines such a generic attribute name-value pair defined as a table
of attribute name-value pair values. The attribute name-value pair
is implementation specific and at the moment there is nothing to
standardize. As an example, consider switches that have exactly the
same LFB classes and capabilities but need to be used in different
roles. A good example would be a switch that could be used either as
Spine or Top-of-Rack (ToR) in data-center setups. An attribute that
defines the role could be retrieved from the FE, which will then
dictate how it is controlled and 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. The CE is expected to read the SupportedArguments
capability in order to know what attributes it can use.
3. Applicability Statement
Examples of SM usage include, but are not limited to, the following
two usage scenarios. These two scenarios are not implementation
details, but rather depict how the SM class can be used to achieve
the intended SM for manipulating the configuration of FEs.
3.1. FE Integrated 3.1. FE Integrated
Only one instance of the FEC class can exist and is directly related Only one instance of the SM LFB class can exist and is directly
to the FE. The configuration parameters pertain to the parent FE. related to the FE.
3.2. Virtual FEs 3.2. Virtual FEs
In the case of the FE software that has hierarchical virtual FEs, In the case of the FE software that has hierarchical virtual FEs,
multiple instances of the FEC class can exist, one per each virtual multiple instances of the SM LFB class can exist, one per each
FE. virtual FE.
3.3. FEM
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.
4. FEC Library 4. SM Library
4.1. Frame Definitions 4.1. Frame Definitions
This LFB does not define any frames This LFB class does not define any frames.
4.2. Datatype Definitions 4.2. Data Type Definitions
This library defines the following datatypes. This library defines the following data types.
+----------+-----------------------------------------+--------------+ +------------+--------------------------------------+---------------+
| DataType | Type | Synopsis | | Data Type | Type | Synopsis |
| Name | | | | Name | | |
+----------+-----------------------------------------+--------------+ +------------+--------------------------------------+---------------+
| IPs | A Struct of 2 components. IPv4 | A struct | | loglevels | An enumerated char-based atomic data | The possible |
| | (byte[4]) and IPv6 (byte[16]) | that defines | | | type. | debug log |
| | addresses. | an IPv4 and | | | | levels. |
| | | an IPv6 | | | | Derived from |
| | | address | | | | syslog. |
| LFBDefs | A Struct that contains three | A struct | | LogRowType | A struct containing three | The logging |
| | components. The LFB Class ID (uint32), | that defines | | | components: the LogModule (string), | module row. |
| | the LFB version (string) and optional | basic LFB | | | the optional ModuleFilename | |
| | the LFB name (string) and the location | definitions | | | (string), and the optional | |
| | of the LFB where it will be retrieved | | | | DebugLevel, which is one of the | |
| | from. | | | | enumerated loglevels. | |
| CEParams | A Struct that contains two components. | A struct | | CERow | A struct that contains three | A struct that |
| | A CE's ID (uint32) and the CE's IPs | that defines | | | components: the address family of | defines the |
| | (array of IPs) | CE | | | the CE IP (uchar), the CE's IPs | CE table row. |
| | | parameters. | | | (octetstring[16]), and the CE's ID | |
+----------+-----------------------------------------+--------------+ | | (uint32). | |
| LCRowtype | A struct that contains four | The LFB Class |
| | components: the LFB class ID | Configuration |
| | (uint32), the LFB version | Definition. |
| | (string[8]), the optional LFB Name | |
| | (string), and the optional | |
| | Parameters (string). | |
| NameVal | A struct that contains two | Arbitrary |
| | components: an attribute name | Name Value |
| | (string) and an attribute value | struct. |
| | (string). | |
+------------+--------------------------------------+---------------+
FEM Data Types FEM Data Types
4.3. Metadata Definitions 4.3. Metadata Definitions
This LFB does not define any metadata definition This LFB does not define any metadata definitions.
4.4. FEC 4.4. SM
The FE Configuration LFB is an LFB that standardizes configuration of The Subsidiary Mechanism LFB is an LFB that standardizes
the FE parameters. configuration of the FE parameters.
4.4.1. Data Handling 4.4.1. Data Handling
The FEC LFB does not handle any packets. It's function is to provide The SM LFB does not handle any packets. Its function is to provide
the configuration parameters to the CE to be updated at runtime. the configuration parameters to the CE to be updated at runtime.
4.4.2. Components 4.4.2. Components
This LFB has four components specified. The FEID, a uint32 component This LFB class has four components specified.
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 The Debug component (ID 1) is a table to support changing of an FE's
Parameters, a table of LFBs, each row a struct of LFB Class ID, LFB module debug levels. Changes in an FE's debug table rows will alter
Version and optional LFB name and location. Finally the CEs, a table the debug level of the corresponding module.
of CE parameters, each row a struct of a CE ID and a table of CE IPs.
The LFBLoad component (ID 2) is a table of LFB 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 [RFC5812]. Each such row MUST provide (and is
specified by this library) the LFB class ID. Optionally, the LFB
class ID version may be specified, and 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 [RFC7121].
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 [RFC5812].
4.4.3. Capabilities 4.4.3. Capabilities
This capability specifies whether this FE supports dynamic loading of This LFB provides three capabilities. The first, DynamicLFBLoading,
new LFBs. 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.
4.4.4. Events 4.4.4. Events
This LFB has five events specified. These events notify the CE This LFB has four events specified.
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.
5. XML for FEC LFB 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.
<?xml version="1.0" encoding="UTF-8"?> The other two events reflect LFB class loading and notify whether an
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" entry of the LFBLoad table is added or deleted.
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> 5. XML for SM LFB
<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> <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
<LFBClassDefs> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" provides="SM">
<LFBClassDef LFBClassID="21"> <!-- XXX -->
<name>FEC</name> <dataTypeDefs>
<synopsis>Forwarding Element Configuration</synopsis> <dataTypeDef>
<version>1.0</version> <name>loglevels</name>
<components> <synopsis>The possible debug log levels. Derived from syslog.
<component componentID="1" access="read-write"> </synopsis>
<name>FEID</name> <atomic>
<synopsis>The FEID</synopsis> <baseType>char</baseType>
<typeRef>uint32</typeRef> <specialValues>
</component> <specialValue value="-1">
<component componentID="2" access="read-write"> <name>DEB_OFF</name>
<name>FEIP</name> <synopsis> The logs are totally turned off </synopsis>
<synopsis>The FE's IP</synopsis> </specialValue>
<array> <specialValue value="0">
<typeRef>IPs</typeRef> <name>DEB_EMERG</name>
</array> <synopsis> Emergency level </synopsis>
</component> </specialValue>
<component componentID="3" access="read-write"> <specialValue value="1">
<name>LFBparameters</name> <name>DEB_ALERT</name>
<synopsis>The LFBs in this FE</synopsis> <synopsis> Alert level </synopsis>
<array> </specialValue>
<typeRef>LFBDefs</typeRef> <specialValue value="2">
</array> <name>DEB_CRIT</name>
</component> <synopsis> Critical level </synopsis>
<component componentID="4" access="read-write"> </specialValue>
<name>CEs</name> <specialValue value="3">
<synopsis>The CEs that should be associated with this <name>DEB_ERR</name>
FE</synopsis> <synopsis> error level </synopsis>
<array> </specialValue>
<typeRef>CEParams</typeRef> <specialValue value="4">
</array> <name>DEB_WARNING</name>
</component> <synopsis> warning level </synopsis>
</components> </specialValue>
<capabilities> <specialValue value="5">
<capability componentID="10"> <name>DEB_NOTICE</name>
<name>DynamicLFBLoading</name> <synopsis>Notice level </synopsis>
<synopsis>This capability specifies whether this FE supports </specialValue>
dynamic loading of new LFBs</synopsis> <specialValue value="6">
<typeRef>boolean</typeRef> <name>DEB_INFO</name>
</capability> <synopsis>Info level </synopsis>
</capabilities> </specialValue>
<events baseID="20"> <specialValue value="7">
<event eventID="1"> <name>DEB_DEBUG</name>
<name>IDChanged</name> <synopsis>Debug level </synopsis>
<synopsis>The FE ID has been changed</synopsis> </specialValue>
<eventTarget> </specialValues>
<eventField>FEID</eventField> </atomic>
</eventTarget> </dataTypeDef>
<eventChanged/> <dataTypeDef>
<eventReports> <name>LogRowtype</name>
<eventReport> <synopsis>The logging module row</synopsis>
<eventField>FEID</eventField> <struct>
</eventReport> <component componentID="1">
</eventReports> <name>lmodule</name>
</event> <synopsis>The LOG Module Name</synopsis>
<event eventID="2"> <typeRef>string</typeRef>
<name>FEIPChanged</name> </component>
<synopsis>An IP of the FE has been changed</synopsis> <component componentID="2">
<eventTarget> <name>filename</name>
<eventField>FEIP</eventField> <synopsis>The Module File Name</synopsis>
</eventTarget> <optional/>
<eventCreated/> <typeRef>string</typeRef>
<eventReports> </component>
<eventReport> <component componentID="3">
<eventField>FEIP</eventField> <name>deblvl</name>
<eventSubscript>_FEIPsrowid_</eventSubscript> <synopsis>debug level</synopsis>
</eventReport> <optional/>
</eventReports> <typeRef>loglevels</typeRef>
</event> </component>
<event eventID="3"> </struct>
<name>FEIPCreated</name> </dataTypeDef>
<synopsis>An FEIP has been deleted</synopsis> <dataTypeDef>
<eventTarget> <name>CERow</name>
<eventField>FEIP</eventField> <synopsis>The CE Table Row</synopsis>
</eventTarget> <struct>
<eventDeleted/> <component componentID="1">
<eventReports> <name>AddressFamily</name>
<eventReport> <synopsis>The address family</synopsis>
<eventField>FEIP</eventField> <atomic>
<eventSubscript>_FEIPsrowid_</eventSubscript> <baseType>uchar</baseType>
</eventReport> <specialValues>
</eventReports> <specialValue value="2">
</event> <name>IFA_AF_INET</name>
<event eventID="4"> <synopsis>IPv4</synopsis>
<name>CEAdded</name> </specialValue>
<synopsis>An CE has been added</synopsis> <specialValue value="10">
<eventTarget> <name>IFA_AF_INET6</name>
<eventField>CEs</eventField> <synopsis>IPv6</synopsis>
</eventTarget> </specialValue>
<eventCreated/> </specialValues>
<eventReports> </atomic>
<eventReport> </component>
<eventField>CEs</eventField> <component componentID="2">
</eventReport> <name>CEIP</name>
<synopsis>CE ip v4 or v6(selected by family)</synopsis>
<typeRef>octetstring[16]</typeRef>
</component>
<component componentID="3">
<name>CEID</name>
<synopsis>The CE ID</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LCRowtype</name>
<synopsis>The LFB Class Configuration Definition</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 LFB Class Version</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
<component componentID="3">
<name>LFBName</name>
<synopsis>The LFB Class Name</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
<component componentID="4">
<name>Parameters</name>
<synopsis>Optional parameters such as where the LFB is
located</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>NameVal</name>
<synopsis>Arbitrary Name Value struct</synopsis>
<struct>
<component componentID="1">
<name>AttrName</name>
<synopsis>The Attribute Name</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="2">
<name>AttrVal</name>
<synopsis>The Attribute Value</synopsis>
<typeRef>string</typeRef>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="19">
<name>SM</name>
<synopsis>
The Subsidiary Management LFB
</synopsis>
<version>1.0</version>
<components>
<component componentID="1" access="read-write">
<name>Debug</name>
<synopsis>A table to support changing of all debug levels
</synopsis>
<array type="variable-size">
<typeRef>LogRowtype</typeRef>
</array>
</component>
<component componentID="2" access="write-only">
<name>LFBLoad</name>
<synopsis>An LFB Class to Load</synopsis>
<array type="variable-size">
<typeRef>LCRowtype</typeRef>
</array>
</component>
<component componentID="3" access="read-write">
<name>AttributeValues</name>
<synopsis>Table of general purpose SM attribute Values
</synopsis>
<array type="variable-size">
<typeRef>NameVal</typeRef>
</array>
</component>
<component componentID="4" access="write-only">
<name>CEs</name>
<synopsis>Table of CEs we are asking the FE to associate
with</synopsis>
<array type="variable-size">
<typeRef>CERow</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>
<capability componentID="11">
<name>SupportedParameters</name>
<synopsis>This capability contains all the supported
parameters</synopsis>
<array type="variable-size">
<typeRef>string</typeRef>
</array>
</capability>
<capability componentID="12">
<name>SupportedAttributes</name>
<synopsis>This capability contains all the supported
attributes names</synopsis>
<array type="variable-size">
<typeRef>string</typeRef>
</array>
</capability>
</capabilities>
<events baseID="20">
<event eventID="1">
<name>CEAdded</name>
<synopsis>An CE has been added</synopsis>
<eventTarget>
<eventField>CEs</eventField>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>CEs</eventField>
<eventSubscript>_CEIDsrowid_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>CEDeleted</name>
<synopsis>An CE has been deleted</synopsis>
<eventTarget>
<eventField>CEs</eventField>
<eventSubscript>_CEIDsrowid_</eventSubscript>
</eventTarget>
<eventDeleted/>
<eventReports>
<eventReport>
<eventField>CEs</eventField>
<eventSubscript>_CEIDsrowid_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>LFBLoaded</name>
<synopsis>An LFB has been loaded</synopsis>
<eventTarget>
<eventField>LFBLoad</eventField>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>LFBLoad</eventField>
<eventSubscript>_LFBLoadrowid_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="4">
<name>LFBUnloaded</name>
<synopsis>An CE has been unloaded</synopsis>
<eventTarget>
<eventField>LFBLoad</eventField>
<eventSubscript>_LFBLoadrowid_</eventSubscript>
</eventTarget>
<eventDeleted/>
<eventReports>
<eventReport>
<eventField>LFBLoad</eventField>
<eventSubscript>_LFBLoadrowid_</eventSubscript>
</eventReports> </eventReport>
</event> </eventReports>
<event eventID="5"> </event>
<name>CEDeleted</name> </events>
<synopsis>An CE has been added</synopsis> </LFBClassDef>
<eventTarget> </LFBClassDefs>
<eventField>CEs</eventField> </LFBLibrary>
</eventTarget>
<eventDeleted/>
<eventReports>
<eventReport>
<eventField>CEs</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Figure 2: FEM XML LFB library Figure 2: FEM XML LFB Library
6. Security Considerations 6. Security Considerations
Security considerations for ForCES LFB subsidiary management will be This document does not alter the ForCES model [RFC5812] or the ForCES
added in a future version of this daft. protocol [RFC5810]. As such, it has no impact on their security
considerations. This document simply defines the operational
parameters and capabilities of an LFB that manage the SM for loading
LFBs and create new connections between FEs and CEs.
On the issue of trust, a designer should take into account that the
CE that creates new connections to CEs is either:
o The FE manager that is responsible for managing the FEs, or
o An already associated CE
In both of these cases, the entity making the connections should
already be trusted to perform such activities. If the entity making
the connections is faulty, rogue, or hacked, there is no way for the
FE to know this, and it will perform any action that the CE requests.
Therefore, 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.
The reader is also referred to the ForCES framework [RFC3746]
document, particularly Section 8, for an analysis of potential
threats introduced by ForCES and how the ForCES architecture
addresses them.
7. IANA Considerations 7. IANA Considerations
7.1. LFB Class Names and LFB Class Identifiers 7.1. LFB Class Names and LFB Class Identifiers
LFB classes defined by this document belong to LFBs defined by LFB classes defined by this document belong to LFBs defined by
Standards Track RFCs. According to IANA, the registration procedure Standards Track RFCs. The registration procedure is Standards Action
is Standards Action for the range 0 to 65535 and First Come First for the range 0 to 65535 and First Come First Served with any
Served with any publicly available specification for over 65535. publicly available specification for identifiers over 65535
This specification includes the following LFB class names and LFB [RFC5226]. This specification registers the following LFB class name
class identifiers: and LFB class identifier in the "Logical Functional Block (LFB) Class
Names and Class Identifiers" registry:
+------------+---------+---------+----------------------+-----------+
| LFB Class | LFB | LFB | Description | Reference |
| Identifier | Class | Version | | |
| | Name | | | |
+------------+---------+---------+----------------------+-----------+
| 21 | FEC | 1.0 | An FEC LFB to | This |
| | | | standardize creation | document |
| | | | of ForCES Network | |
| | | | Elements | |
+------------+---------+---------+----------------------+-----------+
Logical Functional Block (LFB) Class Names and Class Identifiers +------------+--------+---------+-----------------------+-----------+
| LFB Class | LFB | LFB | Description | Reference |
| Identifier | Class | Version | | |
| | Name | | | |
+------------+--------+---------+-----------------------+-----------+
| 19 | SM | 1.0 | An SM LFB to | RFC 7729 |
| | | | standardize | (this |
| | | | subsidiary management | document) |
| | | | for ForCES Network | |
| | | | Elements | |
+------------+--------+---------+-----------------------+-----------+
8. Acknowledgments Logical Functional Block (LFB) Class Name and Class Identifier
The authors would like to thank DJ, Joel, ChuanhuangLi, and many 8. References
others for their discussions and support.
9. References 8.1. Normative References
9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed.,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and
Control Element Separation (ForCES) Protocol J. Halpern, "Forwarding and Control Element Separation
Specification", RFC 5810, March 2010. (ForCES) Protocol Specification", RFC 5810,
DOI 10.17487/RFC5810, March 2010,
<http://www.rfc-editor.org/info/rfc5810>.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", RFC Element Separation (ForCES) Forwarding Element Model",
5812, March 2010. RFC 5812, DOI 10.17487/RFC5812, March 2010,
<http://www.rfc-editor.org/info/rfc5812>.
[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,
"High Availability within a Forwarding and Control Element "High Availability within a Forwarding and Control Element
Separation (ForCES) Network Element", RFC 7121, February Separation (ForCES) Network Element", RFC 7121,
2014. DOI 10.17487/RFC7121, February 2014,
<http://www.rfc-editor.org/info/rfc7121>.
9.2. Informative References 8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
Requirement Levels", BCP 14, RFC 2119, March 1997. DOI 10.17487/RFC3164, August 2001,
<http://www.rfc-editor.org/info/rfc3164>.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation [RFC3654] Khosravi, H., Ed. and T. Anderson, Ed., "Requirements for
of IP Control and Forwarding", RFC 3654, November 2003. Separation of IP Control and Forwarding", RFC 3654,
DOI 10.17487/RFC3654, November 2003,
<http://www.rfc-editor.org/info/rfc3654>.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004,
<http://www.rfc-editor.org/info/rfc3746>.
Appendix A. Appendix
A.1. Use of Virtualized ForCES Elements
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.
A.1.1. Use of Virtualized CEs
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.
A.1.2. Use of Virtualized FEs
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.
A.1.3. Generic Lifecycle of Physical/Virtual Elements
The generic lifecycle of physical/virtual elements including NEs,
FEs, VNEs, VCEs, VFEs, etc. consists of the following FOUR states:
o (a)Instantiation -- This refers to instantiation of CEs and FEs.
o (b) Association -- This refers to associating FEs to the CEs
o (c) Activation -- This refers to activation of CEs and FEs for
normal operation. This state may include monitoring as well with
an objective to satisfy both scaling and reliability requirements.
o (d) Release -- This refers to releasing resources (both physical
and virtual elements) to the pool of available (that is un-
assigned) elements, and reporting this to the appropriate (CE or
FE) manager. It may be required to cleanse the physical/virtual
elements before releasing in order to prevent harvesting of data/
information by the the next user of the CEs/FEs. The details of
the cleansing operation is out of scope of this draft.
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
A.2. Potential Scenarios
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.
A.2.1. Recovery from FE failure
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).
o Step-1: Hypervisor boots up with FEx that connects to CEy and CEw.
o Step-2: The Controller (attached to CEy) instructs FEx to boot an
FE-type VM.
o Step-3: FEx boots FEz and instructs it to connect to CEy
o Step-4: The Controller (attached to FEz) instructs FEz to also
connect to CEw. This is essentially the "Association" part of
Association and Configuration, as discussed earlier.
o Step-5: The Controller (attached to FEz) instructs FEz to increase
its Syslog debug level. This is essentially the "Configuration"
part of Association and Configuration, as discussed earlier.
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.
A.2.2. Recovery from CE failure
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.
o Step-1: The CEx is Active with CEy as its Standby with Standby-
Active or Active-Active setup.
o Step-2: The CEx controls FEy and FEw with both FEy and FEw having
Standby control links to CEy, with Standby-Active or Active-Active
setup. Note that CEx and CEy are controlled, assigned, by CE-
visor, and may have a common, virtual, IP address.
o Step-3: The Controller is fully aware of the status of all of the
CEs, physical and virtual; When CEx fails, its states are fully
transferred (may already be synced) to CEy.
o Step-4: The Standby links from CEy to FEy and FEw become fully
active, and the control, of FEy and FEw, is fully transferred from
CEx and CEy.
o Step-5: A graceful-smooth failover of CEx to CEy is now
successfully complete, and SysLog debug level for CEy is
increased..
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.
A.2.3. Load Balancing
In this section we discuss efficient load balancing of both CE and FE
in virtualized environment.
A.2.4. Orchestration
In this section we discuss efficient Orchestration of both CE and FE
in virtualized multi-admin-domain environment.
A.2.5. Generic LFB Lifecycle Management
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.
A.2.5.1. Booting a CE/FE
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.
A.2.5.2. Bootstrapping the Configuration [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
The FE, e.g., the VM which has just been booted, as described in the Acknowledgments
previous sub-section, needs initial bootstrap configuration (e.g.,
what CEs to connect to etc). This clearly falls in the FEC LFB
domain.
A.2.5.3. Runtime Management The authors would like to thank Damascene Joachimpillai, Joel
Halpern, Chuanhuang Li, and many others for their discussions and
support.
At runtime of the FE, for example, the management could introduce a The authors are grateful to Joel Halpern for shepherding this
new CE for the FE to associate with; it may also be for an FE to document. The authors would also like to thank Alia Atlas for taking
dissociate from a CE, and so on. on the role of sponsoring this document. Finally, thanks to Juergen
Schoenwaelder for his operational directorate's review and Alexey
Melnikov for his security review.
Authors' Addresses Authors' Addresses
Bhumip Khasnabish Bhumip Khasnabish
ZTE TX, Inc. ZTE TX, Inc.
55 Madison Avenue, Suite 160 55 Madison Avenue, Suite 160
Morristown, New Jersey 07960 Morristown, New Jersey 07960
USA United States
Phone: +001-781-752-8003 Phone: +001-781-752-8003
Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI: http://tinyurl.com/bhumip/ URI: http://tinyurl.com/bhumip/
Evangelos Haleplidis Evangelos Haleplidis
University of Patras University of Patras
Department of Electrical and Computer Engineering Department of Electrical and Computer Engineering
Patras 26500 Patras 26500
Greece Greece
Email: ehalep@ece.upatras.gr Email: ehalep@ece.upatras.gr
Jamal Hadi Salim (editor) Jamal Hadi Salim (editor)
Mojatatu Networks Mojatatu Networks
Suite 400, 303 Moodie Dr. Suite 200, 15 Fitzgerald Road
Ottawa, Ontario K2H 9R4 Ottawa, Ontario K2H 9G1
Canada Canada
Email: hadi@mojatatu.com Email: hadi@mojatatu.com
 End of changes. 83 change blocks. 
653 lines changed or deleted 636 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/