2.5.2 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

Last Modified: 2003-04-21

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: subscribe forces (your name)
Archive: http://peach.ease.lsoft.com/archives/FORCES.html
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

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 forwarding element functional model document to IESG
Nov 02  Submit formal definition of controlled objects in functional model
Mar 03  Submit protocol selection/definition document to IESG
Mar 03  Submit applicability statement to IESG
  • - draft-ietf-forces-requirements-10.txt
  • - draft-ietf-forces-applicability-02.txt
  • - draft-ietf-forces-framework-08.txt
  • - draft-ietf-forces-model-00.txt
  • Request For Comments:
    Linux Netlink as an IP Services Protocol (RFC 3549) (72161 bytes)

    Current Meeting Report

    14:35]]ForCES Minutes, IETF 57th, Monday 07/14/03
    Attendees: about 50
    WG status:
    The Requirements and the Framework documents should become RFCs soon. They 
    are currently under AD/IESG review.
    5  min - WG status - chairs
    15 min - ForCES Framework respond to IESG feedback - Ram Gopal
    20 min - ForwArding and Control ElemenT protocol (FACT) - Hormuzd 
              Individual contribution protocol proposal.
    20 min   Netlink2 as ForCES Protocol - Robert Haas
              Individual contribution protocol proposal.
    15 min - ForCES Forwarding Element Functional Model - Joel Halpern 
              Individual contribution model proposal.
              *** NOTE: Authors intend to ask to make the above a WG 
    document. ***
              *** Please read and review prior to meeting or comment on list! 
    15 min - XML/TIPC based ForCES protocol and  ForCES 
    Pre-association Phase Protocol - Jon Maloy
    15 min - ForCES FE Functional Model Elements - Zsolt Haraszti
              Individual contribution model proposal.
              Late contribution - available at:
    king/drafts/draft-haraszti-force s-model-00.txt
    15 min - Demonstration of working prototype of XML/TIPC for ForCES - Jon 
    Reached consensus that protocol selection will be attempted on the 
    mailing list in a month.
    Comments on selection process, Joel Halpern spoke to first 
    determining if the protocols are doing what we want. He thought it is 
    obvious that they meet the requirements. Jason Goldschmidt asked if only 
    post-association will be considered. Answer was yes. Comment was made that 
    protocols should ONLY focus on post-association. Comment was made that 
    documents should be sure to use a consistent language, set by the 
    framework and requirements.
    Framework Presentation (Ram Gopal)
    Update 05 and 06 made changes to address FE virtualization. FE 
    partitioning is done during the pre-association phase. Comments were made 
    about multiple FE managers, these comments were not accepted. Next draft may 
    address offloading concern raised by IESG. Text added to support 
    graceful restart, non-stop forwarding and dynamic association 
    establishment. New section added to better detail of FE 
    loss/restablishment, caching and session reestablishment.
    The new draft adds text to discuss security threat; see security 
    considerations of draft for more info. Security options for FORCES are as 
    follows: No security, TLS, IPSec. New draft incorporates security 
    handshake during association establishment.
    No comments/questions on framework.
    FACT (Hormuzd Khosravi)
    Protocol updates. Now compliant with requirements draft 9.
    New draft adds definitions for separate control and data channels. 
    Protocol Elements (PE) will be sent over data channel, all other FACT 
    messages over the control channel. This was done to prevent against DoS 
    attacks that would saturate the channel between FE and CE. Same 
    reliable transport used for both data and control channel. This 
    requirement is driven by the need for congestion control; though this is not 
    called out in the FORCES requirements document.
    FACT uses reliable transport to meet requirements. TCP/SCTP is 
    recommended. This simplifies the protocol design.
    Security rewritten. 3 modes, no sec., IPSec, TLS. TLS is 
    Joel: we need a mandatory to implement core of protocols for transport and 
    security. David Putzolu: pick one and go with it.
    Description of CE failover and difference between weak and strong 
    consistency. Strong, FE communicates with both. In weak, CE's sync.
    Zsolt Haraszti: problem with separation between data and control 
    channel. For example asynch exception will happen over control. What if 
    asynch exception requires sending the packet to the CE?
    Joel: the kind of events that go over the control channel is regarded 
    about the FE itself. The data channel handles info about packet related 
    Robert Haas: is the priority bits not enough to distinguish between the 
    Joel: Data channel should not be reliable.
    Xiaoming Fu, How does CE-CE work.
    Hormuzd: This is out of scope given the FORCES charter.
    Ram Gopal: FACT can be used for CE-CE.
    David: Framework points out the channel and explains why these other 
    connections are out of scope.
    Xiaoming Fu: Maybe next step in signaling WG and FORCES can work 
    Netlink 2 ­ Robert Haas.
    Summary of changes.
    Joel: is it your assumption that FORCES is used for FE-FE or LFB-LFB 
    communication. Comments to clarifying that netlink2 is not for LFB-LFB 
    Netlink2 in a nutshell.
    Uses groups and multicast to allow for scaling. The Goal is flexible CE-FE 
    addressing. Netlink2 is making use of groups. Then some addressing 
    examples were given.
    Conclusion. Netlink2 addresses scalability whereas FACT focuses more on CE 
    failover and availability.
    Joel: scalability addressed by MC, this concerns him. IS there a need to 
    send the same messages to the different FE's? How common is this today 
    since FE's are not the same. Ie different routes, ports, yadda yadda. It 
    doesn't seem obvious that there is a value add in sending same 
    information to all or a set of FE's.
    Patrick: if multiple FE of the same box they must have the same info for 
    certain things a good example is the forwarding info generated by the 
    routing protocols.
    FE Model - Joel Halpern
    State of document. Most of sections are there. Not all filled out.
    Fine grained FE blocks. Does not want to talk about large scale blocks, 
    like a DiffServ block. How to represent an IP Forwarding block (this is why 
    there needs to be an affinity between NPF and FORCES).
    FE block description. Formal description of a block is needed.
    How to build a classifier? Two classifiers, one that modifies the 
    meta-data, other that has multiple exits. Compromise.
    Meta-data. Where and how to use meta-data? FORCES model that can do 
    useful things, before meta-data definition is answered. Group need to 
    resolve how to tackle this.
    Representation. Is representation for documents same as an on the wire. 
    Team recommends XML Schema. Not DTDs
    Thinks document is consistent with the framework and possibly group. 
    Should document be made a WG doc?
    Comment. Classifiers without metadata seems like science fiction.
    Joel: having a forwarded that does such is more uncommon.
    Jason: why not classifier plus mux?
    Joel reiterates the need for meta-data definition.
    David: Should this document be accepted as WG document? Hums? The Favors 
    have it. Still need to check with mailing list.
    Pre-association protocol - Jon Maloy
    FE/CE manager accepts/rejects new PE's.
    Why do we need this?
    Need for dynamically changes NE's.
    Protocol discussion.
    Robert: Could we use SLP instead of discovery phase proposed for CE-CE 
    Manager protocol?
    Joel: we should focus on our chartered work, not out of scope work.
    FE Model elements (Zsolt Haraszti)
    not alternative model.
    Topo versus encoded.
    a mixture is needed to deal with the problems related to each.


    Forwarding and Control Element Separation (ForCES) Framework
    Forces Forwarding Element Functional Model
    Netlink 222 22 222 2 as ForCES protocol (update)
    Forwarding and Control Element Protocol (FACT)
    ForCES Meeting Summary, IETF 57