Subject: [forces] Re-charter text

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 12 Mar 2013 11:46:57 -0400

Please find below the proposed re-charter text up for discussion
today.
Comments/feedback welcome.

cheers,
jamal

----
Description of Working Group:

This working group focuses on the ForCES architecture.
The ForCES architecture constitutes:
* One or more Control Elements (CE) interacting with one or more
Forwarding Elements (FEs) to form a Network Element (NE). Any or
all of these entities could be physical or virtual.
*a data model to define the controlled or configured entity
*a protocol used to communicate between CEs and FEs
which is agnostic to the model used
* one or more xml documents describing the controlled entity using
the ForCES data model. The protocol acts (in the direction of the controller
to datapath) on these definitions to achieve an end goal of control,
configuration, packet redirect and in the reverse direction for responses,
packet redirects and events.
This working group was originally started to address the desire to create
a standardized control-datapath architecture to control off-the shelf
hardware that implements IP forwarding plane capability.  This could be
commercial chips, ASICs, FPGAs, Network Processors, or software based
forwarding plane devices.

As the work evolved, in order to avoid prejudicing implementation choices
an abstract data model for the forwarding elements and a protocol for
manipulating those forwarding elements was developed and standardized.
Implementations and interoperation were demonstrated.

With the emergence of SDN as an industry focus, there is renewed interest in
the control capabilities and data plane flexibility provided by the ForCES
architecture.  Also, with this interest in SDN there has been a realization
that the same abstractions can be used for service manipulation for overall
device control or for configuration of the devices.

The ForCES working group is now working on a set of additions to the model and
protocol and libraries based on the experience gained from developing the
standards and from many efforts using this architecture.

In addition to the specific work items described below, it is understood that
there are a number of external activities which may have interactions with
the ForCES work.  Discussions of how to use ForCES to model topics of interest
to Network Function Virtualization, I2RS, or OpenFlow may be discussed and
reviewed, although primary responsibility for such documents is likely to live
in other working groups, individual contributions, or other standards bodies.

The following 5 work items are the chartered tasks of this working group:

o Model Extensions and protocol:
This work is to address a set of extensions to the base model and protocol
resulting in updates to RFCs 5810 and 5812.
This effort will produce 2 standards effort documents (one for the model
and another for the protocol).

The model extensions will:
1. Allow complex metadata.
2. Allow optional default values for datatypes
3. Allow optional access-type for datatypes inside complex components
4. Define new base type: Bitmap

The protocol extension will:
1. Table range query.
2. Table append
3. Additional return codes to reduce ambiguity

o Inter-FE Connectivity:
It has been found that ForCES processing often needs to be spread across
multiple FEs.  The original framework identified this as the Fi interface.
Protocol and LFB mechanisms to carry metadata across this Fi interface are
now needed.  This effort will produce a standards track doument defining the
protocol on the wire to address this need, and the LFBs used to represent the
interfaces for sending and receiving such information.

o Inter-FE Connectivity:
It has been found that ForCES processing often needs to be spread across
multiple FEs.  The original framework identified this as the Fi interface.
Protocol and LFB mechanisms to carry metadata across this Fi interface are
now needed.  This effort will produce a standards track doument defining the
protocol on the wire to address this need, and the LFBs used to represent the
interfaces for sending and receiving such information.

o Paralellization:
While in theory an FE can implement an LFB chain with paralellization, the
current mechanism has no means to represent when synchronization is needed,
or to allow the CE to specify where it believes such paralllism is useful.
This work item will produce a single standards track document to improve the
handling of this case.

o Subsidiary Management:
Deployment experience has demonstrated usefulness of expressing the FEM
with the same semantics as any other LFB and thus be controlled by the 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 (eg 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.

Goals and Milestones
September 2013  Request for Publication of Standards Track documents specifying
                              model and protocol changes
Feb 2014        Request for publication of  Subsidiary management LFB
March 2014    Request for publication of Inter-FE LFB and parallelization LFBs
April 2014      Shutdown?