Forwarding and Control Element Separation (forces)

Robert Haas | 5 Jun 2002 16:27

Comment on ForCES Requirements draft: FEs and off-load of signaling functions

I'd like to have the opinion of the list/design team regarding the issue
below, which might impact the requirements draft to some extent (sorry
for popping up just before the last call extended deadline):

Certain FEs begin to provide functions that go beyond per-packet
processing, such as TCP termination, where part of the signaling is
off-loaded to the FE. The definition of "High-Touch Functions" in the
draft does not seem to include such functions.

Would it be wise to consider an additional category, such as "Off-load
Functions", with an appropriate model ? I believe leaving this up to a
"Vendor-Specific Function" would considerably reduce the
attractivity/interoperability guaranteed by ForCES.

Regards,
--
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

headers

Jamal Hadi Salim | 7 Jun 2002 12:40

Re: Comment on ForCES Requirements draft: FEs and off-load of signaling functions


Robert,

Maybe i misunderstood: How does "High-touch" not cover what you are 
addressing? Is it the naming that bothers you?

cheers,
jamal

On Wednesday 05 June 2002 10:27, Robert Haas wrote:
> I'd like to have the opinion of the list/design team regarding the issue
> below, which might impact the requirements draft to some extent (sorry
> for popping up just before the last call extended deadline):
>
> Certain FEs begin to provide functions that go beyond per-packet
> processing, such as TCP termination, where part of the signaling is
> off-loaded to the FE. The definition of "High-Touch Functions" in the
> draft does not seem to include such functions.
>
> Would it be wise to consider an additional category, such as "Off-load
> Functions", with an appropriate model ? I believe leaving this up to a
> "Vendor-Specific Function" would considerably reduce the
> attractivity/interoperability guaranteed by ForCES.
>
> Regards,
> --
> Robert Haas
> IBM Zurich Research Laboratory
> Säumerstrasse 4
> CH-8803 Rüschlikon/Switzerland

(Continue reading)

headers

Jamal Hadi Salim | 7 Jun 2002 12:47

new netlink draft


An updated draft posted at:

ftp://openarchitect.znyx.com/pub/jamal/draft-forces-netlink-03.txt

Please provide comments; we are hoping to last call this.

cheers,
jamal

headers

Robert Haas | 10 Jun 2002 11:33

Re: Comment on ForCES Requirements draft: FEs and off-load ofsignaling functions

Jamal,

Thanks for your response. Let me clarify: the Requirements draft limits the FE
model to express what logical functions can be applied to packets "as they
pass through the FE" (see sect. 6.1). "High-Touch" is defined as a category of
such logical functions.

In my opinion, this model rules out functions such as TCP termination, that
require processing not only as a packet "passes through the FE" (for instance,
handling timers). Functions such as TCP termination are usually performed by
the CE and could be "off-loaded" into the FEs for performance reasons.

Therefore, it seems to me that this issue is not a naming issue, but rather a
design choice defining what the FE model must include or not. Do you agree ?

Thanks,
-Robert

Jamal Hadi Salim wrote:

> Robert,
>
> Maybe i misunderstood: How does "High-touch" not cover what you are
> addressing? Is it the naming that bothers you?
>
> cheers,
> jamal
>
> On Wednesday 05 June 2002 10:27, Robert Haas wrote:
> > I'd like to have the opinion of the list/design team regarding the issue

(Continue reading)

headers

Internet-Drafts | 10 Jun 2002 13:16

I-D ACTION:draft-ietf-forces-netlink-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF.

Title : Netlink as an IP Services Protocol
Author(s) : J. Salim et al.
Filename : draft-ietf-forces-netlink-03.txt
Pages : 34
Date : 07-Jun-02

This document describes Linux Netlink, which is used in Linux both
as an intra-kernel messaging system as well as between kernel and
user space. This document is intended as informational in the con-
text of prior art for the ForCES IETF working group. The focus of
this document is to describe Netlink from a perspective of a protocol
between a Forwarding Engine Component (FEC) and a Control Plane
Component (CPC), the two components that define an IP service.
The document ignores the ability of Netlink as a intra-kernel mes-
saging system, as an inter-process communication scheme (IPC), or
as a configuration tool for other non-networking or non-IP network
services (such as decnet, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-forces-netlink-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then

(Continue reading)

headers

Jamal Hadi Salim | 10 Jun 2002 14:54

Re: Comment on ForCES Requirements draft: FEs and off-load ofsignaling functions

On Mon, 10 Jun 2002, Robert Haas wrote:

> Jamal,
> 
> Thanks for your response. Let me clarify: the Requirements draft limits the FE
> model to express what logical functions can be applied to packets "as they
> pass through the FE" (see sect. 6.1). "High-Touch" is defined as a category of
> such logical functions.
> 
> In my opinion, this model rules out functions such as TCP termination, that
> require processing not only as a packet "passes through the FE" (for instance,
> handling timers). Functions such as TCP termination are usually performed by
> the CE and could be "off-loaded" into the FEs for performance reasons.
> 
> Therefore, it seems to me that this issue is not a naming issue, but rather a
> design choice defining what the FE model must include or not. Do you agree ?
> 

It depends on how you look at it. And it does become a design issue, but
the model doesnt stop you;
lets take TCP termination, for example:
I would think that the setup phase where the splicing is being set up is
a control plane activity. So is the termination. With the current model
you could redirect specific packets to the control plane (eg in this
case, If i understood correctly, would be SYN/FIN packets).
Activity after the connection is "nailed" seems to me belongs to the
FE (such as munging the ACKs and splicing).
On the same token, timers to generate FE events seem to me also to be
control activity.
Did i understand you correctly?

(Continue reading)

headers

Robert Haas | 10 Jun 2002 21:34

Re: Comment on ForCES Requirements draft: FEs and off-load ofsignalingfunctions

Jamal Hadi Salim wrote:

> On Mon, 10 Jun 2002, Robert Haas wrote:
>
> > Jamal,
> >
> > Thanks for your response. Let me clarify: the Requirements draft limits the FE
> > model to express what logical functions can be applied to packets "as they
> > pass through the FE" (see sect. 6.1). "High-Touch" is defined as a category of
> > such logical functions.
> >
> > In my opinion, this model rules out functions such as TCP termination, that
> > require processing not only as a packet "passes through the FE" (for instance,
> > handling timers). Functions such as TCP termination are usually performed by
> > the CE and could be "off-loaded" into the FEs for performance reasons.
> >
> > Therefore, it seems to me that this issue is not a naming issue, but rather a
> > design choice defining what the FE model must include or not. Do you agree ?
> >
>
> It depends on how you look at it. And it does become a design issue, but
> the model doesnt stop you;
> lets take TCP termination, for example:
> I would think that the setup phase where the splicing is being set up is
> a control plane activity. So is the termination. With the current model
> you could redirect specific packets to the control plane (eg in this
> case, If i understood correctly, would be SYN/FIN packets).
> Activity after the connection is "nailed" seems to me belongs to the
> FE (such as munging the ACKs and splicing).
> On the same token, timers to generate FE events seem to me also to be

(Continue reading)

headers

Olivier Marce | 11 Jun 2002 13:09

Re: Requirements Document - Capabilities Model

Hi Joel

"Joel M. Halpern" wrote:

> The DiffServ conceptual model (and MIB / PIB) which have been mentioned as
> starting points for the capabilities model are actually state models, not
> capabilities models.  There is no way to tell from these models how many
> filters a device can handle, or whether it is capable of
> metering.  However, you can tell at any given time exactly what filters it
> has, how they connect to markers, meters, queues, etc.  When you want to
> configure additional processing elements into the processing path, you
> reference the elements of this model.
>

What's about the section 1.2 of RFC3084 ?
"   When a device boots, it opens a COPS connection to its Primary
   PDP.  When the connection is established, the PEP sends information
   about itself to the PDP in the form of a configuration request.
   This information includes client specific information (e.g.,
   hardware type, software release, configuration information)."

Ins't it an sufficient capabilities description step ?

--
Olivier Marce (ARX Project/Active Network WP)
Alcatel R&I Dept                        Tel: +33 (0) 1 69 63 41 67
Route de Nozay                          Fax: +33 (0) 1 69 63 13 59
F-91461 Marcoussis Cedex (France)

(Continue reading)

headers

Olivier Marce | 11 Jun 2002 13:13

Re: Comment on ForCES Requirements draft: FEs and off-loadofsignalingfunctions

Hi Robert

Am I right when I understand that you expect that the FE could offer some
sort of proxy function to the CE (on request of the CE ) ?
If so, am I right when I say that this is in the scope of item #3 of Lily's
message ?

"The third kind of control and configuration is even more powerful and future
looking. In addition to dynamic configuration, CEs might be even allowed to
download a given functionality onto FEs. I am not sure how we model that
yet. But we probably can get by without too concerned with this."

Regards

Robert Haas wrote:
>
> Let's see:
>
> TCP splicing, after the setup phase, boils down to converting sequence numbers back
> and forth, and this is indeed a function that takes place "as packets pass through
> the FE". An ideal candidate for a "High-Touch Function".
>
> But what if I'd like to have some sort of control activity take place in the FE as
> well, such as TCP setup or timers handling ?  The reason is to avoid overloading the
> CE with TCP processing, if the FEs are smart enough to handle this directly. This
> goes beyond the current FE model.
>
> Do you also think that some sort of control activity should be allowed to be
> "off-loaded" into the FEs ?
>

(Continue reading)

headers

Joel M. Halpern | 11 Jun 2002 16:05

Re: Requirements Document - Capabilities Model

When I last reviewed the COPS PIBs, there was some, but only a little,
capability information in the various PIBs.  In conversation with some of
the COPS folks I have been told that more recently both the framework PIB
and the DiffServ PIB have had significant capabilities information added to
them.  I expect to find time before the IETF meeting to review these two
documents.  If there is a good start on the capabilities model in the PIBs,
then we will definitely use that.

Yours,
Joel M. Halpern

PS: For historical context, at one time the DiffServ PIB was closely
aligned to the DiffServ MIB, and the MIB definitely did not have much
useful capabilities information.  Things change.  Note that the information
described in the section you quote is pretty minimal when one things about
capabilities information.  But more has been added in other documents.

At 01:09 PM 6/11/2002 +0200, Olivier Marce wrote:
>Hi Joel
>
>"Joel M. Halpern" wrote:
>
> > The DiffServ conceptual model (and MIB / PIB) which have been mentioned as
> > starting points for the capabilities model are actually state models, not
> > capabilities models.  There is no way to tell from these models how many
> > filters a device can handle, or whether it is capable of
> > metering.  However, you can tell at any given time exactly what filters it
> > has, how they connect to markers, meters, queues, etc.  When you want to
> > configure additional processing elements into the processing path, you
> > reference the elements of this model.

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

2	September 2009
2	August 2009
2	July 2009
3	June 2009
4	March 2009
2	February 2009
1	January 2009
1	November 2008
3	October 2008
8	September 2008
7	August 2008
2	July 2008
9	April 2008
6	March 2008
21	February 2008
20	January 2008
16	December 2007
7	November 2007
2	October 2007
21	September 2007
21	August 2007
21	July 2007
28	June 2007
7	March 2007
7	February 2007
30	January 2007
17	December 2006
45	November 2006
129	October 2006
67	September 2006
74	August 2006
40	July 2006
60	June 2006
14	May 2006
43	April 2006
45	March 2006
35	February 2006
81	January 2006
40	December 2005
102	November 2005
114	October 2005
138	September 2005
92	August 2005
72	July 2005
147	June 2005
55	May 2005
38	April 2005
78	March 2005
193	February 2005
99	January 2005
76	December 2004
63	November 2004
20	October 2004
8	September 2004
46	August 2004
101	July 2004
41	June 2004
32	May 2004
16	April 2004
61	March 2004
37	February 2004
35	January 2004
20	December 2003
236	November 2003
38	October 2003
68	September 2003
66	August 2003
77	July 2003
25	June 2003
7	May 2003
3	April 2003
17	March 2003
3	February 2003
37	January 2003
11	December 2002
9	November 2002
38	October 2002
5	September 2002
1	August 2002
10	July 2002
39	June 2002
32	May 2002
20	April 2002