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

       http://www.sstanamera.com/~forces -- Additional FORCES Web Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

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 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:
Done  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-framework-13.txt
  • - draft-ietf-forces-model-02.txt
  • - draft-ietf-forces-evaluation-00.txt
  • Request For Comments:
    RFC3549 I Linux Netlink as an IP Services Protocol
    RFC3654 I Requirements for Separation of IP Control and Forwarding

    Current Meeting Report

    list.ForCES Minutes - IETF59, Seoul, South Korea,
    Forwarding and Control Element Separation WG (ForCES)
    Tuesday, March 2 at 0900-1130
    CHAIRS: David Putzolu <David.Putzolu@intel.com>
              Patrick Droz <dro@zurich.ibm.com>
    attendees: 62 (signed the blue sheet)
    5  min - WG status & Agenda Bash - chairs
    40 min - Transparent Inter Process Communication protocol proposal - Jon 
    20 min - A Testbed for GRMP Protocol - Dr. Ligang Dong
    20 min - Updated Forces FE model (Steven Blake)
    All presentations from the meeting are available at the following web 
    1) WG status
            1) Charter
                We need to update the charter.
                Please look at the charter and see if the dates are 
    reasonable?  Comments should be sent to the mailing list or David or 
    Patrick as chairs.
            2) Document status:
                a) Forces framework has been approved for publication as an 
                b) Forces Model was just released in February
                    - It's over 100 pages.
                    - Should we consider splitting into 3 different drafts.
                c) Evaluation Drafts
                    - 3 protocols proposed, and an evaluation draft worked.
                    - Design team formed to determine if a merger is 
    possible. Design team will report back on March 20th.
                    - Please send comments to the list on what might be good.
               d) Applicability statement is on hold until further work 
    completed on other drafts.
    2) Transport Inter Process Communication
            TIPC is not a ForCES protocol but rather a transport protocol.
            It is freely available under Linux. It offers also reliable 
                Joel Q: asks 1) Whether the stack could support multiple 
    channels (Ethernet, UDP, etc.) simultaneously, and if so how they would be 
                Jon A: it could support such, and that the decision was based on 
    scope (a cluster used ethernet, inter cluster used other 
                Joel Q: asks 2) whether they had implemented inter cluster or 
    internee support.
                Jon A: they had not completed that work.
                Joel Q: Is there a keep alive protocol assumed by TIPC?
                Jon A: Yes, there is an underlying protocol sending probes. 
    There is a underlying timer that watches the probes to see if it comes 
                David Putzolu Q:
                    Did you determine a connection has a loss or is in error in 
    the transportation?
                Jon Maloy A: There is a queue on each link.  On this queue the 
    buffers will be released once the messages arrives.  when this queue 
    exceeds a certain limit, then the messages will be tossed.
                    The process trying to send the messages will queue 
    messages if congestion is detected in the transport.
                    On the receiving side, the messages will be rejected if the 
    messages are in error.  A messages will be sent back indicating the 
                Hormuzd Q: Is it possible to address a message to multiple LFBs ?
                Jon A: This is possible for multicast, unicast will be on per 
    LFB basis
    3)20 min - A Testbed for GRMP Protocol - Dr. Ligang Dong
            Introduction to Testbed - deployment
            CE code using VC++
            Smartbits software used to measure packets
            Introduction of the experiments on the testbed:
                2 experiments - one for configuration of LFB, second for 
    redirection packets/DoS attacks
                2 scheduling schemes - FCFS, priority based, rate based with RR 
    experiments with scheduling strategy from linux kernel
                Hormuzd Q:
                    Did you experiment with different packet size?
                Dr. Dong A:
                    answer; yes.
                David Putzolu Q:
                    Did you try a congestion aware protocol for the control 
                Dr. Dong A:
                    Yes, we did.  The results (table 3) on the slides.  The 
    information is partially complete.  We will be doing more.
                    Table 1 - is about the loss of control packets.
    3) Updated Forces FE model (Steven Blake)  [20 minutes]
            3rd revision of document.
            David Putzolu Q: The url does not work for the XML
            Steve Blake A: Perhaps we can get this working.                 
            Joel Halpern Q:
                    It would good to have a location to get all the XML for 
            Steve Blake A:
                    May be the working group can provide a location to put all 
    the XML on.   We don't really know where to put XML. MIBs are 
    contained in files.
            Joel Halpern: we are looking for feedback on the XML 
            Open issues:
                    1) Is the augmentation useful
                    2) How useful are input groups?
                    3) in which documents will the protocol payload 
    associated with the LFB attributes be defined?
                            - forces model?
                            - LFB Class definitions?
                            - Protocol specifications?
            Pending work items:
                    (be ready for last call in August)
                    1) Define rules and schema extensions for LFB class 
    derivations via inheritance
                    2) Support for data type augmentation (if needed)
                    3) Inclusions of type and Class IDs (if needed)
                    4) Rules for version handling
                    5) Simplistic handling of LFB class definition using the LFB 
    Library schema
                    6) Improve schema representation of capability 
    attributes for an associated attribute.
              Lily:  1st two items are related
                      The primary reason we have data type augmentation is for 
                      We'd like feedback on that


    Transparent Inter Process Communication
    A Testbedfor GRMP Protocol
    ForCES Forwarding Element Model