Last Modifield: 06/05/2002
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.
| MAY 02 | Submit requirements document to IESG | |
| JUL 02 | Submit framework document to IESG | |
| NOV 02 | Submit formal definition of controlled objects in functional model | |
| NOV 02 | Submit forwarding element functional model document to IESG | |
| MAR 03 | Submit applicability statement to IESG | |
| MAR 03 | Submit protocol selection/definition document to IESG |
Forwarding and Control Element Separation (forces) Monday, November 18 at 0900-1130 ================================== CHAIRS: Patrick Droz <dro@zurich.ibm.com> David Putzolu <david.putzolu@intel.com> Scribe: George Jones <george@uu.net> Agenda bashing: nothing changed Completed Last Calls draft-ietf-forces-framework-03.txt draft-ietf-forces-requirements-07.txt draft-ietf-forces-netlink-03.txt Discussion of draft-ietf-yang-model-01 - authors, history presented - motivation FE == Forwarding Element CE == Control Element * FE tells CE capabilities * FE tells CE current config * CE tells FE desired state - what is in the model * FE block (abstract base class) * Block library (Forwarding, QoS, filters, etc.) * Example FE Blocks * FE stage and directed graph * Two approaches in graph modeling * Topological (DiffServ) + No info carried forward * Topological (DiffServ) vs. Encoded State (QDDIM model) + Explicit info (preamble) carried forward to subsequent stages - open issues * Data modeling language: representation + SMI/SPPI/ASN.1/XML/UML ? * Topological vs. Encoded State approach * Modeling of actual functions + identify minimal categories/set of functions + model for each one - next steps * WG document * Data modeling language * define small set of functions Q: Is your intent to specify the way that the FE and CE communicate ? If so, it's very important to get right.A: yes. Q: (statement) Topological model is easier to reason about.A: We can take it on a case-by case basis. Q: (statement) We need to be aware that we don't just want to encode the a snapshot of the current state of the worldA: We need help from the chairs to avoid this. Chair: show of hands, who's read ?Answer: not enough. Need more discussion to accept as a WG model. Abstract, not easy to discuss. Chair: We'd like people to start submitting actual protocol drafts. Easier to actually talk about/discuss. Action: model will not be WG document yet. Status of other drafts Closing: Do protocol submissions. End of meeting. |