Current Meeting Report

2.4.1 Forwarding and Control Element Separation (forces)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 11-Jan-02
Patrick Droz <>
David Putzolu <>
Routing Area Director(s):
Randy Bush <>
Bill Fenner <>
Routing Area Advisor:
Bill Fenner <>
Mailing Lists:
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 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:
Dec 01   Submit requirements document to IESG
Mar 02   Submit applicability statement to IESG
Mar 02   Submit forwarding element functional model document to IESG
Aug 02   Submit formal definition of controlled objects in functional model
Dec 02   Submit protocol selection/definition document to IESG
No Request For Comments

Current Meeting Report

ForCES Working Group Meeting Minutes from the 53rd IETF, Minneapolis

1300-1500 Monday, March 18, 2002, Salon C

Meeting Agenda
1300-1310 Agenda Bash & Intro - Chairs
WG Status - Relevant Milestones

1310-1320 Bandwidth Methodology Working Group
Terminology and other potential areas of commonality
Howard C. Berkowitz

1320-1325 Netlink as an IP Services Protocol (WG informational draft)
Jamal Hadi Salim

1325-1345 ForCES Requirements (WG requirements draft) - Update
Margaret Wasserman

1345-1410 ForCES Applicability Statement
Mark Handley

1410-1430 ForCES Architectural Framework
Lily Yang

1430-1455 Forwarding Element Model and
ForwArding and Control ElemenT (FACT) Protocol
Ram Gopal

1455-1500 Next steps for WG docs and individual contribs

Welcome and Charter Status

There were about 110 people attending the ForCES meeting.
Both ADs Bill Fenner and Alex Zinin attended the meeting.


1) Bandwidth Methodology Working Group (BMWG) - Howard C. Berkowitz

The purpose of Howard's presentation was to share information on the opportunity for common terminology on control plane and data plane. May be that we have a standard terminology. Working on a document with that reflects thinking of major router vendors. Goal of this presentation is to acquaint the ForCES WG on these documents, and see if we can work together.

The current drafts are:
Both drafts should be updated soon.

2) Netlink as an IP Services Protocol (draft-ietf-forces-netlink-02.txt)
by Jamal Hadi Salim

Jamal presented changes in version 2 of the draft. Removed some sections as well to focus the draft. Next draft will be last-called. Questions have been raised on Linux and GPL - answer is that it is just a reference implementation. Jamal is working on taking Netlink, and extending it to meet the ForCES requirements.

2) ForCES Requirements(draft-ietf-forces-requirements-02.txt)
by Margaret Wasserman, Wind River

Margaret presented the latest requirements draft, which is getting close to last call. She asked how many people had read the draft (about half of folks in room). Changes:
- Added Architectural requirement for High Availability (HA)
- Added a Management mechanisms section
- Removed high-level, low-level model, and switched instead to listing the requirements of the FE Model (with the understanding that the FE Model will be specificed in a separate document).
- Updated the protocol requirements section. Added text on CE-FE communication and for elements joining.
- Added a command bundling feature, with all-or-nothing semantics
- Adding details on what Query Statistics are (this did not make it in to 02 but will be in the next draft, 03)
- Questions

Comments from Jon Sadler:
1) part of doc seems to have troubles with tunnels.
2) don't see all the issues coming out regarding stack partitioning. Imagine an FE that can do tunnel termination. there seem to be issues with stack partitioning
3) Currently the document only talks about IPv4/6. Should be more neutral
Jonathan agreed to send these comments to the list.

Plan: issue a v3. After v3 out, hoping last call, will ask chairs to last-call the document. David: we tried to last-call the last draft

3) ForCES Applicability Statement (draft-crouch-forces-applicability-01.txt)
by Mark Handley

David explained that the Applicability Statement is now an official WG document.

Mark explained that he will re-submit the document immediately after this IETF with the WG document name (draft-ietf-forces-applicability-00.txt).
Mark described "what is an applicability statement"
- a kind of "anti-requirements"
- A little like lower and upper bounds
- Normally an applicability statement is only produced toward the end of the process
Mark explained what has changed:
- Diagnostics
- Redundancy: now included a short section saying whilst we're not trying to rule out. Mark claimed this generally reflects consensus.

Joel Halpern: requirements says "high-availability is solving the problem". Seems to be wrong in Requirements/Applicability documents to prohibit a solution.
Mark: ForCES won't be the way to do CE-FE redundancy.
Joel: is High-Availability part of the problem? AS draft should not preclude CE redundancy.
Mark: divide the problem up into manageable chunks.

Margaret: need to solve High-Availability problem, and need to solve what is Requirements vs. Applicability problem/

David: post problems to the list: should High Availability be in the scope?

Close and Very Close definitions: need to be rewritten. The goal was to get people to think carefully about the problems.

- Reflect what the protocol designers view what the protocol is for.
- Meant to help people think through the failure modes. Clear that the text now does not do that.

Comment from Mic: no talk about the motivation. What is the protocol intended for. What is the motivation for this work. The original BOF talked about it, but not much now. Mark agreed to add text on that.

Howard: is there an opening for the CE-CE protocol? Answer: no

Avri: too many limitations right from the start. Until we have a protocol we have nothing to talk about in terms of applicability. Too early to talk about applicability statement. Need to solidify requirements, framework, protocol first.

Mark: it is the result of IESG/etc saying we need bounds up front to make progress

Conclusions: need to get alignment between AS and requirements on the following topics:
- high availability
- Jamal: COPS does fate sharing, not HA.
- fate sharing
- what should be done if CE or FE goes down.
Conclusion: study hitless restart discussion from the OSPF WG. Partial operation of an FE will be needed.
- capability exchange

4) ForCES Architectural Framework (draft-anderson-forces-arch-00.txt)
by Lily Yang,

Lily presented an individual contribution. David asked that the WG consider whether this should eventually be a ForCES wg document. New in this draft: removed definitions section (refer to the terminology in the requirements document). Lily showed a diagram showing the entities of ForCES, and what is in scope, and what is out of scope.

Described the following pieces of the architecture
- Pre-association Phase (out of scope for ForCES)
- Post-association Phase
- Association Re-establishment: need to re-establish.

Question: scope of WG - like GSMP? GSMP controls MPLS label switching. This is packet-based forwarding, GSMP is connection-oriented. With MPLS, . Asked us to review the GSMP

Avri: quite possible that people ewill take GSMP and propose additions to is. Need requirements before we pick a protocol

Consensus was reached that it is a good idea to have a framework document.

5) Forwarding Element Model and (draft-gopal-forces-fact-00.txt)
ForwArding and Control ElemenT (FACT) Protocol
by Ram Gopal

Ram presented a draft on a FE model. He introduced the building blocks and their functions. The building blocks represent the data path. He used to DiffServ as an example.

Joel: This DiffServ models was not intended to used as an implementation. Capabilites are very tricky to handle.

Jonathan Sadler: What about IS-IS? Answer: encapsulate it.
What about capabilities of Ingress/Egress?
Jamal: Why are BER are used instead of TLV's. He just picked one but TLV could be used as well

Ram is looking for contributers to his draft.


Agreed to
- Netlink informational draft: RFC it in July 2002
- Discuss High Availability on the list
- Sync up the requirements and applicability statement before requirements foes last call
- Applicability statement will stay open for a while,
- Want a working group document on Framework
- FE Model and FACT: proposing coming a WG document, or look for co-authors.
- No model draft was made a WG document
- Howard: will post references to the BMWG work to the list.

List and Archive Info

To Subscribe:
In Body: subscribe forces (your name)


ForCES Requirements Update
FE Model and FACT Protocol
Netlink draft update