Current Meeting Report
Jabber Logs

2.5.1 Forwarding and Control Element Separation (forces)

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
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/05/2002

Patrick Droz <>
David Putzolu <>
Routing Area Director(s):
Bill Fenner <>
Alex Zinin <>
Routing Area Advisor:
Alex Zinin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe forces (your name)
Description of Working Group:
The emergence of off-the-shelf network processor devices that implement the fast path or forwarding plane in network devices such as routers, along with the appearance of a new generation of third party signaling, 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 planes. 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 purposes.

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:
MAY 02  Submit requirements document to IESG
JUL 02  Submit framework document to IESG
NOV 02  Submit formal definition of controlled objects in functional model
NOV 02  Submit forwarding element functional model document to IESG
MAR 03  Submit applicability statement to IESG
MAR 03  Submit protocol selection/definition document to IESG
  • - draft-ietf-forces-netlink-03.txt
  • - draft-ietf-forces-requirements-06.txt
  • - draft-ietf-forces-applicability-00.txt
  • - draft-ietf-forces-framework-00.txt
  • No Request For Comments

    Current Meeting Report

    Forwarding and Control Element Separation 
    Monday, November 18 at 
    CHAIRS: Patrick Droz 
    <>        David Putzolu 
    Scribe: George Jones 
    Agenda bashing: nothing 
    Completed Last 
    Discussion of 
      - authors, history 
    presented  - 
    motivation    FE == Forwarding 
    Element    CE == Control 
    Element    * FE tells CE 
    capabilities    * FE tells CE current 
    config    * CE tells FE desired 
    state  - what is in the 
    model    * FE block (abstract base 
    class)    * Block library (Forwarding, QoS, filters, 
    etc.)    * Example FE 
    Blocks    * FE stage and directed 
    graph    * Two approaches in graph 
    modeling    * Topological 
    (DiffServ)      + No info carried 
    forward    * Topological (DiffServ) vs. Encoded State (QDDIM 
    model)      + Explicit info (preamble) carried forward to subsequent 
    stages  - open 
    issues    * Data modeling language: 
    representation      + SMI/SPPI/ASN.1/XML/UML 
    ?    * Topological vs. Encoded State 
    approach    * Modeling of actual 
    functions      + identify minimal categories/set of 
    functions      + model for each 
    one  - next 
    steps    * WG 
    document    * Data modeling 
    language    * define small set of 
    Q: Is your intent to specify the way that the FE and CE communicate ?  If 
    so, it's very important to get 
    Q: (statement) Topological model is easier to reason 
    about.A: We can take it on a case-by case 
    Q: (statement) We need to be aware that we don't just want to encode the a 
    snapshot of the current state of the 
    worldA: We need help from the chairs to avoid 
    Chair: show of hands, who's read 
    ?Answer: not enough.  Need more discussion to accept as a WG 
    model.        Abstract, not easy to 
    Chair: We'd like people to start submitting actual protocol 
    drafts.       Easier to actually talk 
    Action: model will not be WG document 
    Status of other 
    Closing:  Do protocol 
    End of 


    Forwarding Element Functional Model