Current Meeting Report

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 54th IETF Meeting in Yokohama, Japan. 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-04.txt
  • - draft-ietf-forces-applicability-00.txt
  • - draft-ietf-forces-framework-00.txt
  • No Request For Comments

    Current Meeting Report

    IETF 54, Yokohama, ForCES Minutes

    About 80 people attending the meeting.

    Agenda bashing & list of draft to be reviewed.
    WG status: 2 drafts on last call

    ForCES Model - Draft 0 (Joel presenting)
    Individual contribution: ForCES Functional Model
    Draft about ForCES models:
    - How to represent models (on the wire and in the doc)?
    - How complex a capabilities model?
    - What Elements for the State Model?

    Capabilites & State models should share representation & element
    identification. Should we use a combined document / on the wire
    representation (XML based?) Should we use an existing one (SMI, SPPI)
    We should not build our own

    Q? No opinion on which aspect is used. Instead up level the problem
    that we're trying to solve by picking one of these solutions? What are
    the requirements e.g. do things going on the wire must be small, easy
    to troubleshoot,

    Q: (Margaret) Want a language that is easy to use to pass the
    information around.

    A: (Joel): Important for the model draft to at least have the human
    readable aspect. Important to also consider it from the protocol

    Q: Some people want an open model where capabilities and state info
    might be exchanged over existing protocol.

    A: (Joel) Don't want to mix multiple protocols here. Hope for a
    consistent framework for the control protocol.

    Q: (Margaret): Don't think we're at the point to define the protocols
    in the WG.

    Current doc calls for a simple model, however
    there is now existing work on which to base a more complex
    capabilities model. Framework PIB Diff. Serv. QoS PIB.

    Joel: Should we go for the simple case called for in the document or
    should we make use of the capabilities information of the Framework
    PIB & DiffServ. PIB on our framework? How complex the capability
    model should we include? What is the language to define the

    Q: What do we need to define the capabilities and not the language
    A: (Joel): Need to define the capabilities where we want

    Need to build a good but not excessive set, DiffServ set would seem a
    good starting point for QoS Also need a forwarding set (and forwarding

    Q: (Sue)? How do you match the capabilities and the blocks? You have a
    n x n matrix.
    A: (Joel) No. Capabilities about a number of state elements.

    Q: Doesn't work for the forwarding blocks, this FE link to this FE.
    A: (Joel) Capabilities deal with Forwarding blocks. State model deals
    with the blocks.

    Q: Do we want an FE be controlled by two CE? If yes the model becomes
    more complex. How does topology info between the interconnection of FE
    interact with the protocol?

    Q: FE wants to do mcast. FE from one block to n-blocks. CE setup the FE, mcast forwarding table.

    A: (Joel) Disagreement on whether it works or not. Take if off line.

    NetLink - Draft 03 (no presentation)
    Will declare last call completed if no comment

    Requirement document - Draft 04 (Margaret presenting)
    Last call period ended on the meeting date
    High availability -> CE redundancy
    Include possibility for multiple protocols
    Added requirements to query statistics.

    Last call comments:
    Support both Capability & State model
    Support for failure notifications from FE
    Added text for off-loaded functions

    Is last call complete? Design team thinks so. Doc will be forwarded

    Applicability Statement (David presenting)
    3 main changes to align Applicability stmt with Req. draft
    Added Purpose section
    Changed CE Redundancy/Failover to align with Requirements Draft
    Changed Sections on Locality, per rough consensus on list

    Q: (Russ) - Draft don't say locality are that close (e.g. the room).
    A: (David) Current language is that the Locality is very close (fate sharing)
    David will comment on the list after checking the exact text.
    Q: (Russ) Will propose some text to clarify.

    Architectural framework (Lily presenting)
    What's new?
    CE Redundancy support
    FE Topology examples
    Message exchange examples

    Q: (Alex): Routing/Forwarding table needs to be clarified. Who does
    ARP need to be specified.

    Q? (Chin Choi): What kinds of messages are exchanged between FE?
    A: Mostly data packets that will be routed.

    Fwd & Control Element Protocol (FACT)
    No slides


    None received.