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 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-10

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:
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-10.txt
  • - draft-ietf-forces-model-01.txt
  • Request For Comments:
    RFC3549 I Linux Netlink as an IP Services Protocol

    Current Meeting Report

    ***58th IETF ForCES WG Meeting Minutes
    Monday, November 10 2003 at 1300-1500
    CHAIRS:   David Putzolu <David.Putzolu@intel.com>
              Patrick Droz <dro@zurich.ibm.com>
    5  min - WG status - chairs
    10 min - A proposed vocabulary and conceptual model for discussing 
    metadata within ForCES - Alan DeKok
    25 min - ForCES Model Update - Steven Blake
    5 min - Topology representation for ForCES FE model - Weiming Wang
    20 min - General Router Management Protocol (GRMP) Version 1 - Weiming Wang
    20 min - Netlink2 protocol - Steven Blake
    20 min - Status update for FACT protocol - Ram Gopal
    15 min - Linux traffic control extensions & the forces model - Jamal Hadi 
             (no draft available)
    1) ForCES WG status update on major WG drafts 
    Requirements: waiting for RFC #
    framework: seurity comments from IESG on authorization needs to be 
    Model: more work needs to be done but good progress.
    2) Alan DeKok: A discussion of Metadata in ForCES
    A proposed vocabulary and conceptual model for discussing metadata within 
    ForCES. It is "data about data".
    Meta data: Implicit - inside chip, explicit - outside chip
    Jason: Why is it important?
    Alan: this is important to the definition of the model LFB topology 
    between FEs. Vendors may have internal communication within a chip. This 
    communication is out the scope of the forces communication.
    Robert Haas: explicit internal metadata for forcES, right?
    Alan: depends on implementation. 
    Joel: explicit and LFB-external metadata for ForCES.
    Alan: Yes. if multiple LFBs inside one chip, the actual 
    implementation of metadata between LFBs are not the same as how ForCES 
    defines the metadata. We need to recognize that.
    3) Steve Blake: on model v01
    Changes since v00: merged with Zsolt and Steve's contribution, added as 
    co-authors, significant re-organized
    Directions taken:
    distinguish between FE model and LFB model. Allow packet datapath to be 
    represented using both topological and encoded state. Allow LFBS 
    multiple in/out and group in/out concept
    List of open issues:
    Inter-FE topology - the protocol should be capable of querying this from the 
    FE, but the question is whether it belongs to the protocol or the model.
    ForCES protocol parameters (in scope) possibly inscope: implicit 
    metadata for LFB topology validation & debugging. Do we really need to 
    model pass-thru mode for metadata?
    Multiple Inputs/outputs & input/output groups. Output group can be used as 
    embedded redirector within an LFB Mux and redirector.
    Dynamic LFB topology reconfig is good for enabling support for new 
    protocols? Example: turn on L2TP support. Configuring QoS 
    reservation for a new RSVP flow does not necessary require a topology 
    reconfig. Would the FE stop forwarding while reconfiguring the 
    Joel: code downloading is out of scope for now. But should allow 
    extension later. David: Shouldn't the CE know whether or not the FE stops 
    forwarding when reconfiguring?
    Joel: want to avoid explict "stop, reconfig, start". It is best to have 
    transparent operation.
    Jamal: It is feasible.
    LFB class partitioning: finer grain or coarse grain? We need to come up 
    with the right balance. 
    Modeling port LFBs input and output: split or combined?
    similar problem: ip interface, encap/decap
    modeling lookaside LFBs: devices that receive part of a packet and 
    produce metadata but otherwise are not in the direct datapath modeled as 
    "tap LFB + lookaside LFB" ?
    Modeling queueing and scheduling LFBs. Schedulers pull packets from 
    queues. Model does not model timing.
    Modeling classification - classification LFBs. 
    Protocol-specific LFBs look at appropriate fields within the packets, but 
    not embedded classifiers.
    Jason: what about content inspection for classifiers?
    Upcoming work items for -02: work on Sections 4-8
    Steven solicitated feedback on the draft. 
    4) Weiming Wang: GRMP proposal
    Deveopled separately from GSMP but considers compatibility
    Messages to do FE, LFB, and datapath management. 
    Reliability consideration: use GRMP built-in error mechanism.
    Uses IPsec/TLS for security. Mor work has to be done to cover mor medium
    Operating objects in GRMP:
    object types + object class = object ID
    FE attributes/capabilities/events
    GRMP defined/Model defined/vendor defined
    DoS protection Scheduling & DoS Attack Alert Policy
    Joel:  What you have here is interesting. But why in the protocol? Why not 
    using LFB instead?
    Lily: sounds like there is chicken and egg problem here. 
    Weiming -- the GRMP slave module needs to be up before the ForCES 
    protocol can be used.
    5) Weiming Wang: On Topology representation (PkfID) A name assigned to a 
    single connection or a group of connection, conceptually like virtual 
    Joel -- there are no buffers represented in the protocol, don't know what 
    you mean here. I am really sorry.
    6) Steve Blake: on Netlink2
    - changed TLV encapsulation to permit multiple TLVs in the same 
    Netlink2 message.
    - provided state transition diagrams for FE-CE protocol association
    - added LFB definition derived from Netlink RFC 3549: Interface 
    Service, Address Service, IPv4/v6 Forwarding, Neighbor Discovery.
    - extended security measures for local scope and global scope 
    environment: protection against DoS with policer LFB for data traffic 
    redirected to CE. Netlink2 SYN cookie TLV to protect against Netlink2 SYN 
    flood attacks.
    - use of qualified names for FEs and CEs to perform 
    Netlink2 and ForCES requirements:
    - solves one of the scalability requirements by supporting multicast wires 
    (ForCES-level group addressing): routing table updates can be 
    multicast from CE to all FEs.
    - Netlink2 can be layered directly on top of link layers (Ethernet, 
    Infiniband, etc)
    - all of the other requirements are met.
    Netlink2 reference code:
    - announcement will be made on the list within the next month
    - open source
    - demo of one CE updating route tables of two FEs using Netlink2 group 
    addressing over IP multicast. 
    6) Ram Gopal: on FACT protocol
    TCP used for control channel, DCCP for data channel and TLS for 
    security. There is a rate limiting mechanisms on FE
    Jamal : what is the point of priority?
    Ram: gave an example.
    Explicit ACK/response msgs
    Interconnect independence:
    CE tag, FE Id for interconnect independent addressing
    CE redunancy or Failover (heartbeat)
    7) Jamal: Linux Traffic control extension and ForCES model High level view of 
    an FE
    8) There was a demo given of running Netlink2 code. 


    A Discussion of Metadata in ForCES
    ForCES Forwarding Element Model
    General Router Management Protocol (GRMP) Version 1
    Topology Representation for FE Model (and ForCES Protocol)
    Netlink2 as ForCES Protocol
    Forwarding and Control Element Protocol (FACT)