2.6.2 Forwarding and Control Element Separation (forces)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional FORCES Web Page

Last Modified: 2005-09-20

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://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 2004  Submit forwarding element functional model document to IESG
Mar 2005  Submit formal definition of controlled objects in functional model
Mar 2005  Submit protocol selection/definition document to IESG
Mar 2005  Submit applicability statement to IESG

Internet-Drafts:

  • draft-ietf-forces-model-05.txt
  • draft-ietf-forces-protocol-05.txt
  • draft-ietf-forces-tcptml-01.txt
  • draft-ietf-forces-discovery-01.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

     
    IETF 64 ForCES Meeting in Vancouver

Agenda bash
-David Putzolu (chair)

wg status 
Protocol draft WG LC

Joel has requested for IESG review of draft, need to finalize other drafts before IETF LC



Base LFB library
-Joel Halpern

connectivity lfbs
packet validation & manipulation lfbs
classifier lfbs
packet control lfbs
queue & scheduler lfbs

David P - reuse from MIBs, PIBs, NPF, etc.
Joel - sure we can reuse, there is lots of related work out there

Weiming - how do you communicate between FEs, one being queue & other being scheduler
joel - model doesnt define how to communicate but who communicates, the actual communication is implementation specificjoel - control info is represented using metadata




ForCES MIB
-Robert Haas

Management of entire NE
Not duplicate information available via ForCES
SNMP may or may not see multiple CEs
Single NE MIB alternative & CE MIBs alternative
Furquan - do we consider the case where there will be more than 1 active CE in the NE?
Robert - yes, provided the functionality is not replicated between CEs
Jamal - why do we prefer the multiple CE alternative?
Robert - how do we implement the other option, need to define new protocols to support this
Jamal - how about using AgentX for multiple CE alternative?

MIB Contents

Avri - which FEs are being referred to? how about FEs that are down?
Joel - cant expect the MIB to tell you what FEs it doesnt know about, i.e. has been associated sometime in the past
Robert - agrees to add this to the draft
Avri - should we make this a WG draft?
Jamal - MIB should reflect the FE protocol object
Joel - MIB is controlling the CE, so it wont work this way


ForCES TML Service Primitives
- weiming

Joel - why do u differenciate between attributes and capabilities ??
weiming - agrees

motivation for standardizing SP
SP - APIs...

Joel - dont need to define the parameters, that is the implementation
Jamal - you need to define how its done
Joel - what are the services that TML needs to provide, not apis
Jamal - can we use socket primitives?
Joel - not comfortable defining apis, socket calls in the ietf
weiming - may be use different names?
Joel - doesnt agree this (TML Config) is the primitive
Joel - should not define subroutine for these functions


TCP+UDP TML
-weiming

motivation
TCP+UDP - good deployment
No TML messages
UDP for redirect & HB msgs

Joel - strongly recommed not to invent a CC or DoS prevention mechanism
?? - something is possible if we can look at the TCP queue size, but this is research
univ of amsterdam (prof??)- need to careful about this before sending it out on a real network

Joel - udp tml should only be used when there is no congestion in the environment, should be indicated in the applicability statement as optional tml

Jamal - single hop environment such as chassis may be suitable for this tml
Joel - how will multicast work for udp tml
weiming - have pl configure the tml multicast channels
jamal - can use multicast within one hop environment
joel - what is a master ce?


Intra-NE routing mechanism
- x. Guo

motivation

joel - terminology change, have multiple forwarding tables not routing tables
guo - agrees
jamal - should be merged with the existing topology draft, similarity, end goal is the same
david - why are security requirements different?
hitachi?? - need packet format for transmit packet from one fe to another
huawei?? - 2 cases, single hop & multihop?
jamal - one of the lfbs presented by joel is intended to define how packet traverses
joel - several different issues - need to provide a way to model different approaches, rather than standardizing the packet format



ForCES Implementation Experiences
- Jamal

Using ATCA based hw setup

LFBs to support IPSec processing NE
FEO
FEPO
redirect
netdevice/port
IPv4
IPSec

David - what TML have you used?
Jamal - TCP tml, will probably try udp for redirect shortly

ForTER - ForCES Router implementation
- Ligang Dong


Funding NSF china, 3 sources
More than 10 students working on this

Architecture very similar to NPF
Use Intel SDK for FE
Use ATCA chasis to build the ForCES NE

LFB model based on Intel SDK

    Slides

    Proposed ForCES Base LFB Library
    ForCES MIB Proposal
    ForCES TML Service Primitives
    ForCES TML Over IP Networks
    Intra-NE routing mechanism
    ForTER - A ForCES Router Implementation