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 |
Current Meeting Report
ForCES Meeting Minutes , Dec 10, 2001, 1930-2200
Notetakers: David Putzolu, Patrick Droz
draft-ietf-forces-requirements-01 , Avri Doria
Focus on changes since last draft , open issues that were unresolved in -00
Changes:
Tightened up definitions
Pre-association phase and post-association phase , what is pre-association phase vs. post-association phase? Agreed that pre-association was discovery (who is my FE/who is my CE?) and post-association was connection establishment and control of FE by CE
Multiple-CE issue , decided to allow multiple CEs but declare that CE-CE communication would be out of scope for the ForCES protocol , re-charter later if we want to do it
FE Model , must express logical packet processing capabilities of the FE
Two layer model
Management issue , NE appears as one entity on the network , including management.
However, people may still want to use a MIB for their FE, etc.
Recognized and accepted that external management may access a FE for monitoring and transitioning from pre- to post-association phase.
Transport Protocol , for IP networks an RFC2914 compliant transport will be used. Still need application layer reliability (e.g. acknowledge command success)
Questions?
Kathleen Nichols , PacketDesign: Question on QoS section , reference to a draft , should correct references to be to RFCs not drafts
V. Sharma , Q: When you have mgmt traffic , typically you go to the CE directly rather than the FE. A: We assume that most access is through the CE , just accepting the fact that some may want to go directly to FE , cannot preclude it.
David McDysan - Worldcom , Q: Messages received by FE that need to be processed by CE. May want to mention in requirements that ability to place controllers or multiple controllers in the network is needed. Be more detailed
Ram Gopal , Nokia , Q: Why does the FE Manager talk to the FE , should it talk via the CE? A: Pre-association phase is where FE mgr. needs totalk to FE , it is the entity that informs the FE who its CE is. Q: Is CE and FE mgr in scope of ForCES?
A: Yes, CE and FE managers are outside scope of protocol, but exist.
Comment: Should elucidate that these are not part of the protocol or say that the minimum requirements and say rest is off the table (e.g. we don't care).
? - Q: Maybe in this document we need to address the issue of crashing of FE or CE. A: Will go back and check if there, if not will add it.
? - Comment: May often have management PDUs going through the FE to the CE , is an engineering issue
Alan DeKok , Solidum: Q: 6.2.1.1 Some short text on classification ,
DiffServ model draft should be referenced here.
Chairs: Last call? No strong opinion in the room , decided to do another iteration of the draft before going to last call.
draft-crouch-forces-applicability-00 , ForCES Applicability Statement , Mark Handley
Why does ForCES need one? Try to make sure we are all on the same page , say both what we want to do and what ForCES isn't.
Don't expect this to become standard until ForCES protocol itself goes to RFC
? - Comment: This is perfect for an informational RFC , good place to discuss important issues like what uses of ForCES. A: Don't want to micromanage but do want to give good guidelines.
Manav Mishra - Intel: FE to FE communication question , haven't mentioned FE to FE or CE to CE. A: Still don't have consensus.
Margaret Wasserman , Wind River: Value of writing this now? Isn't this requirements? A: These are more bounding the problem than specifying requirements for a solution.
? - Comment: We are scoping what the design and application of the protocol should look at , don't use it for
Dave McDysan - WorldCom: Requirements should take inspiration from this maybe should defer this till later. Also, label-switching being out of scope may make this work more experimental as we may need that function to be used in production. A: IESG initially directed us to focus on the things that don't exist , IP.
Bill Fenner , Routing AD: Look at applicability statement as something saying what we don't have to solve as opposed what we do have to solve.
Thus lets us focus better on what we do need to solve. A: Agree completely.
Reason this document was people were talking about using ForCES for thing such as controlling an entire WAN from one central box, etc., - wanted to focus ForCES more to not solve all possible configurations.
Chairs: Should we make this a working group document? Rough consensus in the room for making this a WG document. Will take to list for confirmation.
draft-anderson-forces-model-00 , ForCES Model and Architecture , Todd
Anderson
Architecture Picture
? - Comment: Can be extremely complicated to have multiple CE coordination , would be interesting to see on the list who wants to do this.
Ram Gopal: What if one CE set controls one FE, another set con
Margaret Wasserman: CE sets useful for failover, etc.
Ram Gopal - Any CE should be able to talk to any FE.
? , From ForCES protocol perspective should we have one CE or multiple CEs? Is it relevant? A: Need to just explain this model in order to have the FE be aware of multiple CEs. Comment: Don't want to duplicate what is in other working groups. A: GR is out of scope , most seem to think that
Avri Doria: Comments: FEs are logical FEs; Many CEs can be talking to same FE at same time , up to CEs to keep themselves coordinated. CEs also need a way to discover other CEs , that may need to be dealt with. A: Maybe that is part of GC.
Margaret Wasserman: Do the FEs need to tell CEs if other CEs have done something? If we can keep that out of scope things are simpler.
Avri Doria: Agreement , FEs should not need to keep CEs coordinated.
Ram Gopal: This brings out some open issues in requirements and applicability documents.
FE Model
? , When do you assign namespace , part of capability exchange? A: IANA assign. Q: What if two FEs have same capabilities? A: Send same info to CE , use the same namespace of FE types. Q: How does CE differentiate FEs? A: Via protocol connection ID (endpoint ID). Comment: FE has to know which namespace it belongs to. A: FE has to know values of names for its capabilities. Comment: How is range conveyed prior to protocols like RIP, etc. running? A: Range is used to say what acceptable values a FE can support for the value of some configured protocol.
Mark Handley , Where do stage instances appear from? Some are inherent abilities of FE, some might be configured from CE , i.e. configure together these five things. A: FE exposes a fixed topology of stages. Comment: Should not rule out reconfiguration at the start.
Manav Mishra , Intel , Q: Do stages or capabilities and stages get reported to CE? A: Both , first list supported stages, then their types, then the topology of their graft. Q: What about how things are restricted? A: Reported on a per-property basis.
V. Sharma , Q: If you do reconfiguration, is traffic interrupted? A: Probably
Consensus that due to the newness of this draft it should go through another iteration before acceptance as a WG document.
General Comments
Bill Fenner (AD) said that the WG has documents we want to get feedback soon.
Open issues should be posted to the mailing list that people can comment on the unsolved or unresolved problems.
There were also a number of comments made to include FE-to-FE communications.
Slides
ForCES Applicability Statement
ForCES Design Team
'draft-anderson-forces-model-00'