Last Modified: 2003-09-10
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 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|
|RFC3549||I||Linux Netlink as an IP Services Protocol|
***58th IETF ForCES WG Meeting Minutes Monday, November 10 2003 at 1300-1500 ===================================== CHAIRS: David Putzolu <David.Putzolu@intel.com> Patrick Droz <firstname.lastname@example.org> AGENDA: 5 min - WG status - chairs 10 min - A proposed vocabulary and conceptual model for discussing metadata within ForCES - Alan DeKok http://www.ietf.org/internet-drafts/ draft-dekok-forces-metadata-00.txt 25 min - ForCES Model Update - Steven Blake http://www.ietf.org/internet-drafts/ draft-ietf-forces-model-01.txt 5 min - Topology representation for ForCES FE model - Weiming Wang http://www.ietf.org/internet-drafts/ draft-wang-forces-model-topology-00.txt 20 min - General Router Management Protocol (GRMP) Version 1 - Weiming Wang http://www.ietf.org/internet-drafts/ draft-wang-forces-grmp-00.txt 20 min - Netlink2 protocol - Steven Blake http://www.ietf.org/internet-drafts/ draft-jhsrha-forces-netlink2-01.txt 20 min - Status update for FACT protocol - Ram Gopal http://www.ietf.org/internet-drafts/ draft-gopal-forces-fact-05.txt 15 min - Linux traffic control extensions & the forces model - Jamal Hadi Salim (no draft available) Minutes 1) ForCES WG status update on major WG drafts Requirements: waiting for RFC # framework: seurity comments from IESG on authorization needs to be incorporated. Model: more work needs to be done but good progress. 2) Alan DeKok: A discussion of Metadata in ForCES A proposed vocabulary and conceptual model for discussing metadata within ForCES. It is "data about data". Meta data: Implicit - inside chip, explicit - outside chip Jason: Why is it important? Alan: this is important to the definition of the model LFB topology between FEs. Vendors may have internal communication within a chip. This communication is out the scope of the forces communication. Robert Haas: explicit internal metadata for forcES, right? Alan: depends on implementation. Joel: explicit and LFB-external metadata for ForCES. Alan: Yes. if multiple LFBs inside one chip, the actual implementation of metadata between LFBs are not the same as how ForCES defines the metadata. We need to recognize that. 3) Steve Blake: on model v01 Changes since v00: merged with Zsolt and Steve's contribution, added as co-authors, significant re-organized Directions taken: distinguish between FE model and LFB model. Allow packet datapath to be represented using both topological and encoded state. Allow LFBS multiple in/out and group in/out concept List of open issues: Inter-FE topology - the protocol should be capable of querying this from the FE, but the question is whether it belongs to the protocol or the model. ForCES protocol parameters (in scope) possibly inscope: implicit metadata for LFB topology validation & debugging. Do we really need to model pass-thru mode for metadata? Multiple Inputs/outputs & input/output groups. Output group can be used as embedded redirector within an LFB Mux and redirector. Dynamic LFB topology reconfig is good for enabling support for new protocols? Example: turn on L2TP support. Configuring QoS reservation for a new RSVP flow does not necessary require a topology reconfig. Would the FE stop forwarding while reconfiguring the topology? Joel: code downloading is out of scope for now. But should allow extension later. David: Shouldn't the CE know whether or not the FE stops forwarding when reconfiguring? Joel: want to avoid explict "stop, reconfig, start". It is best to have transparent operation. Jamal: It is feasible. LFB class partitioning: finer grain or coarse grain? We need to come up with the right balance. Modeling port LFBs input and output: split or combined? similar problem: ip interface, encap/decap modeling lookaside LFBs: devices that receive part of a packet and produce metadata but otherwise are not in the direct datapath modeled as "tap LFB + lookaside LFB" ? Modeling queueing and scheduling LFBs. Schedulers pull packets from queues. Model does not model timing. Modeling classification - classification LFBs. Protocol-specific LFBs look at appropriate fields within the packets, but not embedded classifiers. Jason: what about content inspection for classifiers? Upcoming work items for -02: work on Sections 4-8 Steven solicitated feedback on the draft. 4) Weiming Wang: GRMP proposal Deveopled separately from GSMP but considers compatibility Messages to do FE, LFB, and datapath management. Reliability consideration: use GRMP built-in error mechanism. Uses IPsec/TLS for security. Mor work has to be done to cover mor medium Operating objects in GRMP: object types + object class = object ID FE attributes/capabilities/events GRMP defined/Model defined/vendor defined DoS protection Scheduling & DoS Attack Alert Policy Joel: What you have here is interesting. But why in the protocol? Why not using LFB instead? Lily: sounds like there is chicken and egg problem here. Weiming -- the GRMP slave module needs to be up before the ForCES protocol can be used. 5) Weiming Wang: On Topology representation (PkfID) A name assigned to a single connection or a group of connection, conceptually like virtual buffer Joel -- there are no buffers represented in the protocol, don't know what you mean here. I am really sorry. 6) Steve Blake: on Netlink2 - changed TLV encapsulation to permit multiple TLVs in the same Netlink2 message. - provided state transition diagrams for FE-CE protocol association - added LFB definition derived from Netlink RFC 3549: Interface Service, Address Service, IPv4/v6 Forwarding, Neighbor Discovery. - extended security measures for local scope and global scope environment: protection against DoS with policer LFB for data traffic redirected to CE. Netlink2 SYN cookie TLV to protect against Netlink2 SYN flood attacks. - use of qualified names for FEs and CEs to perform authentication. Netlink2 and ForCES requirements: - solves one of the scalability requirements by supporting multicast wires (ForCES-level group addressing): routing table updates can be multicast from CE to all FEs. - Netlink2 can be layered directly on top of link layers (Ethernet, Infiniband, etc) - all of the other requirements are met. Netlink2 reference code: - announcement will be made on the list within the next month - open source - demo of one CE updating route tables of two FEs using Netlink2 group addressing over IP multicast. 6) Ram Gopal: on FACT protocol TCP used for control channel, DCCP for data channel and TLS for security. There is a rate limiting mechanisms on FE Jamal : what is the point of priority? Ram: gave an example. Explicit ACK/response msgs Interconnect independence: CE tag, FE Id for interconnect independent addressing CE redunancy or Failover (heartbeat) 7) Jamal: Linux Traffic control extension and ForCES model High level view of an FE 8) There was a demo given of running Netlink2 code.