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 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-09

Chair(s):
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: (un)subscribe forces
Archive: ftp.ietf.org/ietf-mail-archive/forces
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
Done  Submit framework document to IESG
Nov 04  Submit forwarding element functional model document to IESG
Mar 05  Submit formal definition of controlled objects in functional model
Mar 05  Submit protocol selection/definition document to IESG
Mar 05  Submit applicability statement to IESG
Internet-Drafts:
  • - draft-ietf-forces-model-03.txt
    • Request For Comments:
    RFCStatusTitle
    RFC3549 I Linux Netlink as an IP Services Protocol
    RFC3654 I Requirements for Separation of IP Control and Forwarding
    RFC3746 I Forwarding and Control Element Separation (ForCES) Framework

    Current Meeting Report
    ForCES Minutes - IETF60, San Diego, California, United States


    Forwarding and Control Element Separation WG (ForCES)

    Monday, August 2 at 1300-1500
    =============================

    CHAIRS: David Putzolu <David.Putzolu@intel.com>
    Patrick Droz <dro@zurich.ibm.com>

    Attendees: Approximately 40

    Co-chair (David) absent.
    Steve Blake notetaker

    WG status: presented slide
    - no comments


    Alex Audu: draft-audu-forces-PL-00

    - Discussed NE states
    - Joel: do you mean a collection of CEs and FEs? Not sure an NE has state?
    - Alex: Yes, a collection. Any device has a state.
    - Joel: Not necessarily. No single physical device.
    - Alex: Need to know the state of the element.
    - Joel: I think I disagree. Questions you want to ask: Is there a working
    CE? Are there FEs associated with that CE that are working.
    - Alex: NE is defined as the collection. How do the states of the individual components affect the state of the whole.
    - Joel: Redundancy is within the scope of the NE (?). Not sure that the NE is a useful element to discuss with respect to the protocol.
    - Discussed how CE/FE states can be used to compute NE state
    - Joel: this table assumes one CE, but we assume multiple.
    - Alex: table is misleading; mean to say that, for example, "CE State" refers to all CEs.
    - Joel: Long history of how to represent things in SNMP, etc. Don't need to invent new nomenclature.
    - Alex: not intending to invent nomenclature.
    - Patrick: it is not clear that this is part of the charter
    - Joel: If none of your CEs are up, then there is no way to talk to the NE. The NE state is only of concern in the context of network management.
    - Alex: This needs to be defined in the context of ForCES.
    - Discussed CE-FE state transition matrix
    - NE state basically tracks the states of the FEs
    - Discussed Protocol Overview
    - Discussed Message Design
    - Fully Coupled API (FCA)
    - Fully Decoupled API (FDA) (preferred)
    - Discussed ACKs
    - Discussed Message Structure
    - Discussed Layers
    - If transport is IP, don't need a TML
    - Joel: do you want to reinvent everything in transport protocols in the PL? Your statement doesn't follow.
    - Alex: Main reason for TML is to adapt PL to non-IP transports. TML is a transport mapping layer.
    - Joel: You need more than just IP as a transport.



    Avri Doria: draft-doria-forces-protocol-01
    http://psg.com/~avri/forces/forces-ietf60-fpteam.pdf

    - Discussed layers, pre-association phase, post-association phase
    - Discussed PL/TML separation
    - Alex: Making the TML too heavy. Example: security.
    - Avri: How much of this do you want to handle in the PL?
    - Alex: How do you cope with different TMLs on the CE and FE.
    - Jamal: No point in reinventing the wheel. Nothing being reinvented.
    - Discussed message header:
    - Joel: What are you attempting to accomplish with the version field. Differentiating major/minor is not helpful. CEs and FEs may support and advertise a range of supported versions. Encoding specific feature support in a "minor" version will not work out.
    - Jamal: Joel has a point. This was brought out in the interop test.
    - Avri: Ok
    - Discussed Messages
    - Alex: Draft suggests State Maintenance Messages may not be necessary down the road. Believes that state maintenance is demphasized.
    - Avri: Probably agree with you.
    - Alex: Draft should address the issue of state. Need a state machine.
    - Jamal: State machine will come. Have an FE Object and FE Protocol Object which may conflict with the State Maintenance messages.
    - Discussed FE Protocol Object
    - FE Object: not sure what is maps to in the model
    - Joel: The things you capture here are what we tried to capture in the model. We will create two LFBs that always must exist, allowing us to use the same protocol messages to manage FE attributes.
    - Discussed Scalability Factors
    - Discussed HA (specifically CE-CE failover)
    - ?: Not concerned with FE redundancy
    - Avri: Don't understand yet what we want for FE redundancy. Haven't talked about it yet.
    - Jamal: We agree. Don't know what to put in the header to facilitate this. Suggestions welcome.
    - Discussed Security
    - Discussed To-Do items
    - Request that draft-doria-forces-protocol-01.txt become a WG draft.
    - Hums indicate rough consensus for approving it as a WG draft
    - Alex: Comment on the draft. Complexity makes me nervous. Still lots of holes. There is an alternative (my draft). Don't see a resemblance to what previously existed.
    - Patrick: WG previously agreed to a merge. Wasn't sure it was possible, but is was. Not done yet.
    - Joel: Accepting this as a WG document doesn't mean that it is done. It is a good basis for further progress. Expect that the final doc will have major changes from this one.
    - Announcement: Three preliminary implementations have interoperated to form a FE cluster. Future interop tests planned.

    Lily Yang: Analysis of Control, Data separation in ForCES protocol for protection against DoS attacks.
    Authors: Hormuzd Khosravi, Shashidhar Lakkavalli
    - Discussed Requirements
    - Discussed experimental setup
    - Discussed experimental results
    - Jamal: where does the prioritization happen?
    - Lily: think it at the pthread level
    - Jamal: not at the Ethernet level?
    - References: http://www.sstanamera.com/~forces/Ietf59/testbed_dong.pdf
    - Joel: have they tried the experiment with TCP for control, DCCP for data? Don't want retransmission for data.
    - Lily: tried, but the DCCP implementation is buggy
    - Steve: Shouldn't these connections be separate anyway because the endpoints are in separate address spaces?

    Lily Yang: draft-ietf-forces-model-03
    - Discussed changes
    - Discussed output groups
    - Jamal: Need a formal definition of what distinquishes ports in port groups. I'm confused.
    - Joel: Input side is different from the output side. Example Scheduler; need to know which one the packet came from. Different LFBs can do output port selection based on different criteria. The LFB class definition has to be very specific as to how this selection happens.
    - Discussed To-Do items
    - Jamal: Do you think there will only be one LFB class definition document?
    - Joel: One core library document with XML for each included LFB class
    - Patrick: Take off-line please.

    Steven Blake: draft-blake-forces-attrib-00

    - Discussed Bundled Configuration, Attribute Sharing, and Inter-LFB control problems not currently solved by the Model schema:
    - Joel: Can handle Inter-LFB Control problem with special control paths (metadata only) in the topology
    - Jamal: Can handle LPM case by having two LPM LFB instances with flags that show that they share attributes.
    - Steve: Needed mechanisms not in the schema yet.


    Furquan Ansari: draft-ansari-forces-discovery-00
    - Joel: If you separate the bindings from the topology discovery, then couldn't we use something like BFD to do this topology discovery. Then we don't have to invent another protocol.
    - Furquan: Discussing BFD with extensions
    - Jamal: <missed comment>
    - Alex: Don't want a fat protocol (e.g., BFD)
    - Joel: BFD isn't fat!
    - Jamal: Do we really need this?
    - Joel: CE could configure FE to send all unrecognized packets to the CE. CE could receive OSPF Hellos; don't necessarily need a new protocol. Need to be very clear about what problem we are solving.
    - Joel: The CE needs to be able to discover the topology. That does not mean that we need a CE discovery protocol. What is the interoperability we are achieving here. There might be a BFD LFB. Spell out more clearly what the value-add is.
    - Discussed Discovery protocol
    - Discussed Inter-FE Topology Discovery and Maintenance
    - ??: What is the neighbor ID?
    - Furquan: Neighbor ID is FE ID.
    - ??: <couldn't follow comment>
    - Furquan: If you are using IP, then you can get the MAC address.
    - Patrick: Please take offline.
    - Conclusion: need to add inter-FE topology discovery and inter-FE topology maintenance to the charter.
    - Patrick: Need to discuss with co-chair (David)
    - ??: <couldn't follow comment> In case of SONET, could be multiple IP addresses.
    - Furquan: IP address is not the equivalent of a router ID.
    - Jamal: Demo after this.
    - Patrick: Jamal will show the demo. Meeting adjourned.



    All presentations from the meeting are available at the following web site:
    http://www.sstanamera.com/~forces/Ietf60/index.html

    Slides

    Agenda
    ForCES Protocol
    Analysis of Control, Data separation in ForCES protocol for protection against DoS attacks
    Forces-PL Design Criteria
    Some Possible Extensions of the Current LFB Model
    Element Bindings and Topology Discovery Protocol
    Meeting Summary