2.5.2 Forwarding and Control Element Separation (forces)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. 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: 2004-09-07


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 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:

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


  • draft-ietf-forces-model-03.txt
  • draft-ietf-forces-protocol-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

    Minutes ForCES WG at the IETF61 in Washington DC, USA

    Agenda, IETF 61

    Monday, November 8, 2004, 1300-1500

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

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


    5 min - WG status & Agenda Bash - chairs

    30 min - ForCES Protocol Draft Status & Changes Jamal Hadi Salim draft-forces-protocol-01.txt

    10 min - ForCES LFB Path Discussion Robert Haas on behalf of Weiming Wang (no draft available)

    20 min - Options for LFB-level multicast and related issues Robert Haas (no draft available)

    15 min - IP TML Proposal Alex Audu draft-audu-forces-iptml-00.txt

    20 min - TIPC Transport Mapping Layer Proposal Jon Maloy draft-maloy-tipc-01.txt

    5 min - ForCES IP TML Proposal Furquan Ansari draft-khosravi-tcptml-00.txt

    15 min - ForCES Element Discovery Proposal Furquan Ansari draft-ansari-forces-discovery-01.txt

    10 min - Flexinet EU ForCES Protocol Implementation Experience Robert Haas (no draft available)

    Attendees: 50


    The chairs began the meeting by reviewing the agenda and then going over the status of the group. It was stated the the protocol was expected to go through 1 or 2 more drafts before going to WG Last Call.

    Jamal gave a presentation on the protocol covering both the current structure and the open issues. He asked for comments on the open issues:

    - possibly adding a CE protocol LFB but that is still an open question

    - open issue on how path data is recorded.

    - controversial issues:
    -what is a path:
    - a map to a targeted entity
    - or 32 identifier similar to SMI OID

    - issue of how to access multiple rows

    - open question of whether content based access possible

    - packing/transport of path referenced data.

    Authors are looking for input on all the issues
    Q.- are they all in tracker -
    A. believe so, will check
    At the moment there are 8 open issues on the on the list: http://www.mip4.org/issues/tracker/forces/
    There was no further discussion on the protocol draft


    Robert presents on behalf on Weiming the status of the Path LFB path discussion.

    Joel - Weiming is very concerned that subscripting include explicitly what field being used as index. He has a valuable point but I am not sure I got it.

    By what is Weiming subscripting
    - regular subscript
    - content field

    Joel believes every table should have a regular subscript. Weiming has the opinion that we need to explicitly indicate what we are using for selection.

    Joel comment: assume we have specified what you are going subscript, but where is the subscript to be found? or is there another sequence of information that indicates where the subscript is found?

    Joel wonder whether one must always have explicit indices that are index based and content (field ) based. A path should always have attributes and the fields. Joel thinks semantically putting it in the data is the wrong place. We need a clear indication what the target of operation is.

    Jamal wants closure of the discussion.
    Robert is not sure he sees the difference.
    David - need to resolve over the next few weeks probably best is to setup a call with Weiming to discuss.


    Robert presented options for LFB-level multicast and related issues.
    The question is how does one set information into several LFBs.
    There are three ways of doing multicast:

    1) merged multicast: use PL-level multicast for LFB multicasting
    2) split multicast that needs both PL level and LFB level (proposal from Joel, Steven)
    3) xcast that only has unicast PL messages, list of LFB explicitly

    included in message proposal from Weiming

    Q: can you multicast to all LFBs of a given class.
    A: as is no, but if it is important we should find a way to support it.


    Alex presents the TML draft. He starts with the TML functions and design criteria such as simplicity, statelessness, security and trust model.

    Joel is surprised by what he found in the TML draft. He is looking for how to really do it. Either select a protocol with a transport or use TCP with explanation of how to transport.

    A: Well it is an API

    Joel: we need to find the transport

    David: this needs to be added

    Joel: that is where they should start

    David; so you are talking about a service access point

    Jamal: I was going to write a draft on this

    Joel: a service definition has to exist

    jamal: do we expect to see two different vendors to provide a TML and a PL

    At this point the lengthy discussion of what this draft should be was taken off line. But further questions came:

    Joel: I am missing the semantics of the join message. Why do we need TML level join message. Critical piece are missing, what is carrying the message.

    Alex: what transport do you want to map to

    Joel: well what transport do you want to map to. You must pick what the transport is:

    Jamal: this is a first cut.

    Joel: but this should have come first.

    This discussion was again take off line.

    Q; why only one way authentication
    A: Feels that the CE should be trusted.
    Q: there are several different models
    Jamal: there are several different trust models
    Q: what if there is a CE spoofer, could take over the network
    A: but FE initiated so it should know who it is initiating to.


    John Malloy presents TIPC.
    It is a transport protocol connection less and connection oriented Reliable and unreliable including multicast. Can be reliable in one direction And unreliable in the other direction. The protocol does not have any security Features. It is assumed to be operated in a trusted environment. It does have congestion control. They have control and data connections which have lower priority. The main purpose of the draft is to promote TIPC as the TML for ForCES.


    Furquan presented a TCP/IP based TML for ForCES. Control and data connections are used. Security is provided through TLS. It also supports prioritization and it protects against DoS attacks.

    David: the draft needs more details explaining how it should be used.


    In a second presentation Furquan presented a draft on ForCES Element Discovery Proposal. Only very few people had read it so consideration as a WG was deferred to the list. The content of the draft falls under the current ForCES charter.


    Finally Robert presented the FlexiNET project. FlexiNET is a EU project that will make use of ForCES. The objective of FlexiNET is to accelerate the introduction of next generation marketable services, and increase the competitiveness in the telecom field by facilitating the broadening of current business model for services provisioning and exploitation.


    Meeting Agenda & WG Status
    ForCES Protocol Draft Status & Changes
    ForCES LFB Path Discussion
    Options for LFB-Level Multicast and Related Issues
    IP TML Proposal
    TIPC TML Proposal
    ForCES Element Discovery Proposal
    Flexinet EU ForCES Protocol Implementation Experience