2.5.2 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 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-14

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-netlink-04.txt
  • - draft-ietf-forces-requirements-08.txt
  • - draft-ietf-forces-applicability-01.txt
  • - draft-ietf-forces-framework-04.txt
  • No Request For Comments

    Current Meeting Report

    work.IETF 56, ForCES Meeting Minutes
    About 100 persons attended the meeting. Thanks to Hormuzd for taking 
    FACT - Ram Gopal
    Ram presented a protocol overview including the NE model and the message 
    Q Adam - why CE tag if one CE is active?
    A Ram - cause of multiple CE sets
    He then showed message classes and the types. Afterwards the 
    association phase including the sequence of operations were shown. Also the 
    states of the elements were introduces.
    Q Jamal - Is this CE-to-CE or FE-to-FE communication?
    A Ram - NO, CE-to-FE.
    Then the normal operation phases were given. Finally some other 
    features were given like 2 phase, command bundling, and high 
    availability (HA).
    Q XYZ - Can this be used only for post-association?
    A Ram - yes, but certain configuration needs to be done in 
    Q Adam - All IP Address are only 32 bits, is that on purpose?
    A Ram - No, this need to be fixed
    Netlink2 - Robert Haas
    The reasoning why Netlink2 is derived from netlink is because netlink is 
    already widely used in linux systems as a message-based interface 
    between control code (usually running in user space) and forwarding code 
    (kernel space) to perform, for instance, IP routing, ARP, QoS, etc. 
    Netlink2 extends netlink to address the fact that CEs and FEs can be 
    distributed.  The Netlink2 header is an extension of the netlink header 
    with slight changes, and supports optional TLVs. FEs and CEs have unique 
    PIDs. Logical PIDs can be used to group FEs and CEs. Netlink2 extends the 
    concept of the netlink wire to Netlink2 wires and bundles that are built 
    with IP unicast and multicast addresses to enable scalability and 
    Q XYZ - How do multiple CEs send messages to multiple FEs?
    A Robert by different multicast addresses
    Netlink2 has built in reliability, it has a prioritization method, an ACK 
    strategy to confirm messages. It support atomicity, ordering and 
    batching.  The flexibility of Netlink2 comes from its wires & bundles. In 
    the current version of the draft there is no capability discovery yet.
    Q Alex - The draft does not seem to give specifics about 
    Lots of should/could but no details ?
    A Jamal - last section talks about this, the draft gives mechanisms, need to 
    add details
    Q Alex - What about Scalability issues?
    A Jamal - by using broadcast and multicast
    Q Lorenzo Vicisano (co-chair of reliable multicast WG) - Scalability might be 
    limited by reliability
    A Robert - reliable multicast methods from this WG should be used if 
    FE Model - Ram Gopal
    Ram showed the FE Block and the block library. On the Issue list he had - 
    topology discovery out of scope, no restriction of FE block layout, 
    control of topology CE or FE? The intend is to provide a bunch of 
    handles and do not represent topology.
    Q XYZ - what do you mean by logical loops & physical loops?
    A Ram - physical - layout of board, logical - blocks can have some logic
    Q Jamal - looping to same instance should be allowed
    A Ram - yes, this depends on the block properties
    Q Joel - describe blocks on wire and in doc and need input from WG
    Q Jamal - no constraint on how many FE blocks can be connected, add some
    text for this.
    Q Chair - Has the doc been read?
    A Quite a few people have read the draft but more people should be 
    Chair - Should further discuss the draft on the mailing list
    TIPC (Telecom Inter Process Communication) - Jon Maloy
    TIPC is high-speed, reliable message oriented communication service 
    specially designed for cluster environments. They implemented the FACT 
    proposal on top of TPIC and using XML encoding.  The protocol has a 
    logical addressing scheme and agile connections.  It was claimed that TIPC is 
    easily portable. It runs on different interconnects (over Ethernet, 
    Q Alex - Why TIPC over SCTP, it is already a transport?
    Q - how does TIPC addressing work on IP?
    Q - is it used most of the time over Ethernet or over IP ?
    A Jon - over Ethernet,
    Q - then why 2 addressing schemes?
    A - for logical addressing
    TIPC is location transparent, and FE binds to services.
    At the start of the synchronization the topology detection takes place.
    Q Jamal - is this built into TIPC ? or in lower transport ?
    A Jon - yes
    Demo of FACT/XML over 2 P4 systems
    Q Alex - what is the latency of the switch?
    A Jon - currently 1 sec
    Q Jamal - how big is this protocol? Would it fit on top of a router?
    A Jon - code size is 15,000 loc
    Q - why is it inside the kernel?
    A - for performance reasons


    Forwarding and Control Element Protocol (FACT)
    Netlink2 as ForCES Protocol
    ForCES Forwarding Element Functional Model