From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 5 10:27:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02167 for ; Wed, 5 Jun 2002 10:27:31 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00638EF8@cherry.ease.lsoft.com>; Wed, 5 Jun 2002 10:28:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20169323 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Jun 2002 10:28:00 -0400 Received: from 195.212.91.199 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 5 Jun 2002 10:28:00 -0400 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g55ERvfm019562 for ; Wed, 5 Jun 2002 16:27:57 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g55ERvn100132 for ; Wed, 5 Jun 2002 16:27:57 +0200 Received: from dhcp70-214.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46616 from ; Wed, 5 Jun 2002 16:27:56 +0200 X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate.de.ibm.com id g55ERvfm019562 Approved-By: Robert Haas Message-ID: <3CFE1FEC.3283D7A4@zurich.ibm.com> Date: Wed, 5 Jun 2002 16:27:56 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Comment on ForCES Requirements draft: FEs and off-load of signaling functions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02167 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 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 7 11:12:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00352 for ; Fri, 7 Jun 2002 11:12:15 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0063D96E@cherry.ease.lsoft.com>; Fri, 7 Jun 2002 11:12:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20400130 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Jun 2002 11:12:41 -0400 Received: from 208.2.156.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 7 Jun 2002 11:12:41 -0400 Received: from jzny.localdomain ([208.2.156.2]) by rollsroyce.znyx.com (Lotus Domino Release 5.0.7) with SMTP id 2002060708150847:1934 ; Fri, 7 Jun 2002 08:15:08 -0700 X-Mailer: KMail [version 1.2] References: <3CFE1FEC.3283D7A4@zurich.ibm.com> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/07/2002 08:15:08 AM, Serialize by Router on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/07/2002 08:15:10 AM Content-Type: text/plain; charset="iso-8859-1" Approved-By: Jamal Hadi Salim Message-ID: <02060706400901.01652@jzny.localdomain> Date: Fri, 7 Jun 2002 06:40:09 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Comment on ForCES Requirements draft: FEs and off-load of signaling functions Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3CFE1FEC.3283D7A4@zurich.ibm.com> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA00352 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 > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 7 11:19:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00611 for ; Fri, 7 Jun 2002 11:19:15 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0063D8CB@cherry.ease.lsoft.com>; Fri, 7 Jun 2002 11:19:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20400535 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Jun 2002 11:19:45 -0400 Received: from 208.2.156.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 7 Jun 2002 11:19:45 -0400 Received: from jzny.localdomain ([208.2.156.2]) by rollsroyce.znyx.com (Lotus Domino Release 5.0.7) with SMTP id 2002060708221259:1949 ; Fri, 7 Jun 2002 08:22:12 -0700 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/07/2002 08:22:12 AM, Serialize by Router on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/07/2002 08:22:13 AM Content-Type: text/plain; charset="iso-8859-1" Approved-By: Jamal Hadi Salim Message-ID: <02060706471302.01652@jzny.localdomain> Date: Fri, 7 Jun 2002 06:47:13 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: new netlink draft To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA00611 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 From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 10 05:33:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26377 for ; Mon, 10 Jun 2002 05:33:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00641F61@cherry.ease.lsoft.com>; Mon, 10 Jun 2002 5:33:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20559807 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jun 2002 05:33:33 -0400 Received: from 195.212.91.199 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 10 Jun 2002 05:33:33 -0400 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5A9XUAf009962 for ; Mon, 10 Jun 2002 11:33:30 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5A9XUD98812 for ; Mon, 10 Jun 2002 11:33:31 +0200 Received: from dhcp70-214.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60826 from ; Mon, 10 Jun 2002 11:33:24 +0200 X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en Mime-Version: 1.0 References: <3CFE1FEC.3283D7A4@zurich.ibm.com> <02060706400901.01652@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate.de.ibm.com id g5A9XUAf009962 Approved-By: Robert Haas Message-ID: <3D047263.5A68BD60@zurich.ibm.com> Date: Mon, 10 Jun 2002 11:33:23 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs and off-load ofsignaling functions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA26377 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 > > 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 From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 10 07:26:30 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28874 for ; Mon, 10 Jun 2002 07:26:29 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0064224A@cherry.ease.lsoft.com>; Mon, 10 Jun 2002 7:27:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20563170 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jun 2002 07:26:56 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 10 Jun 2002 07:16:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28149; Mon, 10 Jun 2002 07:16:21 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200206101116.HAA28149@ietf.org> Date: Mon, 10 Jun 2002 07:16:21 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-netlink-03.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 "get draft-ietf-forces-netlink-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-netlink-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607132502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-netlink-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-netlink-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607132502.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 10 08:52:39 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01799 for ; Mon, 10 Jun 2002 08:52:38 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006421A7@cherry.ease.lsoft.com>; Mon, 10 Jun 2002 8:52:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20566221 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jun 2002 08:52:22 -0400 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 10 Jun 2002 08:52:22 -0400 Received: from localhost (jamalhadi@localhost) by znyx.com (8.9.3/8.9.3) with ESMTP id FAA00734 for ; Mon, 10 Jun 2002 05:54:47 -0700 X-Sender: jamalhadi@electra.znyx.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Approved-By: Jamal Hadi Salim Message-ID: Date: Mon, 10 Jun 2002 05:54:47 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: Comment on ForCES Requirements draft: FEs and off-load ofsignaling functions To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3D047263.5A68BD60@zurich.ibm.com> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id IAA01799 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? cheers, jamal > > 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 > > > 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 > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 10 15:33:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21226 for ; Mon, 10 Jun 2002 15:33:46 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00643424@cherry.ease.lsoft.com>; Mon, 10 Jun 2002 15:34:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20589568 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jun 2002 15:34:19 -0400 Received: from 195.212.91.201 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 10 Jun 2002 15:34:19 -0400 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5AJYH7n019098 for ; Mon, 10 Jun 2002 21:34:17 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5AJYGD90692 for ; Mon, 10 Jun 2002 21:34:16 +0200 Received: from dhcp70-214.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49190 from ; Mon, 10 Jun 2002 21:34:16 +0200 X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en Mime-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate-3.de.ibm.com id g5AJYH7n019098 Approved-By: Robert Haas Message-ID: <3D04FF36.67D1510F@zurich.ibm.com> Date: Mon, 10 Jun 2002 21:34:14 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs and off-load ofsignalingfunctions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21226 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 > control activity. > Did i understand you correctly? > 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 ? Thanks > > cheers, > jamal > > > > > 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 > > > > 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 > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 11 07:08:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18171 for ; Tue, 11 Jun 2002 07:08:31 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00647681@cherry.ease.lsoft.com>; Tue, 11 Jun 2002 7:09:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20678124 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jun 2002 07:09:00 -0400 Received: from 64.208.49.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 11 Jun 2002 07:09:00 -0400 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA16222 for ; Tue, 11 Jun 2002 13:08:58 +0200 (MET DST) Received: from alcatel.fr ([139.54.208.194]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002061113085749:4415 ; Tue, 11 Jun 2002 13:08:57 +0200 X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20020523155236.0181a690@mail.stevecrocker.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/11/2002 13:08:57, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/11/2002 13:08:58, Serialize complete at 06/11/2002 13:08:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Approved-By: Olivier.Marce@ALCATEL.FR Message-ID: <3D05DA70.D8627EB2@alcatel.fr> Date: Tue, 11 Jun 2002 13:09:36 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Olivier Marce Organization: Alcatel R&I/ARX Subject: Re: Requirements Document - Capabilities Model To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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) From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 11 07:12:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18263 for ; Tue, 11 Jun 2002 07:12:01 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00647651@cherry.ease.lsoft.com>; Tue, 11 Jun 2002 7:12:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20678226 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jun 2002 07:12:35 -0400 Received: from 64.208.49.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 11 Jun 2002 07:12:35 -0400 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA17312 for ; Tue, 11 Jun 2002 13:12:34 +0200 (MET DST) Received: from alcatel.fr ([139.54.208.194]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002061113123229:4445 ; Tue, 11 Jun 2002 13:12:32 +0200 X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <3D04FF36.67D1510F@zurich.ibm.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/11/2002 13:12:32, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/11/2002 13:12:33, Serialize complete at 06/11/2002 13:12:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Approved-By: Olivier.Marce@ALCATEL.FR Message-ID: <3D05DB47.67DAA161@alcatel.fr> Date: Tue, 11 Jun 2002 13:13:11 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Olivier Marce Organization: Alcatel R&I/ARX Subject: Re: Comment on ForCES Requirements draft: FEs and off-loadofsignalingfunctions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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 ? > -- 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) From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 11 10:04:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24820 for ; Tue, 11 Jun 2002 10:04:34 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0064786A@cherry.ease.lsoft.com>; Tue, 11 Jun 2002 10:05:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20684703 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jun 2002 10:05:06 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 11 Jun 2002 10:05:06 -0400 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 3080279; Tue, 11 Jun 2002 10:05:05 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20020523155236.0181a690@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20020611095947.018b8178@mail.stevecrocker.com> Date: Tue, 11 Jun 2002 10:05:00 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements Document - Capabilities Model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3D05DA70.D8627EB2@alcatel.fr> Precedence: list 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. > > > >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) From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 11 12:55:51 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02742 for ; Tue, 11 Jun 2002 12:55:51 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00647CF3@cherry.ease.lsoft.com>; Tue, 11 Jun 2002 12:56:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20693681 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jun 2002 12:56:02 -0400 Received: from 134.134.248.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 11 Jun 2002 12:56:02 -0400 Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5BGtwO29478 for ; Tue, 11 Jun 2002 16:55:59 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002061110042331344 for ; Tue, 11 Jun 2002 10:04:24 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 09:06:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Durham, David" Message-ID: <10C8636AE359D4119118009027AE99870DA5E13B@fmsmsx34.fm.intel.com> Date: Tue, 11 Jun 2002 09:06:35 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Durham, David" Subject: Re: Requirements Document - Capabilities Model To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list I agree with Joel that the DiffServ MIB has no capabilities model, it is primarily state. Nevertheless, the DiffServ PIB together with the Framework PIB actually have a very complete capabilities model. They describe everything from what data structures the device can understand, to what values it supports, it even lets you specify how to configure the state on the device itself. -Dave > -----Original Message----- > From: Olivier Marce [mailto:Olivier.Marce@alcatel.fr] > Sent: Tuesday, June 11, 2002 4:10 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: 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) > From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 12 04:15:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20239 for ; Wed, 12 Jun 2002 04:15:53 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00649C63@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 4:16:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20754889 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jun 2002 04:16:27 -0400 Received: from 64.208.49.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 12 Jun 2002 04:16:27 -0400 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA19929 for ; Wed, 12 Jun 2002 10:16:26 +0200 (MET DST) Received: from alcatel.fr ([139.54.208.194]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002061210162513:2379 ; Wed, 12 Jun 2002 10:16:25 +0200 X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <10C8636AE359D4119118009027AE99870DA5E13B@fmsmsx34.fm.intel.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/12/2002 10:16:25, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/12/2002 10:16:25, Serialize complete at 06/12/2002 10:16:25 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Approved-By: Olivier.Marce@ALCATEL.FR Message-ID: <3D070380.CCCC9F84@alcatel.fr> Date: Wed, 12 Jun 2002 10:17:04 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Olivier Marce Organization: Alcatel R&I/ARX Subject: Re: Requirements Document - Capabilities Model To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Durham, David" wrote: > > I agree with Joel that the DiffServ MIB has no capabilities model, it is > primarily state. Nevertheless, the DiffServ PIB together with the Framework > PIB actually have a very complete capabilities model. They describe > everything from what data structures the device can understand, to what > values it supports, it even lets you specify how to configure the state on > the device itself. > With this in mind, what's about considering COPS + Framework PIB as a candidate to FORCES ? -- 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) From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 12 08:38:26 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25283 for ; Wed, 12 Jun 2002 08:38:26 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0064A012@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 8:39:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20766204 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jun 2002 08:39:01 -0400 Received: from 130.240.3.1 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 12 Jun 2002 08:39:00 -0400 Received: from apocalypse.org (sm-pc301.sm.luth.se [130.240.45.27]) by sm.luth.se (8.12.3/8.12.3) with ESMTP id g5CCctFO010922 for ; Wed, 12 Jun 2002 14:38:58 +0200 (MET DST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 References: <10C8636AE359D4119118009027AE99870DA5E13B@fmsmsx34.fm.intel.com> <3D070380.CCCC9F84@alcatel.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.11 (www dot roaringpenguin dot com slash mimedefang) X-MIME-Autoconverted: from 8bit to quoted-printable by sm.luth.se id g5CCctFO010922 Approved-By: avri Message-ID: <3D07400B.9060902@apocalypse.org> Date: Wed, 12 Jun 2002 14:35:23 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: avri Subject: Re: Requirements Document - Capabilities Model To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA25283 Olivier Marce wrote: > > With this in mind, what's about considering COPS + Framework PIB as a candidate > to FORCES ? > in many respects this is an excellent suggestion. from the beginning i have thought that cops could well be part of the solution. though it would take creating a specific info model/PIB for ForCES in addition to use of other existing PIBs. with the rumors that fly, however, about the continued acceptance of COPS, is this considered a 'safe' candidate? every time i suggest a cops based solution to someone, they tell me it is dead (after suppressing giggles at my naiveté). are companies actually building and _selling_ COPS engines? the reason i ask is getting the info model and PIB done is a significant task, and if COPS is not not really real, then the effort may be better spent elsewhere. a. (a proposer of cops based solutions and co-author of a pib who despairs of ever seeing really real implementations) > > -- > 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) > > > -- Mobile: +46 73 029 8019 Office: +46 920 49 3030 In US: +1 401 663 5024 http://homepage.bethepeople.com/mphp/VXEU-2002/avri From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 12 16:34:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12230 for ; Wed, 12 Jun 2002 16:34:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0064ACAD@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 16:34:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20528570 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jun 2002 16:34:41 -0400 Received: from 143.182.124.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 12 Jun 2002 16:34:40 -0400 Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5CDbMP04552 for ; Wed, 12 Jun 2002 13:37:23 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002061213333902339 for ; Wed, 12 Jun 2002 13:33:39 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:34:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Durham, David" Message-ID: <10C8636AE359D4119118009027AE998719B46D22@fmsmsx34.fm.intel.com> Date: Wed, 12 Jun 2002 13:34:36 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Durham, David" Subject: Re: Requirements Document - Capabilities Model To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Hi Avri > -----Original Message----- > From: avri [mailto:avri@apocalypse.org] > > are companies actually building and _selling_ COPS engines? > You can find one COPS-PR engine including a universal PIB compiler at: http://www.intel.com/labs/manage/cops The compiler will syntax check any PIB and automatically generate the APIs for that PIB which plug into the COPS-PR stack. Other companies sell these too, though they probably aren't reading this mailing list. From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 05:52:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05877 for ; Thu, 13 Jun 2002 05:52:46 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0064C0EB@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 5:53:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20585047 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 05:53:20 -0400 Received: from 195.212.91.200 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 05:53:20 -0400 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5D9rFE8038784 for ; Thu, 13 Jun 2002 11:53:16 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5D9rDB150240 for ; Thu, 13 Jun 2002 11:53:14 +0200 Received: from dhcp70-214.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40098 from ; Thu, 13 Jun 2002 11:53:13 +0200 X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en Mime-Version: 1.0 References: <3D04FF36.67D1510F@zurich.ibm.com> <3D05DB47.67DAA161@alcatel.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Robert Haas Message-ID: <3D086B88.2A3BBDC7@zurich.ibm.com> Date: Thu, 13 Jun 2002 11:53:12 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs andoff-loadofsignalingfunctions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Olivier, Olivier Marce wrote: > 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 ) ? You're right. > 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." Not really: in my view, the ability to download new functionalities into an FE is orthogonal to the type of functionality the FE can execute. In other words, you could think of an FE that provides a static proxy-function: that could be the case for an FE that has been built to execute TCP termination in particular, but no other proxy-function. Therefore, by generalization, such proxy-functions (or "Off-load Functions") could be found in any of the 3 "flexibility" classes: #1 (static capabilities), #2 (reconfigurable capabilities), or #3 (downloadable capabilities). Do you agree with this interpretation of the 3 "flexibility" classes suggested by Lily and how proxy-functions can belong to any of them ? Regards, -Robert > > 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 ? > > > > -- > 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) From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 11:11:26 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16837 for ; Thu, 13 Jun 2002 11:11:26 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0064C74F@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 11:11:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20534492 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 11:11:53 -0400 Received: from 208.2.156.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 11:11:53 -0400 Received: from jzny.localdomain ([208.2.156.2]) by rollsroyce.znyx.com (Lotus Domino Release 5.0.7) with SMTP id 2002061308142966:6712 ; Thu, 13 Jun 2002 08:14:29 -0700 X-Mailer: KMail [version 1.2] References: <3D04FF36.67D1510F@zurich.ibm.com> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/13/2002 08:14:29 AM, Serialize by Router on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/13/2002 08:14:31 AM Content-Type: text/plain; charset="iso-8859-1" Approved-By: Jamal Hadi Salim Message-ID: <02061306390200.01004@jzny.localdomain> Date: Thu, 13 Jun 2002 06:39:02 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Comment on ForCES Requirements draft: FEs and off-load ofsignalingfunctions Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3D04FF36.67D1510F@zurich.ibm.com> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA16837 On Monday 10 June 2002 15:34, Robert Haas wrote: > 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 > > control activity. > > Did i understand you correctly? > > 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 ? > Robert, I think it would be wrong to limit what functionality goes onto the FE. I worked on the requirements team and tried hard to make sure this is clear; If you find that this is not reflected properly, i think it should be clarified. I cant remember who came up with the term "high-touch" and it may already be used by some organizations as marketing cliche and so may already be polluted to mean something else than intended focus. The caveat to note is that while Forces MUST not restrict what functionality goes into the FE vs CE, the charter says the immediate focus (in my opinion it is just an example) is Forwarding + QoS. This may be confusing the other side of the coin where people seem to think the protocol is based on Diffserv configuration. cheers, jamal > Thanks > > > cheers, > > jamal > > > > > 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 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 From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 11:14:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16929 for ; Thu, 13 Jun 2002 11:14:10 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0064C6BC@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 11:14:46 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20534773 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 11:14:45 -0400 Received: from 208.2.156.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 11:14:43 -0400 Received: from jzny.localdomain ([208.2.156.2]) by rollsroyce.znyx.com (Lotus Domino Release 5.0.7) with SMTP id 2002061308172079:6722 ; Thu, 13 Jun 2002 08:17:20 -0700 X-Mailer: KMail [version 1.2] References: <10C8636AE359D4119118009027AE99870DA5E13B@fmsmsx34.fm.intel.com> <3D070380.CCCC9F84@alcatel.fr> <3D07400B.9060902@apocalypse.org> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/13/2002 08:17:21 AM, Serialize by Router on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/13/2002 08:17:22 AM Content-Type: text/plain; charset="iso-8859-1" Approved-By: Jamal Hadi Salim Message-ID: <02061306415401.01004@jzny.localdomain> Date: Thu, 13 Jun 2002 06:41:54 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Requirements Document - Capabilities Model Comments: To: avri To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3D07400B.9060902@apocalypse.org> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA16929 On Wednesday 12 June 2002 08:35, avri wrote: > Olivier Marce wrote: > > With this in mind, what's about considering COPS + Framework PIB as a > > candidate to FORCES ? > > in many respects this is an excellent suggestion. from the > beginning i have thought that cops could well be part of the > solution. though it would take creating a specific info model/PIB > for ForCES in addition to use of other existing PIBs. > > with the rumors that fly, however, about the continued acceptance > of COPS, is this considered a 'safe' candidate? > every time i suggest a cops based solution to someone, they tell > me it is dead (after suppressing giggles at my naiveté). > > are companies actually building and _selling_ COPS engines? > > the reason i ask is getting the info model and PIB done is a > significant task, and if COPS is not not really real, then the > effort may be better spent elsewhere. > Which is one of the reasons why COPS is a bad choice. Out of curiosity, why COPS say in a local scope. Think of a very simple setup with a controller and the FEs sitting in the same chasis. Why not SNMP for example? cheers, jamal > a. > > (a proposer of cops based solutions and co-author of a pib who > despairs of ever seeing really real implementations) > > > -- > > 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) From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 13:18:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22534 for ; Thu, 13 Jun 2002 13:18:10 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0064C88E@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 13:18:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20524244 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 13:18:45 -0400 Received: from 130.240.3.1 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 13:18:44 -0400 Received: from apocalypse.org (sm-pc301.sm.luth.se [130.240.45.27]) by sm.luth.se (8.12.3/8.12.3) with ESMTP id g5DHIdFO023018 for ; Thu, 13 Jun 2002 19:18:42 +0200 (MET DST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 References: <10C8636AE359D4119118009027AE99870DA5E13B@fmsmsx34.fm.intel.com> <3D070380.CCCC9F84@alcatel.fr> <3D07400B.9060902@apocalypse.org> <02061306415401.01004@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.11 (www dot roaringpenguin dot com slash mimedefang) Approved-By: avri Message-ID: <3D08D317.2060708@apocalypse.org> Date: Thu, 13 Jun 2002 19:15:03 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: avri Subject: Re: Requirements Document - Capabilities Model To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > > > Which is one of the reasons why COPS is a bad choice. > Out of curiosity, why COPS say in a local scope. Think of a very simple setup > with a controller and the FEs sitting in the same chasis. Why not SNMP for > example? SNMP? Have you looked at how hard and complicated it is to even configure an MPLS label swtich with MIBS? ForCES seems like it would be even more difficult. Plus the info model for a MIB is pretty much the same level of difficulty as one for a PIB. As is translation into the Info Base. a. -- Mobile: +46 73 029 8019 Office: +46 920 49 3030 In US: +1 401 663 5024 http://homepage.bethepeople.com/mphp/VXEU-2002/avri From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 13:44:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23242 for ; Thu, 13 Jun 2002 13:44:11 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0064C923@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 13:44:46 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20525605 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 13:44:46 -0400 Received: from 143.182.124.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 13:44:45 -0400 Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5DAlRd14170 for ; Thu, 13 Jun 2002 10:47:27 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002061310434422582 for ; Thu, 13 Jun 2002 10:43:44 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 10:44:44 -0700 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Thu, 13 Jun 2002 10:44:43 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Accept Framework individual contrib as WG doc? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, There was not sufficient feedback to the prior request to determine if there is consensus. Please indicate whether you feel that the following draft is ready to become a working group document: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt Thanks, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > Sent: Friday, May 24, 2002 1:41 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > All, > > A new version of the ForCES Framework individual > contribution was submitted last week and the authors > have requested that it be accepted as a working > group document. This document is intended to satisfy > the charter deliverable of "An architectural framework > defining the entities comprising a ForCES network > element and identifying the interactions between > them." > > Patrick and I would like the list to review and > comment whether this draft is ready to be accepted > as a ForCES working group document. Note that > acceptance as a working group document associates > this document with the ForCES WG. It does not grant > formal standards status to the document and the document > will remain open to change or removal. > > Please submit your comments and recommendation to the > mailing list by Friday, May 31, 2002. > > URL: > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > Thanks, > David > > > Lily Yang wrote: > >Patrick, David and all -- > > > >On behalf of my co-authors Ram Dantu, > >Todd Anderson and myself, I would like > >to request the WG review this framework > >draft and consider accepting it as a > >WG document. > > > >Lily > > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > Sent: Wednesday, May 15, 2002 11:13 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > Hi, all -- > > We submitted version 01 of the framework draft last week > after a major > > rewrite: > > * added more description and diagrams to illustrate > different physical > > configuration examples of ForCES CE/FE. > > * added examples of FE topology. > > * restructure the text to focus more on ForCES operation > phases (pre- > > and > > post- association, reestablishment, etc.) > > * added examples to illustrate the handshake between CE and > FE during > > these operational phases. > > > > please let us know what you think -- are these examples/diagrams > > useful? Have we missed anything important? Any comments on the draft > > are welcome! > > > > Thanks, > > Lily > From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 14:22:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24856 for ; Thu, 13 Jun 2002 14:22:36 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0064C9E1@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 14:23:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20527850 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 14:23:11 -0400 Received: from 208.2.156.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 14:23:11 -0400 Received: from jzny.localdomain ([208.2.156.2]) by rollsroyce.znyx.com (Lotus Domino Release 5.0.7) with SMTP id 2002061311254848:7159 ; Thu, 13 Jun 2002 11:25:48 -0700 X-Mailer: KMail [version 1.2] References: <10C8636AE359D4119118009027AE99870DA5E13B@fmsmsx34.fm.intel.com> <02061306415401.01004@jzny.localdomain> <3D08D317.2060708@apocalypse.org> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/13/2002 11:25:48 AM, Serialize by Router on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/13/2002 11:25:50 AM Content-Type: text/plain; charset="iso-8859-1" Approved-By: Jamal Hadi Salim Message-ID: <02061309502106.01004@jzny.localdomain> Date: Thu, 13 Jun 2002 09:50:21 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Requirements Document - Capabilities Model Comments: To: avri To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3D08D317.2060708@apocalypse.org> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA24856 On Thursday 13 June 2002 13:15, avri wrote: > Jamal Hadi Salim wrote: > > Which is one of the reasons why COPS is a bad choice. > > Out of curiosity, why COPS say in a local scope. Think of a very simple > > setup with a controller and the FEs sitting in the same chasis. Why not > > SNMP for example? > > SNMP? Have you looked at how hard and complicated it is to even > configure an MPLS label swtich with MIBS? ForCES seems like it > would be even more difficult. > I was just being a devils advocate ;-> > Plus the info model for a MIB is pretty much the same level of > difficulty as one for a PIB. As is translation into the Info Base. > snacc compiles both PIBs and MIBS. The main positive both COPS and SNMP have is that they are widely used ;-> Some people tend to have emotional attachments to things that they are comfortable with. I am not a fan of either COPS or SNMP. I think the protocol should include good built in event management and reporting, one-to-many communication, and easy to extend models. cheers, jamal > a. > > > -- > Mobile: +46 73 029 8019 > Office: +46 920 49 3030 > In US: +1 401 663 5024 > > http://homepage.bethepeople.com/mphp/VXEU-2002/avri From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 15:49:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28128 for ; Thu, 13 Jun 2002 15:49:05 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0064CA74@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 15:49:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20532333 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 15:49:12 -0400 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 15:49:12 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g5DJnBh06707 for ; Thu, 13 Jun 2002 14:49:11 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3D08F75B.D6FD240E@alcatel.com> Date: Thu, 13 Jun 2002 14:49:47 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Accept Framework individual contrib as WG doc? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I feel it is ready to be transitioned into a working group document. Alex. "Putzolu, David" wrote: > All, > > There was not sufficient feedback to the prior > request to determine if there is consensus. > > Please indicate whether you feel that the following > draft is ready to become a working group document: > > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > > Thanks, > David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework > > defining the entities comprising a ForCES network > > element and identifying the interactions between > > them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 15:59:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28500 for ; Thu, 13 Jun 2002 15:59:28 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0064CBB0@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 16:00:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20532632 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 16:00:02 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 16:00:01 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 3100414 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 16:00:01 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20020613155921.01701970@mail.stevecrocker.com> Date: Thu, 13 Jun 2002 15:59:39 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Accept Framework individual contrib as WG doc? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list I believe it should become a working group document. Yours, Joel M. Halpern At 10:44 AM 6/13/2002 -0700, you wrote: >All, > >There was not sufficient feedback to the prior >request to determine if there is consensus. > >Please indicate whether you feel that the following >draft is ready to become a working group document: > >http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > >Thanks, >David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework > > defining the entities comprising a ForCES network > > element and identifying the interactions between > > them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 13 18:39:54 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02845 for ; Thu, 13 Jun 2002 18:39:54 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0064D20C@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 18:39:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20546371 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jun 2002 18:39:58 -0400 Received: from 66.21.69.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 13 Jun 2002 18:39:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Approved-By: Alex Vasquez Message-ID: <516FCA4FBCDAD3118D0100508B1080ACB0D5C9@LVL7SERVER1> Date: Thu, 13 Jun 2002 18:28:29 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Vasquez Subject: Re: Accept Framework individual contrib as WG doc? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list The proposed draft is ready to become a working group document. Alex -----Original Message----- From: Putzolu, David [mailto:david.putzolu@intel.com] Sent: Thursday, June 13, 2002 1:45 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Accept Framework individual contrib as WG doc? Importance: High All, There was not sufficient feedback to the prior request to determine if there is consensus. Please indicate whether you feel that the following draft is ready to become a working group document: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt Thanks, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > Sent: Friday, May 24, 2002 1:41 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > All, > > A new version of the ForCES Framework individual > contribution was submitted last week and the authors > have requested that it be accepted as a working > group document. This document is intended to satisfy > the charter deliverable of "An architectural framework > defining the entities comprising a ForCES network > element and identifying the interactions between > them." > > Patrick and I would like the list to review and > comment whether this draft is ready to be accepted > as a ForCES working group document. Note that > acceptance as a working group document associates > this document with the ForCES WG. It does not grant > formal standards status to the document and the document > will remain open to change or removal. > > Please submit your comments and recommendation to the > mailing list by Friday, May 31, 2002. > > URL: > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > Thanks, > David > > > Lily Yang wrote: > >Patrick, David and all -- > > > >On behalf of my co-authors Ram Dantu, > >Todd Anderson and myself, I would like > >to request the WG review this framework > >draft and consider accepting it as a > >WG document. > > > >Lily > > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > Sent: Wednesday, May 15, 2002 11:13 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > Hi, all -- > > We submitted version 01 of the framework draft last week > after a major > > rewrite: > > * added more description and diagrams to illustrate > different physical > > configuration examples of ForCES CE/FE. > > * added examples of FE topology. > > * restructure the text to focus more on ForCES operation > phases (pre- > > and > > post- association, reestablishment, etc.) > > * added examples to illustrate the handshake between CE and > FE during > > these operational phases. > > > > please let us know what you think -- are these examples/diagrams > > useful? Have we missed anything important? Any comments on the draft > > are welcome! > > > > Thanks, > > Lily > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 14 03:00:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21654 for ; Fri, 14 Jun 2002 03:00:23 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0064DC5A@cherry.ease.lsoft.com>; Fri, 14 Jun 2002 3:00:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20585826 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Jun 2002 03:00:58 -0400 Received: from 195.89.159.99 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 14 Jun 2002 03:00:57 -0400 Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g5E70uD22566 for ; Fri, 14 Jun 2002 08:00:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: Alistair Munro Message-ID: <000a01c21371$9539caa0$31281eac@degree2.com> Date: Fri, 14 Jun 2002 08:03:27 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Requirements Document - Capabilities Model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <02061309502106.01004@jzny.localdomain> Precedence: list Content-Transfer-Encoding: 7bit Hi All, I'm glad that the suggestion of SNMP is not intended to be serious. I have had the dubious pleasure of working on element management using SNMP (vanilla V.2). It failed mainly because the semantics of a MIB is too poorly defined. To allow implementers to build agents that behave consistently from product to product (even from the same vendor) you have to build a model of the FE at a very detailed semantic level, which is seldom done. Also the FE model diverges so widely from the operational situation in which a FE is being used that it is difficult to build an efficient control/configuring client protocol on SNMP. Finally, although it has improved significantly, SNMP is still fundamentally unsuitable as a protocol for a long-lived controlling relationship (i.e. writing lots of data to many FEs). I have the same reservations about using other existing protocols by imposing alternative semantics on the content of their PDUs. A protocol is designed for a specific purpose and should be used only for that purpose. The MIDCOM group appears to be asking a similar question. However, everybody seems to have a different view of what a middlebox is and does (i.e. anything and everything), so (IMO) it's never going to go anywhere until answers this question first. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: 13 June 2002 14:50 > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Requirements Document - Capabilities Model > > > On Thursday 13 June 2002 13:15, avri wrote: > > Jamal Hadi Salim wrote: > > > Which is one of the reasons why COPS is a bad choice. > > > Out of curiosity, why COPS say in a local scope. Think of a very > > > simple setup with a controller and the FEs sitting in the same > > > chasis. Why not SNMP for example? > > > > SNMP? Have you looked at how hard and complicated it is to even > > configure an MPLS label swtich with MIBS? ForCES seems like > it would > > be even more difficult. > > > > I was just being a devils advocate ;-> > > > Plus the info model for a MIB is pretty much the same level of > > difficulty as one for a PIB. As is translation into the Info Base. > > > > snacc compiles both PIBs and MIBS. > The main positive both COPS and SNMP have is that they are > widely used ;-> Some people tend to have emotional > attachments to things that they are comfortable with. I am > not a fan of either COPS or SNMP. I think the protocol > should include good built in event management and reporting, > one-to-many communication, and easy to extend models. > > cheers, > jamal > > > > > a. > > > > > > -- > > Mobile: +46 73 029 8019 > > Office: +46 920 49 3030 > > In US: +1 401 663 5024 > > > > http://homepage.bethepeople.com/mphp/VXEU-2002/avri > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 14 03:01:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21708 for ; Fri, 14 Jun 2002 03:01:24 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0064DC5D@cherry.ease.lsoft.com>; Fri, 14 Jun 2002 3:02:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20585842 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Jun 2002 03:01:44 -0400 Received: from 195.89.159.99 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 14 Jun 2002 03:01:44 -0400 Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g5E71gD22640 for ; Fri, 14 Jun 2002 08:01:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: Alistair Munro Message-ID: <000b01c21371$b0cbe5a0$31281eac@degree2.com> Date: Fri, 14 Jun 2002 08:04:13 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Accept Framework individual contrib as WG doc? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi David, I supoprt the progression of the draft to WG accepted status. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: 13 June 2002 18:45 > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Accept Framework individual contrib as WG doc? > Importance: High > > > All, > > There was not sufficient feedback to the prior > request to determine if there is consensus. > > Please indicate whether you feel that the following > draft is ready to become a working group document: > > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > > Thanks, > David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework defining the > > entities comprising a ForCES network element and identifying the > > interactions between them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> > > anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments > on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 14 09:31:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28845 for ; Fri, 14 Jun 2002 09:31:32 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0064E0D9@cherry.ease.lsoft.com>; Fri, 14 Jun 2002 9:31:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20602523 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Jun 2002 09:31:38 -0400 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 14 Jun 2002 09:31:38 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5EDZ0j25613 for ; Fri, 14 Jun 2002 08:35:01 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Jun 2002 08:31:34 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 14 Jun 2002 08:30:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Accept Framework individual contrib as WG doc? Thread-Index: AcITAgWksWuRBMkLRKCUhewf5UUOAgApZw1A X-OriginalArrivalTime: 14 Jun 2002 13:30:48.0141 (UTC) FILETIME=[B1B0B7D0:01C213A7] Approved-By: ram.gopal@NOKIA.COM Message-ID: Date: Fri, 14 Jun 2002 09:30:47 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "(Ram Gopal )" Subject: Re: Accept Framework individual contrib as WG doc? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA28845 accept this as working group item. regards ramg > -----Original Message----- > From: ext Putzolu, David [mailto:david.putzolu@intel.com] > Sent: Thursday, June 13, 2002 1:45 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Accept Framework individual contrib as WG doc? > Importance: High > > > All, > > There was not sufficient feedback to the prior > request to determine if there is consensus. > > Please indicate whether you feel that the following > draft is ready to become a working group document: > > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > > Thanks, > David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework > > defining the entities comprising a ForCES network > > element and identifying the interactions between > > them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> > anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments > on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 14 09:56:54 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29743 for ; Fri, 14 Jun 2002 09:56:54 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0064E271@cherry.ease.lsoft.com>; Fri, 14 Jun 2002 9:57:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20605256 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Jun 2002 09:57:29 -0400 Received: from 209.238.9.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 14 Jun 2002 09:57:29 -0400 Received: from 208.55.110.97 (208.55.110.97) by mail07a.vwh1.net (RS ver 1.0.63s) with SMTP id 019944 for ; Fri, 14 Jun 2002 09:57:20 -0400 (EDT) Received: from 192.168.0.116 ([192.168.0.116]) by mail (WinRoute Pro 4.1.27) with SMTP; Fri, 14 Jun 2002 09:44:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Loop-Detect: 1 Approved-By: Vip Sharma Message-ID: <000001c213aa$af89d8d0$7400a8c0@zagrosnetworks.com> Date: Fri, 14 Jun 2002 09:52:13 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Vip Sharma Subject: Re: Accept Framework individual contrib as WG doc? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit David, This draft should become a work group document... vip -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David Sent: Thursday, June 13, 2002 1:45 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Accept Framework individual contrib as WG doc? Importance: High All, There was not sufficient feedback to the prior request to determine if there is consensus. Please indicate whether you feel that the following draft is ready to become a working group document: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt Thanks, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > Sent: Friday, May 24, 2002 1:41 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > All, > > A new version of the ForCES Framework individual > contribution was submitted last week and the authors > have requested that it be accepted as a working > group document. This document is intended to satisfy > the charter deliverable of "An architectural framework > defining the entities comprising a ForCES network > element and identifying the interactions between > them." > > Patrick and I would like the list to review and > comment whether this draft is ready to be accepted > as a ForCES working group document. Note that > acceptance as a working group document associates > this document with the ForCES WG. It does not grant > formal standards status to the document and the document > will remain open to change or removal. > > Please submit your comments and recommendation to the > mailing list by Friday, May 31, 2002. > > URL: > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > Thanks, > David > > > Lily Yang wrote: > >Patrick, David and all -- > > > >On behalf of my co-authors Ram Dantu, > >Todd Anderson and myself, I would like > >to request the WG review this framework > >draft and consider accepting it as a > >WG document. > > > >Lily > > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > Sent: Wednesday, May 15, 2002 11:13 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > Hi, all -- > > We submitted version 01 of the framework draft last week > after a major > > rewrite: > > * added more description and diagrams to illustrate > different physical > > configuration examples of ForCES CE/FE. > > * added examples of FE topology. > > * restructure the text to focus more on ForCES operation > phases (pre- > > and > > post- association, reestablishment, etc.) > > * added examples to illustrate the handshake between CE and > FE during > > these operational phases. > > > > please let us know what you think -- are these examples/diagrams > > useful? Have we missed anything important? Any comments on the draft > > are welcome! > > > > Thanks, > > Lily > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 17 15:49:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18114 for ; Mon, 17 Jun 2002 15:49:24 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00656698@cherry.ease.lsoft.com>; Mon, 17 Jun 2002 15:49:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20780011 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Jun 2002 15:49:33 -0400 Received: from 143.182.246.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 17 Jun 2002 15:49:33 -0400 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5HJnWE01140 for ; Mon, 17 Jun 2002 19:49:32 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002061711375605460 ; Mon, 17 Jun 2002 11:37:56 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 11:32:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Mon, 17 Jun 2002 11:32:27 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Draft Agenda - please send requests Comments: cc: "Patrick Droz (dro@zurich.ibm.com)" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, ForCES is tentatively scheduled to meet at IETF 54 on Monday, July 15, from 0900-1130. It is time to start coming up with an agenda for the meeting. Please send agenda requests to myself or Patrick. Please include the title of your presentation, URL of any relevant drafts, and an estimate of how much time you feel is necessary. So far I have an agenda request for a model contribution that will be submitted as a draft soon. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 18 12:10:51 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24802 for ; Tue, 18 Jun 2002 12:10:51 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00658944@cherry.ease.lsoft.com>; Tue, 18 Jun 2002 12:11:26 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20865571 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Jun 2002 12:11:24 -0400 Received: from 195.212.91.199 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 18 Jun 2002 12:07:13 -0400 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5IG7Cxo003806 for ; Tue, 18 Jun 2002 18:07:12 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5IG7Bc48862 for ; Tue, 18 Jun 2002 18:07:12 +0200 Received: from dhcp70-10.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55320 from ; Tue, 18 Jun 2002 18:07:10 +0200 X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en Mime-Version: 1.0 References: <3D04FF36.67D1510F@zurich.ibm.com> <02061306390200.01004@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate.de.ibm.com id g5IG7Cxo003806 Approved-By: Robert Haas Message-ID: <3D0F5AAE.6F8BCFCE@zurich.ibm.com> Date: Tue, 18 Jun 2002 18:07:10 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs and off-loadofsignalingfunctions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA24802 Jamal, My concern is the limitation of the scope of FEs capabilities to whatever can be done to "the packet as it passes through the FE", as the draft mentions it repeatedly. If there are other capabilities planned for ForCES besides Forwarding+QoS, then the requirements draft should avoid being so restrictive, IMHO. The TCP termination being just one example out of today's FEs capabilities that go beyond the current scope, as I understand now. If you think it's acceptable, then I'll try to come up with a concrete suggestion how to formulate this, that you could then consider including in the draft. Cheers, -Robert Jamal Hadi Salim wrote: > On Monday 10 June 2002 15:34, Robert Haas wrote: > > 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 > > > control activity. > > > Did i understand you correctly? > > > > 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 ? > > > > Robert, > I think it would be wrong to limit what functionality goes onto the FE. I > worked on the requirements team and tried hard to make sure this is clear. > > If you find that this is not reflected properly, i think it should be > clarified. > I cant remember who came up with the term "high-touch" and it may already be > used by some organizations as marketing cliche and so may already be polluted > to mean something else than intended focus. > The caveat to note is that while Forces MUST not restrict what functionality > goes into the FE vs CE, the charter says the immediate focus (in my opinion > it is just an example) is Forwarding + QoS. This may be confusing the other > side of the coin where people seem to think the protocol is based on Diffserv > configuration. > > cheers, > jamal > > > Thanks > > > > > cheers, > > > jamal > > > > > > > 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 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 From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 20 11:08:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02771 for ; Thu, 20 Jun 2002 11:08:46 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0065E02C@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 11:08:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21129148 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Jun 2002 11:08:09 -0400 Received: from 208.2.156.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 20 Jun 2002 11:08:07 -0400 Received: from jzny.localdomain ([208.2.156.2]) by rollsroyce.znyx.com (Lotus Domino Release 5.0.7) with SMTP id 2002062008105554:18296 ; Thu, 20 Jun 2002 08:10:55 -0700 X-Mailer: KMail [version 1.2] References: <02061306390200.01004@jzny.localdomain> <3D0F5AAE.6F8BCFCE@zurich.ibm.com> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/20/2002 08:10:55 AM, Serialize by Router on rollsroyce/Znyx(Release 5.0.7 |March 21, 2001) at 06/20/2002 08:11:00 AM Content-Type: text/plain; charset="iso-8859-1" Approved-By: Jamal Hadi Salim Message-ID: <02061921100102.01197@jzny.localdomain> Date: Wed, 19 Jun 2002 21:10:01 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Comment on ForCES Requirements draft: FEs and off-loadofsignalingfunctions Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3D0F5AAE.6F8BCFCE@zurich.ibm.com> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA02771 Robert, Please come up with the appropriate text. cheers, jamal On Tuesday 18 June 2002 12:07, Robert Haas wrote: > Jamal, > My concern is the limitation of the scope of FEs capabilities to whatever > can be done to "the packet as it passes through the FE", as the draft > mentions it repeatedly. > If there are other capabilities planned for ForCES besides Forwarding+QoS, > then the requirements draft should avoid being so restrictive, IMHO. The > TCP termination being just one example out of today's FEs capabilities that > go beyond the current scope, as I understand now. > > If you think it's acceptable, then I'll try to come up with a concrete > suggestion how to formulate this, that you could then consider including in > the draft. > > Cheers, > -Robert > > Jamal Hadi Salim wrote: > > On Monday 10 June 2002 15:34, Robert Haas wrote: > > > 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 > > > > control activity. > > > > Did i understand you correctly? > > > > > > 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 ? > > > > Robert, > > I think it would be wrong to limit what functionality goes onto the FE. I > > worked on the requirements team and tried hard to make sure this is > > clear. > > > > > > If you find that this is not reflected properly, i think it should be > > clarified. > > > > I cant remember who came up with the term "high-touch" and it may already > > be used by some organizations as marketing cliche and so may already be > > polluted to mean something else than intended focus. > > The caveat to note is that while Forces MUST not restrict what > > functionality goes into the FE vs CE, the charter says the immediate > > focus (in my opinion it is just an example) is Forwarding + QoS. This may > > be confusing the other side of the coin where people seem to think the > > protocol is based on Diffserv configuration. > > > > cheers, > > jamal > > > > > Thanks > > > > > > > cheers, > > > > jamal > > > > > > > > > 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 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 From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 20 14:55:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10346 for ; Thu, 20 Jun 2002 14:55:26 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0065E675@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 14:56:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21142530 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Jun 2002 14:56:06 -0400 Received: from 143.182.246.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 20 Jun 2002 14:56:05 -0400 Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5KIu4C05867 for ; Thu, 20 Jun 2002 18:56:04 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002062011562129884 for ; Thu, 20 Jun 2002 11:56:21 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 11:56:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Thu, 20 Jun 2002 11:56:01 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Framework document accepted as WG doc To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, Thank you for the feedback. There is consensus that draft-anderson-forces-arch-01.txt should be accepted as a working group document and be the basis for the following charter deliverable: o An architectural framework defining the entities comprising a ForCES network element and identifying the interactions between them. This document remains an Internet Draft and is subject to change based on the feedback and guidance of the working group. I have asked the authors to submit it as a working group document and it will proceed and evolve with that status. Cheers, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > Sent: Thursday, June 13, 2002 10:45 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Accept Framework individual contrib as WG doc? > Importance: High > > > All, > > There was not sufficient feedback to the prior > request to determine if there is consensus. > > Please indicate whether you feel that the following > draft is ready to become a working group document: > > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > > Thanks, > David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework defining the > > entities comprising a ForCES network element and identifying the > > interactions between them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> > > anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments > on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > > From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Fri Jun 21 07:46:01 2002 Received: from maestro-demo.lsoft.com (maestro-demo.lsoft.com [209.119.1.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08574 for ; Fri, 21 Jun 2002 07:46:01 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by maestro-demo.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00000B7E@maestro-demo.lsoft.com>; Fri, 21 Jun 2002 7:46:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21203480 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Jun 2002 07:46:36 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 21 Jun 2002 07:36:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07807; Fri, 21 Jun 2002 07:35:53 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200206211135.HAA07807@ietf.org> Date: Fri, 21 Jun 2002 07:35:53 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-applicability-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 : ForCES Applicability Statement Author(s) : A. Crouch, M. Handley Filename : draft-ietf-forces-applicability-00.txt Pages : 9 Date : 20-Jun-02 The ForCES protocol defines a standard framework and mechanism for the interconnection between Control Elements and Forwarding Engines in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-applicability-00.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 "get draft-ietf-forces-applicability-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-applicability-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020620141419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-applicability-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-applicability-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020620141419.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 21 18:29:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03028 for ; Fri, 21 Jun 2002 18:29:32 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00660E41@cherry.ease.lsoft.com>; Fri, 21 Jun 2002 18:29:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21263280 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Jun 2002 18:29:45 -0400 Received: from 143.182.246.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 21 Jun 2002 18:29:43 -0400 Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5LMThB27507 for ; Fri, 21 Jun 2002 22:29:43 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002062115300028303 ; Fri, 21 Jun 2002 15:30:00 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 15:29:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C21973.20D923B0" Approved-By: "Yang, Lily L" Message-ID: Date: Fri, 21 Jun 2002 15:29:38 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: individual contribution draft on ForCES FE model Comments: To: Internet-Drafts Administrator , "yangliuyang67@yahoo.com" , "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C21973.20D923B0 Content-Type: text/plain; charset="iso-8859-1" <> Here is an individual contribution draft on ForCES FE model. Please review and provide feedback. Thanks, Lily ------_=_NextPart_000_01C21973.20D923B0 Content-Type: text/plain; name="draft-yang-forces-model-00.txt" Content-Disposition: attachment; filename="draft-yang-forces-model-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft L. Yang=20 Expiration: December 2002 Intel Labs=20 File: draft-yang-forces-model-00.txt J. Halpern=20 Working Group: ForCES =20 R. Gopal=20 Nokia=20 R. Dantu=20 Netrake=20 June 2002=20 = =20 =20 =20 ForCES Forwarding Element Functional Model=20 =20 =20 =20 draft-yang-forces-model-00.txt=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance = with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are=20 working documents of the Internet Engineering Task Force = (IETF), its=20 areas, and its working groups. Note that other groups may also = distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other = documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as ``work in=20 progress.''=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed = at =20 http://www.ietf.org/shadow.html.=20 =20 Conventions used in this document =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in=20 this document are to be interpreted as described in [RFC-2119]. = =20 1. Abstract=20 This document defines a functional model for ForCES forwarding=20 elements (FEs). This model is used to describe the state of = ForCES=20 forwarding elements within the context of the ForCES protocol, = so=20 that ForCES control elements (CEs) can control the FEs = accordingly.=20 The model is to specify what logical function instances are = present=20 in the FEs and in what order these functions are performed. The = =20 =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 forwarding element model defined herein is intended to satisfy = the=20 requirements specified in the ForCES requirements draft = [FORCES- REQ]. Using this model, predefined or vendor specific logical=20 functions can be expressed and configured. However, the = definition=20 of these components are not described and defined in this = document.=20 Definitions=20 =20 A set of terminology associated with the ForCES requirements is = defined in [FORCES-REQ] and is not copied here. The following = list=20 of terminology is relevant to the FE model defined in this = document.=20 =20 Datapath -- A conceptual path taken by packets within the = forwarding=20 plane, inside an FE. There might exist more than one datapath = within=20 an FE.=20 =20 Forwarding Element (FE) Block -- An abstraction of the basic = packet=20 processing functions in the datapath. It is the building block = of FE=20 functionality. This concept abstracts away implementation = details=20 from the parameters of interest for configuration, control and=20 management by CE. The general rule of thumb on the granularity = of FE=20 blocks is that FE blocks should be coarse grained, stateful and = focus on a particular domain. For example, RFC1812 compliant = IPv4=20 forwarder, classifiers, meters, etc.. =20 =20 Forwarding Element (FE) Stage -- Representation of a FE block=20 instance in a FE's datapath. As a packet flows through an FE = along a=20 datapath, it flows through one or multiple distinct stages, = with=20 each stage implementing an instance of a certain logical = function.=20 There may be one or more combination of such instances in a = FE's=20 datapath. Using NAT as an example, one NAT function is = typically=20 performed before the forwarding stage (packets arriving = externally=20 have their public addresses replaced with private addresses) = and one=20 NAT function is performed after (for packets exiting the = domain,=20 their private addresses are replaced by public ones). So there = are=20 three stages (NAT, forwarding, and NAT again) in this example = FE,=20 with two NAT instances present in two different stages. =20 =20 2. Motivation and Requirements of FE model=20 =20 The ForCES architecture allows Forwarding Elements (FEs) of = varying=20 functionality to participate in a ForCES network element (NE). = The=20 implication of this varying functionality is that CEs can make = only=20 minimal assumptions about the functionality provided by its = FEs. =20 Before CEs can configure and control the forwarding behavior of = FEs,=20 CEs need to query and discover the capabilities and state of = their=20 FEs. [FORCES-REQ] mandates that this capability and state=20 information be expressed in the form of a FE model, and this = model=20 will be used as the basis for CEs to control FEs' capabilities = and=20 manipulate FEs' state via ForCES protocol. =20 =20 [FORCES-REQ] describes all the requirements placed on the FE = model=20 in detail. We provide a brief summary here to highlight some of = the=20 design issues we face. =20 =20 Yang, et. al. Expires December 2002 [Page = 2] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 . The FE model MUST express what logical functions can be = applied=20 to packets as they pass through a FE.=20 . The FE model MUST be capable of supporting/allowing = variations=20 in the way logical functions are implemented on a FE. =20 . The model MUST be capable of describing the order in which=20 these logical functions are applied in a FE. =20 . The FE model SHOULD be extendable and should have provision = to=20 express new or vendor specific logical functions. . =20 . Should be able to support minimal set of logical functions = that are already identified such as port functions,=20 forwarding functions, QoS functions, filtering functions, = high- touch functions, security functions, and vendor-specific=20 functions. =20 =20 Since the motivation of an FE model is to allow CEs later to = control=20 and configure FEs' behavior via ForCES protocol, it becomes=20 essential to examine and understand what kind of control and=20 configuration CEs might do to FEs. We believe that there are = roughly=20 three levels of control and configuration that CEs can do to = FEs. =20 =20 The first level of control and configuration is the simplest of = all.=20 It assumes that each FE's capability is already given and = remains=20 static in its lifetime, and CEs can only control its behavior = by=20 manipulating its state. We call this "static FE" control and=20 configuration. For example, Figure 2 and 3 each shows an FE=20 configuration example by representing the processing steps in a = directed graph interconnecting all the functional stages that=20 packets can possibly traverse. If such a configuration remains=20 static during FE's lifetime, then all CE can control is the=20 parameters associated with each stage in the graph, for = example, the=20 routing table in the LPM forwarder in Figure 2, or the token = bucket=20 parameters associated with meter1 in Figure 3. But CE cannot=20 reconfigure the graph topology dynamically, such as adding = another=20 meter or queue onto the FE in Figure 3 on the fly. For this = kind of=20 static FE control and configuration purpose, the useful FE = model is=20 consisted of the state information that FEs allow CEs to = manipulate=20 and the statistics and events that FEs can collect and report = back=20 to CEs. Such a state model doesn't need to describe a lot of = other=20 information, like the packet formats supported between meter1 = and=20 counter1 in Figure 3, for example. Because such information is = only=20 useful when the graph is re-configured dynamically on the fly. = =20 =20 The second level of control and configuration builds on top of = the=20 first that is just described. Using Figure 3 as an example, = instead=20 of presenting the static FE graph to CE, FE can convey its=20 capabilities to CE by telling CE that "This FE can support one=20 classifier with up to N filters. This FE can also support M = meters,=20 X queues, etc." We call this dynamic FE control and = configuration.=20 For such control and configuration, a more powerful and = flexible FE=20 capability model is required in addition to the FE state model. = For=20 example, it becomes necessary to model the capability of the=20 building blocks like classifiers, filters, meters etc. it also = needs=20 =20 Yang, et. al. Expires December 2002 [Page = 3] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 to describe the packet formats supported at each input and = output of=20 each block to allow correct reconfiguration of the graph by CE. = =20 =20 The third level of control and configuration is even more = powerful=20 and future looking. In addition to dynamic configuration, CEs = might=20 even be allowed to download a given functionality onto FEs at = run=20 time.=20 The FE model proposed in this document intends to fully support = the=20 static FE control and configuration. It is also our intention = to=20 allow extension later to support dynamic FE control and=20 configuration. However, this FE model currently makes no = attempt to=20 address issues beyond the simple static FE control and=20 configuration.=20 =20 3. Capability and configuration Model versus State Model=20 =20 FE Model describes both the static capabilities and the = configured=20 capabilities. At any time after initial configuration the = logical=20 functions associated with an FE model may exhibit different=20 characteristics and may lead to change in state of FE. The=20 capability describes set of parameters or attributes of one or = more =20 logical functions of a FE, which may be useful for configuring = and=20 managing a FE. The state model describes the instantaneous = values or=20 operational behaviour of a FE.=20 Typical capabilities model describes at the coarsest level = such=20 aspects as=20 - this FE can handle IPv4 and IPv6=20 - this FE can perform 6-tuple classification (or can only do DA = based processing, ...)=20 - this FE can perform metering=20 - this FE can handle multiple queues with multiple priorities=20 - this FE can add and remove encapsulating headers of types: = IPSec,=20 GRE, L2TP=20 =20 Where it gets more complicated is coping with the detailed = limits. =20 Issues such has how many classifiers can the FE handle? =20 How many headers can the FE add and remove? How many queues, = and=20 how many buffer pools can the FE support? How many meters can = the=20 FE provide? How flexibly can these various parts be = interconnected?=20 While one could try to build an object model for representing=20 capabilities in full, other efforts have found this to be a=20 significant undertaking. A middle of the road approach is to = define=20 coarse-grained capabilities and simple capacity measures. = Then, if=20 the CE attempts to instruct the FE to set up some specific = behavior=20 it is not capable of, the FE will return an error indicating = the=20 problem.=20 =20 A state model describes the current state of the FE. It lists=20 - on a given port the packets are classified using a given=20 classification filter=20 - a given classifier results in packets being metered in a = certain=20 way, and then marked in a certain way=20 =20 Yang, et. al. Expires December 2002 [Page = 4] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 - packets coming from specific markers are delivered into a = shared=20 queue for handling, while other packets are delivered to a = different=20 queue=20 - a specific scheduler with specific behavior and parameters = will=20 service these collected queues.=20 =20 While the DiffServ and QDDIM models are not designed with the=20 primary goal of direct machine implementation, we will start = with=20 that model as it is better than no starting point. Alternative = suggestions for a state model which can be implemented more=20 generally without significant transformation are sought from = the=20 community.=20 =20 4. FE Model=20 =20 This section proposes a ForCES FE model to satisfy all the=20 requirements in [FORCES-REQ] for FE control and configuration. = The=20 approach taken is to first define a set of well-known FE = logical=20 functions (FE blocks) as the basic building blocks, so that any = FE=20 can be modeled by describing the kind of FE blocks or variants = of=20 these blocks it contains, and how the instances of these blocks = are=20 interconnected together. This model also allows new logical=20 functions be added to accommodate future innovation in = forwarding=20 plane. We believe this approach strikes a good balance between=20 flexibility and extensibility of the model and ease of use by = the=20 CE. =20 =20 4.1. FE Blocks=20 =20 FE blocks are the very basic building blocks from which FEs = model=20 its overall packet processing behavior. The concept of a FE = block is=20 akin to that of an abstract base class in object-oriented=20 terminology. Different FEs can have different implementation of = the=20 same block, but the packet processing behavior looks the same = to the=20 CE. Sometimes it is difficult to decide the granularity of the = FE=20 blocks. The general rule of thumb is that FE blocks should be = coarse=20 grained, stateful and focus on a particular domain. Basically, = if a=20 logical function doesn=92t have anything to configure, = doesn=92t keep=20 any kind of inter-packet state information (tables, etc), then = it=20 probably is not a FE block. For example, CRC check and IP = checksum=20 are not considered to be FE blocks by themselves, instead = should be=20 part of an FE block (i.e. RFC 1812 IP forwarder).=20 =20 A well-defined block has a well-defined packet processing = behavior,=20 and a well-defined set of state and parameters that CE can=20 potentially configure or control via ForCES. =20 =20 Obviously, a namespace is needed to specify different blocks. = The=20 namespace assigns a unique ID or label to each distinct block = type. =20 =20 For each block, it is necessary to specify the relevant = information=20 and parameters such as:=20 =20 Yang, et. al. Expires December 2002 [Page = 5] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 - how many inputs it takes and what kinds of packets and meta = data=20 it takes for each input;=20 - how many outputs it produces and what kind of packets and = meta=20 data it emits for each output and;=20 - the packet processing (such as modification) behavior;=20 - what information is programmed into it (e.g., LPM list, next = hop=20 list, WRED parameters, etc.) and what parameters among them are = configurable; =20 - what statistics it keeps (e.g., drop count, CRC error count,=20 etc.); =20 - what events it can throw (e.g., table miss, port down, etc.). = =20 CEs later use the information to decide how to configure the=20 parameters, how to modify the relevant data structures (like=20 tables), what kind of statistics it can query from FE, and what = actions to take once a certain event happens.=20 =20 We use the classifier defined in [DS-MODEL] as an example.=20 "Classifiers are 1:N(fan-out) devices: they take a single = traffic=20 stream as input and generate N logically separate traffic = streams as=20 output. Classifiers are parameterized by filters and output = streams.=20 Packets from the input stream are sorted into various output = streams=20 by filters which match the contents of the packet or possibly = match=20 other attributes associated with the packet." To further define = filters: "A filter consists of a set of conditions on the = component=20 values of a packet's classification key (the header values,=20 contents, and attributes relevant for classification)." Figure = 1=20 illustrates an example classifier.=20 =20 =20 Unclassified classified=20 traffic traffic=20 +------------+=20 | |--> match Filter1 --> OutputA=20 ------->| classifier |--> match Filter2 --> OutputB=20 | |--> no match --> OutputC=20 +------------+=20 =20 Figure 1. An Example Classifier=20 =20 4.2.FE Block Library=20 =20 We expect a small set of blocks to be defined initially, e.g.,=20 ingress port, egress port, classifier, forwarder, meter, = marker,=20 shaper, scheduler, queue, encapsulator, decapsulator, = encrypter,=20 decrypter, NAT, mux, demux, header compressor, header = decompressor,=20 etc. Such a set of blocks can be viewed as a FE block library. = The=20 minimum set of FE functions required in [FORCES_REQ] must be = part of=20 this library. It is expected that new FE blocks would be = defined and=20 added into this library over time. It is also expected that the = FE=20 model itself be decoupled from the ForCES protocol so that = extension=20 =20 Yang, et. al. Expires December 2002 [Page = 6] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 to basic blocks or changes to the existing blocks should not=20 impact the protocol itself. =20 =20 This document only intends to describe the conceptual FE model = and=20 illustrate it with some examples. However, it is not the = intention=20 of this document to define any specific block or the library = itself.=20 Separate document(s) would be written to achieve that. =20 =20 4.3. FE Stage=20 =20 As a packet flows through an FE along a datapath, it flows = through=20 one or multiple distinct stages, with each stage instantiating = a=20 certain FE logical function. So an FE stage is simply an = instance of=20 a FE block within an FE's datapath. Each FE allocates a = FE-unique=20 stage ID or label to each of its stages and passes the stage ID = or=20 label along with the corresponding block name as part of the FE = model description. This allows multiple instances of the same = block=20 present in a FE's datapath. =20 =20 For each stage, the following information must be defined:=20 - its FE-unique stage ID or label to identify, configure and = manage=20 the logical block of each by CE.;=20 - the corresponding block name (from the namespace) that this = stage=20 instantiating;=20 - all the information for this stage as described in Section = 5.1;=20 - the number of downstream stages to which this stage can send=20 packets;=20 - for each downstream stage: its stage ID or label.=20 =20 4.4. Directed Graph of FE Blocks=20 =20 Once a library of well-understood FE blocks is defined, and a = stage=20 is represented as described in 5.3, any static FE can be = modeled by=20 a directed graph interconnecting all the stages present in the = FE.=20 The static FEs can be defined by identifying all the input = stage(s)=20 and specifying each stage as described in Section 5.3. Figure 2 = shows one simple example of such an FE with three stages. =20 =20 To model a static FE, the following information needs to be=20 represented:=20 - number of stages in the FE;=20 - for each stage: define the stage using the model in 5.3;=20 - identify the input stages=20 =20 It is frequently necessary to share state between FE functional = stages in the forwarding plane. Since this model uses blocks as = the=20 basic way of modeling forwarding plane packet processing = stages, the=20 state information is exposed as part of connecting stage. For=20 example in Figure 2, stage #2 (IPv4 L3 LPM Forwarder) generates = some=20 meta data at its output to carry information on which port the=20 packets should go to, and #3 (Enet-Egress-port-Manager) uses = this=20 meta data to direct the packets to the right egress port.=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 7] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 =20 +------------+ +------------+ +------------+=20 input | Ethernet | | | | Ethernet = |output=20 ------->| Ingress |-->| IPv4 L3 LPM|-->| Egress = |----->=20 | Port Mgr | | Forwarder | | Port Mgr |=20 +------------+ +------------+ +------------+=20 =20 {stage ID=3D1, {stage ID=3D2, {stage = ID=3D3,=20 function=3D function=3D = function=3D=20 Enet-Ing-port, IPv4-L3-LPM-fwd, = Enet-Eg-port-Mgr,=20 #downstream=3D1, #downstream=3D1, = #downstream=3D1,=20 downstream=3D{2} downstream=3D{3} = downstream=3Dnone=20 } } }=20 =20 Figure 2. A very simple example of a static FE.=20 =20 =20 Queue1=20 +---+ +--+=20 | A|------------------->| |--+=20 +->| | | | |=20 | | B|--+ +--+ +--+ +--+ |=20 | +---+ | | | | | |=20 | Meter1 +->| |-->| | |=20 | | | | | |=20 | +--+ +--+ |=20 | Counter1 Absolute Queue2| +--+=20 +---+ | Dropper1 +--+ +--->|A |=20 | A|---+ | |------>|B |=20 -------->| B|------------------------------>| | +--->|C = |------>=20 | C|---+ +--+ | +->|D |=20 | X|-+ | | | +--+=20 +---+ | | +---+ +---+ Queue3| | = Scheduler=20 Classifier1 | | | A|------------>|A | +--+ | |=20 | +->| | | |->| |--+ |=20 | | B|--+ +--+ +->|B | | | |=20 | +---+ | | | | +---+ +--+ |=20 | Meter2 +->| |-+ Mux1 |=20 | | | |=20 | +--+ Queue4 |=20 | Marker1 +--+ |=20 +---------------------------->| |----+ =20 | |=20 +--+=20 =20 Figure 3. An FE example with multiple datapath.=20 =20 =20 There might be more than one datapath within an FE, typically = due to=20 blocks that are either 1:N or N:1. Figure 3 shows one such FE = block=20 example (based on an example in [MD-MODEL]). This FE implements = QoS=20 functions via combination of one or multiple instances of = logical=20 functions like classifier, meter, marker, queue, scheduler, = etc.=20 =20 Yang, et. al. Expires December 2002 [Page = 8] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 Some of the functions are 1:N (fan-out_ functions. For example, = the=20 stage labeled "Classifier1" is 1:4 function with four = downstream=20 stages, namely, Meter1, Queue2, Meter2, Queue4. A packet = entering=20 this FE can potentially take one of the six distinct datapath. = =20 Note that our stage representation can encode largely arbitrary = topologies of the stages. The only restrictions on topology = relate=20 to the source and sink nature of ingress and egress port = functions=20 respectively. For example, egress port functions must not have = nay=20 downstream stages whereas no other stage may refer to an = ingress=20 port function as one of its downstream stages. =20 =20 An FE block may contain zero, one or more ingress port stages.=20 Similarly, an FE block may contain zero, one or more egress = port=20 stages. In another word, not every FE block has to contain any=20 ingress port or egress port stages. For example, Figure 4 shows = two=20 FE blocks. Block #1 contains one ingress port function but no = egress=20 port function, while block #2 contains one egress port function = but=20 no ingress port function. It is possible to connect these two = FE=20 blocks together to achieve the complete ingress-to-egress = packet=20 processing function. This provides the flexibility to spread = the=20 functions across multiple FEs and interconnect them together = later=20 for certain applications. Figure 4 shows such an example.=20 =20 -------------------------------------------------------=20 | +---------+ +------------+ +---------+ |=20 input| | | | | | output |=20 ---+->| Ingress |-->|Header |-->|IPv4 = |---------+--->--+=20 | | port | |Decompressor| |Forwarder| FE | | = | +---------+ +------------+ +---------+ Block #1| | = ------------------------------------------------------| V = | = +-----------------------<-----------------------------+ = | =20 | |-----------------------------------------=20 V | +------------+ +----------+ |=20 | input | | | | output | = =20 +->--+->|Header |-->| Egress |---------+-->=20 | |Compressor | | port | FE |=20 | +------------+ +----------+ Block #2|=20 -----------------------------------------|=20 =20 =20 Figure 4. An example of two different FE blocks connected = together.=20 =20 5. Model Representation=20 =20 A formal data definition language is needed to represent the FE = model described in this document. The following is a list of = some=20 potential candidates. A suitable candidate needs to be chosen = as the=20 representation of FE model. However, we intend to leave this as = an=20 open issue and much debate is needed in the ForCES WG before a=20 =20 Yang, et. al. Expires December 2002 [Page = 9] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 decision can be made. Therefore, we only provide the candidate = list=20 and some initial discussion here without drawing a conclusion = yet.=20 - XML (Extensible Markup Language) Schema=20 - ASN.1 (Abstract Syntax Notation One)=20 - SMI (Structure of Management Information) [RFC1155]=20 - SPPI (Structure of Policy Provisioning Information) [RFC3159] = - SMIng (Next Generation Structure of Management Information)=20 - UML (Universal Modeling Language)=20 =20 XML has the advantage of being human readable with relatively = little=20 effort. However, it is less efficient and requires XML parsing=20 functions in the CE and FE. Currently XML is not widely = deployed and=20 used in network elements. =20 =20 ASN.1 format is human readable, and widely used in network=20 protocols. SMI is based on a subset of ASN.1 and used to define = Management Information Base (MIB) for SNMP. SPPI is the adapted = subset of SMI used to define Policy Information Base (PIB) for = COPS.=20 SMIng is currently being developed by SMIng working group at = IETF=20 and represents a superset of SMIv2 and SPPI. The objective of = SMIng=20 is to replace both SMIv2 and SPPI with a single, updated = language as=20 the data definition language for the monitoring, configuration, = and=20 provisioning of network devices. =20 =20 =20 6. Security Considerations=20 =20 The FE model just describes the representation and organization = of=20 data sets and attributes in the forwarding plane. There is no=20 communication protocol associated defined as part of the FE = model=20 therefore we do not see any security threats in this model.=20 =20 7. Intellectual Property Right=20 =20 The authors are not aware of any intellectual property right = issues=20 pertaining to this document.=20 =20 8. IANA consideration=20 =20 =20 If we are going to identify and name a new logical components = we may=20 need to standardize those components and the attributes. =20 =20 =20 9. Normative References=20 =20 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers",=20 RFC1812, June 1995.=20 =20 [RFC1155] M. Rose, et. al., "Structure and Identification of=20 Management Informationfor TCP/IP-based Internets", = May=20 1990.=20 =20 Yang, et. al. Expires December 2002 [Page = 10] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 =20 =20 [RFC3159] K. McCloghrie, et. al., "Structure of Policy = Provisioning=20 Information (SPPI)", August 2001.=20 =20 10. Informative References=20 =20 [FORCES-REQ] T. Anderson, et. al., "Requirements for Separation = of=20 IP Control and Forwarding", work in progress, April = 2002,=20 .=20 =20 [GOPAL-MODEL] R. Gopal, "Forwarding Element Model", work in=20 progress, February 2002, = .=20 =20 [ANDERSON-MODEL] T. Anderson, "ForCES Architectural Framework = and FE=20 Functional Model", work in progress, November 2001,=20 .=20 =20 [DS-MODEL] Y. Bernet, et. al., "An Informal Management Model = for=20 Diffserv Routers", work in progress, February 2001,=20 .=20 =20 11. Acknowledgments=20 =20 This document draws heavily from the concepts presented in = [GOPAL- MODEL], [ANDERSON-MODEL] and [DS-MODEL]. In addition to the = authors=20 of these documents, the authors would also like to thank the=20 following individuals for their invaluable technical input: = David=20 Putzolu, Hormuzd Khosravi, Eric Johnson, David Durham, Andrzej=20 Matejko.=20 =20 12. Authors' Addresses=20 =20 Lily L. Yang=20 Intel Labs=20 2111 NE 25th Avenue=20 Hillsboro, OR 97124 USA=20 Phone: +1 503 264 8813=20 Email: lily.l.yang@intel.com=20 =20 Joel Halpern=20 P.O.Box 6049=20 Leesburg, VA 20178=20 Phone: +1 703 371 3043=20 Email: jmh@joelhalpern.com=20 =20 Ram Gopal=20 Nokia Research Center=20 5, Wayside Road,=20 =20 Yang, et. al. Expires December 2002 [Page = 11] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 Burlington, MA 01803=20 Phone: +1 781 993 3685=20 Email: ram.gopal@nokia.com=20 =20 Ram Dantu=20 Netrake Corporation =20 3000 Technology Drive =20 Plano, Texas 75074 =20 Phone: +1 214 291 1111 =20 Email: ramd@netrake.com=20 =20 1. = Abstract........................................................1=20 2. Motivation and Requirements of FE = model.........................2=20 3. Capability and configuration Model versus State = Model...........4=20 4. FE = Model........................................................5=20 4.1. FE = Blocks..................................................5=20 4.2. FE Block = Library...........................................6=20 4.3. FE = Stage...................................................7=20 4.4. Directed Graph of FE = Blocks................................7=20 5. Model = Representation............................................9=20 6. Security = Considerations........................................10=20 7. Intellectual Property = Right....................................10=20 8. IANA = consideration.............................................10=20 9. Normative = References...........................................10=20 10. Informative = References........................................11=20 11. = Acknowledgments...............................................11=20 12. Authors' = Addresses............................................11=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 12] =0C ------_=_NextPart_000_01C21973.20D923B0-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 21 18:43:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03276 for ; Fri, 21 Jun 2002 18:43:15 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00660F04@cherry.ease.lsoft.com>; Fri, 21 Jun 2002 18:43:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21264046 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Jun 2002 18:43:52 -0400 Received: from 134.134.214.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 21 Jun 2002 18:43:50 -0400 Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by pallas.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5LMhnI02304 for ; Fri, 21 Jun 2002 22:43:49 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2002062115433514123 ; Fri, 21 Jun 2002 15:43:35 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 15:43:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C21975.18212A90" Approved-By: "Yang, Lily L" Message-ID: Date: Fri, 21 Jun 2002 15:43:42 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: New WG document on ForCES framework Comments: To: "Putzolu, David" , Internet-Drafts Administrator To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C21975.18212A90 Content-Type: text/plain; charset="iso-8859-1" <> David -- Please approve so that the attached draft can be submitted as ForCES WG document. Thanks, Lily ------_=_NextPart_000_01C21975.18212A90 Content-Type: text/plain; name="draft-ietf-forces-framework-00.txt" Content-Disposition: attachment; filename="draft-ietf-forces-framework-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft L. Yang=20 Expiration: December 2002 Intel Labs=20 File: draft-ietf-forces-framework-00.txt R. Dantu=20 Working Group: ForCES Netrake = Corp. =20 T. Anderson=20 Intel Labs = =20 June 2002 = =20 =20 =20 ForCES Architectural Framework=20 =20 =20 =20 draft-ietf-forces-framework-00.txt=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance = with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are=20 working documents of the Internet Engineering Task Force = (IETF), its=20 areas, and its working groups. Note that other groups may also = distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other = documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as ``work in=20 progress.''=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed = at =20 http://www.ietf.org/shadow.html.=20 =20 Conventions used in this document =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in=20 this document are to be interpreted as described in [RFC-2119]. = =20 1. Abstract=20 =20 This document defines the architectural framework for ForCES = network=20 elements (NE), and identifies the associated entities and the=20 interaction among them. This framework is intended to satisfy = the=20 requirements specified in the ForCES requirements draft = [FORCES- REQ].=20 =20 2. Definitions=20 =20 =0C Internet Draft ForCES Framework June 2002 = =20 =20 =20 =20 A set of terminology associated with the ForCES requirements is = defined in [FORCES-REQ] and we only include the ones that are = most=20 relevant to this document here. =20 =20 Forwarding Element (FE) - A logical entity that implements the=20 ForCES protocol. FEs use the underlying hardware to provide = per- packet processing and handling as directed by a CE via the = ForCES=20 protocol. =20 =20 Control Element (CE) - A logical entity that implements the = ForCES=20 protocol and uses it to instruct one or more FEs how to process = packets. CEs handle functionality such as the execution of = control =20 and signaling protocols. =20 =20 ForCES Network Element (NE) - An entity composed of one or more = CEs=20 and one or more FEs. To entities outside a NE, the NE = represents a=20 single point of management. Similarly, a NE usually hides its=20 internal organization from external entities. =20 =20 Pre-association Phase - The period of time during which a FE = Manager=20 (see below) and a CE Manager (see below) are determining which = FE=20 and CE should be part of the same network element. Any = partitioning=20 of PFEs and PCEs occurs during this phase. =20 =20 Post-association Phase - The period of time during which a FE = does=20 know which CE is to control it and vice versa, including the = time=20 during which the CE and FE are establishing communication with = one=20 another. =20 =20 ForCES Protocol - While there may be multiple protocols used = within=20 the overall ForCES architecture, the term "ForCES protocol" = refers=20 only to the ForCES post-association phase protocol (see below). = =20 =20 ForCES Post-Association Phase Protocol - The protocol used for = post- association phase communication between CEs and FEs. This = protocol=20 does not apply to CE-to-CE communication, FE-to-FE = communication, or=20 to communication between FE and CE managers. The ForCES = protocol is=20 a master-slave protocol in which FEs are slaves and CEs are = masters. =20 This protocol includes both the management of the communication = channel (e.g., connection establishment, heartbeats) and the = control=20 messages themselves. This protocol could be a single protocol = or=20 could consist of multiple protocols working together. =20 =20 FE Manager - A logical entity that operates in the = pre-association=20 phase and is responsible for determining to which CE(s) a FE = should=20 communicate. This process is called CE discovery and may = involve=20 the FE manager learning the capabilities of available CEs. A = FE=20 manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which CE(s) = to=20 use. Being a logical entity, a FE manager might be physically=20 =20 Yang, et. al. Expires December 2002 [Page 2] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 combined with any of the other logical entities mentioned in = this=20 section. =20 =20 CE Manager - A logical entity that operates in the = pre-association =20 phase and is responsible for determining to which FE(s) a CE = should =20 communicate. This process is called FE discovery and may = involve=20 the CE manager learning the capabilities of available FEs. A = CE=20 manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which FE to = use. =20 Being a logical entity, a CE manager might be physically = combined=20 with any of the other logical entities mentioned in this = section. =20 =20 Pre-association Phase Protocol - A protocol between FE managers = and=20 CE managers that is used to determine which CEs or FEs to use. = A=20 pre-association phase protocol may include a CE and/or FE = capability=20 discovery mechanism. Note that this capability discovery = process is=20 wholly separate from (and does not replace) that used within = the=20 ForCES protocol. However, the two capability discovery = mechanisms=20 may utilize the same FE model. =20 =20 FE Model - A model that describes the logical processing = functions=20 of a FE. =20 =20 ForCES Protocol Element - A FE or CE. =20 =20 3. Introduction to Forwarding and Control Element Separation = (ForCES) =20 =20 An IP network element (NE) appears to external entities as a=20 monolithic piece of network equipment, e.g., a router, NAT,=20 firewall, or load balancer. Internally, however, an IP network=20 element (NE) (such as a router or switch) is composed of = numerous=20 logically separated entities that cooperate to provide a given=20 functionality (such as routing or IP switching). Two types of=20 network element components exist: control element (CE) in = control=20 plane and forwarding element (FE) in forwarding plane (or data=20 plane). Forwarding elements typically are ASIC, = network-processor,=20 or general-purpose processor-based devices that handle data = path=20 operations for each packet. Control elements are typically = based on=20 general-purpose processors that provide control functionality = like=20 routing and signaling protocols. =20 =20 ForCES aims to define a framework and associated protocol(s) to = standardize the exchange of information between the control = plane=20 and the forwarding plane. Having standard mechanisms between = the CEs=20 and FEs allow these components to be physically separated. This = physical separation accrues several benefits to the ForCES=20 architecture. Separate components would allow component vendors = to=20 specialize in one component without having to become experts in = all=20 components. It also allows CEs and FEs from different component = vendors to interoperate with each other and hence it becomes=20 possible for system vendors to integrate together CEs and FEs = from=20 different component vendors. This translates into a lot more = design=20 choices and flexibility to the system vendors. Overall, ForCES = will=20 =20 Yang, et. al. Expires December 2002 [Page 3] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 enable rapid innovation in both the control and forwarding = planes=20 while maintaining interoperability. Scalability is also easily=20 provided by this architecture in that additional forwarding or=20 control capacity can be added to existing network elements = without=20 the need for forklift upgrades.=20 =20 One example of such physical separation is at the blade level.=20 Figure 1 shows an example configuration of a router, with two=20 control blades and multiple router (forwarding) blades, all=20 interconnected into a switch fabric backplane. In such chassis=20 configuration, the control blades are the CEs while the router=20 blades are FEs, and the switch fabric backplane provides the=20 physical interconnect for all the blades. Routers today with = this=20 kind of configuration use proprietary interface for messaging=20 between CEs and FEs. The goal of ForCES is to replace such=20 proprietary interface with a standard protocol. With a standard = protocol like ForCES implemented on all blades, it becomes = possible=20 for control blades from vendor X and routing blades from vendor = Y to=20 work seamlessly together in one chassis. =20 =20 =20 ------------------------- -------------------------=20 | Control Blade A | | Control Blade B |=20 | (CE) | | (CE) |=20 ------------------------- -------------------------=20 ^ | ^ |=20 | | | |=20 | V | V=20 ---------------------------------------------------------=20 | Switch Fabric Backplane |=20 ---------------------------------------------------------=20 ^ | ^ | ^ | = | | | | =85 | | = =20 | V | V | V = ------------ ------------ ------------ = |Router | |Router | |Router |=20 |Blade #1 | |Blade #2 | |Blade #N |=20 | (FE) | | (FE) | | (FE) |=20 ------------ ------------ ------------ = ^ | ^ | ^ | = | | | | =85 | | = =20 | V | V | V = =20 Figure 1. A router configuration example with separate = blades.=20 =20 Another level of physical separation between the CEs and FEs = can be=20 at the box level. In such configuration, all the CEs and FEs = are=20 physically separated boxes, interconnected with some kind of = high=20 speed LAN connection (like Gigabit Ethernet). These separated = CEs=20 and FEs are only one hop away from each other within a local = area=20 network. The CEs and FEs communicate to each other by running=20 ForCES, and the collection of these CEs and FEs together become = one=20 routing unit to the external world. Figure 2 shows such an = example.=20 =20 Yang, et. al. Expires December 2002 [Page 4] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 In this example, the same physical interconnect (Ethernet) is = shared=20 for both CE-to-FE and FE-to-FE communication. However, that = does not=20 have to be the case. One reason to use different interconnect = might=20 be that CE-to-FE interconnect does not have to be as fast as = the FE- to-FE interconnect, so the more expensive fast ports can be = saved=20 for FE-to-FE. There may also be reliability and redundancy = benefits=20 for the NE.=20 =20 ------- -------=20 | CE1 | | CE2 |=20 ------- -------=20 ^ ^=20 | |=20 V V=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ethernet=20 ^ ^ =85 ^=20 | | |=20 V V V=20 ------- ------- --------=20 | FE#1| | FE#2| | FE#n |=20 ------- ------- --------=20 ^ | ^ | ^ | =20 | | | | | | =20 | V | V | V =20 =20 Figure 2. A router configuration example with separate = boxes.=20 =20 =20 -------------------------------------------------=20 | | | | | | |=20 |OSPF |RIP |BGP |CAC |LDP |=85 |=20 | | | | | | |=20 -------------------------------------------------=20 | ForCES Interface |=20 -------------------------------------------------=20 ^ ^ =20 ForCES | |data =20 control | |packets =20 messages| |(e.g., routing packets) =20 v v=20 -------------------------------------------------=20 | ForCES Interface |=20 -------------------------------------------------=20 | | | | | | |=20 |LPM Fwd|Meter |Shaper |NAT |Classi-|=85 |=20 | | | | |fier | |=20 -------------------------------------------------=20 | FE resources |=20 -------------------------------------------------=20 =20 Figure 3. Examples of CE and FE functions=20 =20 =20 Yang, et. al. Expires December 2002 [Page 5] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 Some examples of control functions that can be implemented in = the CE=20 include routing protocols like RIP, OSPF and BGP, control and=20 signaling protocols like CAC (Call Admission Control), LDP = (Label=20 Distribution Protocol) for MPLS, etc. Examples of forwarding functions in FE include LPM (longest prefix match) forwarder,=20 classifiers, traffic shaper, meter, NAT, etc. Figure 3 shows a=20 diagram with examples in both CE and FE. Any given NE may = contain=20 one or many of these CE and FE functions in it. The diagram = also=20 shows that ForCES protocol is used to transport both the = control=20 messages for ForCES itself and the data packets that are=20 originated/destined from/to the control functions in CE (e.g.,=20 routing packets). Section 5.2 provides more detail on this. =20 =20 A set of requirements for control and forwarding separation is=20 identified in [FORCES-REQ]. This document describes a ForCES=20 architecture that satisfies the architectural requirements of = that=20 document and defines a framework for ForCES network elements = and=20 associated entities to facilitate protocol definition.=20 =20 4. Architecture=20 =20 This section defines the ForCES architectural framework and=20 associated logical components. This ForCES framework defines=20 components of ForCES NEs and also includes several ancillary=20 components. These components can be connected in different = kinds of=20 topologies for flexible packet processing. =20 =20 --------------------------------------- = | ForCES Network Element | = -------------- Fc | -------------- -------------- | = | CE Manager |---------+-| CE 1 |------| CE 2 | | = -------------- | | | Fr | | | = | | -------------- -------------- | = | Fl | | | Fp / | = | | Fp| |----------| / | = | | | |/ | = | | | | | = | | | Fp /|----| | = | | | /--------/ | | = -------------- Ff | -------------- -------------- | = | FE Manager |---------+-| FE 1 | Fi | FE 2 | | = -------------- | | |------| | | = =20 | -------------- -------------- | = | | | | | | | | | | = ----+--+--+--+----------+--+--+--+----- = | | | | | | | |=20 | | | | | | | |=20 Fi/f Fi/f=20 =20 Figure 4. ForCES Architectural Diagram=20 =20 The diagram in Figure 4 shows the logical components of the = ForCES=20 architecture and their relationships. There are two kinds of=20 =20 Yang, et. al. Expires December 2002 [Page 6] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 components inside a ForCES network element: control element = (CE) and=20 forwarding element (FE). The framework allows multiple = instances of=20 CE and FE inside one NE. Each FE contains one or more physical = media=20 interfaces for receiving and transmitting packets from/to the=20 external world. The aggregation of these FE interfaces becomes = the=20 NE=92s external interfaces. In addition to the external = interfaces,=20 there must also exist some kind of interconnect within the NE = so=20 that the CE and FE can communicate with each other, and one FE = can=20 forward packets to another FE. The diagram also shows two = entities=20 outside of the ForCES NE: CE Manager and FE Manager. These two=20 entities provide configuration to the corresponding CE or FE in = the=20 pre-association phase (see Section 5.1). There is no defined = role=20 for FE Manager and CE Manager in post-association phase, thus = these=20 logical components are not considered part of the ForCES NE. =20 =20 For convenience, the logical interactions between these = components=20 are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi. The = FE=20 interface is labeled as Fi/f. More detail is provided in = Section 4=20 and 5 for each of these reference points. It is important to=20 understand all these reference points from the architecture = point of=20 view, however, the ForCES protocol is only defined for one = reference=20 point (Fp). =20 =20 The interface between two ForCES NEs is identical to the = interface=20 between two conventional routers and these two NEs exchange the = protocol packets through the interfaces at Fi/f. ForCES NEs = connect=20 to existing routers transparently.=20 =20 4.1. Control Elements and Fr Reference Point=20 =20 It is not necessary to define any protocols across the Fr = reference=20 point to enable control and forwarding separation for simple=20 configurations like single CE and multiple FEs. However, this=20 architecture permits multiple CEs to be present in a network=20 element. In cases where an implementation uses multiple CEs, it = is=20 expected the invariant that the CEs and FEs together appear as = a=20 single NE MUST be maintained.=20 =20 Multiple CEs may be used for redundancy, load sharing, = distributed=20 control, or other purposes. Redundancy is the case where one = or=20 more CEs are prepared to take over should an active CE fail. = Load=20 sharing is the case where two or more CEs are concurrently = active=20 and where any request that can be serviced by one of the CEs = can=20 also be serviced by any of the other CEs. In both redundancy = and=20 load sharing, the CEs involved are equivalently capable. The = only=20 difference between these two cases is in terms of how many = active=20 CEs there are. Distributed control is the case where two or = more=20 CEs are concurrently active but where certain requests can only = be=20 serviced by certain CEs.=20 =20 When multiple CEs are employed in a ForCES NE, their internal=20 organization is considered an implementation issue that is = beyond=20 the scope of the ForCES effort. CEs are wholly responsible for=20 =20 Yang, et. al. Expires December 2002 [Page 7] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 coordinating amongst themselves via the Fr reference point to=20 provide consistency and synchronization. However, ForCES does = not=20 define the implementation or protocols used between CEs, nor = does it=20 define how to distribute functionality among CEs. Nevertheless, = ForCES will support mechanisms for CE redundancy or fail over, = and=20 it is expected that vendors will provide redundancy or fail = over=20 solutions within this framework.=20 =20 =20 4.2. Forwarding Elements and Fi reference point=20 =20 FEs perform per-packet processing and handling as directed by = CEs.=20 FEs have no initiative of their own. Instead, FEs are slaves = and=20 only do as they are told. FEs may communicate with one or more = CEs=20 concurrently across reference point Fp. FEs have no notion of = CE=20 redundancy, load sharing, or distributed control. Instead, FEs = accept commands from any CE authorized to control them, and it = is up=20 to the CEs to coordinate among themselves to achieve = redundancy,=20 load sharing or distributed control. The idea is to keep FEs as = simple and dumb as possible so that FEs can focus its resource = on=20 the packet processing functions. =20 =20 =20 ------- Fr -------=20 | CE1 | ------| CE2 |=20 ------- -------=20 | \ / |=20 | \ / |=20 | \ / |=20 | \/Fp |=20 | /\ |=20 | / \ |=20 | / \ |=20 ------- Fi -------=20 | FE1 |<----->| FE2 |=20 ------- -------=20 =20 Figure 5. CE redundancy example.=20 =20 For example, in Figure 5, FE1 and FE2 can be configured to = accept=20 commands from both the primary CE (CE1) and the backup CE = (CE2). At=20 the beginning, CE1 issues commands to FEs while CE2 silently = remains=20 in sync with CE1 via CE to CE protocol over Fr reference point. = When=20 CE1 fails, CE2 detects it and starts to take over. Before CE2 = starts=20 issuing commands to the FEs, it might need to recheck the FEs' = state=20 and instruct FEs whether or not it is ok to preserve their = current=20 state. =20 =20 Distributed control can be achieved in the similar fashion, = without=20 much intelligence on the part of FEs. For example, FEs can be=20 configured to detect RSVP and BGP protocol packets, and forward = RSVP=20 packets to one CE and BGP packets to another CE. Hence, FEs may = need=20 to do packet filtering for forwarding packets to specific CEs.=20 =20 Yang, et. al. Expires December 2002 [Page 8] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 =20 This architecture permits multiple FEs to be present in a NE.=20 [FORCES-REQ] dictates that the ForCES protocol MUST be able to = scale=20 to at least hundreds of FEs (see [FORCES-REQ] Section 5, = requirement=20 #11). Each of these FEs may potentially have a different set of = packet processing functions, with different media interfaces. = FEs=20 are responsible for basic maintenance of layer-2 connectivity = with=20 other FEs and with external entities. Many layer-2 media = include=20 sophisticated control protocols. The FORCES protocol (over the = Fp=20 reference point) will be able to carry messages for such = protools so=20 that, in keeping with the "dumb FE model" the CE can provide=20 appropriate intelligence and control over these media.=20 =20 When multiple FEs are present, ForCES requires that packets = MUST be=20 able to arrive at the NE by one FE and leave the NE via a = different=20 FE (See [FORCES-REQ], Section 5, Requirement #3). Packets that = enter the NE via one FE and leave the NE via a different FE are = transferred between FEs across the Fi reference point. The Fi=20 reference point is a separate protocol from the Fp reference = point=20 and is not currently defined by the ForCES architecture.=20 =20 FEs could be connected in different kinds of topologies and = packet=20 processing may spread across several FEs in the topology. = Hence,=20 logical packet flow may be different from physical FE topology. = Figure 6 provides some topology examples. When it is necessary = to=20 forward packets between FEs, CE needs to understand the FE = topology.=20 The FE topology can be queried from FEs by CEs. If the most = common=20 FE topology is full mesh among FEs, ForCES can assume it as the = default topology for FEs and hence no query is needed for such=20 default cases.=20 =20 ----------------- =20 | CE | =20 ----------------- =20 ^ ^ ^=20 / | \=20 / v \=20 / ----- \=20 / +->|FE3|<-+ \=20 v | ----- | v=20 ------- | | -------=20 | FE1 |<-+ +->| FE2 |=20 ------- -------=20 ^ | ^ |=20 | | | |=20 | v | v=20 =20 (a) Full mesh among FE1, FE2 and FE3.=20 =20 ----------- =20 | CE | =20 ----------- =20 =20 Yang, et. al. Expires December 2002 [Page 9] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 ^ ^ ^ ^=20 / | | \=20 /------ | | ------\=20 v v v v=20 ------- ------- ------- -------=20 | FE1 |<->| FE2 |<->| FE3 |<->| FE4 |=20 ------- ------- ------- -------=20 ^ | ^ | ^ | ^ |=20 | | | | | | | |=20 | v | v | v | v=20 =20 (b) Multiple FEs in a daisy chain=20 =20 =20 ^ |=20 | v=20 ----------- =20 | FE1 |<-----------------------| =20 ----------- |=20 ^ ^ |=20 / \ | =20 | ^ / \ ^ | V=20 v | v v | v ---------- = --------- --------- | | = | FE2 | | FE3 |<------------>| CE | = --------- --------- | | = ^ ^ ^ ---------- = | \ / ^ ^=20 | \ / | |=20 | v v | |=20 | ----------- | |=20 | | FE4 |<----------------------| | =20 | ----------- |=20 | | ^ |=20 | v | |=20 | |=20 |----------------------------------------|=20 =20 (c) Multiple FEs connected by a ring=20 =20 Figure 6. Some examples of FE topology.=20 =20 4.3. CE Managers=20 =20 CE managers are responsible for determining which FEs a CE = should=20 control. It is legitimate for CE managers to be hard-coded = with the=20 knowledge of with which FEs its CEs should communicate. A CE = manager=20 may also be physically embedded into a CE and be implemented as = a=20 simple keypad or other direct configuration mechanism on the = CE. =20 Finally, CE managers may be physically and logically separate=20 entities that configure the CE with FE information via such=20 mechanisms as COPS-PR [RFC3084] or SNMP [RFC1157].=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 10] =0C Internet Draft ForCES Framework June 2002 = =20 =20 4.4. FE Managers=20 =20 FE managers are responsible for determining to which CE any=20 particular FE should initially communicate. Like CE managers, = no=20 restrictions are placed on how a FE manager decides to which = CEs its=20 FEs should communicate, nor are restrictions placed on how FE=20 managers are implemented.=20 =20 5. Operational Phases=20 =20 Both FEs and CEs require some configuration in place before = they can=20 start information exchange and function as a coherent network=20 element. Two operational phases are identified in this = framework --=20 pre-association and post-association. =20 =20 5.1.Pre-association Phase=20 =20 Pre-association phase is the period of time during which a FE=20 Manager and a CE Manager are determining which FE and CE should = be=20 part of the same network element. The protocols used during = this=20 phase may include all or some of the message exchange over Fl, = Ff=20 and Fc reference points. However, all these may be optional and = none=20 of this is within the scope of ForCES protocol.=20 =20 5.1.1. Fl Reference Point=20 =20 =20 FE Manager FE CE Manager CE=20 | | | |=20 | | | |=20 |(security exchange) | |=20 1|<------------------------------>| |=20 | | | |=20 |(a list of CEs and their attributes) |=20 2|<-------------------------------| |=20 | | | |=20 |(a list of FEs and their attributes) |=20 3|------------------------------->| |=20 | | | |=20 | | | |=20 |<----------------Fl------------>| |=20 =20 Figure 7. An example of message exchange over Fl reference = point=20 =20 CE managers and FE managers may communicate across the Fl = reference=20 point in the pre-association phase in order to determine which = CEs=20 and FEs should communicate with each other. Communication = across=20 the Fl reference point is optional in this architecture. No=20 requirements are placed on this reference point.=20 =20 CE managers and FE managers may be operated by different = entities. =20 The operator of the CE manager may not want to divulge, except = to=20 specified FE managers, any characteristics of the CEs it = manages. =20 =20 Yang, et. al. Expires December 2002 [Page = 11] =0C Internet Draft ForCES Framework June 2002 = =20 =20 Similarly, the operator of the FE manager may not want to = divulge FE=20 characteristics, except to authorized entities. As such, CE=20 managers and FE managers may need to authenticate one another. = Subsequent communication between CE managers and FE managers = may=20 require other security functions such as privacy, = non-repudiation,=20 freshness, and integrity.=20 =20 Once the necessary security functions have been performed, the = CE=20 and FE managers communicate to determine which CEs and FEs = should=20 communicate with each other. At the very minimum, the CE and = FE=20 managers need to learn of the existence of available FEs and = CEs=20 respectively. This discovery process may or may not entail one = or=20 both managers learning the capabilities of the discovered = ForCES=20 protocol elements. Figure 7 shows an example of possible = message=20 exchange between CE manager and FE manager over Fl reference = point.=20 =20 5.1.2. Ff Reference Point=20 =20 FE Manager FE CE Manager CE=20 | | | |=20 | | | |=20 |(security exchange) |(security exchange)=20 1|<------------>|authentication = 1|<----------->|authentication | | | |=20 |(FE ID, attributes) |(CE ID, attributes)=20 2|<-------------|request 2|<------------|request=20 | | | |=20 3|------------->|response 3|------------>|response=20 |(corresponding CE ID) |(corresponding FE ID)=20 | | | |=20 | | | |=20 |<-----Ff----->| |<-----Fc---->|=20 =20 Figure 8. Examples of message exchange=20 over Ff and Fc reference points.=20 =20 The Ff reference point is used to inform forwarding elements of = the=20 association decisions made by FE managers in pre-association = phase. =20 Only authorized entities may instruct a FE with respect to = which CE=20 should control it. Therefore, privacy, integrity, freshness, = and=20 authentication are necessary between FE manager and FEs when = the FE=20 manager is remote to the FE. Once the appropriate security has = been=20 established, FE manager instructs FEs across this reference = point to=20 join a new NE or to disconnect from an existing NE. Figure 8 = shows=20 example of message exchange over Ff reference point.=20 =20 Note that when the FE manager function may be co-located with = the FE=20 (such as by manual keypad entry of the CE IP address), in which = case=20 this reference point is reduced to a built-in function.=20 =20 5.1.3. Fc Reference Point=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 12] =0C Internet Draft ForCES Framework June 2002 = =20 =20 The Fc reference point is used to inform control elements of = the=20 association decisions made by CE managers in pre-association = phase. =20 When the CE manager is remote, only authorized entities may = instruct=20 a CE to control certain FEs. Privacy, integrity, freshness and = authentication are also required across this reference point in = such=20 a configuration. Once appropriate security has been = established,=20 the CE manager instructs CEs as to which FEs they should = control and=20 how they should control them. Figure 7 shows example of message = exchange over Fc reference point.=20 =20 As with the FE manager and FEs, configurations are possible = where=20 the CE manager and CE are co-located and no protocol is used = for=20 this function.=20 =20 5.2. Post-association Phase and Fp reference point=20 =20 Post-association phase is the period of time during which a FE = and=20 CE have been configured with information necessary to contact = each=20 other and includes both communication establishment and = steady-state=20 communication. The communication between CE and FE is performed = across the Fp ("p" meaning protocol) reference point. ForCES=20 protocol is exclusively used for all communication across the = Fp=20 reference point. =20 =20 5.2.1. Proximity and Interconnect between CEs and FEs=20 The ForCES Working Group has made a conscious decision that the = first version of ForCES will not be designed to support=20 configurations where the CE and FE are located arbitrarily in = the=20 network. In particular, ForCES is intended for "very close" = CE/FE=20 localities in IP networks, as defined by ForCES Applicability=20 Statement ([FORCES-APP]). Very Close localities consist of = control=20 and forwarding elements that either are components in the same=20 physical box, or are separated at most by one local network = hop. =20 =20 CEs and FEs can be connected by a variety of interconnect=20 technologies, including Ethernet connections, backplanes, ATM = (cell)=20 fabrics, etc. ForCES should be able to support each of these=20 interconnects (see [FORCES-REQ] Section 5, requirement #1). = ForCES=20 will make use of an existing RFC2914 compliant L4 protocol with = adequate reliability, security and congestion control (e.g. = TCP,=20 SCTP) for transport purposes.=20 =20 5.2.2. Association Establishment=20 =20 As an example, figure 9 shows some of the message exchange that = need=20 to happen before the association between CE and FE is fully=20 established. Typically, FE would need to inform the CE of its = own=20 capability and its topology in relation to other FEs. The = capability=20 of FE is represented by FE model, described in another separate = document. The model would allow FE to describe what kind of = packet=20 processing functions it contains, in what order these = processing=20 happen, what kind of configurable parameters it allows, what=20 =20 Yang, et. al. Expires December 2002 [Page = 13] =0C Internet Draft ForCES Framework June 2002 = =20 =20 statistics it collects and what events it might throw, etc. = Once=20 such information is available to CE, CE sends all the necessary = configuration to FE so that FE can start receiving and = processing=20 packets. For example, CE might need to send a snapshot of the=20 current routing table to FE so that FE can start routing = packets=20 correctly. Once FE starts accepting packets for processing, we = say=20 the association of this FE with its CE is now established. From = then=20 on, CE and FE enter steady-state communication as described in=20 5.2.2.=20 =20 =20 =20 =20 FE CE=20 | |=20 |(Hello, are you there?)|=20 1|<----------------------|=20 | |=20 |(Yes. let me join the NE please.) =20 2|---------------------->|=20 | |=20 |(Security exchange.) |=20 3|<--------------------->|=20 | |=20 |(What kind of FE are you? -- capability query)=20 4|<----------------------|=20 | |=20 |(Here is my FE functions/state: use model to = describe)=20 5|---------------------->|=20 | |=20 |(How are you connected with others? -- topology = query)=20 6|<----------------------|=20 | |=20 |(Here is the topology info)=20 7|---------------------->|=20 | |=20 |(Config for FE initialization, e.g. routing = table)=20 8|<----------------------|=20 | |=20 |(I am ready to go. Shall I?) =20 9|---------------------->|=20 | |=20 |(Go ahead!) |=20 10|<----------------------|=20 | |=20 =20 Figure 9. Example of message exchange between CE and FE=20 over Fp to establish NE association=20 =20 =20 5.2.3. Steady-state Communication=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 14] =0C Internet Draft ForCES Framework June 2002 = =20 =20 Once an association is established between the CE and the FE, = the=20 ForCES protocol is used by the CE and the FE over Fp reference = point=20 to exchange information to facilitate packet processing. =20 =20 FE CE=20 | |=20 |(Add these new routes.)|=20 1|<----------------------|=20 | |=20 |(Successful.) |=20 2|---------------------->|=20 | |=20 | |=20 | |=20 |(Query some stats.) |=20 1|<----------------------|=20 | |=20 |(Reply with stats collected.) =20 2|---------------------->|=20 | |=20 | |=20 | |=20 |(My port is down, with port #.) = =20 1|---------------------->|=20 | |=20 |(Route to this port instead...) =20 2|<----------------------|=20 | |=20 | |=20 =20 Figure 10. Examples of message exchange between CE and FE = over Fp during steady-state communication=20 =20 Based on the information acquired through CEs' control = processing,=20 CEs will frequently need to manipulate the packet-forwarding=20 behaviors of their FE(s) by sending instructions to FEs. For=20 example, Figure 10 shows one such message exchange in which CE = sends=20 new routes to FE so that FE can add them to its routing table. = CE=20 can also query FE for statistics collected by FE and FE can = also=20 notify CE of some important events, like interface up and down, = etc.=20 Figure 8 also shows such examples.=20 =20 5.2.4. Data Packets across Fp reference point=20 =20 Control packets (such as RIP, OSPF messages) addressed to any = of=20 NE's interfaces are typically redirected by the receiving FE to = its=20 CE, and CE may originate packets and have its FE deliver them = to=20 other NEs. Therefore, the communication across the Fp reference = point includes not only the control messages from CEs to FEs = and the=20 status or statistics report from FEs to CEs, but also the data=20 packets that are redirected between them. Moreover, one FE may = be=20 controlled by multiple CEs. In this configuration, the control=20 protocols supported by the FORCES NEs may spread across = multiple=20 =20 Yang, et. al. Expires December 2002 [Page = 15] =0C Internet Draft ForCES Framework June 2002 = =20 =20 CEs. For example, one CE may support OSPF and another supports = BGP.=20 FEs are configured to recognize these protocol packets and = forward=20 them to the corresponding CE. =20 =20 Figure 11 shows one example of how the OSPF packets originated = by=20 router A are passed to router B. In this example, ForCES = protocol is=20 used to transport the packets from CE to FE inside router A, = and=20 then from FE to CE inside router B. In light of the fact that = ForCES=20 protocol is responsible to transport both the control messages = and=20 the data packets between CE and FE over Fp reference point, it = is=20 possible to use either a single protocol or multiple protocols = to=20 achieve that.=20 =20 =20 --------------------- ----------------------=20 | | | |=20 | +--------+ | | +--------+ |=20 | |CE(OSPF)| | | |CE(OSPF)| |=20 | +--------+ | | +--------+ |=20 | | | | ^ |=20 | |Fp | | |Fp |=20 | v | | | |=20 | +--------+ | | +--------+ |=20 | | FE | | | | FE | |=20 | +--------+ | | +--------+ |=20 | | | | ^ |=20 | Router | | | Router | |=20 | A | | | B | |=20 ---------+----------- -----------+----------=20 v ^=20 | |=20 | |=20 ------------------->--------------- =20 =20 Figure 11. Example to show data packet flow between two = NEs.=20 =20 =20 5.2.5. Proxy FE=20 =20 In the case where a physical FE cannot implement (e.g., due to = the=20 lack of a general purpose CPU) the ForCES protocol directly, a = proxy=20 FE can be used in the middle of Fp reference point. This allows = the=20 CE communicate to the physical FE via the proxy by using = ForCES,=20 while the proxy manipulates the physical FE using some = intermediary=20 form of communication (e.g., a non-ForCES protocol or DMA). In = such=20 an implementation, the combination of the proxy and the = physical FE=20 becomes one logical FE entity. =20 =20 5.3. Association Re-establishment=20 =20 FEs and CEs may join and leave NEs dynamically (see = [FORCES-REQ]=20 Section 5, requirements #12 and #13). When a FE or CE leaves = the NE,=20 the association with the NE is broken. If the leaving party = rejoins=20 =20 Yang, et. al. Expires December 2002 [Page = 16] =0C Internet Draft ForCES Framework June 2002 = =20 =20 a NE later, to re-establish the association, it may or may not = need=20 to re-enter the pre-association phase. Loss of association can = also=20 happen unexpectedly due to loss of connection between the CE = and the=20 FE. Therefore, the framework allows the bi-directional = transition=20 between these two phases, but the ForCES protocol is only = applicable=20 for the post-association phase. However, the protocol should = provide=20 mechanisms to support association re-establishment (see = [FORCES-REQ]=20 Section 5, requirement #7).=20 =20 Let's use the example in Figure 5 to see what happens when the=20 association is broken and later re-established again. Section = 4.2=20 already explains what happens if CE1 fails and how CE2 can take = over. Note that if no CE redundancy is provided, FEs need to be = told=20 at the association establishment time what to do in the case of = CE=20 failure. FEs may be told to stop packet processing all together = if=20 its CE fails. Or, FEs may be told to continue forwarding = packets=20 even in the face of CE failure. No matter what, it needs to be = part=20 of the configuration when the association is established. =20 =20 Let's now look at the case when FE1 leaves the NE temporarily,=20 assuming CE1 is the working CE for the moment. FE1 may = voluntarily=20 decides to leave the association. Or, it is more likely that = FE1=20 stops functioning simply due to unexpected failure. In former = case,=20 CE1 receives a "leave-association request" from FE1. In the = latter,=20 CE1 detects the failure of FE1 by some other mean. In both = cases,=20 CE1 would keep a note of such event for FE1 while continue=20 commanding FE2. When FE1 decides to rejoin again, or when it is = back=20 up again from the failure, FE1 would need to re-discover its = master=20 (CE). This can be achieved by several means. It may re-enter = the=20 pre-association phase and get that information from its FE = manager.=20 It may retrieve the previous CE information from its cache, if = it=20 decides that the information is still valid. Or, that = information=20 can be simply hard-coded or pre-configured into it. Once it=20 discovers its CE, it starts message exchange with CE to = re-establish=20 the association just as outlined in Figure 9, with the possible = exception that it might be able to bypass the transport of the=20 complete initialization information. Suppose that FE1 still = have its=20 routing table and other state information from the last = association,=20 instead of sending all the information again from scratch, it = can=20 choose to use more efficient mechanism to re-sync up the state = with=20 its CE. For example, a checksum of the state might give a quick = indication of whether or not the state is in-sync with its CE. = By=20 comparing its state with CE first, it sends information update = only=20 if it is needed.=20 =20 =20 6. Applicability to RFC1812 =20 =20 [FORCES-REQ] Section 5, requirement #9 dictates that "All = proposed=20 ForCES architecture MUST explain how that architecture may be=20 applied to support all of a router's functions as defined in=20 [RFC1812]." RFC1812 discusses many important requirements for = IPv4=20 routers from the link layer to the application layer. This = section=20 =20 Yang, et. al. Expires December 2002 [Page = 17] =0C Internet Draft ForCES Framework June 2002 = =20 =20 addresses the relevant requirements for implementing IPv4 = routers=20 based on ForCES architecture and how ForCES satisfies these=20 requirements.=20 =20 6.1. General Router Requirements=20 =20 Routers have at least two or more logical interfaces. When CEs = and=20 FEs are separated by ForCES within a single NE, some additional = interfaces are needed for intra-NE communications. Figure 12 = shows=20 an example to illustrate that. This NE contains one CE and two = FEs.=20 Each FE has four interfaces; two of them are used for receiving = and=20 transmitting packets to the external world, while the other two = are=20 for intra-NE connections. CE has two logical interfaces #9 and = #10,=20 connected to interfaces #3 and #6 from FE1 and FE2, = respectively.=20 Interface #4 and #5 are connected for FE1-FE2 communication. So = this=20 router NE provides four external interfaces (#1, 2, 7 and 8). =20 =20 ---------------------------------=20 | router NE |=20 | ----------- ----------- |=20 | | FE1 | | FE2 | |=20 | ----------- ----------- |=20 | 1| 2| 3| 4| 5| 6| 7| 8| |=20 | | | | | | | | | |=20 | | | | +----+ | | | |=20 | | | | | | | |=20 | | | 9| 10| | | |=20 | | | -------------- | | |=20 | | | | CE | | | |=20 | | | -------------- | | |=20 | | | | | |=20 -----+--+----------------+--+----=20 | | | | =20 | | | | =20 =20 Figure 12. A router NE example with four = interfaces.=20 =20 IPv4 routers must implement IP to support its packet forwarding = function, which is driven by its FIB (Forwarding Information = Base).=20 This Internet layer forwarding (see [RFC1812] Section 5)=20 functionality naturally belongs to FEs in the ForCES = architecture. =20 =20 A router may implement transport layer protocols (like TCP and = UDP)=20 that are required to support application layer protocols (see=20 [RFC1812] Section 6). One important class of application = protocols=20 is routing protocols (see [RFC1812] Section 7). In ForCES=20 architecture, routing protocols are naturally implemented by = CEs.=20 Routing protocols require routers communicate with each other. = This=20 communication between CEs in different routers is supported in=20 ForCES by the FEs' ability to redirect data packets =20 addressed to routers (i.e., NEs) and CEs' ability to originate=20 packets and have them delivered by their FEs. This = communication=20 =20 Yang, et. al. Expires December 2002 [Page = 18] =0C Internet Draft ForCES Framework June 2002 = =20 =20 occurs across Fp reference point inside each router and between = neighboring routers' interfaces, as illustrated in Figure 11. =20 =20 6.2.Link Layer=20 =20 Since FEs own all the external interfaces for the router, FEs = need=20 to conform to all the link layer requirements in RFC1812, = including=20 ARP support. Interface parameters, including MTU, IP address, = etc.,=20 must be configurable by CEs via ForCES. FEs must also inform = CEs the=20 status change of the interfaces (like link up/down) via ForCES. = =20 6.3.Internet Layer Protocols=20 =20 Both FEs and CEs must implement IP protocol and all mandatory=20 options as RFC1812 specified. If an FE receives a packet = containing=20 a completed source route, the packet has reached its final=20 destination. The option as received (the recorded route) MUST = be=20 passed up to the transport layer (or to ICMP message = processing) at=20 CEs. Both FEs and CEs might choose to silently discard packets=20 without sending ICMP errors, and such events should be logged. = FEs=20 can report statistics for such events to CEs via ForCES. =20 =20 When multiple FEs are involved to process packets, the = appearance of=20 single NE must be strictly maintained. For example, = Time-To-Live=20 (TTL) must be decremented only once within a single NE. For = example,=20 it can be always decremented by the last FE with egress = function.=20 Similarly, when source =20 =20 When IP multicast is supported in routers, IGMP is implemented = in=20 CEs. CEs are also required of ICMP support, while it is = optional for=20 FEs to support ICMP. Such an option can be communicated to CEs = as=20 part of the FE model. Therefore, FEs can always rely upon CEs = to=20 send out ICMP error messages, but FEs also have the option to=20 generate ICMP error messages themselves. =20 =20 6.4.Internet Layer Forwarding=20 =20 IP forwarding is implemented by FEs. After routing protocol = update=20 its routing tables at CEs, ForCES is used to send the new = routing=20 table entries from CEs to FEs. Each FE has its own routing = table and=20 uses this table to direct packets to the next hop interface. = Note=20 that the routing table could be different from FE to FE because = each=20 FE has a different set of next hop interfaces. =20 =20 Upon receiving IP packets, FEs verify the IP header and process = most=20 of the IP options. Some options can't be processed until the = routing=20 decision has been made. Routing decision is made after = examining the=20 destination IP address. If the destination address belongs to = the=20 router itself, the packets are forwarded to CEs. Otherwise, FEs = determine the next hop IP address by looking up in its routing=20 table. FEs also determine the network interface it uses to send = the=20 packets. Sometimes an FE may need to forward the packets to = another=20 FE before packets can be forwarded out to the next hop. Right = before=20 =20 Yang, et. al. Expires December 2002 [Page = 19] =0C Internet Draft ForCES Framework June 2002 = =20 =20 packets are forwarded out to the next hop, FEs decrement TTL by = 1=20 and process any IP options that can not be processed before. = FEs=20 perform any IP fragmentation if necessary, determine link layer = address (e.g., by ARP), and encapsulates the IP datagram (or = each of=20 the fragments thereof) in an appropriate link layer frame and = queues=20 it for output on the interface selected.=20 =20 Other options mentioned in RFC1812 for IP forwarding may also = be=20 implemented at FEs, for example, packet filtering.=20 =20 FEs typically forward packets destined locally to CEs. FEs may = also=20 forward exceptional packets (packets that FEs don't know how to = handle) to CEs. CEs are required to handle packets forwarded by = FEs=20 for whatever different reasons. It might be necessary for = ForCES to=20 attach some meta-data with the packets to indicate the reasons = of=20 forwarding from FEs to CEs. Upon receiving packets with = meta-data=20 from FEs, CEs can decide to either process the packets = themselves,=20 or pass the packets to the upper layer protocols including = routing=20 and management protocols. If CEs are to process the packets by=20 themselves, CEs may choose to discard the packets, or modify = and re- send the packets. CEs may also originate new packets and = deliver=20 them to FEs for further forwarding. =20 =20 Any state change during router operation must also be handled=20 correctly according to RFC1812. For example, when an FE ceases=20 forwarding, the entire NE may continue forwarding packets, but = it=20 needs to stop advertising routes that are affected by the = failed FE. =20 =20 6.5.Transport Layer =20 =20 Transport layer is typically implemented at CEs to support = higher=20 layer application protocols like routing protocols. In = practice,=20 this means that most CEs implement both the Transmission = Control=20 Protocol (TCP) and the User Datagram Protocol (UDP).=20 =20 Both CEs and FEs need to implement ForCES protocol. If any = layer-4=20 transport is used to support ForCES, then both CEs and FEs need = to=20 implement the L4 transport and ForCES protocols. It is possible = that=20 all FEs inside an NE implements only one such protocol entity. = =20 6.6. Application Layer -- Routing Protocols=20 =20 Both interior routing protocols and exterior routing protocols = are=20 implemented on CEs. The routing packets originated by CEs are=20 forwarded to FEs for delivery. The results of such protocols = (like=20 routing table update) are communicated to FEs via ForCES.=20 =20 6.7. Application Layer -- Network Management Protocol=20 =20 RFC1812 also dictates "Routers MUST be manageable by SNMP." = (see=20 [RFC1157] Section 8) In general, for post-association phase, = most=20 external management tasks (including SNMP) SHOULD be done = through=20 interaction with the CE in order to support the appearance of a = =20 Yang, et. al. Expires December 2002 [Page = 20] =0C Internet Draft ForCES Framework June 2002 = =20 =20 single functional device. Therefore, it is recommended that = SNMP=20 management agent be implemented by CEs and the SNMP messages = sent to=20 FEs be redirected to their CEs. This also requires that ForCES = In=20 certain conditions (e.g. CE/FE disconnection), it may be useful = to=20 allow SNMP to be used to diagnose and repair problems. However, = care=20 should be taken when exercising such mechanisms and guidelines = are=20 provided in [FORCES-REQ], Section 5, requirement #4.=20 =20 7. Summary=20 =20 This document defines an architectural framework for ForCES. It = identifies the relevant components for an ForCES network = element,=20 including (one or more) FEs, (one or more) CEs, FE manager=20 (optional), and CE manager (optional). It also identifies the=20 interaction among these components and discusses all the major=20 reference points. It is important to point out that, among all = the=20 reference points, only the interface between CEs and FEs is = within=20 the scope of ForCES. ForCES alone may not be enough to support = all=20 different NE configurations. However, we believe ForCES is the = most=20 important element in realizing the physical separation and=20 interoperability of CEs and FEs, and hence the first interface = that=20 ought to be standardized. Simple and useful configurations can = still=20 be implemented with only CE-FE interface standardized, e.g., = single=20 CE with full-meshed FEs and static configuration without the = need=20 for CE/FE managers.=20 =20 8. Security Considerations=20 =20 The security necessary across each reference point except Fp is = discussed throughout the document. In general, the physical=20 separation of two entities usually requires much stricter = security=20 measurement in place. For example, we pointed out in Section = 5.1=20 that authentication becomes necessary between CE manager and FE = manager, between CE and CE manager, between FE and FE manager = in=20 some configuration. The physical separation of CE and FE also=20 imposes serious security requirement for ForCES protocol. The=20 security requirements for reference point Fp (i.e., ForCES = protocol)=20 are discussed in detail in [FORCES-REQ] Section 8.=20 =20 9. Intellectual Property Right=20 =20 The authors are not aware of any intellectual property right = issues=20 pertaining to this document.=20 =20 10. Normative References=20 =20 [RFC2914] S. Floyd, "Congestion Control Principles", RFC2914,=20 September 2000.=20 =20 [RFC1157] J. Case, et. al., "A Simple Network Management = Protocol=20 (SNMP)", RFC1157, May 1990.=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 21] =0C Internet Draft ForCES Framework June 2002 = =20 =20 [RFC3084] K. Chan, et. al., "COPS Usage for Policy Provisioning = (COPS-PR)", RFC3084, March 2001.=20 =20 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers",=20 RFC1812, June 1995.=20 =20 11. Informative References=20 =20 [FORCES-REQ] T. Anderson, et. al., "Requirements for Separation = of=20 IP Control and Forwarding", work in progress, February 2002, = .=20 =20 [FORCES-APP] A. Crouch, et. al., "ForCES Applicability = Statement",=20 work in progress, February 2002, = .=20 =20 12. Acknowledgments=20 =20 Joel M. Halpern gave us many insightful comments and = suggestions and=20 pointed out several major issues. Many of our colleagues and = people=20 in the ForCES mailing list also provided valuable feedback,=20 including Alan Crouch, Patrick Droz, David Putzolu, Hormuzd M.=20 Khosravi, and Ryszard Dyrga.=20 =20 13. Authors' Addresses=20 =20 Lily L. Yang=20 Intel Labs=20 2111 NE 25th Avenue=20 Hillsboro, OR 97124 USA=20 Phone: +1 503 264 8813=20 Email: lily.l.yang@intel.com=20 =20 Ram Dantu=20 Netrake Corporation=20 3000 Technology Drive=20 Plano, Texas 75074=20 Phone: +1 214 291 1111=20 Email: ramd@netrake.com=20 =20 Todd A. Anderson=20 Intel Labs=20 2111 NE 25th Avenue=20 Hillsboro, OR 97124 USA=20 Phone: +1 503 712 1760=20 Email: todd.a.anderson@intel.com=20 =20 =20 =20 =20 1. = Abstract........................................................1=20 2. = Definitions.....................................................1=20 =20 Yang, et. al. Expires December 2002 [Page = 22] =0C Internet Draft ForCES Framework June 2002 = =20 =20 3. Introduction to Forwarding and Control Element Separation=20 = (ForCES)...........................................................3=20 4. = Architecture....................................................6=20 4.1. Control Elements and Fr Reference = Point....................7=20 4.2. Forwarding Elements and Fi reference = point.................8=20 4.3. CE = Managers...............................................10=20 4.4. FE = Managers...............................................11=20 5. Operational = Phases.............................................11=20 5.1. Pre-association = Phase.....................................11=20 5.1.1. Fl Reference = Point...................................11=20 5.1.2. Ff Reference = Point...................................12=20 5.1.3. Fc Reference = Point...................................12=20 5.2. Post-association Phase and Fp reference = point.............13=20 5.2.1. Proximity and Interconnect between CEs and = FEs.......13=20 5.2.2. Association = Establishment............................13=20 5.2.3. Steady-state = Communication...........................14=20 5.2.4. Data Packets across Fp reference = point...............15=20 5.2.5. Proxy = FE.............................................16=20 5.3. Association = Re-establishment..............................16=20 6. Applicability to = RFC1812.......................................17=20 6.1. General Router = Requirements...............................18=20 6.2. Link = Layer................................................19=20 6.3. Internet Layer = Protocols..................................19=20 6.4. Internet Layer = Forwarding.................................19=20 6.5. Transport = Layer...........................................20=20 6.6. Application Layer -- Routing = Protocols....................20=20 6.7. Application Layer -- Network Management = Protocol..........20=20 7. = Summary........................................................21=20 8. Security = Considerations........................................21=20 9. Intellectual Property = Right....................................21=20 10. Normative = References..........................................21=20 11. Informative = References........................................22=20 12. = Acknowledgments...............................................22=20 13. Authors' = Addresses............................................22=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 23] =0C ------_=_NextPart_000_01C21975.18212A90-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 24 14:05:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21631 for ; Mon, 24 Jun 2002 14:05:17 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006659F3@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 14:06:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21416857 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Jun 2002 14:05:59 -0400 Received: from 143.182.246.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 24 Jun 2002 14:05:59 -0400 Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5OI5vh18254 for ; Mon, 24 Jun 2002 18:05:58 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002062411061919804 for ; Mon, 24 Jun 2002 11:06:19 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 11:05:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Khosravi, Hormuzd M" Message-ID: Date: Mon, 24 Jun 2002 11:05:56 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: new netlink draft To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list I would like to last call the latest version of the Netlink draft. Please do send us any comments/suggestions on the draft. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Sent: Friday, June 07, 2002 3:47 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] 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 From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 25 07:10:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00091 for ; Tue, 25 Jun 2002 07:10:56 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006673DE@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 7:11:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21494077 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Jun 2002 07:11:27 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 25 Jun 2002 07:01:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29001; Tue, 25 Jun 2002 07:00:44 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200206251100.HAA29001@ietf.org> Date: Tue, 25 Jun 2002 07:00:44 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-framework-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 : ForCES Architectural Framework Author(s) : L. Yang et al. Filename : draft-ietf-forces-framework-00.txt Pages : 23 Date : 24-Jun-02 This document defines the architectural framework for ForCES network elements (NE), and identifies the associated entities and the interaction among them. This framework is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES- REQ]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-00.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 "get draft-ietf-forces-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020624143527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143527.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 25 07:12:00 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00176 for ; Tue, 25 Jun 2002 07:12:00 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0066743C@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 7:12:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21494096 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Jun 2002 07:12:42 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 25 Jun 2002 07:02:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29263; Tue, 25 Jun 2002 07:01:58 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200206251101.HAA29263@ietf.org> Date: Tue, 25 Jun 2002 07:01:58 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-yang-forces-model-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ForCES Forwarding Element Functional Model Author(s) : L. Yang et al. Filename : draft-yang-forces-model-00.txt Pages : 12 Date : 24-Jun-02 This document defines a functional model for ForCES forwarding elements (FEs). This model is used to describe the state of ForCES forwarding elements within the context of the ForCES protocol, so that ForCES control elements (CEs) can control the FEs accordingly. The model is to specify what logical function instances are present in the FEs and in what order these functions are performed. The forwarding element model defined herein is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES- REQ]. Using this model, predefined or vendor specific logical functions can be expressed and configured. However, the definition of these components are not described and defined in this document. Definitions A set of terminology associated with the ForCES requirements is defined in [FORCES-REQ] and is not copied here. The following list of terminology is relevant to the FE model defined in this document. Datapath -- A conceptual path taken by packets within the forwarding plane, inside an FE. There might exist more than one datapath within an FE. Forwarding Element (FE) Block -- An abstraction of the basic packet processing functions in the datapath. It is the building block of FE functionality. This concept abstracts away implementation details from the parameters of interest for configuration, control and management by CE. The general rule of thumb on the granularity of FE blocks is that FE blocks should be coarse grained, stateful and focus on a particular domain. For example, RFC1812 compliant IPv4 forwarder, classifiers, meters, etc.. Forwarding Element (FE) Stage -- Representation of a FE block instance in a FE's datapath. As a packet flows through an FE along a datapath, it flows through one or multiple distinct stages, with each stage implementing an instance of a certain logical function. There may be one or more combination of such instances in a FE's datapath. Using NAT as A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yang-forces-model-00.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 "get draft-yang-forces-model-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yang-forces-model-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020624143732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yang-forces-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-yang-forces-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143732.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 25 08:09:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01886 for ; Tue, 25 Jun 2002 08:09:41 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006675C9@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 8:10:23 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21495185 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Jun 2002 08:10:22 -0400 Received: from 195.212.91.200 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 25 Jun 2002 08:10:22 -0400 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5PCALDb067434 for ; Tue, 25 Jun 2002 14:10:21 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5PCAKo76214 for ; Tue, 25 Jun 2002 14:10:20 +0200 Received: from dhcp70-102.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38776 from ; Tue, 25 Jun 2002 14:10:16 +0200 X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en Mime-Version: 1.0 References: <02061306390200.01004@jzny.localdomain> <3D0F5AAE.6F8BCFCE@zurich.ibm.com> <02061921100102.01197@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate-2.de.ibm.com id g5PCALDb067434 Approved-By: Robert Haas Message-ID: <3D185DA8.69D9E60D@zurich.ibm.com> Date: Tue, 25 Jun 2002 14:10:16 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs andoff-loadofsignalingfunctions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA01886 Jamal, Hormuzd, Here is a suggestion that could fit into section 6.5 "Minimal Set of Logical Functions". The idea is to ensure that the FE model remains flexible and it does not imply that FEs must support such functionalities. 8) Off-loaded Functions Per-packet processing can leave state in the FE, so that logical functions executed during packet processing can perform in a consistent manner (for instance, each packet may update the state of the token bucket occupancy of a given policer). In addition, FEs MUST allow logical functions to execute asynchronously from packet processing, according to a certain finite-state machine, in order to perform functions that are, for instance, off-loaded from the CE to the FE. The FE model MUST be capable of expressing these asynchronous functions. Examples of such functions include the finite-state machine execution required by TCP termination or OSPF Hello processing, triggered not only by packet events, but timer events as well. Regards, -Robert Jamal Hadi Salim wrote: > Robert, > Please come up with the appropriate text. > > cheers, > jamal > > On Tuesday 18 June 2002 12:07, Robert Haas wrote: > > Jamal, > > My concern is the limitation of the scope of FEs capabilities to whatever > > can be done to "the packet as it passes through the FE", as the draft > > mentions it repeatedly. > > If there are other capabilities planned for ForCES besides Forwarding+QoS, > > then the requirements draft should avoid being so restrictive, IMHO. The > > TCP termination being just one example out of today's FEs capabilities that > > go beyond the current scope, as I understand now. > > > > If you think it's acceptable, then I'll try to come up with a concrete > > suggestion how to formulate this, that you could then consider including in > > the draft. > > > > Cheers, > > -Robert > > > > Jamal Hadi Salim wrote: > > > On Monday 10 June 2002 15:34, Robert Haas wrote: > > > > 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 > > > > > control activity. > > > > > Did i understand you correctly? > > > > > > > > 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 ? > > > > > > Robert, > > > I think it would be wrong to limit what functionality goes onto the FE. I > > > worked on the requirements team and tried hard to make sure this is > > > clear. > > > > > > > > > If you find that this is not reflected properly, i think it should be > > > clarified. > > > > > > I cant remember who came up with the term "high-touch" and it may already > > > be used by some organizations as marketing cliche and so may already be > > > polluted to mean something else than intended focus. > > > The caveat to note is that while Forces MUST not restrict what > > > functionality goes into the FE vs CE, the charter says the immediate > > > focus (in my opinion it is just an example) is Forwarding + QoS. This may > > > be confusing the other side of the coin where people seem to think the > > > protocol is based on Diffserv configuration. > > > > > > cheers, > > > jamal > > > > > > > Thanks > > > > > > > > > cheers, > > > > > jamal > > > > > > > > > > > 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 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 -- 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 From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 25 13:55:03 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18656 for ; Tue, 25 Jun 2002 13:55:02 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00667E81@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 13:55:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21524303 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Jun 2002 13:55:44 -0400 Received: from 143.182.246.24 by NEWS-BP.COM (SMTPL release 1.0f) with TCP; Tue, 25 Jun 2002 13:55:43 -0400 Received: from azsmsxvs043.ch.intel.com (azsmsxvs043.ch.intel.com [10.2.248.13]) by pan.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5PHtga01791 for ; Tue, 25 Jun 2002 17:55:42 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by azsmsxvs043.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2002062510554215484 for ; Tue, 25 Jun 2002 10:55:42 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 10:55:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Tue, 25 Jun 2002 10:55:37 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Agenda Slot Finalized: Monday July 15, 0900-1130 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, The agenda for IETF 54 has been finalized. ForCES will meet on Monday, July 15, 2002, from 0900-1130. See you there! Cheers, David