2.6.2 Forwarding and Control Element Separation (forces)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional FORCES Web Page

Last Modified: 2005-09-20


Patrick Droz <dro@zurich.ibm.com>
David Putzolu <David.Putzolu@intel.com>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: forces@peach.ease.lsoft.com
To Subscribe: listserv@peach.ease.lsoft.com
In Body: (un)subscribe forces
Archive: ftp://ftp.ietf.org/ietf-mail-archive/forces

Description of Working Group:

The emergence of off-the-shelf network processor devices that
the fast path or forwarding plane in network devices such as routers,
along with the appearance of a new generation of third party
routing, and other router control plane software, has created the need
for standard mechanisms to allow these components to be combined into
functional wholes. ForCES aims to define a framework and associated
mechanisms for standardizing the exchange of information between the
logically separate functionality of the control plane, including
entities such as routing protocols, admission control, and signaling,
and the forwarding plane, where per-packet activities such as packet
forwarding, queuing, and header editing occur. By defining a set
of standard mechanisms for control and forwarding separation, ForCES
will enable rapid innovation in both the control and forwarding
A standard separation mechanism allows the control and forwarding
planes to innovate in parallel while maintaining interoperability.

The products of this working group will be:

o A set of requirements for mechanisms to logically
  separate the control and data forwarding planes of
  an IP network element (NE)

o An applicability statement for the ForCES model
  and protocol

o Informational RFCs as necessary documenting current
  approaches to the functional model and controlled
  objects therein

o An architectural framework defining the entities
  comprising a ForCES network element and identifying
  the interactions between them.

o A description of the functional model of a
  Forwarding Element

o A formal definition of the controlled objects in the
  functional model of a forwarding element. This
  includes IP forwarding, IntServ and DiffServ QoS. An
  existing specification language shall be used for
  this task.

o Specification of IP-based protocol for transport of the
  controlled objects. When the control and forwarding devices
  are separated beyond a single hop, ForCES will make use of an
  existing  RFC2914 compliant L4 protocol with adequate reliability,
  security and congestion control (e.g. TCP, SCTP) for transport

The main focus area of the working group will be control and
forwarding separation for IP forwarding devices where the
control and forwarding elements are in close (same room/small
number of hops) or very close (same box/one hop) proximity. Other
scenarios will be considered but at not the main focus of the
work. The functional model of the forwarding element will include
QoS (DiffServ and IntServ) capabilities of modern networking
devices such as routers.  In order to minimize the effort to
integrate forwarding elements and control elements, a mechanism
for auto discovery and capability information exchange will form
an integral part of the standardized interface.

ForCES will coordinate with other standards bodies and working
groups as appropriate. Examples of such bodies include IETF/GSMP,
IETF/Megaco, the Network Processing Forum (NPF), the Multiservice
Switching Forum (MSF), IEEE P1520, and SoftSwitch. ForCES will
review relevant protocol efforts such as GSMP and Megaco and will
extend or reuse them if appropriate. If protocol reuse is
accepted as satisfactory for fulfilling the ForCES requirements
then ForCES may recharter to adopt specific deliverables around
the selected protocol.

Goals and Milestones:

Done  Submit requirements document to IESG
Done  Submit framework document to IESG
Nov 2004  Submit forwarding element functional model document to IESG
Mar 2005  Submit formal definition of controlled objects in functional model
Mar 2005  Submit protocol selection/definition document to IESG
Mar 2005  Submit applicability statement to IESG


  • draft-ietf-forces-model-05.txt
  • draft-ietf-forces-protocol-05.txt
  • draft-ietf-forces-tcptml-01.txt
  • draft-ietf-forces-discovery-01.txt

    Request For Comments:

    RFC3549 I Linux Netlink as an IP Services Protocol
    RFC3654 I Requirements for Separation of IP Control and Forwarding
    RFC3746 I Forwarding and Control Element Separation (ForCES) Framework

    Current Meeting Report

    IETF 64 ForCES Meeting in Vancouver
    Agenda bash
    -David Putzolu (chair)
    wg status 
    Protocol draft WG LC
    Joel has requested for IESG review of draft, need to finalize other drafts before IETF LC
    Base LFB library
    -Joel Halpern
    connectivity lfbs
    packet validation & manipulation lfbs
    classifier lfbs
    packet control lfbs
    queue & scheduler lfbs
    David P - reuse from MIBs, PIBs, NPF, etc.
    Joel - sure we can reuse, there is lots of related work out there
    Weiming - how do you communicate between FEs, one being queue & other being scheduler
    joel - model doesnt define how to communicate but who communicates, the actual communication is implementation specificjoel - control info is represented using metadata
    ForCES MIB
    -Robert Haas
    Management of entire NE
    Not duplicate information available via ForCES
    SNMP may or may not see multiple CEs
    Single NE MIB alternative & CE MIBs alternative
    Furquan - do we consider the case where there will be more than 1 active CE in the NE?
    Robert - yes, provided the functionality is not replicated between CEs
    Jamal - why do we prefer the multiple CE alternative?
    Robert - how do we implement the other option, need to define new protocols to support this
    Jamal - how about using AgentX for multiple CE alternative?
    MIB Contents
    Avri - which FEs are being referred to? how about FEs that are down?
    Joel - cant expect the MIB to tell you what FEs it doesnt know about, i.e. has been associated sometime in the past
    Robert - agrees to add this to the draft
    Avri - should we make this a WG draft?
    Jamal - MIB should reflect the FE protocol object
    Joel - MIB is controlling the CE, so it wont work this way
    ForCES TML Service Primitives
    - weiming
    Joel - why do u differenciate between attributes and capabilities ??
    weiming - agrees
    motivation for standardizing SP
    SP - APIs...
    Joel - dont need to define the parameters, that is the implementation
    Jamal - you need to define how its done
    Joel - what are the services that TML needs to provide, not apis
    Jamal - can we use socket primitives?
    Joel - not comfortable defining apis, socket calls in the ietf
    weiming - may be use different names?
    Joel - doesnt agree this (TML Config) is the primitive
    Joel - should not define subroutine for these functions
    TCP+UDP - good deployment
    No TML messages
    UDP for redirect & HB msgs
    Joel - strongly recommed not to invent a CC or DoS prevention mechanism
    ?? - something is possible if we can look at the TCP queue size, but this is research
    univ of amsterdam (prof??)- need to careful about this before sending it out on a real network
    Joel - udp tml should only be used when there is no congestion in the environment, should be indicated in the applicability statement as optional tml
    Jamal - single hop environment such as chassis may be suitable for this tml
    Joel - how will multicast work for udp tml
    weiming - have pl configure the tml multicast channels
    jamal - can use multicast within one hop environment
    joel - what is a master ce?
    Intra-NE routing mechanism
    - x. Guo
    joel - terminology change, have multiple forwarding tables not routing tables
    guo - agrees
    jamal - should be merged with the existing topology draft, similarity, end goal is the same
    david - why are security requirements different?
    hitachi?? - need packet format for transmit packet from one fe to another
    huawei?? - 2 cases, single hop & multihop?
    jamal - one of the lfbs presented by joel is intended to define how packet traverses
    joel - several different issues - need to provide a way to model different approaches, rather than standardizing the packet format
    ForCES Implementation Experiences
    - Jamal
    Using ATCA based hw setup
    LFBs to support IPSec processing NE
    David - what TML have you used?
    Jamal - TCP tml, will probably try udp for redirect shortly
    ForTER - ForCES Router implementation
    - Ligang Dong
    Funding NSF china, 3 sources
    More than 10 students working on this
    Architecture very similar to NPF
    Use Intel SDK for FE
    Use ATCA chasis to build the ForCES NE
    LFB model based on Intel SDK


    Proposed ForCES Base LFB Library
    ForCES MIB Proposal
    ForCES TML Service Primitives
    ForCES TML Over IP Networks
    Intra-NE routing mechanism
    ForTER - A ForCES Router Implementation