NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Patrick Droz <dro@zurich.ibm.com>
David Putzolu <David.Putzolu@intel.com>
Rob Coltun <rcoltun@redback.com>
Abha Ahuja <ahuja@wibh.net>
Rob Coltun <rcoltun@redback.com>
Abha Ahuja <ahuja@wibh.net>
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
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.
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 |
---------------------------------------------------------------------
ForCES Working Group Meeting Minutes from the 51th IETF, London UK
---------------------------------------------------------------------
Meeting Agenda
--------------
- Agenda Bashing
- WG Charter
- Linux Netlink Draft
- 2 Requirements Drafts
Welcome and Charter Status
--------------------------
There were about 200 people attending the first ForCES meeting.
Unfortunately there was only one blue-sheet available so many people did not have the chance to sign it in the given time. ForCES is now an official IETF Working Group. This was confirmed by Rob Coltun (routing area director). A short summary was given concerning the status after Joint meeting with the GSMP WG at the last IETF.
- Agreed that ForCES is a separate effort
- Strong encouragement to examine GSMP as a candidate protocol when the time comes
- The IESG added a statement to the charter that the WG has to use an existing protocol in case the distance between a CE and FE is multi-hop in compliance to RFC 2914
There were no question concerning the charter.
I-D Presentations
-----------------
1) Netlink as an IP services protocol (draft-salim-netlink-jhshk-00.txt) by Jamal Hadi Salim, Znyx
Jamal showed that there are some commonalities between what ForCES wants to a achieve and what the Netlink interface can provide. He also showed that the Netlink the way it stands today is not sufficient for a distributed setup required for ForCES. Netlink originates from BSD route socket. It was originally only used for routing information but this has been expanded. The concept is based on the idea of "IP service" abstraction and asynchronous event notification. Flow-graphs were presented and the message format which makes use of TLVs was introduced. As an example IPv4 forwarding functionality was shown. It was agreed that the draft would become an informational. Comments from the mic indicated that PFkey could also be considered. Jamal's response was that PFkey is a subset of Netlink i.e it is another IP service. The IPSEC folks decided to use PFkey because it was standardized for IPSEC and therefore widely deployed. They had started with netlink on Linux, but had to change for standardization reasons. It was also noted that the documentation of Netlink is somewhat lacking. I-Ds in the space seem to be welcome. Further comments on the mice from Steve Willis asked first to get a problem statement before jumping into the solution. Furthermore, a requirements document will be needed. Afterward should follow an architecture document.
2) Requirements for Separation of IP Control and Forwarding Services
(draft-salim-forces-alt-jhs-00.txt) by Jamal Hadi Salim Znyx
Jamal presented his framework draft which is a lot more generic compared to his first presentation. It allows for more than one control element (CE) to control an forwarding element (FE). It is also open whether the FE and CE are Co-located or not. Even a multi-box environment could be supported where FEs and CEs can physically be separated. Every CE can control multiple of FEs. There are also requirements for gathering statistics. People at the mic suggested also to include classification engines and QoS engines. It was also suggested to use a more generic term such as "data-plane engine" instead of FE. The interaction between CEs and FEs is defined as an offering of service to each other. It is also suggested to have multicast capabilities. Jamal suggested to define the exact functionality of "forwarding" that includes all the things that can happen to the date being forwarded.
3) Requirements for Separation of IP Control and Forwarding
(draft-anderson-forces-req-02.txt) by Todd Anderson, Intel and Ed Bowen, IBM
Todd presented the changes that had been made since version 01. Unfortunately the draft did not make the official dead-line but it was posted to the list. He presented New requirements that were discussed on the mailing list that are still open issues were presented. This includes resource notification and partitioning. This would allow that an FE is only a subset of resources of a box. That is motivated by the portioning discussions in the GSMP working group. A second new requirement is to come up with an exact model of an FE. It is the way and FE can tell a CE how it looks like and what in can to for the CE. The CE can in this way discover what can happing to the data while traversing the data plane. But the FE should still be kept as simple as possible a CE should be able to tell an FE that it does not want to be controlled at all by the FE. Thus most of the complexity could be kept in the CEs. This particularly applies in the case where the FE is just a fast packet forwarding engine without much intelligence.
Then the list of the already established requirements was give which include:
- CEs and FEs can be connected by various types of interconnects
- Inter-FE forwarding should be possible
- A packet that traverses a single hop consisting of more than one physical device should be treated as a single hope e.g. only decrement TTL by 1.
- ForCES will require a protocol
- Mans have to be provide to detect loss of connectivity
- Packet redirection has to be provided
- It must support different types of FEs
- It must allow for topology discovery
= It must be scalable
- It most provide event notification
What is still open is whether the communication between the FE and CE should be reliable or not.
Conclusions
-----------
To to the strong overlap of the 2 requirements documents the 3 authors were asked to merge their document into a ingle one and resolve some of the open issues either directly or on the mailing list. This was the consensus of the group. The draft on Netlink was accepted as an informational draft.
Thanks to Alan Crouch for taking the minutes.
List and Archive Info
---------------------
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
Agenda
Forces Requirement Proposal
Linux Netlink as an IP Services Protocol
ForCES Requirements