From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 5 11:41:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03875 for ; Thu, 5 Jun 2003 11:41:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nwq2-0000VG-00 for forces-archive@IETF.ORG; Thu, 05 Jun 2003 11:39:38 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19Nwq1-0000V7-00 for forces-archive@IETF.ORG; Thu, 05 Jun 2003 11:39:37 -0400 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.009FB550@cherry.ease.lsoft.com>; Thu, 5 Jun 2003 11:41:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44797814 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Jun 2003 11:41:27 -0400 Received: from 194.196.100.235 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Jun 2003 11:41:26 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h55FfB8m110748 for ; Thu, 5 Jun 2003 17:41:13 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h55Fea8P264590 for ; Thu, 5 Jun 2003 17:40:36 +0200 Received: from dhcp70-38.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA13478 from ; Thu, 5 Jun 2003 17:40:36 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Mime-Version: 1.0 References: <42050DF556283A4D977B111EB706320812FD69@orsmsx407.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate-2.de.ibm.com id h55FfB8m110748 Approved-By: Robert Haas Message-ID: <3EDF6474.90107@zurich.ibm.com> Date: Thu, 5 Jun 2003 17:40:36 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA03875 Hi all, The requirements draft uses non-conforming wording in section 7 point 6). I checked in RFC 2119, and the words "MAY NOT" do not exist there. So the sentence "ForCES MAY NOT impose strict reliability" should be changed to "MUST NOT". Regards, -Robert Khosravi, Hormuzd M wrote: >Hi Folks, > >Continuing from my last email......... >Here is the brief summary of IESG comments/discussion/changes in the >draft: >Chairs, IESG can provide more details on their comments... ? > >1. comment - Reliability - IESG was not satisfied with the Reliability >text, >especially in context with the Security requirement (TLS can only be >used >with reliable transport). IESG was leaning towards use of reliable >transport >which would also simplify the Security requirement. Chairs, can add more >details here ? >Discussion - This topic was most heavily discussed in the Design team >for more >than a month over several emails. I cannot go thru all the details here, >but >essentially the team came up with this text which tries to capture all >the >different thoughts of the team. >New Text - >A) The ForCES protocol will be used to transport information that >requires varying levels of reliability. By strict or robust reliability >in this requirement we mean, no losses, no corruption, no re-ordering of > >information being transported and delivery in a timely fashion. >B) Some information or payloads, such as redirected packets or packet >sampling, may not require robust reliability (can tolerate some degree >of losses). >For information of this sort, ForCES MAY NOT impose strict reliability. >C) Payloads such as configuration information, e.g. ACLs, FIB entries, >or FE capability information (described in section 7, (1))are mission >critical and must be delivered in a robust reliable fashion. Thus, for >information >of this sort, ForCES MUST either provide built-in protocol mechanisms or >use a >reliable transport protocol for achieving robust/strict reliability. >D) Some information or payloads, such as heartbeat packets that may be >used to detect loss of association between CE and FEs (see section 7, >(8)), may >prefer timeliness over reliable delivery. For information of this sort, >ForCES >MAY NOT impose strict reliability. >E) When ForCES is carried over multi-hop IP networks, it is a >requirement >that ForCES MUST use a [RFC2914]-compliant transport protocol. >F) In cases where ForCES is not running over an IP network such as an >Ethernet or cell fabric between CE and FE, then reliability still MUST >be provided >when carrying critical information of the types specified in (C) above, >either >by the underlying link/network/transport layers or by built-in protocol >mechanisms. > >2. comment - Security - TLS can only work with reliable transport which >was >the cause of some confusion to the IESG. Also, the Sec. directorate >wanted >us to have text which described all the different attacks which were >possible >on a ForCES box & come up with requirements after some analysis from >that angle. >The Design team agreed and came up with the new text. >New Text - >a) FE configuration will contain information critical to the >functioning of a network (e.g. IP Forwarding Tables). As such, it MUST >be >possible to ensure the integrity of all ForCES protocol messages and >protect >against man-in-the-middle attacks. >b) FE configuration information may also contain information derived >from business relationships (e.g. service >level agreements). Because of the confidential nature of the >information, >it MUST be possible to secure (make private) all ForCES protocol >messages. >c) In order to ensure that authorized CEs and FEs are participating in >a NE and defend against CE or FE impersonation attacks, the ForCES >architecture MUST select a means of authentication for CEs and FEs. >d) In some deployments ForCES is expected to be deployed between CEs >and FEs connected to each other inside a box >over a backplane, where physical security of the box ensures that >man-in-the-middle, snooping, and impersonation attacks are not possible. >In >such scenarios the ForCES architecture MAY rely on the physical security >of >the box to defend against these attacks and protocol mechanisms May be >turned off. >e) In the case when CEs and FEs are connected over a network, security >mechanisms MUST be specified or selected that protect the ForCES >protocol >against such attacks. Any security solution used for ForCES MUST >specify >how it deals with such attacks. > >3. comment - The IESG suggested that it was important for ForCES to >think >about DoS attacks to the protocol. The ForCES protocol could be attacked >with bogus routing packets which could lead to the protocol >disfunctioning. >Alex, could provide more details here ? >The Design team agreed and came up with the new text. >New Text - >Protection against Denial of Service Attacks (based on CPU overload or >queue overflow) >Systems utilizing the ForCES protocol can be attacked using denial of >service attacks based on CPU overload or queue overflow. >The ForCES protocol could be exploited by such attacks to >cause the CE to become unable to control the FE or appropriately >communicate >with other routers and systems. The ForCES protocol MUST therefore >provide >mechanisms for controlling FE capabilities that can be used to protect >against such attacks. FE capabilities that Must be manipulated >via ForCES include the ability to install classifiers and filters to >detect >and drop attack packets, as well as to be able to install rate limiters >that >limit the rate of packets which appear to be valid but may be part of an >attack (e.g. bogus BGP packets). > >4. comment - The IESG suggested that it was important for ForCES to talk >about IPFLOW/PSAMP functions which have been widely deployed in >networks. >The Design team agreed and came up with the new text. >New Text - >IPFLOW/PSAMP Functions >Several applications such as, Usage-based Accounting, Traffic >engineering, >require flow-based IP traffic measurements from Network Elements. >[IPFLOW] >defines architecture for IP traffic flow monitoring, measuring and >exporting. The FE model SHOULD be able to express metering functions and >flow accounting needed for exporting IP traffic flow information. >Similarly to support measurement-based applications, [PSAMP] describes a >framework to define a standard set of capabilities for network elements >to >sample subsets of packets by statistical and other methods. The FE model >SHOULD be able to express statistical packet filtering functions and >packet >information needed for supporting packet sampling applications. > >Pls do let us know if you have any comments. > >Thanks >Hormuzd > >-----Original Message----- >From: Alex Zinin [mailto:zinin@psg.com] >Sent: Wednesday, May 21, 2003 7:02 PM >To: Khosravi, Hormuzd M >Cc: Forwarding and Control Element Separation >Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > > >Folks- > > I've just updated the ID tracker to include the comments from the > IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should > have been done before.) > > There were also some comments from the ops-dir proxied by Randy, > which resulted in a discussion between the WG chairs and Pekka. I'd > like to ask the chairs to send a summary of the discussion to the > list. > > Hormuzd, to make sure the WG can follow the discussion, could you > please come up with a summary in a form similar to the following: > > Comment: ... > > Summary of discussion: ... > > Changes in document: ... > > Thanks. > > > -- 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 5 13:35:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07357 for ; Thu, 5 Jun 2003 13:35:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NycJ-0001NF-00 for forces-archive@IETF.ORG; Thu, 05 Jun 2003 13:33:35 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19NycI-0001N4-00 for forces-archive@IETF.ORG; Thu, 05 Jun 2003 13:33:34 -0400 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.009FB93B@cherry.ease.lsoft.com>; Thu, 5 Jun 2003 13:35:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44805643 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Jun 2003 13:34:51 -0400 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Jun 2003 13:34:51 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h55HWnA03197 for ; Thu, 5 Jun 2003 17:32:49 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h55HUNt27464 for ; Thu, 5 Jun 2003 17:30:23 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003060510451205244 for ; Thu, 05 Jun 2003 10:45:12 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Jun 2003 10:34:50 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [FORCES] ForCES Requirements draft updated (v-09) Thread-Index: AcMrePAUzg4Gr+UiR7Ofm/2nA722lAADhriQ X-OriginalArrivalTime: 05 Jun 2003 17:34:50.0448 (UTC) FILETIME=[C43E7500:01C32B88] Approved-By: "Khosravi, Hormuzd M" Message-ID: <42050DF556283A4D977B111EB706320812FDF8@orsmsx407.jf.intel.com> Date: Thu, 5 Jun 2003 10:34:49 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA07357 Hi Robert, Using "MAY NOT" for that sentence was suggested by Patrick, our initial wording for that sentence was "ForCES SHOULD NOT impose strict reliability". However, Patrick pointed out that "SHOULD NOT" has a "NOT RECOMMENDED" tag, which was not our intent with the text. Hence it was changed. Using "MUST NOT" also has the "NOT RECOMMENDED" tag and therefore I don't think this would bring out the correct intent for the text. Thanks Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com] Sent: Thursday, June 05, 2003 8:41 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) Hi all, The requirements draft uses non-conforming wording in section 7 point 6). I checked in RFC 2119, and the words "MAY NOT" do not exist there. So the sentence "ForCES MAY NOT impose strict reliability" should be changed to "MUST NOT". Regards, -Robert Khosravi, Hormuzd M wrote: >Hi Folks, > >Continuing from my last email......... >Here is the brief summary of IESG comments/discussion/changes in the >draft: >Chairs, IESG can provide more details on their comments... ? > >1. comment - Reliability - IESG was not satisfied with the Reliability >text, >especially in context with the Security requirement (TLS can only be >used >with reliable transport). IESG was leaning towards use of reliable >transport >which would also simplify the Security requirement. Chairs, can add more >details here ? >Discussion - This topic was most heavily discussed in the Design team >for more >than a month over several emails. I cannot go thru all the details here, >but >essentially the team came up with this text which tries to capture all >the >different thoughts of the team. >New Text - >A) The ForCES protocol will be used to transport information that >requires varying levels of reliability. By strict or robust reliability >in this requirement we mean, no losses, no corruption, no re-ordering of > >information being transported and delivery in a timely fashion. >B) Some information or payloads, such as redirected packets or packet >sampling, may not require robust reliability (can tolerate some degree >of losses). >For information of this sort, ForCES MAY NOT impose strict reliability. >C) Payloads such as configuration information, e.g. ACLs, FIB entries, >or FE capability information (described in section 7, (1))are mission >critical and must be delivered in a robust reliable fashion. Thus, for >information >of this sort, ForCES MUST either provide built-in protocol mechanisms or >use a >reliable transport protocol for achieving robust/strict reliability. >D) Some information or payloads, such as heartbeat packets that may be >used to detect loss of association between CE and FEs (see section 7, >(8)), may >prefer timeliness over reliable delivery. For information of this sort, >ForCES >MAY NOT impose strict reliability. >E) When ForCES is carried over multi-hop IP networks, it is a >requirement >that ForCES MUST use a [RFC2914]-compliant transport protocol. >F) In cases where ForCES is not running over an IP network such as an >Ethernet or cell fabric between CE and FE, then reliability still MUST >be provided >when carrying critical information of the types specified in (C) above, >either >by the underlying link/network/transport layers or by built-in protocol >mechanisms. > >2. comment - Security - TLS can only work with reliable transport which >was >the cause of some confusion to the IESG. Also, the Sec. directorate >wanted >us to have text which described all the different attacks which were >possible >on a ForCES box & come up with requirements after some analysis from >that angle. >The Design team agreed and came up with the new text. >New Text - >a) FE configuration will contain information critical to the >functioning of a network (e.g. IP Forwarding Tables). As such, it MUST >be >possible to ensure the integrity of all ForCES protocol messages and >protect >against man-in-the-middle attacks. >b) FE configuration information may also contain information derived >from business relationships (e.g. service >level agreements). Because of the confidential nature of the >information, >it MUST be possible to secure (make private) all ForCES protocol >messages. >c) In order to ensure that authorized CEs and FEs are participating in >a NE and defend against CE or FE impersonation attacks, the ForCES >architecture MUST select a means of authentication for CEs and FEs. >d) In some deployments ForCES is expected to be deployed between CEs >and FEs connected to each other inside a box >over a backplane, where physical security of the box ensures that >man-in-the-middle, snooping, and impersonation attacks are not possible. >In >such scenarios the ForCES architecture MAY rely on the physical security >of >the box to defend against these attacks and protocol mechanisms May be >turned off. >e) In the case when CEs and FEs are connected over a network, security >mechanisms MUST be specified or selected that protect the ForCES >protocol >against such attacks. Any security solution used for ForCES MUST >specify >how it deals with such attacks. > >3. comment - The IESG suggested that it was important for ForCES to >think >about DoS attacks to the protocol. The ForCES protocol could be attacked >with bogus routing packets which could lead to the protocol >disfunctioning. >Alex, could provide more details here ? >The Design team agreed and came up with the new text. >New Text - >Protection against Denial of Service Attacks (based on CPU overload or >queue overflow) >Systems utilizing the ForCES protocol can be attacked using denial of >service attacks based on CPU overload or queue overflow. >The ForCES protocol could be exploited by such attacks to >cause the CE to become unable to control the FE or appropriately >communicate >with other routers and systems. The ForCES protocol MUST therefore >provide >mechanisms for controlling FE capabilities that can be used to protect >against such attacks. FE capabilities that Must be manipulated >via ForCES include the ability to install classifiers and filters to >detect >and drop attack packets, as well as to be able to install rate limiters >that >limit the rate of packets which appear to be valid but may be part of an >attack (e.g. bogus BGP packets). > >4. comment - The IESG suggested that it was important for ForCES to talk >about IPFLOW/PSAMP functions which have been widely deployed in >networks. >The Design team agreed and came up with the new text. >New Text - >IPFLOW/PSAMP Functions >Several applications such as, Usage-based Accounting, Traffic >engineering, >require flow-based IP traffic measurements from Network Elements. >[IPFLOW] >defines architecture for IP traffic flow monitoring, measuring and >exporting. The FE model SHOULD be able to express metering functions and >flow accounting needed for exporting IP traffic flow information. >Similarly to support measurement-based applications, [PSAMP] describes a >framework to define a standard set of capabilities for network elements >to >sample subsets of packets by statistical and other methods. The FE model >SHOULD be able to express statistical packet filtering functions and >packet >information needed for supporting packet sampling applications. > >Pls do let us know if you have any comments. > >Thanks >Hormuzd > >-----Original Message----- >From: Alex Zinin [mailto:zinin@psg.com] >Sent: Wednesday, May 21, 2003 7:02 PM >To: Khosravi, Hormuzd M >Cc: Forwarding and Control Element Separation >Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > > >Folks- > > I've just updated the ID tracker to include the comments from the > IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should > have been done before.) > > There were also some comments from the ops-dir proxied by Randy, > which resulted in a discussion between the WG chairs and Pekka. I'd > like to ask the chairs to send a summary of the discussion to the > list. > > Hormuzd, to make sure the WG can follow the discussion, could you > please come up with a summary in a form similar to the following: > > Comment: ... > > Summary of discussion: ... > > Changes in document: ... > > Thanks. > > > -- 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 6 04:53:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14350 for ; Fri, 6 Jun 2003 04:53:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCws-0007T7-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 04:51:46 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19OCwr-0007T4-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 04:51:45 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00A01E02@cherry.ease.lsoft.com>; Fri, 6 Jun 2003 4:53:38 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44867921 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 6 Jun 2003 04:53:37 -0400 Received: from 194.196.100.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Jun 2003 04:53:36 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h568rIIe013220 for ; Fri, 6 Jun 2003 10:53:21 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h568qxvQ217706 for ; Fri, 6 Jun 2003 10:52:59 +0200 Received: from dhcp70-38.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22538 from ; Fri, 6 Jun 2003 10:52:59 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Mime-Version: 1.0 References: <42050DF556283A4D977B111EB706320812FDF8@orsmsx407.jf.intel.com> Content-Type: multipart/alternative; boundary="------------060001030005040800020302" Approved-By: Robert Haas Message-ID: <3EE0566B.6010204@zurich.ibm.com> Date: Fri, 6 Jun 2003 10:52:59 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --------------060001030005040800020302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate-5.de.ibm.com id h568rIIe013220 Content-Transfer-Encoding: quoted-printable Hi Hormuzd, Khosravi, Hormuzd M wrote: >Hi Robert, > >Using "MAY NOT" for that sentence was suggested by Patrick, >our initial wording for that sentence was=20 >"ForCES SHOULD NOT impose strict reliability". >However, Patrick pointed out that "SHOULD NOT" has a >"NOT RECOMMENDED" tag, which was not our intent with the text. >Hence it was changed. Using "MUST NOT" also has the >"NOT RECOMMENDED" tag and therefore I don't think this >would bring out the correct intent for the text. > "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the=20 excerpt from RFC 2119. This is why I think it is more appropriate to use "MUST NOT" instead of=20 "MAY NOT". The meaning remains as intended and there is no room for=20 confusion: "ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose str= ict reliability" means that it is prohibited that ForCES imposes strict reliability. Or=20 do you mean sth else ? Thanks, -Robert 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. > >Thanks >Hormuzd >-----Original Message----- >From: Robert Haas [mailto:rha@zurich.ibm.com]=20 >Sent: Thursday, June 05, 2003 8:41 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > > >Hi all, >The requirements draft uses non-conforming wording in section 7 point 6). >I checked in RFC 2119, and the words "MAY NOT" do not exist there. >So the sentence "ForCES MAY NOT impose strict reliability" should be=20 >changed to "MUST NOT". > >Regards, >-Robert > > >Khosravi, Hormuzd M wrote: > > =20 > >>Hi Folks, >> >>Continuing from my last email......... >>Here is the brief summary of IESG comments/discussion/changes in the >>draft: >>Chairs, IESG can provide more details on their comments... ? >> >>1. comment - Reliability - IESG was not satisfied with the Reliability >>text, >>especially in context with the Security requirement (TLS can only be >>used >>with reliable transport). IESG was leaning towards use of reliable >>transport >>which would also simplify the Security requirement. Chairs, can add mor= e >>details here ? >>Discussion - This topic was most heavily discussed in the Design team >>for more >>than a month over several emails. I cannot go thru all the details here= , >>but >>essentially the team came up with this text which tries to capture all >>the >>different thoughts of the team. >>New Text - >>A) The ForCES protocol will be used to transport information that >>requires varying levels of reliability. By strict or robust reliability >>in this requirement we mean, no losses, no corruption, no re-ordering o= f >> >>information being transported and delivery in a timely fashion. >>B) Some information or payloads, such as redirected packets or packet >>sampling, may not require robust reliability (can tolerate some degree >>of losses). >>For information of this sort, ForCES MAY NOT impose strict reliability. >>C) Payloads such as configuration information, e.g. ACLs, FIB entries, >>or FE capability information (described in section 7, (1))are mission >>critical and must be delivered in a robust reliable fashion. Thus, for >>information >>of this sort, ForCES MUST either provide built-in protocol mechanisms o= r >>use a >>reliable transport protocol for achieving robust/strict reliability. >>D) Some information or payloads, such as heartbeat packets that may be >>used to detect loss of association between CE and FEs (see section 7, >>(8)), may >>prefer timeliness over reliable delivery. For information of this sort, >>ForCES >>MAY NOT impose strict reliability. >>E) When ForCES is carried over multi-hop IP networks, it is a >>requirement >>that ForCES MUST use a [RFC2914]-compliant transport protocol. >>F) In cases where ForCES is not running over an IP network such as an >>Ethernet or cell fabric between CE and FE, then reliability still MUST >>be provided >>when carrying critical information of the types specified in (C) above, >>either >>by the underlying link/network/transport layers or by built-in protocol >>mechanisms. >> >>2. comment - Security - TLS can only work with reliable transport which >>was >>the cause of some confusion to the IESG. Also, the Sec. directorate >>wanted >>us to have text which described all the different attacks which were >>possible >>on a ForCES box & come up with requirements after some analysis from >>that angle. >>The Design team agreed and came up with the new text. >>New Text - >>a) FE configuration will contain information critical to the >>functioning of a network (e.g. IP Forwarding Tables). As such, it MUST >>be >>possible to ensure the integrity of all ForCES protocol messages and >>protect >>against man-in-the-middle attacks. >>b) FE configuration information may also contain information derived >> =20 >> >>from business relationships (e.g. service=20 > =20 > >>level agreements). Because of the confidential nature of the >>information,=20 >>it MUST be possible to secure (make private) all ForCES protocol >>messages. >>c) In order to ensure that authorized CEs and FEs are participating in >>a NE and defend against CE or FE impersonation attacks, the ForCES >>architecture MUST select a means of authentication for CEs and FEs. >>d) In some deployments ForCES is expected to be deployed between CEs >>and FEs connected to each other inside a box=20 >>over a backplane, where physical security of the box ensures that >>man-in-the-middle, snooping, and impersonation attacks are not possible. >>In >>such scenarios the ForCES architecture MAY rely on the physical securit= y >>of >>the box to defend against these attacks and protocol mechanisms May be=20 >>turned off. >>e) In the case when CEs and FEs are connected over a network, security >>mechanisms MUST be specified or selected that protect the ForCES >>protocol >>against such attacks. Any security solution used for ForCES MUST >>specify >>how it deals with such attacks. >> >>3. comment - The IESG suggested that it was important for ForCES to >>think >>about DoS attacks to the protocol. The ForCES protocol could be attacke= d >>with bogus routing packets which could lead to the protocol >>disfunctioning. >>Alex, could provide more details here ? >>The Design team agreed and came up with the new text. >>New Text -=20 >>Protection against Denial of Service Attacks (based on CPU overload or >>queue overflow) >>Systems utilizing the ForCES protocol can be attacked using denial of >>service attacks based on CPU overload or queue overflow. =20 >>The ForCES protocol could be exploited by such attacks to >>cause the CE to become unable to control the FE or appropriately >>communicate >>with other routers and systems. The ForCES protocol MUST therefore >>provide >>mechanisms for controlling FE capabilities that can be used to protect >>against such attacks. FE capabilities that Must be manipulated >>via ForCES include the ability to install classifiers and filters to >>detect >>and drop attack packets, as well as to be able to install rate limiters >>that >>limit the rate of packets which appear to be valid but may be part of a= n >>attack (e.g. bogus BGP packets). >> >>4. comment - The IESG suggested that it was important for ForCES to tal= k >>about IPFLOW/PSAMP functions which have been widely deployed in >>networks. >>The Design team agreed and came up with the new text. >>New Text -=20 >>IPFLOW/PSAMP Functions >>Several applications such as, Usage-based Accounting, Traffic >>engineering, >>require flow-based IP traffic measurements from Network Elements. >>[IPFLOW] >>defines architecture for IP traffic flow monitoring, measuring and >>exporting. The FE model SHOULD be able to express metering functions an= d >>flow accounting needed for exporting IP traffic flow information. >>Similarly to support measurement-based applications, [PSAMP] describes = a >>framework to define a standard set of capabilities for network elements >>to >>sample subsets of packets by statistical and other methods. The FE mode= l >>SHOULD be able to express statistical packet filtering functions and >>packet >>information needed for supporting packet sampling applications. >> >>Pls do let us know if you have any comments. >> >>Thanks >>Hormuzd >> >>-----Original Message----- >>From: Alex Zinin [mailto:zinin@psg.com]=20 >>Sent: Wednesday, May 21, 2003 7:02 PM >>To: Khosravi, Hormuzd M >>Cc: Forwarding and Control Element Separation >>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) >> >> >>Folks- >> >>I've just updated the ID tracker to include the comments from the >>IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should >>have been done before.) >> >>There were also some comments from the ops-dir proxied by Randy, >>which resulted in a discussion between the WG chairs and Pekka. I'd >>like to ask the chairs to send a summary of the discussion to the >>list. >> >>Hormuzd, to make sure the WG can follow the discussion, could you >>please come up with a summary in a form similar to the following: >> >> Comment: ... >> >> Summary of discussion: ... >> >> Changes in document: ... >> >>Thanks. >> >>=20 >> >> =20 >> > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------060001030005040800020302 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hormuzd,

Khosravi, Hormuzd M wrote:
Hi Robert,

Using "MAY NOT" for that sentence was suggested by Patrick,
our initial wording for that sentence was
"ForCES SHOULD NOT impose strict reliability".
However, Patrick pointed out that "SHOULD NOT" has a
"NOT RECOMMENDED" tag, which was not our intent with the text.
Hence it was changed. Using "MUST NOT" also has the
"NOT RECOMMENDED" tag and therefore I don't think this
would bring out the correct intent for the text.
"MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the excerpt from RFC 2119.

This is why I think it is more appropriate to use "MUST NOT" instead of "MAY NOT". The meaning remains as intended and there is no room for confusion: 
"ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose strict reliability"
means that it is prohibited that ForCES imposes strict reliability. Or do you mean sth else ?

Thanks,
-Robert


1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.



Thanks
Hormuzd
-----Original Message-----
From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, June 05, 2003 8:41 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)


Hi all,
The requirements draft uses non-conforming wording in section 7 point 6).
I checked in RFC 2119, and the words "MAY NOT" do not exist there.
So the sentence "ForCES MAY NOT impose strict reliability" should be
changed to "MUST NOT".

Regards,
-Robert


Khosravi, Hormuzd M wrote:

  
Hi Folks,

Continuing from my last email.........
Here is the brief summary of IESG comments/discussion/changes in the
draft:
Chairs, IESG can provide more details on their comments... ?

1. comment - Reliability - IESG was not satisfied with the Reliability
text,
especially in context with the Security requirement (TLS can only be
used
with reliable transport). IESG was leaning towards use of reliable
transport
which would also simplify the Security requirement. Chairs, can add more
details here ?
Discussion - This topic was most heavily discussed in the Design team
for more
than a month over several emails. I cannot go thru all the details here,
but
essentially the team came up with this text which tries to capture all
the
different thoughts of the team.
New Text -
A) The ForCES protocol will be used to transport information that
requires varying levels of reliability. By strict or robust reliability
in this requirement we mean, no losses, no corruption, no re-ordering of

information being transported and delivery in a timely fashion.
B) Some information or payloads, such as redirected packets or packet
sampling, may not require robust reliability (can tolerate some degree
of losses).
For information of this sort, ForCES MAY NOT impose strict reliability.
C) Payloads such as configuration information, e.g. ACLs, FIB entries,
or FE capability information (described in section 7, (1))are mission
critical and must be delivered in a robust reliable fashion. Thus, for
information
of this sort, ForCES MUST either provide built-in protocol mechanisms or
use a
reliable transport protocol for achieving robust/strict reliability.
D) Some information or payloads, such as heartbeat packets that may be
used to detect loss of association between CE and FEs (see section 7,
(8)), may
prefer timeliness over reliable delivery. For information of this sort,
ForCES
MAY NOT impose strict reliability.
E) When ForCES is carried over multi-hop IP networks, it is a
requirement
that ForCES MUST use a [RFC2914]-compliant transport protocol.
F) In cases where ForCES is not running over an IP network such as an
Ethernet or cell fabric between CE and FE, then reliability still MUST
be provided
when carrying critical information of the types specified in (C) above,
either
by the underlying link/network/transport layers or by built-in protocol
mechanisms.

2. comment - Security - TLS can only work with reliable transport which
was
the cause of some confusion to the IESG. Also, the Sec. directorate
wanted
us to have text which described all the different attacks which were
possible
on a ForCES box & come up with requirements after some analysis from
that angle.
The Design team agreed and came up with the new text.
New Text -
a) FE configuration will contain information critical to the
functioning of a network (e.g. IP Forwarding Tables). As such, it MUST
be
possible to ensure the integrity of all ForCES protocol messages and
protect
against man-in-the-middle attacks.
b) FE configuration information may also contain information derived
    
>from business relationships (e.g. service
  
level agreements). Because of the confidential nature of the
information,
it MUST be possible to secure (make private) all ForCES protocol
messages.
c) In order to ensure that authorized CEs and FEs are participating in
a NE and defend against CE or FE impersonation attacks, the ForCES
architecture MUST select a means of authentication for CEs and FEs.
d) In some deployments ForCES is expected to be deployed between CEs
and FEs connected to each other inside a box
over a backplane, where physical security of the box ensures that
man-in-the-middle, snooping, and impersonation attacks are not possible.
In
such scenarios the ForCES architecture MAY rely on the physical security
of
the box to defend against these attacks and protocol mechanisms May be
turned off.
e) In the case when CEs and FEs are connected over a network, security
mechanisms MUST be specified or selected that protect the ForCES
protocol
against such attacks.  Any security solution used for ForCES MUST
specify
how it deals with such attacks.

3. comment - The IESG suggested that it was important for ForCES to
think
about DoS attacks to the protocol. The ForCES protocol could be attacked
with bogus routing packets which could lead to the protocol
disfunctioning.
Alex, could provide more details here ?
The Design team agreed and came up with the new text.
New Text -
Protection against Denial of Service Attacks (based on CPU overload or
queue overflow)
Systems utilizing the ForCES protocol can be attacked using denial of
service attacks based on CPU overload or queue overflow.
The ForCES protocol could be exploited by such attacks to
cause the CE to become unable to control the FE or appropriately
communicate
with other routers and systems.  The ForCES protocol MUST therefore
provide
mechanisms for controlling FE capabilities that can be used to protect
against such attacks. FE capabilities that Must be manipulated
via ForCES include the ability to install classifiers and filters to
detect
and drop attack packets, as well as to be able to install rate limiters
that
limit the rate of packets which appear to be valid but may be part of an
attack (e.g. bogus BGP packets).

4. comment - The IESG suggested that it was important for ForCES to talk
about IPFLOW/PSAMP functions which have been widely deployed in
networks.
The Design team agreed and came up with the new text.
New Text -
IPFLOW/PSAMP Functions
Several applications such as, Usage-based Accounting, Traffic
engineering,
require flow-based IP traffic measurements from Network Elements.
[IPFLOW]
defines architecture for IP traffic flow monitoring, measuring and
exporting. The FE model SHOULD be able to express metering functions and
flow accounting needed for exporting IP traffic flow information.
Similarly to support measurement-based applications, [PSAMP] describes a
framework to define a standard set of capabilities for network elements
to
sample subsets of packets by statistical and other methods. The FE model
SHOULD be able to express statistical packet filtering functions and
packet
information needed for supporting packet sampling applications.

Pls do let us know if you have any comments.

Thanks
Hormuzd

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Wednesday, May 21, 2003 7:02 PM
To: Khosravi, Hormuzd M
Cc: Forwarding and Control Element Separation
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)


Folks-

I've just updated the ID tracker to include the comments from the
IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should
have been done before.)

There were also some comments from the ops-dir proxied by Randy,
which resulted in a discussion between the WG chairs and Pekka. I'd
like to ask the chairs to send a summary of the discussion to the
list.

Hormuzd, to make sure the WG can follow the discussion, could you
please come up with a summary in a form similar to the following:

  Comment: ...

    Summary of discussion: ...

    Changes in document: ...

Thanks.



    

  

--
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

--------------060001030005040800020302-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 6 16:36:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11690 for ; Fri, 6 Jun 2003 16:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONuu-0006Fa-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 16:34:28 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19ONus-0006FW-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 16:34:27 -0400 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.00A03287@cherry.ease.lsoft.com>; Fri, 6 Jun 2003 16:36:20 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44835234 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 6 Jun 2003 16:36:18 -0400 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Jun 2003 16:36:18 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h56KSPC09391 for ; Fri, 6 Jun 2003 20:28:25 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h56KTcx09744 for ; Fri, 6 Jun 2003 20:29:39 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003060613361724337 for ; Fri, 06 Jun 2003 13:36:17 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 13:36:17 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C6B.479CA7D4" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [FORCES] ForCES Requirements draft updated (v-09) Thread-Index: AcMsCSOJazko+shGSrykzXTvs+bEigAX0yOQ X-OriginalArrivalTime: 06 Jun 2003 20:36:17.0374 (UTC) FILETIME=[47C547E0:01C32C6B] Approved-By: "Khosravi, Hormuzd M" Message-ID: <42050DF556283A4D977B111EB706320812FE09@orsmsx407.jf.intel.com> Date: Fri, 6 Jun 2003 13:36:17 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C32C6B.479CA7D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, =20 The intent of the text is NOT "ForCES prohibits strict reliability for = that case" which is why Patrick suggested using MAY NOT for the wording. = Using "MUST NOT" changes the meaning of the text to what you have = stated, which is not the intent. If using MAY NOT was such a big issue, = I am sure that the chairs would have pointed that out earlier. However, = if the text must be changed to remove "MAY NOT", I would suggest the = following wording..."ForCES MUST NOT be restricted to strict = reliability" which would bring out the correct intent of the text i.e. = both strictly reliable & non-strictly reliable are fine for that case. =20 Thanks Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Friday, June 06, 2003 1:53 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) =09 =09 Hi Hormuzd, =09 Khosravi, Hormuzd M wrote: =09 Hi Robert, =09 Using "MAY NOT" for that sentence was suggested by Patrick, our initial wording for that sentence was "ForCES SHOULD NOT impose strict reliability". However, Patrick pointed out that "SHOULD NOT" has a "NOT RECOMMENDED" tag, which was not our intent with the text. Hence it was changed. Using "MUST NOT" also has the "NOT RECOMMENDED" tag and therefore I don't think this would bring out the correct intent for the text. "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the = excerpt from RFC 2119. =09 This is why I think it is more appropriate to use "MUST NOT" instead of = "MAY NOT". The meaning remains as intended and there is no room for = confusion:=20 "ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose = strict reliability" means that it is prohibited that ForCES imposes strict reliability. Or = do you mean sth else ? =09 Thanks, -Robert =09 =09 =09 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. =09 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. =09 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. =09 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. =09 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. =09 Thanks Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com] Sent: Thursday, June 05, 2003 8:41 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) =09 =09 Hi all, The requirements draft uses non-conforming wording in section 7 point = 6). I checked in RFC 2119, and the words "MAY NOT" do not exist there. So the sentence "ForCES MAY NOT impose strict reliability" should be changed to "MUST NOT". =09 Regards, -Robert =09 =09 Khosravi, Hormuzd M wrote: =09 =20 Hi Folks, =09 Continuing from my last email......... Here is the brief summary of IESG comments/discussion/changes in the draft: Chairs, IESG can provide more details on their comments... ? =09 1. comment - Reliability - IESG was not satisfied with the = Reliability text, especially in context with the Security requirement (TLS can only be used with reliable transport). IESG was leaning towards use of reliable transport which would also simplify the Security requirement. Chairs, can add = more details here ? Discussion - This topic was most heavily discussed in the Design team for more than a month over several emails. I cannot go thru all the details = here, but essentially the team came up with this text which tries to capture = all the different thoughts of the team. New Text - A) The ForCES protocol will be used to transport information that requires varying levels of reliability. By strict or robust = reliability in this requirement we mean, no losses, no corruption, no re-ordering = of =09 information being transported and delivery in a timely fashion. B) Some information or payloads, such as redirected packets or packet sampling, may not require robust reliability (can tolerate some = degree of losses). For information of this sort, ForCES MAY NOT impose strict = reliability. C) Payloads such as configuration information, e.g. ACLs, FIB = entries, or FE capability information (described in section 7, (1))are mission critical and must be delivered in a robust reliable fashion. Thus, = for information of this sort, ForCES MUST either provide built-in protocol mechanisms = or use a reliable transport protocol for achieving robust/strict reliability. D) Some information or payloads, such as heartbeat packets that may = be used to detect loss of association between CE and FEs (see section 7, (8)), may prefer timeliness over reliable delivery. For information of this = sort, ForCES MAY NOT impose strict reliability. E) When ForCES is carried over multi-hop IP networks, it is a requirement that ForCES MUST use a [RFC2914]-compliant transport protocol. F) In cases where ForCES is not running over an IP network such as an Ethernet or cell fabric between CE and FE, then reliability still = MUST be provided when carrying critical information of the types specified in (C) = above, either by the underlying link/network/transport layers or by built-in = protocol mechanisms. =09 2. comment - Security - TLS can only work with reliable transport = which was the cause of some confusion to the IESG. Also, the Sec. directorate wanted us to have text which described all the different attacks which were possible on a ForCES box & come up with requirements after some analysis from that angle. The Design team agreed and came up with the new text. New Text - a) FE configuration will contain information critical to the functioning of a network (e.g. IP Forwarding Tables). As such, it = MUST be possible to ensure the integrity of all ForCES protocol messages and protect against man-in-the-middle attacks. b) FE configuration information may also contain information derived =20 >from business relationships (e.g. service =20 level agreements). Because of the confidential nature of the information, it MUST be possible to secure (make private) all ForCES protocol messages. c) In order to ensure that authorized CEs and FEs are participating = in a NE and defend against CE or FE impersonation attacks, the ForCES architecture MUST select a means of authentication for CEs and FEs. d) In some deployments ForCES is expected to be deployed between CEs and FEs connected to each other inside a box over a backplane, where physical security of the box ensures that man-in-the-middle, snooping, and impersonation attacks are not = possible. In such scenarios the ForCES architecture MAY rely on the physical = security of the box to defend against these attacks and protocol mechanisms May = be turned off. e) In the case when CEs and FEs are connected over a network, = security mechanisms MUST be specified or selected that protect the ForCES protocol against such attacks. Any security solution used for ForCES MUST specify how it deals with such attacks. =09 3. comment - The IESG suggested that it was important for ForCES to think about DoS attacks to the protocol. The ForCES protocol could be = attacked with bogus routing packets which could lead to the protocol disfunctioning. Alex, could provide more details here ? The Design team agreed and came up with the new text. New Text - Protection against Denial of Service Attacks (based on CPU overload = or queue overflow) Systems utilizing the ForCES protocol can be attacked using denial of service attacks based on CPU overload or queue overflow. The ForCES protocol could be exploited by such attacks to cause the CE to become unable to control the FE or appropriately communicate with other routers and systems. The ForCES protocol MUST therefore provide mechanisms for controlling FE capabilities that can be used to = protect against such attacks. FE capabilities that Must be manipulated via ForCES include the ability to install classifiers and filters to detect and drop attack packets, as well as to be able to install rate = limiters that limit the rate of packets which appear to be valid but may be part of = an attack (e.g. bogus BGP packets). =09 4. comment - The IESG suggested that it was important for ForCES to = talk about IPFLOW/PSAMP functions which have been widely deployed in networks. The Design team agreed and came up with the new text. New Text - IPFLOW/PSAMP Functions Several applications such as, Usage-based Accounting, Traffic engineering, require flow-based IP traffic measurements from Network Elements. [IPFLOW] defines architecture for IP traffic flow monitoring, measuring and exporting. The FE model SHOULD be able to express metering functions = and flow accounting needed for exporting IP traffic flow information. Similarly to support measurement-based applications, [PSAMP] = describes a framework to define a standard set of capabilities for network = elements to sample subsets of packets by statistical and other methods. The FE = model SHOULD be able to express statistical packet filtering functions and packet information needed for supporting packet sampling applications. =09 Pls do let us know if you have any comments. =09 Thanks Hormuzd =09 -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, May 21, 2003 7:02 PM To: Khosravi, Hormuzd M Cc: Forwarding and Control Element Separation Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) =09 =09 Folks- =09 I've just updated the ID tracker to include the comments from the IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should have been done before.) =09 There were also some comments from the ops-dir proxied by Randy, which resulted in a discussion between the WG chairs and Pekka. I'd like to ask the chairs to send a summary of the discussion to the list. =09 Hormuzd, to make sure the WG can follow the discussion, could you please come up with a summary in a form similar to the following: =09 Comment: ... =09 Summary of discussion: ... =09 Changes in document: ... =09 Thanks. =09 =09 =09 =20 =09 =20 -- Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C32C6B.479CA7D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Robert,
 
The=20 intent of the text is NOT "ForCES prohibits strict reliability for = that=20 case" which is why Patrick suggested using MAY NOT for the wording. = Using "MUST=20 NOT" changes the meaning of the text to what you have stated, which is = not the=20 intent. If using MAY NOT was such a big issue, I am sure that the = chairs=20 would have pointed that out earlier. However, if the text must be = changed to=20 remove "MAY NOT", I would suggest the following wording..."ForCES MUST = NOT be=20 restricted to strict reliability" which would bring out the correct = intent of=20 the text i.e. both strictly reliable & non-strictly reliable are = fine for=20 that case.
 
Thanks
Hormuzd
-----Original Message-----
From: = Robert Haas=20 [mailto:rha@zurich.ibm.com]
Sent: Friday, June 06, 2003 = 1:53=20 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: = [FORCES]=20 ForCES Requirements draft updated (v-09)

Hi=20 Hormuzd,

Khosravi, Hormuzd M wrote:
Hi Robert,

Using "MAY NOT" for that sentence was suggested by Patrick,
our initial wording for that sentence was
"ForCES SHOULD NOT impose strict reliability".
However, Patrick pointed out that "SHOULD NOT" has a
"NOT RECOMMENDED" tag, which was not our intent with the text.
Hence it was changed. Using "MUST NOT" also has the
"NOT RECOMMENDED" tag and therefore I don't think this
would bring out the correct intent for the text.
"MUST = NOT"=20 does not have the "NOT RECOMMENDED" tag. See below the excerpt from = RFC=20 2119.

This is why I think it is more appropriate to use "MUST = NOT"=20 instead of "MAY NOT". The meaning remains as intended and there is no = room for=20 confusion: 
"ForCES MAY NOT impose strict reliability" =
-> "ForCES MUST NOT impose strict reliability"
means=20 that it is prohibited that ForCES imposes strict reliability. Or do = you mean=20 sth else ?

Thanks,
-Robert


1. MUST   This =
word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.


Thanks
Hormuzd
-----Original Message-----
From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, June 05, 2003 8:41 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)


Hi all,
The requirements draft uses non-conforming wording in section 7 point =
6).
I checked in RFC 2119, and the words "MAY NOT" do not exist there.
So the sentence "ForCES MAY NOT impose strict reliability" should be
changed to "MUST NOT".

Regards,
-Robert


Khosravi, Hormuzd M wrote:

  
Hi Folks,

Continuing from my last email.........
Here is the brief summary of IESG comments/discussion/changes in the
draft:
Chairs, IESG can provide more details on their comments... ?

1. comment - Reliability - IESG was not satisfied with the Reliability
text,
especially in context with the Security requirement (TLS can only be
used
with reliable transport). IESG was leaning towards use of reliable
transport
which would also simplify the Security requirement. Chairs, can add more
details here ?
Discussion - This topic was most heavily discussed in the Design team
for more
than a month over several emails. I cannot go thru all the details here,
but
essentially the team came up with this text which tries to capture all
the
different thoughts of the team.
New Text -
A) The ForCES protocol will be used to transport information that
requires varying levels of reliability. By strict or robust reliability
in this requirement we mean, no losses, no corruption, no re-ordering of

information being transported and delivery in a timely fashion.
B) Some information or payloads, such as redirected packets or packet
sampling, may not require robust reliability (can tolerate some degree
of losses).
For information of this sort, ForCES MAY NOT impose strict reliability.
C) Payloads such as configuration information, e.g. ACLs, FIB entries,
or FE capability information (described in section 7, (1))are mission
critical and must be delivered in a robust reliable fashion. Thus, for
information
of this sort, ForCES MUST either provide built-in protocol mechanisms or
use a
reliable transport protocol for achieving robust/strict reliability.
D) Some information or payloads, such as heartbeat packets that may be
used to detect loss of association between CE and FEs (see section 7,
(8)), may
prefer timeliness over reliable delivery. For information of this sort,
ForCES
MAY NOT impose strict reliability.
E) When ForCES is carried over multi-hop IP networks, it is a
requirement
that ForCES MUST use a [RFC2914]-compliant transport protocol.
F) In cases where ForCES is not running over an IP network such as an
Ethernet or cell fabric between CE and FE, then reliability still MUST
be provided
when carrying critical information of the types specified in (C) above,
either
by the underlying link/network/transport layers or by built-in protocol
mechanisms.

2. comment - Security - TLS can only work with reliable transport which
was
the cause of some confusion to the IESG. Also, the Sec. directorate
wanted
us to have text which described all the different attacks which were
possible
on a ForCES box & come up with requirements after some analysis from
that angle.
The Design team agreed and came up with the new text.
New Text -
a) FE configuration will contain information critical to the
functioning of a network (e.g. IP Forwarding Tables). As such, it MUST
be
possible to ensure the integrity of all ForCES protocol messages and
protect
against man-in-the-middle attacks.
b) FE configuration information may also contain information derived
    
>from business =
relationships (e.g. service
  
level agreements). Because =
of the confidential nature of the
information,
it MUST be possible to secure (make private) all ForCES protocol
messages.
c) In order to ensure that authorized CEs and FEs are participating in
a NE and defend against CE or FE impersonation attacks, the ForCES
architecture MUST select a means of authentication for CEs and FEs.
d) In some deployments ForCES is expected to be deployed between CEs
and FEs connected to each other inside a box
over a backplane, where physical security of the box ensures that
man-in-the-middle, snooping, and impersonation attacks are not possible.
In
such scenarios the ForCES architecture MAY rely on the physical security
of
the box to defend against these attacks and protocol mechanisms May be
turned off.
e) In the case when CEs and FEs are connected over a network, security
mechanisms MUST be specified or selected that protect the ForCES
protocol
against such attacks.  Any security solution used for ForCES MUST
specify
how it deals with such attacks.

3. comment - The IESG suggested that it was important for ForCES to
think
about DoS attacks to the protocol. The ForCES protocol could be attacked
with bogus routing packets which could lead to the protocol
disfunctioning.
Alex, could provide more details here ?
The Design team agreed and came up with the new text.
New Text -
Protection against Denial of Service Attacks (based on CPU overload or
queue overflow)
Systems utilizing the ForCES protocol can be attacked using denial of
service attacks based on CPU overload or queue overflow.
The ForCES protocol could be exploited by such attacks to
cause the CE to become unable to control the FE or appropriately
communicate
with other routers and systems.  The ForCES protocol MUST therefore
provide
mechanisms for controlling FE capabilities that can be used to protect
against such attacks. FE capabilities that Must be manipulated
via ForCES include the ability to install classifiers and filters to
detect
and drop attack packets, as well as to be able to install rate limiters
that
limit the rate of packets which appear to be valid but may be part of an
attack (e.g. bogus BGP packets).

4. comment - The IESG suggested that it was important for ForCES to talk
about IPFLOW/PSAMP functions which have been widely deployed in
networks.
The Design team agreed and came up with the new text.
New Text -
IPFLOW/PSAMP Functions
Several applications such as, Usage-based Accounting, Traffic
engineering,
require flow-based IP traffic measurements from Network Elements.
[IPFLOW]
defines architecture for IP traffic flow monitoring, measuring and
exporting. The FE model SHOULD be able to express metering functions and
flow accounting needed for exporting IP traffic flow information.
Similarly to support measurement-based applications, [PSAMP] describes a
framework to define a standard set of capabilities for network elements
to
sample subsets of packets by statistical and other methods. The FE model
SHOULD be able to express statistical packet filtering functions and
packet
information needed for supporting packet sampling applications.

Pls do let us know if you have any comments.

Thanks
Hormuzd

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Wednesday, May 21, 2003 7:02 PM
To: Khosravi, Hormuzd M
Cc: Forwarding and Control Element Separation
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)


Folks-

I've just updated the ID tracker to include the comments from the
IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should
have been done before.)

There were also some comments from the ops-dir proxied by Randy,
which resulted in a discussion between the WG chairs and Pekka. I'd
like to ask the chairs to send a summary of the discussion to the
list.

Hormuzd, to make sure the WG can follow the discussion, could you
please come up with a summary in a form similar to the following:

  Comment: ...

    Summary of discussion: ...

    Changes in document: ...

Thanks.



    

  

--
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

=00 ------_=_NextPart_001_01C32C6B.479CA7D4-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 6 17:07:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12935 for ; Fri, 6 Jun 2003 17:07:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OOOY-0006XA-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 17:05:06 -0400 Received: from lime.ease.lsoft.com ([209.119.0.43]) by ietf-mx with esmtp (Exim 4.12) id 19OOOW-0006X7-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 17:05:05 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0000F176@LIME.ease.lsoft.com>; Fri, 6 Jun 2003 17:04:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44836923 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 6 Jun 2003 17:06:56 -0400 Received: from 194.196.100.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Jun 2003 17:06:56 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h56L6ssn101812 for ; Fri, 6 Jun 2003 23:06:54 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h56L6sBP137686 for ; Fri, 6 Jun 2003 23:06:54 +0200 Received: from [9.164.17.145] by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA112006 from ; Fri, 6 Jun 2003 23:06:53 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en Mime-Version: 1.0 References: <42050DF556283A4D977B111EB706320812FE09@orsmsx407.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate-3.de.ibm.com id h56L6ssn101812 Approved-By: Patrick Droz Message-ID: <3EE1026C.7030804@zurich.ibm.com> Date: Fri, 6 Jun 2003 23:06:52 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12935 Hormuzd, I did not suggest the MAY NOT. What I said is that the SHOULD NOT phrasing is a non recommended term. I also asked the DT if they are happy with the new wording but nobody responded to it. My take is we should use terms that are approved and do have a very clear meaning. Therefore, I ask again what is the exact meaning of that particular phrase. What is the protocol exactly expecting to use? Thanks, Patrick Khosravi, Hormuzd M wrote: > Hi Robert, > > The intent of the text is NOT "ForCES prohibits strict reliability for > that case" which is why Patrick suggested using MAY NOT for the wording. > Using "MUST NOT" changes the meaning of the text to what you have > stated, which is not the intent. If using MAY NOT was such a big issue, > I am sure that the chairs would have pointed that out earlier. However, > if the text must be changed to remove "MAY NOT", I would suggest the > following wording..."ForCES MUST NOT be restricted to strict > reliability" which would bring out the correct intent of the text i.e. > both strictly reliable & non-strictly reliable are fine for that case. > > Thanks > Hormuzd > > -----Original Message----- > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, June 06, 2003 1:53 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > > Hi Hormuzd, > > Khosravi, Hormuzd M wrote: > >>Hi Robert, >> >>Using "MAY NOT" for that sentence was suggested by Patrick, >>our initial wording for that sentence was >>"ForCES SHOULD NOT impose strict reliability". >>However, Patrick pointed out that "SHOULD NOT" has a >>"NOT RECOMMENDED" tag, which was not our intent with the text. >>Hence it was changed. Using "MUST NOT" also has the >>"NOT RECOMMENDED" tag and therefore I don't think this >>would bring out the correct intent for the text. > > "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the > excerpt from RFC 2119. > > This is why I think it is more appropriate to use "MUST NOT" instead > of "MAY NOT". The meaning remains as intended and there is no room > for confusion: > > "ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose strict reliability" > > means that it is prohibited that ForCES imposes strict reliability. > Or do you mean sth else ? > > Thanks, > -Robert > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > definition is an absolute prohibition of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. > > > >>Thanks >>Hormuzd >>-----Original Message----- >>From: Robert Haas [mailto:rha@zurich.ibm.com] >>Sent: Thursday, June 05, 2003 8:41 AM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) >> >> >>Hi all, >>The requirements draft uses non-conforming wording in section 7 point 6). >>I checked in RFC 2119, and the words "MAY NOT" do not exist there. >>So the sentence "ForCES MAY NOT impose strict reliability" should be >>changed to "MUST NOT". >> >>Regards, >>-Robert >> >> >>Khosravi, Hormuzd M wrote: >> >> >> >>>Hi Folks, >>> >>>Continuing from my last email......... >>>Here is the brief summary of IESG comments/discussion/changes in the >>>draft: >>>Chairs, IESG can provide more details on their comments... ? >>> >>>1. comment - Reliability - IESG was not satisfied with the Reliability >>>text, >>>especially in context with the Security requirement (TLS can only be >>>used >>>with reliable transport). IESG was leaning towards use of reliable >>>transport >>>which would also simplify the Security requirement. Chairs, can add more >>>details here ? >>>Discussion - This topic was most heavily discussed in the Design team >>>for more >>>than a month over several emails. I cannot go thru all the details here, >>>but >>>essentially the team came up with this text which tries to capture all >>>the >>>different thoughts of the team. >>>New Text - >>>A) The ForCES protocol will be used to transport information that >>>requires varying levels of reliability. By strict or robust reliability >>>in this requirement we mean, no losses, no corruption, no re-ordering of >>> >>>information being transported and delivery in a timely fashion. >>>B) Some information or payloads, such as redirected packets or packet >>>sampling, may not require robust reliability (can tolerate some degree >>>of losses). >>>For information of this sort, ForCES MAY NOT impose strict reliability. >>>C) Payloads such as configuration information, e.g. ACLs, FIB entries, >>>or FE capability information (described in section 7, (1))are mission >>>critical and must be delivered in a robust reliable fashion. Thus, for >>>information >>>of this sort, ForCES MUST either provide built-in protocol mechanisms or >>>use a >>>reliable transport protocol for achieving robust/strict reliability. >>>D) Some information or payloads, such as heartbeat packets that may be >>>used to detect loss of association between CE and FEs (see section 7, >>>(8)), may >>>prefer timeliness over reliable delivery. For information of this sort, >>>ForCES >>>MAY NOT impose strict reliability. >>>E) When ForCES is carried over multi-hop IP networks, it is a >>>requirement >>>that ForCES MUST use a [RFC2914]-compliant transport protocol. >>>F) In cases where ForCES is not running over an IP network such as an >>>Ethernet or cell fabric between CE and FE, then reliability still MUST >>>be provided >>>when carrying critical information of the types specified in (C) above, >>>either >>>by the underlying link/network/transport layers or by built-in protocol >>>mechanisms. >>> >>>2. comment - Security - TLS can only work with reliable transport which >>>was >>>the cause of some confusion to the IESG. Also, the Sec. directorate >>>wanted >>>us to have text which described all the different attacks which were >>>possible >>>on a ForCES box & come up with requirements after some analysis from >>>that angle. >>>The Design team agreed and came up with the new text. >>>New Text - >>>a) FE configuration will contain information critical to the >>>functioning of a network (e.g. IP Forwarding Tables). As such, it MUST >>>be >>>possible to ensure the integrity of all ForCES protocol messages and >>>protect >>>against man-in-the-middle attacks. >>>b) FE configuration information may also contain information derived >>> >> >>>from business relationships (e.g. service >> >> >>>level agreements). Because of the confidential nature of the >>>information, >>>it MUST be possible to secure (make private) all ForCES protocol >>>messages. >>>c) In order to ensure that authorized CEs and FEs are participating in >>>a NE and defend against CE or FE impersonation attacks, the ForCES >>>architecture MUST select a means of authentication for CEs and FEs. >>>d) In some deployments ForCES is expected to be deployed between CEs >>>and FEs connected to each other inside a box >>>over a backplane, where physical security of the box ensures that >>>man-in-the-middle, snooping, and impersonation attacks are not possible. >>>In >>>such scenarios the ForCES architecture MAY rely on the physical security >>>of >>>the box to defend against these attacks and protocol mechanisms May be >>>turned off. >>>e) In the case when CEs and FEs are connected over a network, security >>>mechanisms MUST be specified or selected that protect the ForCES >>>protocol >>>against such attacks. Any security solution used for ForCES MUST >>>specify >>>how it deals with such attacks. >>> >>>3. comment - The IESG suggested that it was important for ForCES to >>>think >>>about DoS attacks to the protocol. The ForCES protocol could be attacked >>>with bogus routing packets which could lead to the protocol >>>disfunctioning. >>>Alex, could provide more details here ? >>>The Design team agreed and came up with the new text. >>>New Text - >>>Protection against Denial of Service Attacks (based on CPU overload or >>>queue overflow) >>>Systems utilizing the ForCES protocol can be attacked using denial of >>>service attacks based on CPU overload or queue overflow. >>>The ForCES protocol could be exploited by such attacks to >>>cause the CE to become unable to control the FE or appropriately >>>communicate >>>with other routers and systems. The ForCES protocol MUST therefore >>>provide >>>mechanisms for controlling FE capabilities that can be used to protect >>>against such attacks. FE capabilities that Must be manipulated >>>via ForCES include the ability to install classifiers and filters to >>>detect >>>and drop attack packets, as well as to be able to install rate limiters >>>that >>>limit the rate of packets which appear to be valid but may be part of an >>>attack (e.g. bogus BGP packets). >>> >>>4. comment - The IESG suggested that it was important for ForCES to talk >>>about IPFLOW/PSAMP functions which have been widely deployed in >>>networks. >>>The Design team agreed and came up with the new text. >>>New Text - >>>IPFLOW/PSAMP Functions >>>Several applications such as, Usage-based Accounting, Traffic >>>engineering, >>>require flow-based IP traffic measurements from Network Elements. >>>[IPFLOW] >>>defines architecture for IP traffic flow monitoring, measuring and >>>exporting. The FE model SHOULD be able to express metering functions and >>>flow accounting needed for exporting IP traffic flow information. >>>Similarly to support measurement-based applications, [PSAMP] describes a >>>framework to define a standard set of capabilities for network elements >>>to >>>sample subsets of packets by statistical and other methods. The FE model >>>SHOULD be able to express statistical packet filtering functions and >>>packet >>>information needed for supporting packet sampling applications. >>> >>>Pls do let us know if you have any comments. >>> >>>Thanks >>>Hormuzd >>> >>>-----Original Message----- >>>From: Alex Zinin [mailto:zinin@psg.com] >>>Sent: Wednesday, May 21, 2003 7:02 PM >>>To: Khosravi, Hormuzd M >>>Cc: Forwarding and Control Element Separation >>>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) >>> >>> >>>Folks- >>> >>>I've just updated the ID tracker to include the comments from the >>>IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should >>>have been done before.) >>> >>>There were also some comments from the ops-dir proxied by Randy, >>>which resulted in a discussion between the WG chairs and Pekka. I'd >>>like to ask the chairs to send a summary of the discussion to the >>>list. >>> >>>Hormuzd, to make sure the WG can follow the discussion, could you >>>please come up with a summary in a form similar to the following: >>> >>> Comment: ... >>> >>> Summary of discussion: ... >>> >>> Changes in document: ... >>> >>>Thanks. >>> >>> >>> >>> >> >> >> > > > -- > 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 > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 6 17:24:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13836 for ; Fri, 6 Jun 2003 17:24:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OOfG-0006jB-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 17:22:22 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19OOfF-0006j8-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 17:22:21 -0400 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.00A03323@cherry.ease.lsoft.com>; Fri, 6 Jun 2003 17:24:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44837875 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 6 Jun 2003 17:24:00 -0400 Received: from 143.209.238.79 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Jun 2003 17:23:59 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds955.usa.alcatel.com (8.12.9/8.12.9) with ESMTP id h56LNwTG016775 for ; Fri, 6 Jun 2003 16:23:59 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <42050DF556283A4D977B111EB706320812FE09@orsmsx407.jf.intel.com> <3EE1026C.7030804@zurich.ibm.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by auds955.usa.alcatel.com id h56LNwTG016775 Approved-By: Alex Audu Message-ID: <3EE1066D.52D3F185@alcatel.com> Date: Fri, 6 Jun 2003 16:23:57 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA13836 Hormuzd, What is the implication of "FORCES MUST NOT be restricted to strict reliability" on inter-operability? Regards, Alex. Patrick Droz wrote: > Hormuzd, > > I did not suggest the MAY NOT. What I said is that the SHOULD > NOT phrasing is a non recommended term. I also asked the DT > if they are happy with the new wording but nobody responded > to it. My take is we should use terms that are approved and > do have a very clear meaning. Therefore, I ask again what is > the exact meaning of that particular phrase. What is the > protocol exactly expecting to use? > > Thanks, > Patrick > > Khosravi, Hormuzd M wrote: > > Hi Robert, > > > > The intent of the text is NOT "ForCES prohibits strict reliability for > > that case" which is why Patrick suggested using MAY NOT for the wording. > > Using "MUST NOT" changes the meaning of the text to what you have > > stated, which is not the intent. If using MAY NOT was such a big issue, > > I am sure that the chairs would have pointed that out earlier. However, > > if the text must be changed to remove "MAY NOT", I would suggest the > > following wording..."ForCES MUST NOT be restricted to strict > > reliability" which would bring out the correct intent of the text i.e. > > both strictly reliable & non-strictly reliable are fine for that case. > > > > Thanks > > Hormuzd > > > > -----Original Message----- > > From: Robert Haas [mailto:rha@zurich.ibm.com] > > Sent: Friday, June 06, 2003 1:53 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > > > > Hi Hormuzd, > > > > Khosravi, Hormuzd M wrote: > > > >>Hi Robert, > >> > >>Using "MAY NOT" for that sentence was suggested by Patrick, > >>our initial wording for that sentence was > >>"ForCES SHOULD NOT impose strict reliability". > >>However, Patrick pointed out that "SHOULD NOT" has a > >>"NOT RECOMMENDED" tag, which was not our intent with the text. > >>Hence it was changed. Using "MUST NOT" also has the > >>"NOT RECOMMENDED" tag and therefore I don't think this > >>would bring out the correct intent for the text. > > > > "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the > > excerpt from RFC 2119. > > > > This is why I think it is more appropriate to use "MUST NOT" instead > > of "MAY NOT". The meaning remains as intended and there is no room > > for confusion: > > > > "ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose strict reliability" > > > > means that it is prohibited that ForCES imposes strict reliability. > > Or do you mean sth else ? > > > > Thanks, > > -Robert > > > > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > > definition is an absolute requirement of the specification. > > > > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > > definition is an absolute prohibition of the specification. > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > > there may exist valid reasons in particular circumstances when the > > particular behavior is acceptable or even useful, but the full > > implications should be understood and the case carefully weighed > > before implementing any behavior described with this label. > > > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > > truly optional. > > > > > > > >>Thanks > >>Hormuzd > >>-----Original Message----- > >>From: Robert Haas [mailto:rha@zurich.ibm.com] > >>Sent: Thursday, June 05, 2003 8:41 AM > >>To: FORCES@PEACH.EASE.LSOFT.COM > >>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > >> > >> > >>Hi all, > >>The requirements draft uses non-conforming wording in section 7 point 6). > >>I checked in RFC 2119, and the words "MAY NOT" do not exist there. > >>So the sentence "ForCES MAY NOT impose strict reliability" should be > >>changed to "MUST NOT". > >> > >>Regards, > >>-Robert > >> > >> > >>Khosravi, Hormuzd M wrote: > >> > >> > >> > >>>Hi Folks, > >>> > >>>Continuing from my last email......... > >>>Here is the brief summary of IESG comments/discussion/changes in the > >>>draft: > >>>Chairs, IESG can provide more details on their comments... ? > >>> > >>>1. comment - Reliability - IESG was not satisfied with the Reliability > >>>text, > >>>especially in context with the Security requirement (TLS can only be > >>>used > >>>with reliable transport). IESG was leaning towards use of reliable > >>>transport > >>>which would also simplify the Security requirement. Chairs, can add more > >>>details here ? > >>>Discussion - This topic was most heavily discussed in the Design team > >>>for more > >>>than a month over several emails. I cannot go thru all the details here, > >>>but > >>>essentially the team came up with this text which tries to capture all > >>>the > >>>different thoughts of the team. > >>>New Text - > >>>A) The ForCES protocol will be used to transport information that > >>>requires varying levels of reliability. By strict or robust reliability > >>>in this requirement we mean, no losses, no corruption, no re-ordering of > >>> > >>>information being transported and delivery in a timely fashion. > >>>B) Some information or payloads, such as redirected packets or packet > >>>sampling, may not require robust reliability (can tolerate some degree > >>>of losses). > >>>For information of this sort, ForCES MAY NOT impose strict reliability. > >>>C) Payloads such as configuration information, e.g. ACLs, FIB entries, > >>>or FE capability information (described in section 7, (1))are mission > >>>critical and must be delivered in a robust reliable fashion. Thus, for > >>>information > >>>of this sort, ForCES MUST either provide built-in protocol mechanisms or > >>>use a > >>>reliable transport protocol for achieving robust/strict reliability. > >>>D) Some information or payloads, such as heartbeat packets that may be > >>>used to detect loss of association between CE and FEs (see section 7, > >>>(8)), may > >>>prefer timeliness over reliable delivery. For information of this sort, > >>>ForCES > >>>MAY NOT impose strict reliability. > >>>E) When ForCES is carried over multi-hop IP networks, it is a > >>>requirement > >>>that ForCES MUST use a [RFC2914]-compliant transport protocol. > >>>F) In cases where ForCES is not running over an IP network such as an > >>>Ethernet or cell fabric between CE and FE, then reliability still MUST > >>>be provided > >>>when carrying critical information of the types specified in (C) above, > >>>either > >>>by the underlying link/network/transport layers or by built-in protocol > >>>mechanisms. > >>> > >>>2. comment - Security - TLS can only work with reliable transport which > >>>was > >>>the cause of some confusion to the IESG. Also, the Sec. directorate > >>>wanted > >>>us to have text which described all the different attacks which were > >>>possible > >>>on a ForCES box & come up with requirements after some analysis from > >>>that angle. > >>>The Design team agreed and came up with the new text. > >>>New Text - > >>>a) FE configuration will contain information critical to the > >>>functioning of a network (e.g. IP Forwarding Tables). As such, it MUST > >>>be > >>>possible to ensure the integrity of all ForCES protocol messages and > >>>protect > >>>against man-in-the-middle attacks. > >>>b) FE configuration information may also contain information derived > >>> > >> > >>>from business relationships (e.g. service > >> > >> > >>>level agreements). Because of the confidential nature of the > >>>information, > >>>it MUST be possible to secure (make private) all ForCES protocol > >>>messages. > >>>c) In order to ensure that authorized CEs and FEs are participating in > >>>a NE and defend against CE or FE impersonation attacks, the ForCES > >>>architecture MUST select a means of authentication for CEs and FEs. > >>>d) In some deployments ForCES is expected to be deployed between CEs > >>>and FEs connected to each other inside a box > >>>over a backplane, where physical security of the box ensures that > >>>man-in-the-middle, snooping, and impersonation attacks are not possible. > >>>In > >>>such scenarios the ForCES architecture MAY rely on the physical security > >>>of > >>>the box to defend against these attacks and protocol mechanisms May be > >>>turned off. > >>>e) In the case when CEs and FEs are connected over a network, security > >>>mechanisms MUST be specified or selected that protect the ForCES > >>>protocol > >>>against such attacks. Any security solution used for ForCES MUST > >>>specify > >>>how it deals with such attacks. > >>> > >>>3. comment - The IESG suggested that it was important for ForCES to > >>>think > >>>about DoS attacks to the protocol. The ForCES protocol could be attacked > >>>with bogus routing packets which could lead to the protocol > >>>disfunctioning. > >>>Alex, could provide more details here ? > >>>The Design team agreed and came up with the new text. > >>>New Text - > >>>Protection against Denial of Service Attacks (based on CPU overload or > >>>queue overflow) > >>>Systems utilizing the ForCES protocol can be attacked using denial of > >>>service attacks based on CPU overload or queue overflow. > >>>The ForCES protocol could be exploited by such attacks to > >>>cause the CE to become unable to control the FE or appropriately > >>>communicate > >>>with other routers and systems. The ForCES protocol MUST therefore > >>>provide > >>>mechanisms for controlling FE capabilities that can be used to protect > >>>against such attacks. FE capabilities that Must be manipulated > >>>via ForCES include the ability to install classifiers and filters to > >>>detect > >>>and drop attack packets, as well as to be able to install rate limiters > >>>that > >>>limit the rate of packets which appear to be valid but may be part of an > >>>attack (e.g. bogus BGP packets). > >>> > >>>4. comment - The IESG suggested that it was important for ForCES to talk > >>>about IPFLOW/PSAMP functions which have been widely deployed in > >>>networks. > >>>The Design team agreed and came up with the new text. > >>>New Text - > >>>IPFLOW/PSAMP Functions > >>>Several applications such as, Usage-based Accounting, Traffic > >>>engineering, > >>>require flow-based IP traffic measurements from Network Elements. > >>>[IPFLOW] > >>>defines architecture for IP traffic flow monitoring, measuring and > >>>exporting. The FE model SHOULD be able to express metering functions and > >>>flow accounting needed for exporting IP traffic flow information. > >>>Similarly to support measurement-based applications, [PSAMP] describes a > >>>framework to define a standard set of capabilities for network elements > >>>to > >>>sample subsets of packets by statistical and other methods. The FE model > >>>SHOULD be able to express statistical packet filtering functions and > >>>packet > >>>information needed for supporting packet sampling applications. > >>> > >>>Pls do let us know if you have any comments. > >>> > >>>Thanks > >>>Hormuzd > >>> > >>>-----Original Message----- > >>>From: Alex Zinin [mailto:zinin@psg.com] > >>>Sent: Wednesday, May 21, 2003 7:02 PM > >>>To: Khosravi, Hormuzd M > >>>Cc: Forwarding and Control Element Separation > >>>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > >>> > >>> > >>>Folks- > >>> > >>>I've just updated the ID tracker to include the comments from the > >>>IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should > >>>have been done before.) > >>> > >>>There were also some comments from the ops-dir proxied by Randy, > >>>which resulted in a discussion between the WG chairs and Pekka. I'd > >>>like to ask the chairs to send a summary of the discussion to the > >>>list. > >>> > >>>Hormuzd, to make sure the WG can follow the discussion, could you > >>>please come up with a summary in a form similar to the following: > >>> > >>> Comment: ... > >>> > >>> Summary of discussion: ... > >>> > >>> Changes in document: ... > >>> > >>>Thanks. > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > > -- > > 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 > > > > > > -- > Dr. Patrick Droz | dro@zurich.ibm.com > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 6 17:37:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14398 for ; Fri, 6 Jun 2003 17:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OOs9-0006pz-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 17:35:41 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19OOs7-0006pu-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 17:35:39 -0400 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.00A03315@cherry.ease.lsoft.com>; Fri, 6 Jun 2003 17:37:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44841636 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 6 Jun 2003 17:37:31 -0400 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Jun 2003 17:36:27 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h56LSYC11089 for ; Fri, 6 Jun 2003 21:28:34 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h56LTlx25445 for ; Fri, 6 Jun 2003 21:29:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003060614362625840 for ; Fri, 06 Jun 2003 14:36:26 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 14:36:26 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [FORCES] ForCES Requirements draft updated (v-09) Thread-Index: AcMsb5XP45FfOu90RwGX6eFyuN1rXwAAuUEQ X-OriginalArrivalTime: 06 Jun 2003 21:36:26.0334 (UTC) FILETIME=[AEE0DFE0:01C32C73] Approved-By: "Khosravi, Hormuzd M" Message-ID: <42050DF556283A4D977B111EB706320812FE0B@orsmsx407.jf.intel.com> Date: Fri, 6 Jun 2003 14:36:25 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA14398 Patrick, The exact meaning of that text is brought out in the wording that I suggested i.e. "ForCES MUST NOT be restricted to strict reliability for that particular case" This was the intended meaning of the text. Does this make things clear ? Let me know. Thanks Hormuzd -----Original Message----- From: Patrick Droz [mailto:dro@zurich.ibm.com] Sent: Friday, June 06, 2003 2:07 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) Hormuzd, I did not suggest the MAY NOT. What I said is that the SHOULD NOT phrasing is a non recommended term. I also asked the DT if they are happy with the new wording but nobody responded to it. My take is we should use terms that are approved and do have a very clear meaning. Therefore, I ask again what is the exact meaning of that particular phrase. What is the protocol exactly expecting to use? Thanks, Patrick Khosravi, Hormuzd M wrote: > Hi Robert, > > The intent of the text is NOT "ForCES prohibits strict reliability for > that case" which is why Patrick suggested using MAY NOT for the wording. > Using "MUST NOT" changes the meaning of the text to what you have > stated, which is not the intent. If using MAY NOT was such a big issue, > I am sure that the chairs would have pointed that out earlier. However, > if the text must be changed to remove "MAY NOT", I would suggest the > following wording..."ForCES MUST NOT be restricted to strict > reliability" which would bring out the correct intent of the text i.e. > both strictly reliable & non-strictly reliable are fine for that case. > > Thanks > Hormuzd > > -----Original Message----- > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, June 06, 2003 1:53 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > > Hi Hormuzd, > > Khosravi, Hormuzd M wrote: > >>Hi Robert, >> >>Using "MAY NOT" for that sentence was suggested by Patrick, >>our initial wording for that sentence was >>"ForCES SHOULD NOT impose strict reliability". >>However, Patrick pointed out that "SHOULD NOT" has a >>"NOT RECOMMENDED" tag, which was not our intent with the text. >>Hence it was changed. Using "MUST NOT" also has the >>"NOT RECOMMENDED" tag and therefore I don't think this >>would bring out the correct intent for the text. > > "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the > excerpt from RFC 2119. > > This is why I think it is more appropriate to use "MUST NOT" instead > of "MAY NOT". The meaning remains as intended and there is no room > for confusion: > > "ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose strict reliability" > > means that it is prohibited that ForCES imposes strict reliability. > Or do you mean sth else ? > > Thanks, > -Robert > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > definition is an absolute prohibition of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. > > > >>Thanks >>Hormuzd >>-----Original Message----- >>From: Robert Haas [mailto:rha@zurich.ibm.com] >>Sent: Thursday, June 05, 2003 8:41 AM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) >> >> >>Hi all, >>The requirements draft uses non-conforming wording in section 7 point 6). >>I checked in RFC 2119, and the words "MAY NOT" do not exist there. >>So the sentence "ForCES MAY NOT impose strict reliability" should be >>changed to "MUST NOT". >> >>Regards, >>-Robert >> >> >>Khosravi, Hormuzd M wrote: >> >> >> >>>Hi Folks, >>> >>>Continuing from my last email......... >>>Here is the brief summary of IESG comments/discussion/changes in the >>>draft: >>>Chairs, IESG can provide more details on their comments... ? >>> >>>1. comment - Reliability - IESG was not satisfied with the Reliability >>>text, >>>especially in context with the Security requirement (TLS can only be >>>used >>>with reliable transport). IESG was leaning towards use of reliable >>>transport >>>which would also simplify the Security requirement. Chairs, can add more >>>details here ? >>>Discussion - This topic was most heavily discussed in the Design team >>>for more >>>than a month over several emails. I cannot go thru all the details here, >>>but >>>essentially the team came up with this text which tries to capture all >>>the >>>different thoughts of the team. >>>New Text - >>>A) The ForCES protocol will be used to transport information that >>>requires varying levels of reliability. By strict or robust reliability >>>in this requirement we mean, no losses, no corruption, no re-ordering of >>> >>>information being transported and delivery in a timely fashion. >>>B) Some information or payloads, such as redirected packets or packet >>>sampling, may not require robust reliability (can tolerate some degree >>>of losses). >>>For information of this sort, ForCES MAY NOT impose strict reliability. >>>C) Payloads such as configuration information, e.g. ACLs, FIB entries, >>>or FE capability information (described in section 7, (1))are mission >>>critical and must be delivered in a robust reliable fashion. Thus, for >>>information >>>of this sort, ForCES MUST either provide built-in protocol mechanisms or >>>use a >>>reliable transport protocol for achieving robust/strict reliability. >>>D) Some information or payloads, such as heartbeat packets that may be >>>used to detect loss of association between CE and FEs (see section 7, >>>(8)), may >>>prefer timeliness over reliable delivery. For information of this sort, >>>ForCES >>>MAY NOT impose strict reliability. >>>E) When ForCES is carried over multi-hop IP networks, it is a >>>requirement >>>that ForCES MUST use a [RFC2914]-compliant transport protocol. >>>F) In cases where ForCES is not running over an IP network such as an >>>Ethernet or cell fabric between CE and FE, then reliability still MUST >>>be provided >>>when carrying critical information of the types specified in (C) above, >>>either >>>by the underlying link/network/transport layers or by built-in protocol >>>mechanisms. >>> >>>2. comment - Security - TLS can only work with reliable transport which >>>was >>>the cause of some confusion to the IESG. Also, the Sec. directorate >>>wanted >>>us to have text which described all the different attacks which were >>>possible >>>on a ForCES box & come up with requirements after some analysis from >>>that angle. >>>The Design team agreed and came up with the new text. >>>New Text - >>>a) FE configuration will contain information critical to the >>>functioning of a network (e.g. IP Forwarding Tables). As such, it MUST >>>be >>>possible to ensure the integrity of all ForCES protocol messages and >>>protect >>>against man-in-the-middle attacks. >>>b) FE configuration information may also contain information derived >>> >> >>>from business relationships (e.g. service >> >> >>>level agreements). Because of the confidential nature of the >>>information, >>>it MUST be possible to secure (make private) all ForCES protocol >>>messages. >>>c) In order to ensure that authorized CEs and FEs are participating in >>>a NE and defend against CE or FE impersonation attacks, the ForCES >>>architecture MUST select a means of authentication for CEs and FEs. >>>d) In some deployments ForCES is expected to be deployed between CEs >>>and FEs connected to each other inside a box >>>over a backplane, where physical security of the box ensures that >>>man-in-the-middle, snooping, and impersonation attacks are not possible. >>>In >>>such scenarios the ForCES architecture MAY rely on the physical security >>>of >>>the box to defend against these attacks and protocol mechanisms May be >>>turned off. >>>e) In the case when CEs and FEs are connected over a network, security >>>mechanisms MUST be specified or selected that protect the ForCES >>>protocol >>>against such attacks. Any security solution used for ForCES MUST >>>specify >>>how it deals with such attacks. >>> >>>3. comment - The IESG suggested that it was important for ForCES to >>>think >>>about DoS attacks to the protocol. The ForCES protocol could be attacked >>>with bogus routing packets which could lead to the protocol >>>disfunctioning. >>>Alex, could provide more details here ? >>>The Design team agreed and came up with the new text. >>>New Text - >>>Protection against Denial of Service Attacks (based on CPU overload or >>>queue overflow) >>>Systems utilizing the ForCES protocol can be attacked using denial of >>>service attacks based on CPU overload or queue overflow. >>>The ForCES protocol could be exploited by such attacks to >>>cause the CE to become unable to control the FE or appropriately >>>communicate >>>with other routers and systems. The ForCES protocol MUST therefore >>>provide >>>mechanisms for controlling FE capabilities that can be used to protect >>>against such attacks. FE capabilities that Must be manipulated >>>via ForCES include the ability to install classifiers and filters to >>>detect >>>and drop attack packets, as well as to be able to install rate limiters >>>that >>>limit the rate of packets which appear to be valid but may be part of an >>>attack (e.g. bogus BGP packets). >>> >>>4. comment - The IESG suggested that it was important for ForCES to talk >>>about IPFLOW/PSAMP functions which have been widely deployed in >>>networks. >>>The Design team agreed and came up with the new text. >>>New Text - >>>IPFLOW/PSAMP Functions >>>Several applications such as, Usage-based Accounting, Traffic >>>engineering, >>>require flow-based IP traffic measurements from Network Elements. >>>[IPFLOW] >>>defines architecture for IP traffic flow monitoring, measuring and >>>exporting. The FE model SHOULD be able to express metering functions and >>>flow accounting needed for exporting IP traffic flow information. >>>Similarly to support measurement-based applications, [PSAMP] describes a >>>framework to define a standard set of capabilities for network elements >>>to >>>sample subsets of packets by statistical and other methods. The FE model >>>SHOULD be able to express statistical packet filtering functions and >>>packet >>>information needed for supporting packet sampling applications. >>> >>>Pls do let us know if you have any comments. >>> >>>Thanks >>>Hormuzd >>> >>>-----Original Message----- >>>From: Alex Zinin [mailto:zinin@psg.com] >>>Sent: Wednesday, May 21, 2003 7:02 PM >>>To: Khosravi, Hormuzd M >>>Cc: Forwarding and Control Element Separation >>>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) >>> >>> >>>Folks- >>> >>>I've just updated the ID tracker to include the comments from the >>>IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should >>>have been done before.) >>> >>>There were also some comments from the ops-dir proxied by Randy, >>>which resulted in a discussion between the WG chairs and Pekka. I'd >>>like to ask the chairs to send a summary of the discussion to the >>>list. >>> >>>Hormuzd, to make sure the WG can follow the discussion, could you >>>please come up with a summary in a form similar to the following: >>> >>> Comment: ... >>> >>> Summary of discussion: ... >>> >>> Changes in document: ... >>> >>>Thanks. >>> >>> >>> >>> >> >> >> > > > -- > 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 > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 6 17:43:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14756 for ; Fri, 6 Jun 2003 17:43:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OOy2-0006vA-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 17:41:46 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19OOxz-0006v7-00 for forces-archive@IETF.ORG; Fri, 06 Jun 2003 17:41:44 -0400 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.00A033D6@cherry.ease.lsoft.com>; Fri, 6 Jun 2003 17:43:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44846163 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 6 Jun 2003 17:43:34 -0400 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Jun 2003 17:43:33 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h56LfVU13952 for ; Fri, 6 Jun 2003 21:41:31 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h56Ld4N04605 for ; Fri, 6 Jun 2003 21:39:04 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003060614535630140 for ; Fri, 06 Jun 2003 14:53:56 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 14:43:32 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [FORCES] ForCES Requirements draft updated (v-09) Thread-Index: AcMscf9U+Ixd6TaYRTux/bhM2a62+gAAhWNA X-OriginalArrivalTime: 06 Jun 2003 21:43:32.0957 (UTC) FILETIME=[AD2A60D0:01C32C74] Approved-By: "Khosravi, Hormuzd M" Message-ID: <42050DF556283A4D977B111EB706320812FE0C@orsmsx407.jf.intel.com> Date: Fri, 6 Jun 2003 14:43:32 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA14756 Alex, That's a good question. However, the inter-operability would depend on the protocol design. The requirements are essentially trying not to restrict the protocol designers for all cases, giving them more choices while designing the protocol. Regards Hormuzd -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com] Sent: Friday, June 06, 2003 2:24 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) Hormuzd, What is the implication of "FORCES MUST NOT be restricted to strict reliability" on inter-operability? Regards, Alex. Patrick Droz wrote: > Hormuzd, > > I did not suggest the MAY NOT. What I said is that the SHOULD > NOT phrasing is a non recommended term. I also asked the DT > if they are happy with the new wording but nobody responded > to it. My take is we should use terms that are approved and > do have a very clear meaning. Therefore, I ask again what is > the exact meaning of that particular phrase. What is the > protocol exactly expecting to use? > > Thanks, > Patrick > > Khosravi, Hormuzd M wrote: > > Hi Robert, > > > > The intent of the text is NOT "ForCES prohibits strict reliability for > > that case" which is why Patrick suggested using MAY NOT for the wording. > > Using "MUST NOT" changes the meaning of the text to what you have > > stated, which is not the intent. If using MAY NOT was such a big issue, > > I am sure that the chairs would have pointed that out earlier. However, > > if the text must be changed to remove "MAY NOT", I would suggest the > > following wording..."ForCES MUST NOT be restricted to strict > > reliability" which would bring out the correct intent of the text i.e. > > both strictly reliable & non-strictly reliable are fine for that case. > > > > Thanks > > Hormuzd > > > > -----Original Message----- > > From: Robert Haas [mailto:rha@zurich.ibm.com] > > Sent: Friday, June 06, 2003 1:53 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > > > > Hi Hormuzd, > > > > Khosravi, Hormuzd M wrote: > > > >>Hi Robert, > >> > >>Using "MAY NOT" for that sentence was suggested by Patrick, > >>our initial wording for that sentence was > >>"ForCES SHOULD NOT impose strict reliability". > >>However, Patrick pointed out that "SHOULD NOT" has a > >>"NOT RECOMMENDED" tag, which was not our intent with the text. > >>Hence it was changed. Using "MUST NOT" also has the > >>"NOT RECOMMENDED" tag and therefore I don't think this > >>would bring out the correct intent for the text. > > > > "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the > > excerpt from RFC 2119. > > > > This is why I think it is more appropriate to use "MUST NOT" instead > > of "MAY NOT". The meaning remains as intended and there is no room > > for confusion: > > > > "ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose strict reliability" > > > > means that it is prohibited that ForCES imposes strict reliability. > > Or do you mean sth else ? > > > > Thanks, > > -Robert > > > > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > > definition is an absolute requirement of the specification. > > > > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > > definition is an absolute prohibition of the specification. > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > > there may exist valid reasons in particular circumstances when the > > particular behavior is acceptable or even useful, but the full > > implications should be understood and the case carefully weighed > > before implementing any behavior described with this label. > > > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > > truly optional. > > > > > > > >>Thanks > >>Hormuzd > >>-----Original Message----- > >>From: Robert Haas [mailto:rha@zurich.ibm.com] > >>Sent: Thursday, June 05, 2003 8:41 AM > >>To: FORCES@PEACH.EASE.LSOFT.COM > >>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > >> > >> > >>Hi all, > >>The requirements draft uses non-conforming wording in section 7 point 6). > >>I checked in RFC 2119, and the words "MAY NOT" do not exist there. > >>So the sentence "ForCES MAY NOT impose strict reliability" should be > >>changed to "MUST NOT". > >> > >>Regards, > >>-Robert > >> > >> > >>Khosravi, Hormuzd M wrote: > >> > >> > >> > >>>Hi Folks, > >>> > >>>Continuing from my last email......... > >>>Here is the brief summary of IESG comments/discussion/changes in the > >>>draft: > >>>Chairs, IESG can provide more details on their comments... ? > >>> > >>>1. comment - Reliability - IESG was not satisfied with the Reliability > >>>text, > >>>especially in context with the Security requirement (TLS can only be > >>>used > >>>with reliable transport). IESG was leaning towards use of reliable > >>>transport > >>>which would also simplify the Security requirement. Chairs, can add more > >>>details here ? > >>>Discussion - This topic was most heavily discussed in the Design team > >>>for more > >>>than a month over several emails. I cannot go thru all the details here, > >>>but > >>>essentially the team came up with this text which tries to capture all > >>>the > >>>different thoughts of the team. > >>>New Text - > >>>A) The ForCES protocol will be used to transport information that > >>>requires varying levels of reliability. By strict or robust reliability > >>>in this requirement we mean, no losses, no corruption, no re-ordering of > >>> > >>>information being transported and delivery in a timely fashion. > >>>B) Some information or payloads, such as redirected packets or packet > >>>sampling, may not require robust reliability (can tolerate some degree > >>>of losses). > >>>For information of this sort, ForCES MAY NOT impose strict reliability. > >>>C) Payloads such as configuration information, e.g. ACLs, FIB entries, > >>>or FE capability information (described in section 7, (1))are mission > >>>critical and must be delivered in a robust reliable fashion. Thus, for > >>>information > >>>of this sort, ForCES MUST either provide built-in protocol mechanisms or > >>>use a > >>>reliable transport protocol for achieving robust/strict reliability. > >>>D) Some information or payloads, such as heartbeat packets that may be > >>>used to detect loss of association between CE and FEs (see section 7, > >>>(8)), may > >>>prefer timeliness over reliable delivery. For information of this sort, > >>>ForCES > >>>MAY NOT impose strict reliability. > >>>E) When ForCES is carried over multi-hop IP networks, it is a > >>>requirement > >>>that ForCES MUST use a [RFC2914]-compliant transport protocol. > >>>F) In cases where ForCES is not running over an IP network such as an > >>>Ethernet or cell fabric between CE and FE, then reliability still MUST > >>>be provided > >>>when carrying critical information of the types specified in (C) above, > >>>either > >>>by the underlying link/network/transport layers or by built-in protocol > >>>mechanisms. > >>> > >>>2. comment - Security - TLS can only work with reliable transport which > >>>was > >>>the cause of some confusion to the IESG. Also, the Sec. directorate > >>>wanted > >>>us to have text which described all the different attacks which were > >>>possible > >>>on a ForCES box & come up with requirements after some analysis from > >>>that angle. > >>>The Design team agreed and came up with the new text. > >>>New Text - > >>>a) FE configuration will contain information critical to the > >>>functioning of a network (e.g. IP Forwarding Tables). As such, it MUST > >>>be > >>>possible to ensure the integrity of all ForCES protocol messages and > >>>protect > >>>against man-in-the-middle attacks. > >>>b) FE configuration information may also contain information derived > >>> > >> > >>>from business relationships (e.g. service > >> > >> > >>>level agreements). Because of the confidential nature of the > >>>information, > >>>it MUST be possible to secure (make private) all ForCES protocol > >>>messages. > >>>c) In order to ensure that authorized CEs and FEs are participating in > >>>a NE and defend against CE or FE impersonation attacks, the ForCES > >>>architecture MUST select a means of authentication for CEs and FEs. > >>>d) In some deployments ForCES is expected to be deployed between CEs > >>>and FEs connected to each other inside a box > >>>over a backplane, where physical security of the box ensures that > >>>man-in-the-middle, snooping, and impersonation attacks are not possible. > >>>In > >>>such scenarios the ForCES architecture MAY rely on the physical security > >>>of > >>>the box to defend against these attacks and protocol mechanisms May be > >>>turned off. > >>>e) In the case when CEs and FEs are connected over a network, security > >>>mechanisms MUST be specified or selected that protect the ForCES > >>>protocol > >>>against such attacks. Any security solution used for ForCES MUST > >>>specify > >>>how it deals with such attacks. > >>> > >>>3. comment - The IESG suggested that it was important for ForCES to > >>>think > >>>about DoS attacks to the protocol. The ForCES protocol could be attacked > >>>with bogus routing packets which could lead to the protocol > >>>disfunctioning. > >>>Alex, could provide more details here ? > >>>The Design team agreed and came up with the new text. > >>>New Text - > >>>Protection against Denial of Service Attacks (based on CPU overload or > >>>queue overflow) > >>>Systems utilizing the ForCES protocol can be attacked using denial of > >>>service attacks based on CPU overload or queue overflow. > >>>The ForCES protocol could be exploited by such attacks to > >>>cause the CE to become unable to control the FE or appropriately > >>>communicate > >>>with other routers and systems. The ForCES protocol MUST therefore > >>>provide > >>>mechanisms for controlling FE capabilities that can be used to protect > >>>against such attacks. FE capabilities that Must be manipulated > >>>via ForCES include the ability to install classifiers and filters to > >>>detect > >>>and drop attack packets, as well as to be able to install rate limiters > >>>that > >>>limit the rate of packets which appear to be valid but may be part of an > >>>attack (e.g. bogus BGP packets). > >>> > >>>4. comment - The IESG suggested that it was important for ForCES to talk > >>>about IPFLOW/PSAMP functions which have been widely deployed in > >>>networks. > >>>The Design team agreed and came up with the new text. > >>>New Text - > >>>IPFLOW/PSAMP Functions > >>>Several applications such as, Usage-based Accounting, Traffic > >>>engineering, > >>>require flow-based IP traffic measurements from Network Elements. > >>>[IPFLOW] > >>>defines architecture for IP traffic flow monitoring, measuring and > >>>exporting. The FE model SHOULD be able to express metering functions and > >>>flow accounting needed for exporting IP traffic flow information. > >>>Similarly to support measurement-based applications, [PSAMP] describes a > >>>framework to define a standard set of capabilities for network elements > >>>to > >>>sample subsets of packets by statistical and other methods. The FE model > >>>SHOULD be able to express statistical packet filtering functions and > >>>packet > >>>information needed for supporting packet sampling applications. > >>> > >>>Pls do let us know if you have any comments. > >>> > >>>Thanks > >>>Hormuzd > >>> > >>>-----Original Message----- > >>>From: Alex Zinin [mailto:zinin@psg.com] > >>>Sent: Wednesday, May 21, 2003 7:02 PM > >>>To: Khosravi, Hormuzd M > >>>Cc: Forwarding and Control Element Separation > >>>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > >>> > >>> > >>>Folks- > >>> > >>>I've just updated the ID tracker to include the comments from the > >>>IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should > >>>have been done before.) > >>> > >>>There were also some comments from the ops-dir proxied by Randy, > >>>which resulted in a discussion between the WG chairs and Pekka. I'd > >>>like to ask the chairs to send a summary of the discussion to the > >>>list. > >>> > >>>Hormuzd, to make sure the WG can follow the discussion, could you > >>>please come up with a summary in a form similar to the following: > >>> > >>> Comment: ... > >>> > >>> Summary of discussion: ... > >>> > >>> Changes in document: ... > >>> > >>>Thanks. > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > > -- > > 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 > > > > > > -- > Dr. Patrick Droz | dro@zurich.ibm.com > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 9 17:31:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21998 for ; Mon, 9 Jun 2003 17:31:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PUCU-0007Fp-00 for forces-archive@IETF.ORG; Mon, 09 Jun 2003 17:29:10 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19PUCO-0007Fk-00 for forces-archive@IETF.ORG; Mon, 09 Jun 2003 17:29:04 -0400 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.00A0894F@cherry.ease.lsoft.com>; Mon, 9 Jun 2003 17:31:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45088696 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 9 Jun 2003 17:31:02 -0400 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Jun 2003 17:31:01 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h59LN0b02515 for ; Mon, 9 Jun 2003 21:23:02 GMT Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with ESMTP id h59LVWF11598 for ; Mon, 9 Jun 2003 21:31:32 GMT Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 14:30:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C32ECE.61798380" Approved-By: "Yang, Lily L" Message-ID: Date: Mon, 9 Jun 2003 14:30:42 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: new rev of ForCES framework draft (v05) 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_01C32ECE.61798380 Content-Type: text/plain; charset="iso-8859-1" Hi, all -- Here is the new rev of ForCES framework draft (v05). Most of the changes in this rev is in respond to the AD/Routing Directorate feedback that we received in early April. We will provide a detailed summary of our respond in a separate email. In addition to that, the following are a list of modifications that went into this rev: 1) terminology change: We found that "FE topology" is being used to mean two different things in the requirement, framework and FE model drafts -- either inter-FE topology (that is, the topology of how multiple FEs are inter-connected), or intra-FE topology (that is, the topology of how FE blocks are inter-connected within one FE). To avoid the confusion, we use "FE topology" to mean "inter-FE topology" while "FE block topology" to mean "intra-FE topology". 2) author addition: Ram Gopal contributed most of the content on the new Security Considerations section and we think it is only appropriate to acknowledge his contribution by adding him to the author list. 3) terminology section matching with new requirement draft. We will appreciate your feedback. Thanks, Lily <> ------_=_NextPart_000_01C32ECE.61798380 Content-Type: text/plain; name="draft-ietf-forces-framework-05.txt" Content-Disposition: attachment; filename="draft-ietf-forces-framework-05.txt" Content-Transfer-Encoding: quoted-printable =20 Internet Draft L. = Yang=20 Expiration: Dec 2003 Intel = Corp.=20 File: draft-ietf-forces-framework-05.txt R. = Dantu=20 Working Group: ForCES Univ. of North = Texas =20 T. = Anderson=20 Intel = Corp.=20 R. = Gopal=20 = Nokia =20 June = 2003 =20 =20 =20 Forwarding and Control Element Separation (ForCES) = Framework=20 =20 =20 =20 =20 draft-ietf-forces-framework-05.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 Copyright Notice =20 =20 Copyright (C) The Internet Society (2002). All Rights = Reserved.=20 =20 Abstract=20 =20 This document defines the architectural framework for the = ForCES=20 (Forwarding and Control Element Separation) network elements, = and=20 identifies the associated entities and the interaction among = them.=20 =20 Table of Contents=20 =20 =0C Internet Draft ForCES Framework June 2003 = =20 =20 =20 1. = Definitions.....................................................3=20 2. Introduction to Forwarding and Control Element Separation=20 = (ForCES)...........................................................5=20 3. = Architecture....................................................8=20 3.1. Control Elements and Fr Reference = Point....................9=20 3.2. Forwarding Elements and Fi reference = point................10=20 3.3. CE = Managers...............................................13=20 3.4. FE = Managers...............................................13=20 4. Operational = Phases.............................................13=20 4.1. Pre-association = Phase.....................................13=20 4.1.1. Fl Reference = Point...................................13=20 4.1.2. Ff Reference = Point...................................14=20 4.1.3. Fc Reference = Point...................................15=20 4.2. Post-association Phase and Fp reference = point.............15=20 4.2.1. Proximity and Interconnect between CEs and = FEs.......15=20 4.2.2. Association = Establishment............................16=20 4.2.3. Steady-state = Communication...........................17=20 4.2.4. Data Packets across Fp reference = point...............18=20 4.2.5. Proxy = FE.............................................19=20 4.3. Association = Re-establishment..............................19=20 4.3.1. CE graceful = restart..................................19=20 4.3.2. FE = restart...........................................20=20 5. Applicability to = RFC1812.......................................21=20 5.1. General Router = Requirements...............................22=20 5.2. Link = Layer................................................23=20 5.3. Internet Layer = Protocols..................................23=20 5.4. Internet Layer = Forwarding.................................24=20 5.5. Transport = Layer...........................................24=20 5.6. Application Layer -- Routing = Protocols....................25=20 5.7. Application Layer -- Network Management = Protocol..........25=20 6. = Summary........................................................25=20 7. Security = Considerations........................................26=20 7.1. Analysis of Potential Threats Introduced by = ForCES........26=20 7.1.1. =91=91Join=92=92 or =91=91Remove=92=92 Flooding on = CEs...................26=20 7.1.2. Impersonation = Attack.................................27=20 7.1.3. Replay = Attack........................................27=20 7.1.4. Attack during Fail = Over..............................27=20 7.1.5. Data = Integrity.......................................27=20 7.1.6. Data = Confidentiality.................................27=20 7.1.7. Sharing security = parameters..........................28=20 7.1.8. Denial of Service Attack via External = Interface......28=20 7.2. Security Recommendations for = ForCES.......................28=20 7.2.1. Security = Configuration...............................29=20 7.2.2. Using TLS with = ForCES................................29=20 7.2.3. Using IPsec with = ForCES..............................30=20 8. Normative = References...........................................31=20 9. Informative = References.........................................32=20 10. = Acknowledgement...............................................32=20 11. Authors' = Addresses............................................33=20 12. Intellectual Property = Right...................................33=20 13. Full Copyright = Statement......................................33=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 2] =0C Internet Draft ForCES Framework June 2003 = =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. Definitions=20 =20 A set of terminology associated with the ForCES requirements is = defined in [3] and we only include the ones that are most = relevant=20 to this document here. =20 =20 Addressable Entity (AE) -=0D - = An entity that is directly addressable=20 given some interconnect technology. For example, on IP = networks, it=20 is a device to which we can communicate using an IP address; = and on=20 a switch fabric, it is a device to which we can communicate = using a=20 switch fabric port number. =20 =20 Physical Forwarding Element (PFE) - An AE that includes = hardware=20 used to provide per-packet processing and handling. This = hardware=20 may consist of (but is not limited to) network processors, = ASICs, or=20 general processors, installed on line cards, daughter boards,=20 mezzanine cards, or in stand-alone boxes.=20 =20 PFE Partition - A logical partition of a PFE consisting of some = subset of each of the resources (e.g., ports, memory, = forwarding=20 table entries) available on the PFE. This concept is analogous = to=20 that of the resources assigned to a virtual switching element = as=20 described in [8]. =20 =20 Physical Control Element (PCE) - An AE that includes hardware = used=20 to provide control functionality. This hardware typically = includes=20 a general-purpose processor. =20 =20 PCE Partition - A logical partition of a PCE consisting of some = subset of each of the resources available on the PCE. =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. FEs may happen to be a single blade (or PFE), a = partition=20 of a PFE or multiple PFEs.=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. CEs may consist of PCE partitions or = whole=20 PCEs.=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 Yang, et. al. Expires Dec 2003 [Page 3] =0C Internet Draft ForCES Framework June 2003 = =20 =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.=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, however this is currently out of scope. Being a logical=20 entity, a FE manager might be physically combined with any of = the=20 other logical entities mentioned in this 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 however this is currently out of scope. Being a logical = entity, a=20 CE manager might be physically combined with any of the other=20 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 =20 Yang, et. al. Expires Dec 2003 [Page 4] =0C Internet Draft ForCES Framework June 2003 = =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 FE Topology -- Representation of how the multiple FEs in a = single NE=20 are interconnected. Sometimes it is called inter-FE topology, = to be=20 distinguished from intra-FE topology (or FE block topology) = used by=20 FE model.=20 =20 Inter-FE topology - see FE Topology.=20 =20 2. 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 = element (NE) (such as a router) is composed of numerous = logically=20 separated entities that cooperate to provide a given = functionality=20 (such as routing). Two types of network element components = exist:=20 control element (CE) in control plane and forwarding element = (FE) in=20 forwarding plane (or data plane). Forwarding elements = typically are=20 ASIC, network-processor, or general-purpose processor-based = devices=20 that handle data path operations for each packet. Control = elements=20 are typically based on general-purpose processors that provide=20 control functionality like routing and signaling protocols. =20 =20 ForCES aims to define a framework and associated protocol(s) to = standardize information exchange between the control and = forwarding=20 plane. Having standard mechanisms allows CEs and FEs to become = physically separated standard components. This physical = separation=20 accrues several benefits to the ForCES architecture. Separate=20 components would allow component vendors to specialize in one=20 component without having to become experts in all components.=20 Standard protocol also allows the CEs and FEs from different=20 component vendors to interoperate with each other and hence it=20 becomes possible for system vendors to integrate together the = CEs=20 and FEs from different component suppliers. This = interoperability=20 translates into a lot more design choices and flexibility to = the=20 system vendors. Overall, ForCES will enable rapid innovation = in=20 both the control and forwarding planes while maintaining=20 interoperability. Scalability is also easily provided by this=20 architecture in that additional forwarding or control capacity = can=20 be added to existing network elements without the need for = forklift=20 upgrades.=20 =20 ------------------------- -------------------------=20 | Control Blade A | | Control Blade B |=20 | (CE) | | (CE) |=20 ------------------------- -------------------------=20 ^ | ^ |=20 | | | |=20 | V | V=20 =20 Yang, et. al. Expires Dec 2003 [Page 5] =0C Internet Draft ForCES Framework June 2003 = =20 =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 One example of such physical separation is at the blade level.=20 Figure 1 shows such 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 = 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. Control blade A may = be=20 the primary CE while control blade B is the backup CE providing = redundancy. It is also possible to have a redundant switch = fabric=20 for high availability support. Routers today with this kind of = configuration use proprietary interface for messaging between = CEs=20 and FEs. The goal of ForCES is to replace such proprietary=20 interface with a standard protocol. With a standard protocol = like=20 ForCES implemented on all blades, it becomes possible for = control=20 blades from vendor X and routing blades from vendor Y to work=20 seamlessly together in one chassis. =20 =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 Yang, et. al. Expires Dec 2003 [Page 6] =0C Internet Draft ForCES Framework June 2003 = =20 =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 In both examples shown here, the same physical interconnect is = used=20 for both CE-to-FE and FE-to-FE communication. However, that = does=20 not have to be the case. One reason to use different = interconnect=20 is that CE-to-FE interconnect does not have to be as fast as = the FE- to-FE interconnect, so the more expensive fast connections can = be=20 saved for FE-to-FE only. The separate interconnects may also=20 provide reliability and redundancy benefits for the NE.=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 RSVP (Resource Reservation Protocol), = LDP=20 (Label Distribution Protocol) for MPLS, etc. Examples of = forwarding=20 functions in FE include LPM (longest prefix match) forwarder,=20 classifiers, traffic shaper, meter, NAT, etc. Figure 3 shows a = 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 4.2.4 provides more detail on this. = =20 -------------------------------------------------=20 | | | | | | |=20 |OSPF |RIP |BGP |RSVP |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 =20 Yang, et. al. Expires Dec 2003 [Page 7] =0C Internet Draft ForCES Framework June 2003 = =20 =20 Figure 3. Examples of CE and FE functions=20 =20 =20 A set of requirements for control and forwarding separation is=20 identified in [3]. This document describes a ForCES = architecture=20 that satisfies the architectural requirements of that document = and=20 defines a framework for ForCES network elements and the = associated=20 entities to facilitate protocol definition. Whenever = necessary,=20 this document uses many examples to illustrate the issues = and/or=20 possible solutions in ForCES. These examples are intended to = be=20 just examples, and should not be taken as the only or definite = ways=20 of doing certain things. It is expected that separate document = will=20 be produced by the ForCES working group to specify the ForCES=20 protocol(s).=20 =20 3. Architecture=20 =20 This section defines the ForCES architectural framework and the = associated logical components. This ForCES framework defines=20 components of ForCES NEs including several ancillary = components. =20 These components may be connected in different kinds of = topologies=20 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 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 interfaces for receiving and transmitting packets from/to = the=20 =20 Yang, et. al. Expires Dec 2003 [Page 8] =0C Internet Draft ForCES Framework June 2003 = =20 =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 = 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, as = shown=20 in Figure 4. The FE external interfaces are labeled as Fi/f. = More=20 detail is provided in Section 4 and 5 for each of these = reference=20 points. All these reference points are important in = understanding=20 the ForCES architecture, however, the ForCES protocol is only defined over one reference 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 external interfaces at Fi/f. = ForCES=20 NEs connect to existing routers transparently.=20 =20 3.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, = the=20 invariant that the CEs and FEs together appear as a single NE = must=20 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 any request that can be serviced by one of the CEs can also = be=20 serviced by any of the other CEs. For both redundancy and 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 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 ForCES. CEs are wholly responsible for = coordinating=20 amongst themselves via the Fr reference point to provide = consistency=20 and synchronization. However, ForCES does not define the=20 implementation or protocols used between CEs, nor does it = define how=20 to distribute functionality among CEs. Nevertheless, ForCES = will=20 =20 Yang, et. al. Expires Dec 2003 [Page 9] =0C Internet Draft ForCES Framework June 2003 = =20 =20 support mechanisms for CE redundancy or fail over, and it is=20 expected that vendors will provide redundancy or fail over = solutions=20 within this framework.=20 =20 =20 3.2. Forwarding Elements and Fi reference point=20 =20 FE is a logical entity that implements the ForCES protocol and = uses=20 the underlying hardware to provide per-packet processing and=20 handling as directed by a CE. It is possible to partition one=20 physical FE into multiple logical FEs. It is also possible for = one=20 FE to use multiple physical FEs. The mapping between physical = FE(s)=20 and the logical FE(s) is beyond the scope of ForCES. For = example, a=20 logical partition of a physical FE can be created by assigning = some=20 portion of each of the resources (e.g., ports, memory, = forwarding=20 table entries) available on the physical FE to each of the = logical=20 FEs. Such concept of FE virtualization is analogous to a = virtual=20 switching element as described in [8]. FE virtualization = should=20 occur only in the pre-association phase and hence has no impact = on=20 ForCES.=20 =20 FEs perform all packet processing functions 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=20 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). =20 Upon detection of CE1 failure, perhaps across the Fr or Fp = reference=20 =20 Yang, et. al. Expires Dec 2003 [Page 10] =0C Internet Draft ForCES Framework June 2003 = =20 =20 point, CE2 is configured to take over activities of CE1. This = is=20 beyond the scope of ForCES and is not discussed further.=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=20 need to do packet filtering for forwarding packets to specific = CEs.=20 =20 This architecture permits multiple FEs to be present in a NE. = [3]=20 dictates that the ForCES protocol must be able to scale to at = least=20 hundreds of FEs (see [3] Section 5, requirement #11). Each of = these=20 FEs may potentially have a different set of packet processing=20 functions, with different media interfaces. FEs are = responsible for=20 basic maintenance of layer-2 connectivity with other FEs and = with=20 external entities. Many layer-2 media include sophisticated = control=20 protocols. The FORCES protocol (over the Fp reference point) = will=20 be able to carry messages for such protocols so that, in = keeping=20 with the "dumb FE=92=92 model, the CE can provide appropriate=20 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 [3], Section 5, Requirement #3). Packets that enter = the NE=20 via one FE and leave the NE via a different FE are transferred=20 between FEs across the Fi reference point. Fi reference point = could=20 be used by FEs to discovery their (inter-FE) topology, perhaps=20 during pre-association phase. The Fi reference point is a = separate=20 protocol from the Fp reference point and is not currently = defined by=20 the ForCES architecture.=20 =20 ----------------- =20 | CE | =20 ----------------- =20 ^ ^ ^=20 / | \=20 / v \=20 / ------- \=20 / +->| FE3 |<-+ \=20 / | | | | \=20 v | ------- | v=20 ------- | | -------=20 | FE1 |<-+ +->| FE2 |=20 | |<--------------->| |=20 ------- -------=20 ^ | ^ |=20 | | | |=20 | v | v=20 =20 (a) Full mesh among FE1, FE2 and FE3.=20 =20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 11] =0C Internet Draft ForCES Framework June 2003 = =20 =20 ----------- =20 | CE | =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 ^ |=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 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, the CE needs to understand the FE=20 topology. The FE topology can be queried from the FEs by CEs. = =20 =20 Yang, et. al. Expires Dec 2003 [Page 12] =0C Internet Draft ForCES Framework June 2003 = =20 =20 3.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=20 manager may also be physically embedded into a CE and be = implemented=20 as a simple keypad or other direct configuration mechanism on = the=20 CE. 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 [6] or SNMP [4].=20 =20 3.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 CE = its=20 FEs should communicate, nor are restrictions placed on how FE=20 managers are implemented. Each FE should have one and only one = FE=20 manager, while different FEs may have the same or different FE=20 manager(s). Each manager can choose to exist and operate=20 independent of other manager.=20 =20 4. 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 4.1.Pre-association Phase=20 =20 Pre-association phase is the period of time during which an 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=20 none of this is within the scope of ForCES protocol.=20 =20 4.1.1. 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 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. = =20 Subsequent communication between CE managers and FE managers = may=20 =20 Yang, et. al. Expires Dec 2003 [Page 13] =0C Internet Draft ForCES Framework June 2003 = =20 =20 require other security functions such as privacy, = non-repudiation,=20 freshness, and integrity.=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 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 4.1.2. Ff Reference Point=20 =20 The Ff reference point is used to inform forwarding elements of = the=20 association decisions made by the FE manager in pre-association = phase. Only authorized entities may instruct a FE with respect = to=20 which CE should control it. Therefore, privacy, integrity,=20 freshness, and authentication are necessary between the FE = manager=20 and FEs when the FE manager is remote to the FE. Once the=20 appropriate security has been established, the FE manager = instructs=20 the FEs across this reference point to join a new NE or to=20 disconnect from an existing NE. The FE Manager could also = assign=20 unique FE identifiers to the FEs using this reference point. = The FE=20 identifiers are useful in post association phase to express FE=20 topology. Figure 8 shows example of message exchange over Ff=20 reference point.=20 =20 Note that the FE manager function may be co-located with the FE = (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 FE Manager FE CE Manager CE=20 | | | |=20 =20 Yang, et. al. Expires Dec 2003 [Page 14] =0C Internet Draft ForCES Framework June 2003 = =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 =20 4.1.3. Fc Reference Point=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=20 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 4.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 association establishment and = steady-state=20 communication. The communication between CE and FE is = performed=20 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 4.2.1. Proximity and Interconnect between CEs and FEs=20 =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 ([7]). Very Close localities consist of control and=20 forwarding elements that either are components in the same = physical=20 box, or are separated at most by one local network hop. =20 =20 Yang, et. al. Expires Dec 2003 [Page 15] =0C Internet Draft ForCES Framework June 2003 = =20 =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 [3] Section 5, requirement #1). ForCES will = make=20 use of an existing RFC2914 ([2]) compliant L4 protocol with = adequate=20 reliability, security and congestion control (e.g. TCP, SCTP) = for=20 transport purposes.=20 =20 4.2.2. Association Establishment=20 =20 =20 FE CE=20 | |=20 |(Security exchange.) |=20 1|<--------------------->|=20 | |=20 |(Let me join the NE please.) =20 2|---------------------->|=20 | |=20 |(What kind of FE are you? -- capability query)=20 3|<----------------------|=20 | |=20 |(Here is my FE functions/state: use model to = describe)=20 4|---------------------->|=20 | |=20 |(How are you connected with other FEs?)=20 5|<----------------------|=20 | |=20 |(Here is the FE topology info)=20 6|---------------------->|=20 | |=20 |(Initial config for FE -- optional)=20 7|<----------------------|=20 | |=20 |(I am ready to go. Shall I?) =20 8|---------------------->|=20 | |=20 |(Go ahead!) |=20 9|<----------------------|=20 | |=20 =20 Figure 9. Example of message exchange between CE and FE=20 over Fp to establish NE association=20 =20 As an example, figure 9 shows some of the message exchange that = may=20 happen before the association between the CE and FE is fully=20 established. Either the CE or FE can initiate the connection.=20 Security handshake is necessary to authenticate the two=20 communication endpoints to each other before any further = message=20 exchange can happen. The exact details of the security = handshake=20 depend on the security solution chosen by ForCES protocol. It = is=20 most likely that either IPSec or TLS will be used. Section 9=20 Yang, et. al. Expires Dec 2003 [Page 16] =0C Internet Draft ForCES Framework June 2003 = =20 =20 provides more details on the security considerations for = ForCES. =20 After the successful security handshake, the FE needs to inform = the=20 CE of its own capability and its topology in relation to other = FEs. =20 The capability of the FE is represented by the FE model, = described=20 in a separate document. The model would allow a FE to describe = what=20 kind of packet processing functions it contains, in what order = the=20 processing happens, what kinds of configurable parameters it = allows,=20 what statistics it collects and what events it might throw, = etc. =20 Once such information is available to the CE, the CE may choose = to=20 send some initial or default configuration to the FE so that = the FE=20 can start receiving and processing packets correctly. Such=20 initialization may not be necessary if the FE already obtains = the=20 information from its own bootstrap process. Once FE starts=20 accepting packets for processing, we say the association of = this FE=20 with its CE is now established. From then on, the CE and FE = enter=20 steady-state communication.=20 =20 =20 4.2.3. Steady-state Communication=20 =20 Once an association is established between the CE and FE, the = ForCES=20 protocol is used by the CE and FE over Fp reference point to=20 exchange information to facilitate packet processing. =20 =20 =20 FE CE=20 | |=20 |(Add these new routes.)|=20 1|<----------------------|=20 | |=20 |(Successful.) |=20 2|---------------------->|=20 | |=20 | |=20 |(Query some stats.) |=20 1|<----------------------|=20 | |=20 |(Reply with stats collected.) =20 2|---------------------->|=20 | |=20 | |=20 |(My port is down, with port #.) = =20 1|---------------------->|=20 | |=20 |(Here is a new forwarding table) =20 2|<----------------------| =20 | |=20 | |=20 =20 Figure 10. Examples of message exchange between CE and FE = over Fp during steady-state communication=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 17] =0C Internet Draft ForCES Framework June 2003 = =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 message exchange examples in which the = CE=20 sends new routes to the FE so that the FE can add them to its=20 forwarding table. The CE may query the FE for statistics = collected=20 by the FE and the FE may notify the CE of important events such = as=20 port failure.=20 =20 4.2.4. Data Packets across Fp reference point=20 =20 Control plane protocol packets (such as RIP, OSPF messages)=20 addressed to any of NE's interfaces are typically redirected by = the=20 receiving FE to its CE, and CE may originate packets and have = its FE=20 deliver them to other NEs. Therefore, ForCES protocol over Fp = not=20 only transports the ForCES protocol messages between CEs and = FEs,=20 but also encapsulates the data packets from control plane = protocols. =20 Moreover, one FE may be controlled by multiple CEs for = distributed=20 control. In this configuration, the control protocols = supported by=20 the FORCES NEs may spread across multiple CEs. For example, = one CE=20 may support routing protocols like OSPF and BGP, while a = signaling=20 and admission control protocol like RSVP is supported in = another CE. =20 FEs are configured to recognize and filter these protocol = packets=20 and forward them to the corresponding CE. =20 =20 --------------------- ----------------------=20 | | | |=20 | +--------+ | | +--------+ |=20 | |CE(BGP) | | | |CE(BGP) | |=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 Figure 11 shows one example of how the BGP packets originated = by=20 router A are passed to router B. In this example, the ForCES=20 protocol is used to transport the packets from the CE to the FE = inside router A, and then from the FE to the CE inside router = B. In=20 light of the fact that the ForCES protocol is responsible for=20 transporting both the control messages and the data packets = between=20 =20 Yang, et. al. Expires Dec 2003 [Page 18] =0C Internet Draft ForCES Framework June 2003 = =20 =20 the CE and FE over Fp reference point, it is possible to use = either=20 a single protocol or multiple protocols to achieve this.=20 =20 4.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 4.3. Association Re-establishment=20 =20 FEs and CEs may join and leave NEs dynamically (see [3] Section = 5,=20 requirements #12). When a FE or CE leaves the NE, the = association=20 with the NE is broken. If the leaving party rejoins a NE = later, to=20 re-establish the association, it may or may not need to = re-enter the=20 pre-association phase. Loss of association can also happen=20 unexpectedly due to loss of connection between the CE and the = 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=20 provide mechanisms to support association re-establishment. = This=20 includes the ability for CEs and FEs to determine when there is = a=20 loss of association between them, ability to restore = association and=20 efficient state (re)synchronization mechanisms (see [3] Section = 5,=20 requirement #7). Note that security association and state must = be=20 also re-established to guarantee the same level of security = exists=20 before and after the association re-establishment.=20 =20 4.3.1. CE graceful restart=20 =20 The failure and restart of the CE in a router can potentially = cause=20 much stress and disruption on the control plane throughout a=20 network. Because when a CE has to restart for any reason, the=20 router loses routing adjacencies or sessions with its routing=20 neighbors. Neighbors who detect the lost adjacency normally = re- compute new routes and then send routing updates to their own=20 neighbors to communicate the lost adjacency. Their neighbors = do the=20 same thing to propagate throughout the network. In the = meantime,=20 the restarting router cannot receive traffic from other routers = because the neighbors have stopped using the router=92s = previously=20 advertised routes. When the restarting router restores = adjacencies,=20 neighbors must once again re-compute new routes and send out=20 additional routing updates. The restarting router is unable to=20 forward packets until it has re-established routing adjacencies = with=20 neighbors, received route updates through these adjacencies, = and=20 computed new routes. Until convergence takes place throughout = the=20 network, packets may be lost in transient black holes or = forwarding=20 loops. =20 =20 Yang, et. al. Expires Dec 2003 [Page 19] =0C Internet Draft ForCES Framework June 2003 = =20 =20 =20 A high availability mechanism known as the "graceful restart" = has=20 been used by the IP routing protocols (OSPF [10], BGP [11], BGP = [11]) and MPLS label distribution protocol (LDP [9]) to help=20 minimize the negative effects on routing throughout an entire=20 network caused by a restarting router. Route flap on = neighboring=20 routers is avoided, and a restarting router can continue to = forward=20 packets that would otherwise be dropped. =20 =20 While the details differ from protocol to protocol, the general = idea=20 behind the graceful restart mechanism remains the same. With = the=20 graceful restart, a restarting router can inform its neighbors = when=20 it restarts. The neighbors may detect the lost adjacency but = do not=20 recompute new routes or send routing updates to their = neighbors. =20 The neighbors also hold on to the routes received from the=20 restarting router before restart and assume they are still = valid for=20 a limited time. By doing so, the restarting router=92s FEs can = also=20 continue to receive and forward traffic from other neighbors = for a=20 limited time by using the routes they already have. The = restarting=20 router then re-establishes routing adjacencies, downloads = updated=20 routes from all its neighbors, recomputes new routes and uses = them=20 to replace the older routes it was using. It then sends these=20 updated routes to its neighbors and signals the completion of = the=20 graceful restart process.=20 =20 Non-stop forwarding is a requirement for graceful restart. It = is=20 necessary so a router can continue to forward packets while it = is=20 downloading routing information and recomputing new routes. = This=20 ensures that packets will not be dropped. As one can see, one = of=20 the benefits afforded by the separation of CE and FE is exactly = the=20 ability of non-stop forwarding in the face of the CE failure = and=20 restart. The support of dynamic changes to CE/FE association = in=20 ForCES also makes it compatible with high availability = mechanisms=20 such as graceful restart.=20 =20 ForCES should be able to support CE graceful restart easily. = When=20 the association is established the first time, the CE must = inform=20 the FEs what to do in the case of CE failure. If graceful = restart=20 is not supported, the FEs may be told to stop packet processing = all=20 together if its CE fails. If graceful restart is supported, = the FEs=20 should be told to cache and hold on to its FE state including = the=20 forwarding tables across the restarts. A timer must be = included so=20 that the timeout causes such cached state to expire eventually. = =20 Those timers should be settable by the CE. =20 =20 4.3.2. FE restart=20 =20 In the same example in Figure 5, assuming CE1 is the working CE = for=20 the moment, what would happen if one of the FEs, say FE1, = leaves the=20 NE temporarily? FE1 may voluntarily decide to leave the=20 association. Alternatively, FE1 may stop functioning simply = due to=20 unexpected failure. In former case, CE1 receives a "leave- =20 Yang, et. al. Expires Dec 2003 [Page 20] =0C Internet Draft ForCES Framework June 2003 = =20 =20 association request" from FE1. In the latter, CE1 detects the=20 failure of FE1 by some other means. In both cases, CE1 must = inform=20 the routing protocols of such an event, most likely prompting a = reachability and SPF (Shortest Path First) recalculation and=20 associated downloading of new FIBs from CE1 to the other = remaining=20 FEs (only FE2 in this example). Such recalculation and FIB = update=20 will also be propagated from the CE1 to its neighbors that are=20 affected by the connectivity of FE1. =20 =20 When FE1 decides to rejoin again, or when it restarts again = from the=20 failure, FE1 needs to re-discover its master (CE). This can be = achieved by several means. It may re-enter the pre-association = phase and get that information from its FE manager. It may = retrieve=20 the previous CE information from its cache, if it can validate = the=20 information freshness. Once it discovers its CE, it starts = message=20 exchange with CE to re-establish the association just as = outlined in=20 Figure 9, with the possible exception that it might be able to=20 bypass the transport of the complete initial configuration. = Suppose=20 that FE1 still has its routing table and other state = information=20 from the last association, instead of sending all the = information=20 again from scratch, it may be able to use more efficient = mechanism=20 to re-sync up the state with its CE if such mechanism is = supported=20 by the ForCES protocol. For example, CRC-32 of the state might = give=20 a quick indication of whether or not the state is in-sync with = its=20 CE. By comparing its state with CE first, it sends information = update only if it is needed. ForCES protocol may choose to=20 implement similar optimization mechanisms, but it may also = choose=20 not to, as this is not a requirement.=20 =20 =20 5. Applicability to RFC1812 =20 =20 [3] Section 5, requirement #9 dictates that "All proposed = ForCES=20 architecture must explain how that architecture supports all of = the=20 router functions as defined in RFC1812." RFC1812 discusses = many=20 important requirements for IPv4 routers from the link layer to = the=20 application layer. This section addresses the relevant = requirements=20 in RFC1812 for implementing IPv4 routers based on ForCES=20 architecture and explains how ForCES satisfies these = requirements by=20 providing guidelines on how to separate the functionalities = required=20 into forwarding plane and control plane. =20 =20 In general, the forwarding plane carries out the bulk of the = per- packet processing that is required at line speed, while the = control=20 plane carries most of the computationally complex operations = that=20 are typical of the control and signaling protocols. However, = it is=20 impossible to draw a rigid line to divide the processing into = CEs=20 and FEs cleanly. Nor should the ForCES architecture limit the=20 innovative approaches in control and forwarding plane = separation. =20 As more and more processing power is available in the FEs, some = of=20 the control functions that traditionally are performed by CEs = may=20 now be moved to FEs for better performance and scalability. = Such=20 offloaded functions may include part of ICMP or TCP processing, = or=20 =20 Yang, et. al. Expires Dec 2003 [Page 21] =0C Internet Draft ForCES Framework June 2003 = =20 =20 part of routing protocols. Once off-loaded onto the forwarding = plane, such CE functions, even though logically belonging to = the=20 control plane, now become part of the FE functions. Just like = the=20 other logical functions performed by FEs, such off-loaded = functions=20 must be expressed as part of the FE model so that the CEs can = decide=20 how to best take advantage of these off-loaded functions when=20 present on the FEs.=20 =20 5.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. =20 Therefore, this router NE provides four external interfaces = (#1, 2,=20 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 [1] 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 [1] Section 6). One important class of application=20 protocols is routing protocols (see RFC1812 [1] Section 7). In = ForCES architecture, routing protocols are naturally = implemented by=20 CEs. Routing protocols require routers communicate with each = other. =20 =20 Yang, et. al. Expires Dec 2003 [Page 22] =0C Internet Draft ForCES Framework June 2003 = =20 =20 This communication between CEs in different routers is = supported in=20 ForCES by FEs' ability to redirect data packets addressed to = routers=20 (i.e., NEs) and CEs' ability to originate packets and have them = delivered by their FEs. This communication occurs across Fp=20 reference point inside each router and between neighboring = routers'=20 external interfaces, as illustrated in Figure 11. =20 =20 5.2.Link Layer=20 =20 Since FEs own all the external interfaces for the router, FEs = need=20 to conform to the link layer requirements in RFC1812. = Arguably, ARP=20 support may be implemented in either CEs or FEs. As we will = see=20 later, a number of behaviors that RFC1812 mandates fall into = this=20 category -- they may be performed by the FE and may be = performed by=20 the CE. A general guideline is needed to ensure = interoperability=20 between separated control and forwarding planes. The guideline = we=20 offer here is that in general CEs are required to be capable of = these kind of operations while FEs may or may not choose to=20 implement them. FE model should indicate its capabilities in = this=20 regard so that CEs can decide where these functions are = implemented.=20 =20 Interface parameters, including MTU, IP address, etc., must be=20 configurable by CEs via ForCES. CEs must be able to determine=20 whether a physical interface in an FE is available to send = packets=20 or not. FEs must also inform CEs the status change of the=20 interfaces (like link up/down) via ForCES.=20 =20 5.3.Internet Layer Protocols=20 =20 Both FEs and CEs must implement IP protocol and all mandatory=20 extensions as RFC1812 specified. CEs should implement IP = options=20 like source route and record route while FEs may choose to = implement=20 those as well. Timestamp option should be implemented by FEs = to=20 insert the timestamp most accurately. FE must interpret the IP = options that it understands and preserve the rest unchanged for = use=20 by CEs. Both FEs and CEs might choose to silently discard = packets=20 without sending ICMP errors, but such events should be logged = and=20 counted. FEs may report statistics for such events to CEs via=20 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=20 example, it can be always decremented by the last FE with = egress=20 function. =20 =20 FEs must receive and process normally any packets with a = broadcast=20 destination address or a multicast destination address that the = router has asked to receive. When IP multicast is supported in = routers, IGMP is implemented in CEs. CEs are also required of = ICMP=20 support, while it is optional for FEs to support ICMP. Such an = option can be communicated to CEs as part of the FE model. =20 Therefore, FEs can always rely upon CEs to send out ICMP error=20 =20 Yang, et. al. Expires Dec 2003 [Page 23] =0C Internet Draft ForCES Framework June 2003 = =20 =20 messages, but FEs also have the option to generate ICMP error=20 messages themselves. =20 =20 5.4.Internet Layer Forwarding=20 =20 IP forwarding is implemented by FEs. When the routing table is = updated at CEs, ForCES is used to send the new route entries = from=20 CEs to FEs. Each FE has its own forwarding table and uses this = table to direct packets to the next hop interface. =20 =20 Upon receiving IP packets, FE verifies the IP header and = processes=20 most of the IP options. Some options cannot be processed until = the=20 routing decision has been made. Routing decision is made after = examining the destination IP address. If the destination = address=20 belongs to the router itself, the packets are filtered and = either=20 processed locally or forwarded to CE, depending upon the=20 instructions set-up by CE. Otherwise, FE determines the next = hop IP=20 address by looking up in its forwarding table. FE also = determines=20 the network interface it uses to send the packets. Sometimes = FE may=20 need to forward the packets to another FE before packets can be = forwarded out to the next hop. Right before packets are = forwarded=20 out to the next hop, FE decrements TTL by 1 and processes any = IP=20 options that cannot be processed before. FE performs any IP=20 fragmentation if necessary, determines link layer address = (e.g., by=20 ARP), and encapsulates the IP datagram (or each of the = fragments=20 thereof) in an appropriate link layer frame and queues it for = output=20 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 do not know how = to=20 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 = 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 = 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 5.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 =20 Yang, et. al. Expires Dec 2003 [Page 24] =0C Internet Draft ForCES Framework June 2003 = =20 =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 some = layer-4=20 transport is used to support ForCES, then both CEs and FEs need = to=20 implement the L4 transport and ForCES protocols. =20 =20 5.6. Application Layer -- Routing Protocols=20 =20 Interior and exterior routing protocols are implemented on CEs. = The=20 routing packets originated by CEs are forwarded to FEs for = delivery. =20 The results of such protocols (like forwarding table updates) = are=20 communicated to FEs via ForCES.=20 =20 For performance or scalability reasons, portions of the control = plane functions that need faster response may be moved from the = CEs=20 and off-loaded onto the FEs. For example in OSPF, the Hello=20 protocol packets are generated and processed periodically. = When=20 done at CEs, the inbound Hello packets have to traverse from = the=20 external interfaces at the FEs to the CEs via the internal = CE-FE=20 channel. Similarly, the outbound Hello packets have to go from = the=20 CEs to the FEs and to the external interfaces. Frequent Hello=20 updates place heavy processing overhead on the CEs and can = overwhelm=20 the CE-FE channel as well. Since typically there are far more = FEs=20 than CEs in a router, the off-loaded Hello packets are = processed in=20 a much more distributed and scalable fashion. By expressing = such=20 off-loaded functions in the FE model, we can ensure=20 interoperability.=20 =20 5.7. Application Layer -- Network Management Protocol=20 =20 RFC1812 also dictates "Routers MUST be manageable by SNMP." = (see=20 [4] Section 8) In general, for post-association phase, most = external=20 management tasks (including SNMP) should be done through = interaction=20 with the CE in order to support the appearance of a single=20 functional device. Therefore, it is recommended that SNMP=20 management agent be implemented by CEs and the SNMP messages=20 received by FEs be redirected to their CEs. AgentX framework=20 defined in RFC2741 ([5]) may be applied here such that CEs act = in=20 the role of master agent to process SNMP protocol messages = while FEs=20 act in the role of subagent to provide access to the MIB = objects=20 residing on FEs. AgentX protocol messages between the master = agent=20 (CE) and the subagent (FE) are encapsulated and transported via = ForCES, just like data packets from any other application layer = protocols. =20 =20 6. Summary=20 =20 This document defines an architectural framework for ForCES. = It=20 identifies the relevant components for a ForCES network = element,=20 including (one or more) FEs, (one or more) CEs, one optional FE = manager, and one optional CE manager. It also identifies the=20 interaction among these components and discusses all the major=20 =20 Yang, et. al. Expires Dec 2003 [Page 25] =0C Internet Draft ForCES Framework June 2003 = =20 =20 reference points. It is important to point out that, among all = the=20 reference points, only the Fp interface between CEs and FEs is=20 within the scope of ForCES. ForCES alone may not be enough to=20 support all desirable NE configurations. However, we believe = that=20 ForCES over Fp interface is the most important element in = realizing=20 physical separation and interoperability of CEs and FEs, and = hence=20 the first interface that ought to be standardized. Simple and=20 useful configurations can still be implemented with only CE-FE=20 interface being standardized, e.g., single CE with full-meshed = FEs.=20 =20 7. Security Considerations=20 =20 In general, the physical separation of two entities usually = results=20 in a potentially insecure link between the two entities and = hence=20 much stricter security measurements are required. For example, = we=20 pointed out in Section 4.1 that authentication becomes = necessary=20 between CE manager and FE manager, between CE and CE manager,=20 between FE and FE manager in some configurations. The physical = separation of CE and FE also imposes serious security = requirement=20 for ForCES protocol over Fp interface. This section first = attempts=20 to describe the security threats that may be introduced by the=20 physical separation of the FEs and the CEs, and then it = provides=20 recommendation and guidelines for secure operation and = management of=20 ForCES protocol over Fp interface.=20 =20 7.1. Analysis of Potential Threats Introduced by ForCES=20 =20 This section provides the threat analysis for ForCES, with a = focus=20 on Fp interface. Each threat is described in details with the=20 effects on the ForCES protocol entities or/and the NE as a = whole,=20 and the required functionalities that need to be in place to = defend=20 the threat. =20 =20 7.1.1. =91=91Join=92=92 or =91=91Remove=92=92 Flooding on CEs=20 =20 Threats: A malicious node could send a stream of false = =91=91join NE=92=92 or=20 =91=91remove from NE=92=92 requests on behalf of non-existent = or unauthorized=20 FE to legitimate CEs at a very rapid rate and thereby create=20 unnecessary state in the CEs.=20 =20 Effects: If by maintaining state for non-existent or = unauthorized=20 FEs, a CE may become unavailable for other processing and hence = suffer from denial of service (DoS) attack similar to the TCP = SYN=20 DoS. If multiple CEs are used, the unnecessary state = information may=20 also be conveyed to multiple CEs via Fr interface (e.g., from = the=20 active CE to the stand-by CE) and hence subject multiple CEs to = DoS=20 attack. =20 =20 Requirement: A CE that receives a =91=91join=92=92 or = =91=91remove=92=92 request should=20 not create any state information until it has authenticated the = FE=20 endpoint.=20 =20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 26] =0C Internet Draft ForCES Framework June 2003 = =20 =20 7.1.2. Impersonation Attack =20 =20 Threats: A malicious node can impersonate a CE or FE and send = out=20 false messages.=20 =20 Effects: The whole NE could be compromised.=20 =20 Requirement: The CE or FE must authenticate the message before = accepting and processing it. =20 =20 =20 7.1.3. Replay Attack=20 =20 Threat: A malicious node could replay the entire message = previously=20 sent by a FE or CE entity to get around authentication. =20 =20 Effect: The NE could be compromised.=20 =20 Requirement: Replay protection mechanism needs to be part of = the=20 security protocol to defend this attack.=20 =20 7.1.4. Attack during Fail Over=20 =20 Threat: A malicious node may exploit the CE fail-over mechanism = to=20 take over the control of NE. For example, suppose two CE=92s, = say CE-A=20 and CE-B, are controlling several FE=92s. CE-A is active and = CE-B is=20 stand-by. When CE-A fails, CE-B is taking over the active CE=20 position. The FEs already had a trusted relationship with = CE-A, but=20 the FEs may not have the same trusted relationship established = with=20 CE-B prior to the fail-over. A malicious node can take over as = CE-B=20 if such trusted relationship is not established during the = fail- over. =20 =20 Effect: The NE may be compromised after such insecure = fail-over.=20 =20 Requirement: The level of trust relationship between the = stand-by=20 CE and the FEs must be as strong as the one between the active = CE=20 and the FEs, and such security association must be = re-established=20 during fail-over.=20 =20 7.1.5. Data Integrity =20 =20 Threats: A malicious node may inject false messages to = legitimate CE=20 or FE. =20 =20 Effect: An FE or CE receives the fabricated packet and performs = incorrect or catastrophic operation.=20 =20 Requirement: Protocol messages require integrity protection.=20 =20 7.1.6. Data Confidentiality=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 27] =0C Internet Draft ForCES Framework June 2003 = =20 =20 Threat: When FE and CE are physically separated, a malicious = node=20 may eavesdrop the messages in transit. Some of the messages are = critical to the functioning of the whole network, while others = may=20 contain confidential business data. Leaking of such information = may=20 result in compromise even beyond the immediate CE or FE. =20 =20 Effect: Sensitive information might be exposed between CE and = FE.=20 =20 Requirement: Data confidentiality between FE and CE must be=20 available for sensitive information.=20 =20 7.1.7. Sharing security parameters=20 =20 Threat: Consider a scenario where several FEs communicating to = the=20 same CE share the same authentication keys for the Fp = interface. If=20 any FE or the CE is compromised, all other entities are = compromised.=20 =20 Effect: The whole NE is compromised.=20 =20 Requirement: To avoid this side effect, it=92s better to = configure=20 different security parameters for each FE-CE communication over = Fp=20 interface.=20 =20 7.1.8. Denial of Service Attack via External Interface=20 =20 Threat: When an FE receives a packet that is destined for its = CE,=20 the FE forwards the packet over the Fp interface. Malicious = node can=20 generate huge message storm like routing protocol packets etc.=20 through the external Fi/f interface so that the FE has to = process=20 and forward all packets to CE through Fp interface.=20 =20 Effect: CE encounters resource exhaustion and bandwidth = starvation=20 on Fp interface due to an overwhelming number of packets from = FEs.=20 =20 Requirement: Rate limiting mechanism needs to be in place at = both FE=20 and CE. Rate Limiter can be configured at FE for each message = type=20 that are being received through Fi/F interface.=20 =20 7.2. Security Recommendations for ForCES=20 =20 The requirements document [3] suggested that ForCES protocol = should=20 support reliability over Fp interface, but no particular = transport=20 protocol is yet specified for ForCES. This framework document = does=20 not intend to specify the particular transport either, and so = we=20 only provide recommendations and guidelines based on the = existing=20 standard security protocols that can work with the common = transport=20 candidates suitable for ForCES.=20 =20 We highlight two existing security protocol solutions, namely = IPsec=20 (IP Security) [14] or TLS (Transport Layer Security) [13]. TLS = works=20 with reliable transports such as TCP or SCTP, while IPsec can = be=20 used with any transport (UDP, TCP, SCTP). Both TLS and IPsec = can be=20 =20 Yang, et. al. Expires Dec 2003 [Page 28] =0C Internet Draft ForCES Framework June 2003 = =20 =20 used potentially to satisfy all of the security requirements = for=20 ForCES protocol.=20 =20 It is important to realize that even if the NE is in a = single-box,=20 the DoS attacks can still be launched through Fi/f interfaces.=20 Therefore, it is still important to have counter-measurement as = stated in 1.1.9 for DoS while authentication, confidentiality = and=20 integrity can be provided by the physical security of the box.=20 =20 7.2.1. Security Configuration =20 =20 The NE administrator has the freedom to determine the exact = security=20 configuration that is needed for the specific deployment. For=20 example, ForCES may be deployed between CEs and FEs connected = to=20 each other inside a box over a backplane. In such scenario,=20 physical security of the box ensures that most of the attacks = such=20 as man-in-the-middle, snooping, and impersonation are not = possible,=20 and hence ForCES architecture may rely on the physical security = of=20 the box to defend against these attacks and protocol mechanisms = may=20 be turned off. However, it is also shown that denial of = service=20 attack via external interface as described in Section 7.1.8 is = still=20 a potential threat even for such =91=91all-in-one-box=92=92 = deployment=20 scenario and hence the rate limiting mechanism is still = necessary. =20 This is just one example to show that it is important to assess = the=20 security needs of the ForCES-enabled network elements under=20 different deployment scenarios. It should be possible for the=20 administrator to configure the level of security needed for the = ForCES protocol.=20 =20 7.2.2. Using TLS with ForCES=20 =20 TLS [13] can be used if a reliable transport such as TCP or = SCTP is=20 used for ForCES over Fp interface. The TLS handshake protocol = is=20 used during association establishment or re-establishment phase = to=20 negotiate a TLS session between the CE and FE. Once the = session is=20 in place, the TLS record protocol is used to secure ForCES=20 communication messages between the CE and FE.=20 =20 A basic outline of how TLS can be used with ForCES is described = below. Steps 1) till 7) complete the security handshake as=20 illustrated in Figure 9 while step 8) is for all the further=20 communication between the CE and FE, including the rest of = messages=20 after the security handshake shown in Figure 9 and the = steady-state=20 communication shown in Figure 10.=20 =20 1) During Pre-association phase all FEs are configured with the = CEs=20 (including both the active CE and the standby CE). =20 2) The FE establishes a TLS connection with the CE (master) and = negotiates a cipher suite.=20 3) The FE (slave) gets the CE certificate, validates the = signature,=20 checks the expiration date, checks if the certificate has been=20 revoked.=20 =20 Yang, et. al. Expires Dec 2003 [Page 29] =0C Internet Draft ForCES Framework June 2003 = =20 =20 4) The CE (master) gets the FE certificate and performs the = same=20 validation as the FE in step 4). =20 5) If any of the check fails in step 5 or step 6, endpoint must = generate an error message and abort.=20 6) After successful mutual authentication, a TLS session is=20 established between CE and FE.=20 7) The FE sends a =91=91join NE=92=92 message to the CE. =20 8) The FE and CE use TLS session for further communication.=20 =20 Note that there are different ways for the CE and FE to = validate a=20 received certificate. One way is to configure the FE Manager or = CE=20 Manager or other central component as CA, so that the CE or FE = can=20 query this pre-configured CA to validate that the certificate = has=20 not been revoked. Another way is to have the CE and the FE=20 configured directly a list of valid certificates in the pre- association phase. =20 =20 In the case of fail-over, it is the responsibility of the = active CE=20 and the standby CE to synchronize ForCES states including the = TLS=20 states to minimize the state reestablishment during fail-over. = Care=20 must be taken to ensure that the standby CE is also = authenticated in=20 the same way as the active CE, either before or during the = fail- over.=20 =20 7.2.3. Using IPsec with ForCES=20 =20 IPsec [14] can be used with any transport protocol, such as = UDP,=20 SCTP and TCP over Fp interface for ForCES. We recommend using = ESP=20 in transport mode for ForCES because message confidentiality is = required for ForCES and the communication between the CE and FE = is=20 point-to-point. =20 =20 IPsec can be used with both manual and automated SA and=20 cryptographic key management. But Ipsec=92s replay protection=20 mechanisms are not available if manual key management is used. = Hence, automatic key management is recommended if replay = protection=20 is deemed important. Otherwise, manual key management might be = sufficient for some deployment scenarios, esp. when the number = of=20 CEs and FEs is relatively small. It is recommended that the = keys be=20 changed periodically even for manual key management.=20 =20 Unlike TLS, IPsec provides security services between the CE and = FE=20 at IP level, and so the security handshake as illustrated in = Figure=20 9 amounts to a =91=91no-op=92=92 when manual key management is = used. The=20 following outline the steps taken for ForCES in such a case.=20 =20 1) During Pre-association phase all FEs are configured with the = CEs=20 (including active CE and standby CE) and SA parameters = manually.=20 2) The FE sends a =91=91join NE=92=92 message to the CE. This = message and all=20 others that follow are afforded security service according to = the=20 manually configured IPsec SA parameters, but replay protection = is=20 not available. =20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 30] =0C Internet Draft ForCES Framework June 2003 = =20 =20 It is up to the administrator to decide whether to share the = same=20 key across multiple FE-CE communication, but it is recommended = that=20 different keys be used. Similarly, it is recommended that = different=20 keys be used for inbound and outbound traffic.=20 =20 If automatic key management is needed, IKE [15] can be used for = that=20 purpose. Other automatic key distribution techniques such as=20 Kerberos may be used as well. The key exchange process = constitutes=20 the security handshake as illustrated in Figure 9. The = following=20 shows the steps involved in using IKE with IPsec for ForCES. = Steps=20 1) to 6) constitute the security handshake in Figure 9.=20 =20 1) During Pre-association phase all FEs are configured with the = CEs=20 (including active CE and standby CE), IPsec policy etc.=20 2) The FE kicks off IKE process and tries to establish an IPsec = SA=20 with the CE (master). The FE (Slave) gets the CE certificate as = part=20 of the IKE negotiation. The FE validates signature, checks the=20 expiration date, checks if the certificate has been revoked.=20 3) The CE (master) gets the FE certificate and performs the = same=20 check as the FE in step 3).=20 4) If any of the check fails in step 3 or step 4, the endpoint = must=20 generate an error message and abort.=20 5) After successful mutual authentication, IPsec session is=20 established between the CE and FE.=20 6) The FE sends a =91=91join NE=92=92 message to CE. No SADB = entry is created=20 in FE yet.=20 7) The FE and CE use the IPsec session for further = communication.=20 =20 FE Manager or CE Manager or other central component can be used = as=20 CA for validating CE and FE certificates during the IKE = process. =20 Alternatively, during the pre-association phase, the CE and FE = can=20 be configured directly with the required information such as=20 certificates or passwords etc depending upon the type of=20 authentication that administrator wants to configure. =20 =20 In the case of fail-over, it is the responsibility of active CE = and=20 standby CE to synchronize ForCES states and IPsec states to = minimize=20 the state reestablishment during fail-over. Alternatively, the = FE=20 needs to establish different IPsec SA during the startup = operation=20 itself with each CE=92s. This will minimize the periodic state=20 transfer across IPsec layer though Fr (CE-CE) Interface. =20 =20 =20 8. Normative References=20 =20 [1] F. Baker, =91=91Requirements for IP Version 4 Routers", = RFC1812, June=20 1995.=20 =20 [2] S. Floyd, =91=91Congestion Control Principles", RFC2914, = September=20 2000.=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 31] =0C Internet Draft ForCES Framework June 2003 = =20 =20 [3] H. Khosravi, et. al., =91=91Requirements for Separation of = IP Control=20 and Forwarding", work in progress, May 2003, = .=20 =20 9. Informative References=20 =20 [4] J. Case, et. al., =91=91A Simple Network Management = Protocol (SNMP)",=20 RFC1157, May 1990.=20 =20 [5] M. Daniele, et. al., =91=91Agent Extensibility (AgentX) = Protocol=20 Version 1", RFC2741, Jan 2000.=20 =20 [6] K. Chan, et. al., =91=91COPS Usage for Policy Provisioning = (COPS- PR)", RFC3084, March 2001.=20 =20 [7] A. Crouch, et. al., =91=91ForCES Applicability Statement", = work in=20 progress, June 2002, .=20 =20 [8] T. Anderson, J. Buerkle, =91=91Requirements for the Dynamic = Partitioning of Switching Elements", RFC3532, May 2003.=20 =20 [9] M. Leelanivas, et. al., =91=91Graceful Restart Mechanism = for Label=20 Distribution Protocol=92=92, RFC 3478, Feb. 2003.=20 =20 [10] J. Moy, et. al., =91=91Graceful OSPF Restart=92=92, work = in progress,=20 March 2003, .=20 =20 [11] S. R. Sangli, et. al., =91=91Graceful Restart Mechanism = for BGP=92=92,=20 work in progress, Jan 203, < draft-ietf-idr-restart-06.txt>.=20 =20 [12] M. Shand and L. Ginsberg, =91=91Restart Signaling for = IS-IS=92=92, work=20 in progress, March 2003, .=20 =20 [13] T. Dierks and C. Allen, =91=91The TLS Protocol, version = 1.0=92=92,=20 RFC2246, Jan. 1999.=20 =20 [14] S. Kent and R. Atkinson, =91=91Security Architecture for = the=20 Internet Protocol=92=92, RFC2401, Nov. 1998.=20 =20 [15] D. Harkins and D. Carrel, =91=91The Internet Key Exchange = (IKE)=92=92,=20 RFC2409, Nov. 1998.=20 =20 [16] S. M. Bellovin, =91=91Guidelines for Mandating the Use of = Ipsec=92=92,=20 work in progress, Oct. 2002, .=20 =20 10. Acknowledgement=20 =20 Joel M. Halpern gave us many insightful comments and = suggestions and=20 pointed out several major issues. T. Sridhar suggested that = the=20 AgentX protocol could be used with SNMP to manage the ForCES = network=20 elements. Many of our colleagues and people in the ForCES = mailing=20 list also provided valuable feedback.=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 32] =0C Internet Draft ForCES Framework June 2003 = =20 =20 11. Authors' Addresses=20 =20 Lily L. Yang=20 Intel Corp., MS JF3-206,=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 Department of Computer Science,=20 University of North Texas,=20 Denton, Texas, 76203=20 Phone: +1 940 565 2822=20 Email: rdantu@unt.edu=20 =20 Todd A. Anderson=20 Intel Corp.=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 Ram Gopal=20 Nokia Research Center=20 5, Wayside Road,=20 Burlington, MA 01803=20 Phone: +1 781 993 3685=20 Email: ram.gopal@nokia.com=20 =20 12. Intellectual Property Right=20 =20 The authors are not aware of any intellectual property right = issues=20 pertaining to this document.=20 =20 13. Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2002). All Rights Reserved. = =20 This document and translations of it may be copied and = furnished to=20 others, and derivative works that comment on or otherwise = explain it=20 or assist in its implementation may be prepared, copied, = published=20 and distributed, in whole or in part, without restriction of = any=20 kind, provided that the above copyright notice and this = paragraph=20 are included on all such copies and derivative works. However, = this=20 document itself may not be modified in any way, such as by = removing=20 the copyright notice or references to the Internet Society or = other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other = than=20 English.=20 =20 Yang, et. al. Expires Dec 2003 [Page 33] =0C Internet Draft ForCES Framework June 2003 = =20 =20 =20 The limited permissions granted above are perpetual and will = not be=20 revoked by the Internet Society or its successors or assigns.=20 This document and the information contained herein is provided = on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION = HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES = OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 34] =0C ------_=_NextPart_000_01C32ECE.61798380-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 9 17:44:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22157 for ; Mon, 9 Jun 2003 17:44:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PUPV-0007Im-00 for forces-archive@IETF.ORG; Mon, 09 Jun 2003 17:42:37 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19PUPO-0007Id-00 for forces-archive@IETF.ORG; Mon, 09 Jun 2003 17:42:30 -0400 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.00A08972@cherry.ease.lsoft.com>; Mon, 9 Jun 2003 17:44:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45090038 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 9 Jun 2003 17:44:20 -0400 Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Jun 2003 17:44:19 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h59Ldjp00992 for ; Mon, 9 Jun 2003 21:39:45 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h59LbaR23993 for ; Mon, 9 Jun 2003 21:37:36 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003060914402822323 ; Mon, 09 Jun 2003 14:40:32 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 14:43:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C32ED0.2E37F400" Approved-By: "Yang, Lily L" Message-ID: Date: Mon, 9 Jun 2003 14:43:35 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: AD/Routing Directorate Feedback, ForCES Framework Draft Comments: To: "Putzolu, David" , dro@zurich.ibm.com, Alex Zinin Comments: cc: rdantu@unt.edu, "Anderson, Todd A" , ram.gopal@nokia.com 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_01C32ED0.2E37F400 Content-Type: text/plain; charset="ISO-8859-1" Hi, David, Patrick and Alex -- In early April, we received some feedback on the ForCES framework draft from the ADs and the routing directorate. A summary of the authors' responds is provided here. Attached you find the new version of the draft that we just submitted. Please review the new document and let us know our next steps in the RFC process. Lily --------------summary of our respond------------- The following format is used to address each comment/concern listed in David Putzolu's original posting. [summary of comments]... [summary of authors' discussion] ... [document change] ... 1) FE Virtualization [summary of comments] A single physical FE might be partitioned into multiple virtual FEs. I think the requirements talks abut this but the framework doesn't explicitly call out how this is handled. I believe the approach being taken is one where each FE (where FE is defined as the slave endpoint of an Fp connection) is a single logical entity, and partitioning of a physical FE into multiple such entities is beyond the scope of Fp and is instead a pre-association phase issue. The framework should explicitly call this out and may also want to include a reference to the new informational RFC that just issued on requirements for accomplishing this from the GSMP wg. RFC-Editor has not yet gotten around to it, so here is the URL for the draft: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-dyn-part-reqs-03.txt [summary of authors' discussion] FE partition should be done in the pre-association phase and hence ForCES is agnostic to the FE partitioning. [document change] Section 3.2 first paragraph is modified to point this out. 2) Multiple FEMgrs [summary of comments] The framework seems to say that there is one FE manager. It is possible that in some architectures each FE may have associated with it a FEMgr, thus necessitating selection of a single FEMgr among many. The rtg-dir questioned where such an interaction fits in the framework. Initial impression was that this would be a Fi interaction (if the FEMgrs are collocated with the FEs). Is this the right place, and if so, it should be documented. [summary of authors' discussion] We believe this is not an issue. It is perfectly ok for each FE has its own FEMgr, and as long as each FEMgr does its job by telling its FE which CE it belongs to, we see no any need to coordinate among the multiple FEMgrs, nor any need to elect only single FEMgr among many. [document change] None. 3) DoS attacks [summary of comments] 4.2.4 should explicitly call out that Fp could be a vector used by adversaries for DoS attacks on the NE. As such, it should explicitly be said that the combination of packet filterings on FEs, plus prioritization of specific packets being sent across Fp, helps to combat such attacks. Also - probably add a SHOULD that FEs should support the ability to do rate limiting of packets to CE. This is necessary to prevent flooding of the CE w/packets from FE. [summary of authors' discussion] Agree. This is an important point that should be captured in the security consideration section. [document change] Section 7 (security consideration) is rewritten with detailed threat analysis including DoS attack. 4) OSPF Offload [summary of comments] The ADs and the rtg-dir where both concerned that features such as OSPF offload, while useful, are probably so new that standardizing support for them is not practical in the first rev of forces. They suggested that support for that be removed from sections 5, 5.2, and 5.6. [summary of authors' discussion] This is entirely requirements-driven. The mailing list had some discussion long ago on this and the requirement draft reflected it. Since the new requirement draft still calls for such support, we maintain the same stand on this. [document change] None. 5) Non-stop forwarding/Graceful restart [summary of comments] Section 4.3 talks a bit about features needed for graceful restart, and requirements section 5 item 7 discusses this topic. The framework should explicitly spell out the need to support this and name it appropriately ("graceful restart") in its own section. In that section the framework should indicate the specific capabilities that FEs are expected to provide to enable graceful restart, i.e. "In order to enable graceful restart, FEs MAY choose to cash forwarding and QoS state across CE restarts. If they do so, they MUST include timers that eventually cause such cached state to expire. Those timers SHOULD be settable by CEs." (Note: this is just an example, need to be more specific about this. Include justifications & refs to appropriate RFCs, WGs, and drafts). [summary of authors' discussion] Agree. [document change] Section 4.3 "Association Re-establishment" is rewritten and reorganized into 2 subsections. 4.3.1 "CE graceful Restart" is devoted to this issue. References to graceful restart [9-12] are also added. 6) Terminology issue: route vs. forward [summary of comments] Section 4.2.3 shows a "route to this port instead" message going from CE to FE. Would be more accurate to indicate that the CE is downloading a new FIB to the FE here. [summary of authors' discussion] Agree. [document change] Figure 10 is fixed. 7) Vagueness of CE action in response to FE loss/reestablishment [summary of comments] Section 4.3 says a CE would "note" the event of FE loss or reestablishment. Would be more informative to say that the CE would inform routing protocols of such an event, most likely prompting a reachability and SPF recalculation and associated downloading of new FIB and other calculations. [summary of authors' discussion] Agree. [document change] Section 4.3.2 "FE restart" is rewritten with such clarification. 8) Security handshakes as part of association establishment and re-establishment [summary of comments] Sections 4.2.2 and 4.2.4 should explicitly call out the fact that FEs and CEs will perform a security handshake as part of the association establishment/re-establishment interaction. Need to make sure that the association is the intended one. Authentication mechanism (IPSec? TLS? other?) to be used to accomplish this should be identified. [summary of authors' discussion] Agree. Security handshake should be called out explicitly in 4.2.2, but the details of such handshake is left to Security Consideration section. [document change] Sections 4.2.2, 4.3 and Figure 7 are fixed to call out the security handshake and re-establishment explicitly. More details on this is provided in Section 7.2. 9) Cached state in re-establishment [summary of comments] The end of section 4.3 mentions the possibility that a FE may reuse cached state to save Fp interactions during a connection re-establishment. While it is ok for the framework to call out such a possibility, it should also make it clear that whether such a feature is actually part of Fp will depend on protocol selection/definition. Also, a checksum is a poor choice as it is rather unreliable. FIBs are very important and as such a more reliable mechanism (e.g. CRC-32) should be used. [summary of authors' discussion] Agree. [document change] Section 4.3.2 clarifies this. 10) Security Considerations [summary of comments] This is where the IESG expects the security analysis of the framework and outlining the actual security mechanisms that should be present in the architecture. The document should provide vulnerability analysis of the framework, and how identified vulnerabilities should be covered. [summary of authors' discussion] Agree. [document change] Section 7 is rewritten entirely to provide detailed threat analysis and security recommendation based on TLS and IPsec. We didn't choose one over the other here because we believe it is best to delay the decision of choosing a specific security mechanism to protocol design phase, when the proper choice of transport should be debated first before we can debate the right choice for security. 11) Editorial changes [summary of comments] Security considerations belongs before references. There are 8 bit characters in the draft that need to be excised. [summary of authors' discussion] Agree. [document change] Fixed. ------_=_NextPart_000_01C32ED0.2E37F400 Content-Type: text/plain; name="draft-ietf-forces-framework-05.txt" Content-Disposition: attachment; filename="draft-ietf-forces-framework-05.txt" Content-Transfer-Encoding: quoted-printable =20 Internet Draft L. = Yang=20 Expiration: Dec 2003 Intel = Corp.=20 File: draft-ietf-forces-framework-05.txt R. = Dantu=20 Working Group: ForCES Univ. of North = Texas =20 T. = Anderson=20 Intel = Corp.=20 R. = Gopal=20 = Nokia =20 June = 2003 =20 =20 =20 Forwarding and Control Element Separation (ForCES) = Framework=20 =20 =20 =20 =20 draft-ietf-forces-framework-05.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 Copyright Notice =20 =20 Copyright (C) The Internet Society (2002). All Rights = Reserved.=20 =20 Abstract=20 =20 This document defines the architectural framework for the = ForCES=20 (Forwarding and Control Element Separation) network elements, = and=20 identifies the associated entities and the interaction among = them.=20 =20 Table of Contents=20 =20 =0C Internet Draft ForCES Framework June 2003 = =20 =20 =20 1. = Definitions.....................................................3=20 2. Introduction to Forwarding and Control Element Separation=20 = (ForCES)...........................................................5=20 3. = Architecture....................................................8=20 3.1. Control Elements and Fr Reference = Point....................9=20 3.2. Forwarding Elements and Fi reference = point................10=20 3.3. CE = Managers...............................................13=20 3.4. FE = Managers...............................................13=20 4. Operational = Phases.............................................13=20 4.1. Pre-association = Phase.....................................13=20 4.1.1. Fl Reference = Point...................................13=20 4.1.2. Ff Reference = Point...................................14=20 4.1.3. Fc Reference = Point...................................15=20 4.2. Post-association Phase and Fp reference = point.............15=20 4.2.1. Proximity and Interconnect between CEs and = FEs.......15=20 4.2.2. Association = Establishment............................16=20 4.2.3. Steady-state = Communication...........................17=20 4.2.4. Data Packets across Fp reference = point...............18=20 4.2.5. Proxy = FE.............................................19=20 4.3. Association = Re-establishment..............................19=20 4.3.1. CE graceful = restart..................................19=20 4.3.2. FE = restart...........................................20=20 5. Applicability to = RFC1812.......................................21=20 5.1. General Router = Requirements...............................22=20 5.2. Link = Layer................................................23=20 5.3. Internet Layer = Protocols..................................23=20 5.4. Internet Layer = Forwarding.................................24=20 5.5. Transport = Layer...........................................24=20 5.6. Application Layer -- Routing = Protocols....................25=20 5.7. Application Layer -- Network Management = Protocol..........25=20 6. = Summary........................................................25=20 7. Security = Considerations........................................26=20 7.1. Analysis of Potential Threats Introduced by = ForCES........26=20 7.1.1. =91=91Join=92=92 or =91=91Remove=92=92 Flooding on = CEs...................26=20 7.1.2. Impersonation = Attack.................................27=20 7.1.3. Replay = Attack........................................27=20 7.1.4. Attack during Fail = Over..............................27=20 7.1.5. Data = Integrity.......................................27=20 7.1.6. Data = Confidentiality.................................27=20 7.1.7. Sharing security = parameters..........................28=20 7.1.8. Denial of Service Attack via External = Interface......28=20 7.2. Security Recommendations for = ForCES.......................28=20 7.2.1. Security = Configuration...............................29=20 7.2.2. Using TLS with = ForCES................................29=20 7.2.3. Using IPsec with = ForCES..............................30=20 8. Normative = References...........................................31=20 9. Informative = References.........................................32=20 10. = Acknowledgement...............................................32=20 11. Authors' = Addresses............................................33=20 12. Intellectual Property = Right...................................33=20 13. Full Copyright = Statement......................................33=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 2] =0C Internet Draft ForCES Framework June 2003 = =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. Definitions=20 =20 A set of terminology associated with the ForCES requirements is = defined in [3] and we only include the ones that are most = relevant=20 to this document here. =20 =20 Addressable Entity (AE) -=0D - = An entity that is directly addressable=20 given some interconnect technology. For example, on IP = networks, it=20 is a device to which we can communicate using an IP address; = and on=20 a switch fabric, it is a device to which we can communicate = using a=20 switch fabric port number. =20 =20 Physical Forwarding Element (PFE) - An AE that includes = hardware=20 used to provide per-packet processing and handling. This = hardware=20 may consist of (but is not limited to) network processors, = ASICs, or=20 general processors, installed on line cards, daughter boards,=20 mezzanine cards, or in stand-alone boxes.=20 =20 PFE Partition - A logical partition of a PFE consisting of some = subset of each of the resources (e.g., ports, memory, = forwarding=20 table entries) available on the PFE. This concept is analogous = to=20 that of the resources assigned to a virtual switching element = as=20 described in [8]. =20 =20 Physical Control Element (PCE) - An AE that includes hardware = used=20 to provide control functionality. This hardware typically = includes=20 a general-purpose processor. =20 =20 PCE Partition - A logical partition of a PCE consisting of some = subset of each of the resources available on the PCE. =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. FEs may happen to be a single blade (or PFE), a = partition=20 of a PFE or multiple PFEs.=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. CEs may consist of PCE partitions or = whole=20 PCEs.=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 Yang, et. al. Expires Dec 2003 [Page 3] =0C Internet Draft ForCES Framework June 2003 = =20 =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.=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, however this is currently out of scope. Being a logical=20 entity, a FE manager might be physically combined with any of = the=20 other logical entities mentioned in this 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 however this is currently out of scope. Being a logical = entity, a=20 CE manager might be physically combined with any of the other=20 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 =20 Yang, et. al. Expires Dec 2003 [Page 4] =0C Internet Draft ForCES Framework June 2003 = =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 FE Topology -- Representation of how the multiple FEs in a = single NE=20 are interconnected. Sometimes it is called inter-FE topology, = to be=20 distinguished from intra-FE topology (or FE block topology) = used by=20 FE model.=20 =20 Inter-FE topology - see FE Topology.=20 =20 2. 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 = element (NE) (such as a router) is composed of numerous = logically=20 separated entities that cooperate to provide a given = functionality=20 (such as routing). Two types of network element components = exist:=20 control element (CE) in control plane and forwarding element = (FE) in=20 forwarding plane (or data plane). Forwarding elements = typically are=20 ASIC, network-processor, or general-purpose processor-based = devices=20 that handle data path operations for each packet. Control = elements=20 are typically based on general-purpose processors that provide=20 control functionality like routing and signaling protocols. =20 =20 ForCES aims to define a framework and associated protocol(s) to = standardize information exchange between the control and = forwarding=20 plane. Having standard mechanisms allows CEs and FEs to become = physically separated standard components. This physical = separation=20 accrues several benefits to the ForCES architecture. Separate=20 components would allow component vendors to specialize in one=20 component without having to become experts in all components.=20 Standard protocol also allows the CEs and FEs from different=20 component vendors to interoperate with each other and hence it=20 becomes possible for system vendors to integrate together the = CEs=20 and FEs from different component suppliers. This = interoperability=20 translates into a lot more design choices and flexibility to = the=20 system vendors. Overall, ForCES will enable rapid innovation = in=20 both the control and forwarding planes while maintaining=20 interoperability. Scalability is also easily provided by this=20 architecture in that additional forwarding or control capacity = can=20 be added to existing network elements without the need for = forklift=20 upgrades.=20 =20 ------------------------- -------------------------=20 | Control Blade A | | Control Blade B |=20 | (CE) | | (CE) |=20 ------------------------- -------------------------=20 ^ | ^ |=20 | | | |=20 | V | V=20 =20 Yang, et. al. Expires Dec 2003 [Page 5] =0C Internet Draft ForCES Framework June 2003 = =20 =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 One example of such physical separation is at the blade level.=20 Figure 1 shows such 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 = 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. Control blade A may = be=20 the primary CE while control blade B is the backup CE providing = redundancy. It is also possible to have a redundant switch = fabric=20 for high availability support. Routers today with this kind of = configuration use proprietary interface for messaging between = CEs=20 and FEs. The goal of ForCES is to replace such proprietary=20 interface with a standard protocol. With a standard protocol = like=20 ForCES implemented on all blades, it becomes possible for = control=20 blades from vendor X and routing blades from vendor Y to work=20 seamlessly together in one chassis. =20 =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 Yang, et. al. Expires Dec 2003 [Page 6] =0C Internet Draft ForCES Framework June 2003 = =20 =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 In both examples shown here, the same physical interconnect is = used=20 for both CE-to-FE and FE-to-FE communication. However, that = does=20 not have to be the case. One reason to use different = interconnect=20 is that CE-to-FE interconnect does not have to be as fast as = the FE- to-FE interconnect, so the more expensive fast connections can = be=20 saved for FE-to-FE only. The separate interconnects may also=20 provide reliability and redundancy benefits for the NE.=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 RSVP (Resource Reservation Protocol), = LDP=20 (Label Distribution Protocol) for MPLS, etc. Examples of = forwarding=20 functions in FE include LPM (longest prefix match) forwarder,=20 classifiers, traffic shaper, meter, NAT, etc. Figure 3 shows a = 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 4.2.4 provides more detail on this. = =20 -------------------------------------------------=20 | | | | | | |=20 |OSPF |RIP |BGP |RSVP |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 =20 Yang, et. al. Expires Dec 2003 [Page 7] =0C Internet Draft ForCES Framework June 2003 = =20 =20 Figure 3. Examples of CE and FE functions=20 =20 =20 A set of requirements for control and forwarding separation is=20 identified in [3]. This document describes a ForCES = architecture=20 that satisfies the architectural requirements of that document = and=20 defines a framework for ForCES network elements and the = associated=20 entities to facilitate protocol definition. Whenever = necessary,=20 this document uses many examples to illustrate the issues = and/or=20 possible solutions in ForCES. These examples are intended to = be=20 just examples, and should not be taken as the only or definite = ways=20 of doing certain things. It is expected that separate document = will=20 be produced by the ForCES working group to specify the ForCES=20 protocol(s).=20 =20 3. Architecture=20 =20 This section defines the ForCES architectural framework and the = associated logical components. This ForCES framework defines=20 components of ForCES NEs including several ancillary = components. =20 These components may be connected in different kinds of = topologies=20 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 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 interfaces for receiving and transmitting packets from/to = the=20 =20 Yang, et. al. Expires Dec 2003 [Page 8] =0C Internet Draft ForCES Framework June 2003 = =20 =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 = 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, as = shown=20 in Figure 4. The FE external interfaces are labeled as Fi/f. = More=20 detail is provided in Section 4 and 5 for each of these = reference=20 points. All these reference points are important in = understanding=20 the ForCES architecture, however, the ForCES protocol is only defined over one reference 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 external interfaces at Fi/f. = ForCES=20 NEs connect to existing routers transparently.=20 =20 3.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, = the=20 invariant that the CEs and FEs together appear as a single NE = must=20 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 any request that can be serviced by one of the CEs can also = be=20 serviced by any of the other CEs. For both redundancy and 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 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 ForCES. CEs are wholly responsible for = coordinating=20 amongst themselves via the Fr reference point to provide = consistency=20 and synchronization. However, ForCES does not define the=20 implementation or protocols used between CEs, nor does it = define how=20 to distribute functionality among CEs. Nevertheless, ForCES = will=20 =20 Yang, et. al. Expires Dec 2003 [Page 9] =0C Internet Draft ForCES Framework June 2003 = =20 =20 support mechanisms for CE redundancy or fail over, and it is=20 expected that vendors will provide redundancy or fail over = solutions=20 within this framework.=20 =20 =20 3.2. Forwarding Elements and Fi reference point=20 =20 FE is a logical entity that implements the ForCES protocol and = uses=20 the underlying hardware to provide per-packet processing and=20 handling as directed by a CE. It is possible to partition one=20 physical FE into multiple logical FEs. It is also possible for = one=20 FE to use multiple physical FEs. The mapping between physical = FE(s)=20 and the logical FE(s) is beyond the scope of ForCES. For = example, a=20 logical partition of a physical FE can be created by assigning = some=20 portion of each of the resources (e.g., ports, memory, = forwarding=20 table entries) available on the physical FE to each of the = logical=20 FEs. Such concept of FE virtualization is analogous to a = virtual=20 switching element as described in [8]. FE virtualization = should=20 occur only in the pre-association phase and hence has no impact = on=20 ForCES.=20 =20 FEs perform all packet processing functions 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=20 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). =20 Upon detection of CE1 failure, perhaps across the Fr or Fp = reference=20 =20 Yang, et. al. Expires Dec 2003 [Page 10] =0C Internet Draft ForCES Framework June 2003 = =20 =20 point, CE2 is configured to take over activities of CE1. This = is=20 beyond the scope of ForCES and is not discussed further.=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=20 need to do packet filtering for forwarding packets to specific = CEs.=20 =20 This architecture permits multiple FEs to be present in a NE. = [3]=20 dictates that the ForCES protocol must be able to scale to at = least=20 hundreds of FEs (see [3] Section 5, requirement #11). Each of = these=20 FEs may potentially have a different set of packet processing=20 functions, with different media interfaces. FEs are = responsible for=20 basic maintenance of layer-2 connectivity with other FEs and = with=20 external entities. Many layer-2 media include sophisticated = control=20 protocols. The FORCES protocol (over the Fp reference point) = will=20 be able to carry messages for such protocols so that, in = keeping=20 with the "dumb FE=92=92 model, the CE can provide appropriate=20 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 [3], Section 5, Requirement #3). Packets that enter = the NE=20 via one FE and leave the NE via a different FE are transferred=20 between FEs across the Fi reference point. Fi reference point = could=20 be used by FEs to discovery their (inter-FE) topology, perhaps=20 during pre-association phase. The Fi reference point is a = separate=20 protocol from the Fp reference point and is not currently = defined by=20 the ForCES architecture.=20 =20 ----------------- =20 | CE | =20 ----------------- =20 ^ ^ ^=20 / | \=20 / v \=20 / ------- \=20 / +->| FE3 |<-+ \=20 / | | | | \=20 v | ------- | v=20 ------- | | -------=20 | FE1 |<-+ +->| FE2 |=20 | |<--------------->| |=20 ------- -------=20 ^ | ^ |=20 | | | |=20 | v | v=20 =20 (a) Full mesh among FE1, FE2 and FE3.=20 =20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 11] =0C Internet Draft ForCES Framework June 2003 = =20 =20 ----------- =20 | CE | =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 ^ |=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 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, the CE needs to understand the FE=20 topology. The FE topology can be queried from the FEs by CEs. = =20 =20 Yang, et. al. Expires Dec 2003 [Page 12] =0C Internet Draft ForCES Framework June 2003 = =20 =20 3.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=20 manager may also be physically embedded into a CE and be = implemented=20 as a simple keypad or other direct configuration mechanism on = the=20 CE. 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 [6] or SNMP [4].=20 =20 3.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 CE = its=20 FEs should communicate, nor are restrictions placed on how FE=20 managers are implemented. Each FE should have one and only one = FE=20 manager, while different FEs may have the same or different FE=20 manager(s). Each manager can choose to exist and operate=20 independent of other manager.=20 =20 4. 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 4.1.Pre-association Phase=20 =20 Pre-association phase is the period of time during which an 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=20 none of this is within the scope of ForCES protocol.=20 =20 4.1.1. 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 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. = =20 Subsequent communication between CE managers and FE managers = may=20 =20 Yang, et. al. Expires Dec 2003 [Page 13] =0C Internet Draft ForCES Framework June 2003 = =20 =20 require other security functions such as privacy, = non-repudiation,=20 freshness, and integrity.=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 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 4.1.2. Ff Reference Point=20 =20 The Ff reference point is used to inform forwarding elements of = the=20 association decisions made by the FE manager in pre-association = phase. Only authorized entities may instruct a FE with respect = to=20 which CE should control it. Therefore, privacy, integrity,=20 freshness, and authentication are necessary between the FE = manager=20 and FEs when the FE manager is remote to the FE. Once the=20 appropriate security has been established, the FE manager = instructs=20 the FEs across this reference point to join a new NE or to=20 disconnect from an existing NE. The FE Manager could also = assign=20 unique FE identifiers to the FEs using this reference point. = The FE=20 identifiers are useful in post association phase to express FE=20 topology. Figure 8 shows example of message exchange over Ff=20 reference point.=20 =20 Note that the FE manager function may be co-located with the FE = (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 FE Manager FE CE Manager CE=20 | | | |=20 =20 Yang, et. al. Expires Dec 2003 [Page 14] =0C Internet Draft ForCES Framework June 2003 = =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 =20 4.1.3. Fc Reference Point=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=20 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 4.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 association establishment and = steady-state=20 communication. The communication between CE and FE is = performed=20 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 4.2.1. Proximity and Interconnect between CEs and FEs=20 =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 ([7]). Very Close localities consist of control and=20 forwarding elements that either are components in the same = physical=20 box, or are separated at most by one local network hop. =20 =20 Yang, et. al. Expires Dec 2003 [Page 15] =0C Internet Draft ForCES Framework June 2003 = =20 =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 [3] Section 5, requirement #1). ForCES will = make=20 use of an existing RFC2914 ([2]) compliant L4 protocol with = adequate=20 reliability, security and congestion control (e.g. TCP, SCTP) = for=20 transport purposes.=20 =20 4.2.2. Association Establishment=20 =20 =20 FE CE=20 | |=20 |(Security exchange.) |=20 1|<--------------------->|=20 | |=20 |(Let me join the NE please.) =20 2|---------------------->|=20 | |=20 |(What kind of FE are you? -- capability query)=20 3|<----------------------|=20 | |=20 |(Here is my FE functions/state: use model to = describe)=20 4|---------------------->|=20 | |=20 |(How are you connected with other FEs?)=20 5|<----------------------|=20 | |=20 |(Here is the FE topology info)=20 6|---------------------->|=20 | |=20 |(Initial config for FE -- optional)=20 7|<----------------------|=20 | |=20 |(I am ready to go. Shall I?) =20 8|---------------------->|=20 | |=20 |(Go ahead!) |=20 9|<----------------------|=20 | |=20 =20 Figure 9. Example of message exchange between CE and FE=20 over Fp to establish NE association=20 =20 As an example, figure 9 shows some of the message exchange that = may=20 happen before the association between the CE and FE is fully=20 established. Either the CE or FE can initiate the connection.=20 Security handshake is necessary to authenticate the two=20 communication endpoints to each other before any further = message=20 exchange can happen. The exact details of the security = handshake=20 depend on the security solution chosen by ForCES protocol. It = is=20 most likely that either IPSec or TLS will be used. Section 9=20 Yang, et. al. Expires Dec 2003 [Page 16] =0C Internet Draft ForCES Framework June 2003 = =20 =20 provides more details on the security considerations for = ForCES. =20 After the successful security handshake, the FE needs to inform = the=20 CE of its own capability and its topology in relation to other = FEs. =20 The capability of the FE is represented by the FE model, = described=20 in a separate document. The model would allow a FE to describe = what=20 kind of packet processing functions it contains, in what order = the=20 processing happens, what kinds of configurable parameters it = allows,=20 what statistics it collects and what events it might throw, = etc. =20 Once such information is available to the CE, the CE may choose = to=20 send some initial or default configuration to the FE so that = the FE=20 can start receiving and processing packets correctly. Such=20 initialization may not be necessary if the FE already obtains = the=20 information from its own bootstrap process. Once FE starts=20 accepting packets for processing, we say the association of = this FE=20 with its CE is now established. From then on, the CE and FE = enter=20 steady-state communication.=20 =20 =20 4.2.3. Steady-state Communication=20 =20 Once an association is established between the CE and FE, the = ForCES=20 protocol is used by the CE and FE over Fp reference point to=20 exchange information to facilitate packet processing. =20 =20 =20 FE CE=20 | |=20 |(Add these new routes.)|=20 1|<----------------------|=20 | |=20 |(Successful.) |=20 2|---------------------->|=20 | |=20 | |=20 |(Query some stats.) |=20 1|<----------------------|=20 | |=20 |(Reply with stats collected.) =20 2|---------------------->|=20 | |=20 | |=20 |(My port is down, with port #.) = =20 1|---------------------->|=20 | |=20 |(Here is a new forwarding table) =20 2|<----------------------| =20 | |=20 | |=20 =20 Figure 10. Examples of message exchange between CE and FE = over Fp during steady-state communication=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 17] =0C Internet Draft ForCES Framework June 2003 = =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 message exchange examples in which the = CE=20 sends new routes to the FE so that the FE can add them to its=20 forwarding table. The CE may query the FE for statistics = collected=20 by the FE and the FE may notify the CE of important events such = as=20 port failure.=20 =20 4.2.4. Data Packets across Fp reference point=20 =20 Control plane protocol packets (such as RIP, OSPF messages)=20 addressed to any of NE's interfaces are typically redirected by = the=20 receiving FE to its CE, and CE may originate packets and have = its FE=20 deliver them to other NEs. Therefore, ForCES protocol over Fp = not=20 only transports the ForCES protocol messages between CEs and = FEs,=20 but also encapsulates the data packets from control plane = protocols. =20 Moreover, one FE may be controlled by multiple CEs for = distributed=20 control. In this configuration, the control protocols = supported by=20 the FORCES NEs may spread across multiple CEs. For example, = one CE=20 may support routing protocols like OSPF and BGP, while a = signaling=20 and admission control protocol like RSVP is supported in = another CE. =20 FEs are configured to recognize and filter these protocol = packets=20 and forward them to the corresponding CE. =20 =20 --------------------- ----------------------=20 | | | |=20 | +--------+ | | +--------+ |=20 | |CE(BGP) | | | |CE(BGP) | |=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 Figure 11 shows one example of how the BGP packets originated = by=20 router A are passed to router B. In this example, the ForCES=20 protocol is used to transport the packets from the CE to the FE = inside router A, and then from the FE to the CE inside router = B. In=20 light of the fact that the ForCES protocol is responsible for=20 transporting both the control messages and the data packets = between=20 =20 Yang, et. al. Expires Dec 2003 [Page 18] =0C Internet Draft ForCES Framework June 2003 = =20 =20 the CE and FE over Fp reference point, it is possible to use = either=20 a single protocol or multiple protocols to achieve this.=20 =20 4.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 4.3. Association Re-establishment=20 =20 FEs and CEs may join and leave NEs dynamically (see [3] Section = 5,=20 requirements #12). When a FE or CE leaves the NE, the = association=20 with the NE is broken. If the leaving party rejoins a NE = later, to=20 re-establish the association, it may or may not need to = re-enter the=20 pre-association phase. Loss of association can also happen=20 unexpectedly due to loss of connection between the CE and the = 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=20 provide mechanisms to support association re-establishment. = This=20 includes the ability for CEs and FEs to determine when there is = a=20 loss of association between them, ability to restore = association and=20 efficient state (re)synchronization mechanisms (see [3] Section = 5,=20 requirement #7). Note that security association and state must = be=20 also re-established to guarantee the same level of security = exists=20 before and after the association re-establishment.=20 =20 4.3.1. CE graceful restart=20 =20 The failure and restart of the CE in a router can potentially = cause=20 much stress and disruption on the control plane throughout a=20 network. Because when a CE has to restart for any reason, the=20 router loses routing adjacencies or sessions with its routing=20 neighbors. Neighbors who detect the lost adjacency normally = re- compute new routes and then send routing updates to their own=20 neighbors to communicate the lost adjacency. Their neighbors = do the=20 same thing to propagate throughout the network. In the = meantime,=20 the restarting router cannot receive traffic from other routers = because the neighbors have stopped using the router=92s = previously=20 advertised routes. When the restarting router restores = adjacencies,=20 neighbors must once again re-compute new routes and send out=20 additional routing updates. The restarting router is unable to=20 forward packets until it has re-established routing adjacencies = with=20 neighbors, received route updates through these adjacencies, = and=20 computed new routes. Until convergence takes place throughout = the=20 network, packets may be lost in transient black holes or = forwarding=20 loops. =20 =20 Yang, et. al. Expires Dec 2003 [Page 19] =0C Internet Draft ForCES Framework June 2003 = =20 =20 =20 A high availability mechanism known as the "graceful restart" = has=20 been used by the IP routing protocols (OSPF [10], BGP [11], BGP = [11]) and MPLS label distribution protocol (LDP [9]) to help=20 minimize the negative effects on routing throughout an entire=20 network caused by a restarting router. Route flap on = neighboring=20 routers is avoided, and a restarting router can continue to = forward=20 packets that would otherwise be dropped. =20 =20 While the details differ from protocol to protocol, the general = idea=20 behind the graceful restart mechanism remains the same. With = the=20 graceful restart, a restarting router can inform its neighbors = when=20 it restarts. The neighbors may detect the lost adjacency but = do not=20 recompute new routes or send routing updates to their = neighbors. =20 The neighbors also hold on to the routes received from the=20 restarting router before restart and assume they are still = valid for=20 a limited time. By doing so, the restarting router=92s FEs can = also=20 continue to receive and forward traffic from other neighbors = for a=20 limited time by using the routes they already have. The = restarting=20 router then re-establishes routing adjacencies, downloads = updated=20 routes from all its neighbors, recomputes new routes and uses = them=20 to replace the older routes it was using. It then sends these=20 updated routes to its neighbors and signals the completion of = the=20 graceful restart process.=20 =20 Non-stop forwarding is a requirement for graceful restart. It = is=20 necessary so a router can continue to forward packets while it = is=20 downloading routing information and recomputing new routes. = This=20 ensures that packets will not be dropped. As one can see, one = of=20 the benefits afforded by the separation of CE and FE is exactly = the=20 ability of non-stop forwarding in the face of the CE failure = and=20 restart. The support of dynamic changes to CE/FE association = in=20 ForCES also makes it compatible with high availability = mechanisms=20 such as graceful restart.=20 =20 ForCES should be able to support CE graceful restart easily. = When=20 the association is established the first time, the CE must = inform=20 the FEs what to do in the case of CE failure. If graceful = restart=20 is not supported, the FEs may be told to stop packet processing = all=20 together if its CE fails. If graceful restart is supported, = the FEs=20 should be told to cache and hold on to its FE state including = the=20 forwarding tables across the restarts. A timer must be = included so=20 that the timeout causes such cached state to expire eventually. = =20 Those timers should be settable by the CE. =20 =20 4.3.2. FE restart=20 =20 In the same example in Figure 5, assuming CE1 is the working CE = for=20 the moment, what would happen if one of the FEs, say FE1, = leaves the=20 NE temporarily? FE1 may voluntarily decide to leave the=20 association. Alternatively, FE1 may stop functioning simply = due to=20 unexpected failure. In former case, CE1 receives a "leave- =20 Yang, et. al. Expires Dec 2003 [Page 20] =0C Internet Draft ForCES Framework June 2003 = =20 =20 association request" from FE1. In the latter, CE1 detects the=20 failure of FE1 by some other means. In both cases, CE1 must = inform=20 the routing protocols of such an event, most likely prompting a = reachability and SPF (Shortest Path First) recalculation and=20 associated downloading of new FIBs from CE1 to the other = remaining=20 FEs (only FE2 in this example). Such recalculation and FIB = update=20 will also be propagated from the CE1 to its neighbors that are=20 affected by the connectivity of FE1. =20 =20 When FE1 decides to rejoin again, or when it restarts again = from the=20 failure, FE1 needs to re-discover its master (CE). This can be = achieved by several means. It may re-enter the pre-association = phase and get that information from its FE manager. It may = retrieve=20 the previous CE information from its cache, if it can validate = the=20 information freshness. Once it discovers its CE, it starts = message=20 exchange with CE to re-establish the association just as = outlined in=20 Figure 9, with the possible exception that it might be able to=20 bypass the transport of the complete initial configuration. = Suppose=20 that FE1 still has its routing table and other state = information=20 from the last association, instead of sending all the = information=20 again from scratch, it may be able to use more efficient = mechanism=20 to re-sync up the state with its CE if such mechanism is = supported=20 by the ForCES protocol. For example, CRC-32 of the state might = give=20 a quick indication of whether or not the state is in-sync with = its=20 CE. By comparing its state with CE first, it sends information = update only if it is needed. ForCES protocol may choose to=20 implement similar optimization mechanisms, but it may also = choose=20 not to, as this is not a requirement.=20 =20 =20 5. Applicability to RFC1812 =20 =20 [3] Section 5, requirement #9 dictates that "All proposed = ForCES=20 architecture must explain how that architecture supports all of = the=20 router functions as defined in RFC1812." RFC1812 discusses = many=20 important requirements for IPv4 routers from the link layer to = the=20 application layer. This section addresses the relevant = requirements=20 in RFC1812 for implementing IPv4 routers based on ForCES=20 architecture and explains how ForCES satisfies these = requirements by=20 providing guidelines on how to separate the functionalities = required=20 into forwarding plane and control plane. =20 =20 In general, the forwarding plane carries out the bulk of the = per- packet processing that is required at line speed, while the = control=20 plane carries most of the computationally complex operations = that=20 are typical of the control and signaling protocols. However, = it is=20 impossible to draw a rigid line to divide the processing into = CEs=20 and FEs cleanly. Nor should the ForCES architecture limit the=20 innovative approaches in control and forwarding plane = separation. =20 As more and more processing power is available in the FEs, some = of=20 the control functions that traditionally are performed by CEs = may=20 now be moved to FEs for better performance and scalability. = Such=20 offloaded functions may include part of ICMP or TCP processing, = or=20 =20 Yang, et. al. Expires Dec 2003 [Page 21] =0C Internet Draft ForCES Framework June 2003 = =20 =20 part of routing protocols. Once off-loaded onto the forwarding = plane, such CE functions, even though logically belonging to = the=20 control plane, now become part of the FE functions. Just like = the=20 other logical functions performed by FEs, such off-loaded = functions=20 must be expressed as part of the FE model so that the CEs can = decide=20 how to best take advantage of these off-loaded functions when=20 present on the FEs.=20 =20 5.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. =20 Therefore, this router NE provides four external interfaces = (#1, 2,=20 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 [1] 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 [1] Section 6). One important class of application=20 protocols is routing protocols (see RFC1812 [1] Section 7). In = ForCES architecture, routing protocols are naturally = implemented by=20 CEs. Routing protocols require routers communicate with each = other. =20 =20 Yang, et. al. Expires Dec 2003 [Page 22] =0C Internet Draft ForCES Framework June 2003 = =20 =20 This communication between CEs in different routers is = supported in=20 ForCES by FEs' ability to redirect data packets addressed to = routers=20 (i.e., NEs) and CEs' ability to originate packets and have them = delivered by their FEs. This communication occurs across Fp=20 reference point inside each router and between neighboring = routers'=20 external interfaces, as illustrated in Figure 11. =20 =20 5.2.Link Layer=20 =20 Since FEs own all the external interfaces for the router, FEs = need=20 to conform to the link layer requirements in RFC1812. = Arguably, ARP=20 support may be implemented in either CEs or FEs. As we will = see=20 later, a number of behaviors that RFC1812 mandates fall into = this=20 category -- they may be performed by the FE and may be = performed by=20 the CE. A general guideline is needed to ensure = interoperability=20 between separated control and forwarding planes. The guideline = we=20 offer here is that in general CEs are required to be capable of = these kind of operations while FEs may or may not choose to=20 implement them. FE model should indicate its capabilities in = this=20 regard so that CEs can decide where these functions are = implemented.=20 =20 Interface parameters, including MTU, IP address, etc., must be=20 configurable by CEs via ForCES. CEs must be able to determine=20 whether a physical interface in an FE is available to send = packets=20 or not. FEs must also inform CEs the status change of the=20 interfaces (like link up/down) via ForCES.=20 =20 5.3.Internet Layer Protocols=20 =20 Both FEs and CEs must implement IP protocol and all mandatory=20 extensions as RFC1812 specified. CEs should implement IP = options=20 like source route and record route while FEs may choose to = implement=20 those as well. Timestamp option should be implemented by FEs = to=20 insert the timestamp most accurately. FE must interpret the IP = options that it understands and preserve the rest unchanged for = use=20 by CEs. Both FEs and CEs might choose to silently discard = packets=20 without sending ICMP errors, but such events should be logged = and=20 counted. FEs may report statistics for such events to CEs via=20 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=20 example, it can be always decremented by the last FE with = egress=20 function. =20 =20 FEs must receive and process normally any packets with a = broadcast=20 destination address or a multicast destination address that the = router has asked to receive. When IP multicast is supported in = routers, IGMP is implemented in CEs. CEs are also required of = ICMP=20 support, while it is optional for FEs to support ICMP. Such an = option can be communicated to CEs as part of the FE model. =20 Therefore, FEs can always rely upon CEs to send out ICMP error=20 =20 Yang, et. al. Expires Dec 2003 [Page 23] =0C Internet Draft ForCES Framework June 2003 = =20 =20 messages, but FEs also have the option to generate ICMP error=20 messages themselves. =20 =20 5.4.Internet Layer Forwarding=20 =20 IP forwarding is implemented by FEs. When the routing table is = updated at CEs, ForCES is used to send the new route entries = from=20 CEs to FEs. Each FE has its own forwarding table and uses this = table to direct packets to the next hop interface. =20 =20 Upon receiving IP packets, FE verifies the IP header and = processes=20 most of the IP options. Some options cannot be processed until = the=20 routing decision has been made. Routing decision is made after = examining the destination IP address. If the destination = address=20 belongs to the router itself, the packets are filtered and = either=20 processed locally or forwarded to CE, depending upon the=20 instructions set-up by CE. Otherwise, FE determines the next = hop IP=20 address by looking up in its forwarding table. FE also = determines=20 the network interface it uses to send the packets. Sometimes = FE may=20 need to forward the packets to another FE before packets can be = forwarded out to the next hop. Right before packets are = forwarded=20 out to the next hop, FE decrements TTL by 1 and processes any = IP=20 options that cannot be processed before. FE performs any IP=20 fragmentation if necessary, determines link layer address = (e.g., by=20 ARP), and encapsulates the IP datagram (or each of the = fragments=20 thereof) in an appropriate link layer frame and queues it for = output=20 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 do not know how = to=20 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 = 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 = 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 5.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 =20 Yang, et. al. Expires Dec 2003 [Page 24] =0C Internet Draft ForCES Framework June 2003 = =20 =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 some = layer-4=20 transport is used to support ForCES, then both CEs and FEs need = to=20 implement the L4 transport and ForCES protocols. =20 =20 5.6. Application Layer -- Routing Protocols=20 =20 Interior and exterior routing protocols are implemented on CEs. = The=20 routing packets originated by CEs are forwarded to FEs for = delivery. =20 The results of such protocols (like forwarding table updates) = are=20 communicated to FEs via ForCES.=20 =20 For performance or scalability reasons, portions of the control = plane functions that need faster response may be moved from the = CEs=20 and off-loaded onto the FEs. For example in OSPF, the Hello=20 protocol packets are generated and processed periodically. = When=20 done at CEs, the inbound Hello packets have to traverse from = the=20 external interfaces at the FEs to the CEs via the internal = CE-FE=20 channel. Similarly, the outbound Hello packets have to go from = the=20 CEs to the FEs and to the external interfaces. Frequent Hello=20 updates place heavy processing overhead on the CEs and can = overwhelm=20 the CE-FE channel as well. Since typically there are far more = FEs=20 than CEs in a router, the off-loaded Hello packets are = processed in=20 a much more distributed and scalable fashion. By expressing = such=20 off-loaded functions in the FE model, we can ensure=20 interoperability.=20 =20 5.7. Application Layer -- Network Management Protocol=20 =20 RFC1812 also dictates "Routers MUST be manageable by SNMP." = (see=20 [4] Section 8) In general, for post-association phase, most = external=20 management tasks (including SNMP) should be done through = interaction=20 with the CE in order to support the appearance of a single=20 functional device. Therefore, it is recommended that SNMP=20 management agent be implemented by CEs and the SNMP messages=20 received by FEs be redirected to their CEs. AgentX framework=20 defined in RFC2741 ([5]) may be applied here such that CEs act = in=20 the role of master agent to process SNMP protocol messages = while FEs=20 act in the role of subagent to provide access to the MIB = objects=20 residing on FEs. AgentX protocol messages between the master = agent=20 (CE) and the subagent (FE) are encapsulated and transported via = ForCES, just like data packets from any other application layer = protocols. =20 =20 6. Summary=20 =20 This document defines an architectural framework for ForCES. = It=20 identifies the relevant components for a ForCES network = element,=20 including (one or more) FEs, (one or more) CEs, one optional FE = manager, and one optional CE manager. It also identifies the=20 interaction among these components and discusses all the major=20 =20 Yang, et. al. Expires Dec 2003 [Page 25] =0C Internet Draft ForCES Framework June 2003 = =20 =20 reference points. It is important to point out that, among all = the=20 reference points, only the Fp interface between CEs and FEs is=20 within the scope of ForCES. ForCES alone may not be enough to=20 support all desirable NE configurations. However, we believe = that=20 ForCES over Fp interface is the most important element in = realizing=20 physical separation and interoperability of CEs and FEs, and = hence=20 the first interface that ought to be standardized. Simple and=20 useful configurations can still be implemented with only CE-FE=20 interface being standardized, e.g., single CE with full-meshed = FEs.=20 =20 7. Security Considerations=20 =20 In general, the physical separation of two entities usually = results=20 in a potentially insecure link between the two entities and = hence=20 much stricter security measurements are required. For example, = we=20 pointed out in Section 4.1 that authentication becomes = necessary=20 between CE manager and FE manager, between CE and CE manager,=20 between FE and FE manager in some configurations. The physical = separation of CE and FE also imposes serious security = requirement=20 for ForCES protocol over Fp interface. This section first = attempts=20 to describe the security threats that may be introduced by the=20 physical separation of the FEs and the CEs, and then it = provides=20 recommendation and guidelines for secure operation and = management of=20 ForCES protocol over Fp interface.=20 =20 7.1. Analysis of Potential Threats Introduced by ForCES=20 =20 This section provides the threat analysis for ForCES, with a = focus=20 on Fp interface. Each threat is described in details with the=20 effects on the ForCES protocol entities or/and the NE as a = whole,=20 and the required functionalities that need to be in place to = defend=20 the threat. =20 =20 7.1.1. =91=91Join=92=92 or =91=91Remove=92=92 Flooding on CEs=20 =20 Threats: A malicious node could send a stream of false = =91=91join NE=92=92 or=20 =91=91remove from NE=92=92 requests on behalf of non-existent = or unauthorized=20 FE to legitimate CEs at a very rapid rate and thereby create=20 unnecessary state in the CEs.=20 =20 Effects: If by maintaining state for non-existent or = unauthorized=20 FEs, a CE may become unavailable for other processing and hence = suffer from denial of service (DoS) attack similar to the TCP = SYN=20 DoS. If multiple CEs are used, the unnecessary state = information may=20 also be conveyed to multiple CEs via Fr interface (e.g., from = the=20 active CE to the stand-by CE) and hence subject multiple CEs to = DoS=20 attack. =20 =20 Requirement: A CE that receives a =91=91join=92=92 or = =91=91remove=92=92 request should=20 not create any state information until it has authenticated the = FE=20 endpoint.=20 =20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 26] =0C Internet Draft ForCES Framework June 2003 = =20 =20 7.1.2. Impersonation Attack =20 =20 Threats: A malicious node can impersonate a CE or FE and send = out=20 false messages.=20 =20 Effects: The whole NE could be compromised.=20 =20 Requirement: The CE or FE must authenticate the message before = accepting and processing it. =20 =20 =20 7.1.3. Replay Attack=20 =20 Threat: A malicious node could replay the entire message = previously=20 sent by a FE or CE entity to get around authentication. =20 =20 Effect: The NE could be compromised.=20 =20 Requirement: Replay protection mechanism needs to be part of = the=20 security protocol to defend this attack.=20 =20 7.1.4. Attack during Fail Over=20 =20 Threat: A malicious node may exploit the CE fail-over mechanism = to=20 take over the control of NE. For example, suppose two CE=92s, = say CE-A=20 and CE-B, are controlling several FE=92s. CE-A is active and = CE-B is=20 stand-by. When CE-A fails, CE-B is taking over the active CE=20 position. The FEs already had a trusted relationship with = CE-A, but=20 the FEs may not have the same trusted relationship established = with=20 CE-B prior to the fail-over. A malicious node can take over as = CE-B=20 if such trusted relationship is not established during the = fail- over. =20 =20 Effect: The NE may be compromised after such insecure = fail-over.=20 =20 Requirement: The level of trust relationship between the = stand-by=20 CE and the FEs must be as strong as the one between the active = CE=20 and the FEs, and such security association must be = re-established=20 during fail-over.=20 =20 7.1.5. Data Integrity =20 =20 Threats: A malicious node may inject false messages to = legitimate CE=20 or FE. =20 =20 Effect: An FE or CE receives the fabricated packet and performs = incorrect or catastrophic operation.=20 =20 Requirement: Protocol messages require integrity protection.=20 =20 7.1.6. Data Confidentiality=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 27] =0C Internet Draft ForCES Framework June 2003 = =20 =20 Threat: When FE and CE are physically separated, a malicious = node=20 may eavesdrop the messages in transit. Some of the messages are = critical to the functioning of the whole network, while others = may=20 contain confidential business data. Leaking of such information = may=20 result in compromise even beyond the immediate CE or FE. =20 =20 Effect: Sensitive information might be exposed between CE and = FE.=20 =20 Requirement: Data confidentiality between FE and CE must be=20 available for sensitive information.=20 =20 7.1.7. Sharing security parameters=20 =20 Threat: Consider a scenario where several FEs communicating to = the=20 same CE share the same authentication keys for the Fp = interface. If=20 any FE or the CE is compromised, all other entities are = compromised.=20 =20 Effect: The whole NE is compromised.=20 =20 Requirement: To avoid this side effect, it=92s better to = configure=20 different security parameters for each FE-CE communication over = Fp=20 interface.=20 =20 7.1.8. Denial of Service Attack via External Interface=20 =20 Threat: When an FE receives a packet that is destined for its = CE,=20 the FE forwards the packet over the Fp interface. Malicious = node can=20 generate huge message storm like routing protocol packets etc.=20 through the external Fi/f interface so that the FE has to = process=20 and forward all packets to CE through Fp interface.=20 =20 Effect: CE encounters resource exhaustion and bandwidth = starvation=20 on Fp interface due to an overwhelming number of packets from = FEs.=20 =20 Requirement: Rate limiting mechanism needs to be in place at = both FE=20 and CE. Rate Limiter can be configured at FE for each message = type=20 that are being received through Fi/F interface.=20 =20 7.2. Security Recommendations for ForCES=20 =20 The requirements document [3] suggested that ForCES protocol = should=20 support reliability over Fp interface, but no particular = transport=20 protocol is yet specified for ForCES. This framework document = does=20 not intend to specify the particular transport either, and so = we=20 only provide recommendations and guidelines based on the = existing=20 standard security protocols that can work with the common = transport=20 candidates suitable for ForCES.=20 =20 We highlight two existing security protocol solutions, namely = IPsec=20 (IP Security) [14] or TLS (Transport Layer Security) [13]. TLS = works=20 with reliable transports such as TCP or SCTP, while IPsec can = be=20 used with any transport (UDP, TCP, SCTP). Both TLS and IPsec = can be=20 =20 Yang, et. al. Expires Dec 2003 [Page 28] =0C Internet Draft ForCES Framework June 2003 = =20 =20 used potentially to satisfy all of the security requirements = for=20 ForCES protocol.=20 =20 It is important to realize that even if the NE is in a = single-box,=20 the DoS attacks can still be launched through Fi/f interfaces.=20 Therefore, it is still important to have counter-measurement as = stated in 1.1.9 for DoS while authentication, confidentiality = and=20 integrity can be provided by the physical security of the box.=20 =20 7.2.1. Security Configuration =20 =20 The NE administrator has the freedom to determine the exact = security=20 configuration that is needed for the specific deployment. For=20 example, ForCES may be deployed between CEs and FEs connected = to=20 each other inside a box over a backplane. In such scenario,=20 physical security of the box ensures that most of the attacks = such=20 as man-in-the-middle, snooping, and impersonation are not = possible,=20 and hence ForCES architecture may rely on the physical security = of=20 the box to defend against these attacks and protocol mechanisms = may=20 be turned off. However, it is also shown that denial of = service=20 attack via external interface as described in Section 7.1.8 is = still=20 a potential threat even for such =91=91all-in-one-box=92=92 = deployment=20 scenario and hence the rate limiting mechanism is still = necessary. =20 This is just one example to show that it is important to assess = the=20 security needs of the ForCES-enabled network elements under=20 different deployment scenarios. It should be possible for the=20 administrator to configure the level of security needed for the = ForCES protocol.=20 =20 7.2.2. Using TLS with ForCES=20 =20 TLS [13] can be used if a reliable transport such as TCP or = SCTP is=20 used for ForCES over Fp interface. The TLS handshake protocol = is=20 used during association establishment or re-establishment phase = to=20 negotiate a TLS session between the CE and FE. Once the = session is=20 in place, the TLS record protocol is used to secure ForCES=20 communication messages between the CE and FE.=20 =20 A basic outline of how TLS can be used with ForCES is described = below. Steps 1) till 7) complete the security handshake as=20 illustrated in Figure 9 while step 8) is for all the further=20 communication between the CE and FE, including the rest of = messages=20 after the security handshake shown in Figure 9 and the = steady-state=20 communication shown in Figure 10.=20 =20 1) During Pre-association phase all FEs are configured with the = CEs=20 (including both the active CE and the standby CE). =20 2) The FE establishes a TLS connection with the CE (master) and = negotiates a cipher suite.=20 3) The FE (slave) gets the CE certificate, validates the = signature,=20 checks the expiration date, checks if the certificate has been=20 revoked.=20 =20 Yang, et. al. Expires Dec 2003 [Page 29] =0C Internet Draft ForCES Framework June 2003 = =20 =20 4) The CE (master) gets the FE certificate and performs the = same=20 validation as the FE in step 4). =20 5) If any of the check fails in step 5 or step 6, endpoint must = generate an error message and abort.=20 6) After successful mutual authentication, a TLS session is=20 established between CE and FE.=20 7) The FE sends a =91=91join NE=92=92 message to the CE. =20 8) The FE and CE use TLS session for further communication.=20 =20 Note that there are different ways for the CE and FE to = validate a=20 received certificate. One way is to configure the FE Manager or = CE=20 Manager or other central component as CA, so that the CE or FE = can=20 query this pre-configured CA to validate that the certificate = has=20 not been revoked. Another way is to have the CE and the FE=20 configured directly a list of valid certificates in the pre- association phase. =20 =20 In the case of fail-over, it is the responsibility of the = active CE=20 and the standby CE to synchronize ForCES states including the = TLS=20 states to minimize the state reestablishment during fail-over. = Care=20 must be taken to ensure that the standby CE is also = authenticated in=20 the same way as the active CE, either before or during the = fail- over.=20 =20 7.2.3. Using IPsec with ForCES=20 =20 IPsec [14] can be used with any transport protocol, such as = UDP,=20 SCTP and TCP over Fp interface for ForCES. We recommend using = ESP=20 in transport mode for ForCES because message confidentiality is = required for ForCES and the communication between the CE and FE = is=20 point-to-point. =20 =20 IPsec can be used with both manual and automated SA and=20 cryptographic key management. But Ipsec=92s replay protection=20 mechanisms are not available if manual key management is used. = Hence, automatic key management is recommended if replay = protection=20 is deemed important. Otherwise, manual key management might be = sufficient for some deployment scenarios, esp. when the number = of=20 CEs and FEs is relatively small. It is recommended that the = keys be=20 changed periodically even for manual key management.=20 =20 Unlike TLS, IPsec provides security services between the CE and = FE=20 at IP level, and so the security handshake as illustrated in = Figure=20 9 amounts to a =91=91no-op=92=92 when manual key management is = used. The=20 following outline the steps taken for ForCES in such a case.=20 =20 1) During Pre-association phase all FEs are configured with the = CEs=20 (including active CE and standby CE) and SA parameters = manually.=20 2) The FE sends a =91=91join NE=92=92 message to the CE. This = message and all=20 others that follow are afforded security service according to = the=20 manually configured IPsec SA parameters, but replay protection = is=20 not available. =20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 30] =0C Internet Draft ForCES Framework June 2003 = =20 =20 It is up to the administrator to decide whether to share the = same=20 key across multiple FE-CE communication, but it is recommended = that=20 different keys be used. Similarly, it is recommended that = different=20 keys be used for inbound and outbound traffic.=20 =20 If automatic key management is needed, IKE [15] can be used for = that=20 purpose. Other automatic key distribution techniques such as=20 Kerberos may be used as well. The key exchange process = constitutes=20 the security handshake as illustrated in Figure 9. The = following=20 shows the steps involved in using IKE with IPsec for ForCES. = Steps=20 1) to 6) constitute the security handshake in Figure 9.=20 =20 1) During Pre-association phase all FEs are configured with the = CEs=20 (including active CE and standby CE), IPsec policy etc.=20 2) The FE kicks off IKE process and tries to establish an IPsec = SA=20 with the CE (master). The FE (Slave) gets the CE certificate as = part=20 of the IKE negotiation. The FE validates signature, checks the=20 expiration date, checks if the certificate has been revoked.=20 3) The CE (master) gets the FE certificate and performs the = same=20 check as the FE in step 3).=20 4) If any of the check fails in step 3 or step 4, the endpoint = must=20 generate an error message and abort.=20 5) After successful mutual authentication, IPsec session is=20 established between the CE and FE.=20 6) The FE sends a =91=91join NE=92=92 message to CE. No SADB = entry is created=20 in FE yet.=20 7) The FE and CE use the IPsec session for further = communication.=20 =20 FE Manager or CE Manager or other central component can be used = as=20 CA for validating CE and FE certificates during the IKE = process. =20 Alternatively, during the pre-association phase, the CE and FE = can=20 be configured directly with the required information such as=20 certificates or passwords etc depending upon the type of=20 authentication that administrator wants to configure. =20 =20 In the case of fail-over, it is the responsibility of active CE = and=20 standby CE to synchronize ForCES states and IPsec states to = minimize=20 the state reestablishment during fail-over. Alternatively, the = FE=20 needs to establish different IPsec SA during the startup = operation=20 itself with each CE=92s. This will minimize the periodic state=20 transfer across IPsec layer though Fr (CE-CE) Interface. =20 =20 =20 8. Normative References=20 =20 [1] F. Baker, =91=91Requirements for IP Version 4 Routers", = RFC1812, June=20 1995.=20 =20 [2] S. Floyd, =91=91Congestion Control Principles", RFC2914, = September=20 2000.=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 31] =0C Internet Draft ForCES Framework June 2003 = =20 =20 [3] H. Khosravi, et. al., =91=91Requirements for Separation of = IP Control=20 and Forwarding", work in progress, May 2003, = .=20 =20 9. Informative References=20 =20 [4] J. Case, et. al., =91=91A Simple Network Management = Protocol (SNMP)",=20 RFC1157, May 1990.=20 =20 [5] M. Daniele, et. al., =91=91Agent Extensibility (AgentX) = Protocol=20 Version 1", RFC2741, Jan 2000.=20 =20 [6] K. Chan, et. al., =91=91COPS Usage for Policy Provisioning = (COPS- PR)", RFC3084, March 2001.=20 =20 [7] A. Crouch, et. al., =91=91ForCES Applicability Statement", = work in=20 progress, June 2002, .=20 =20 [8] T. Anderson, J. Buerkle, =91=91Requirements for the Dynamic = Partitioning of Switching Elements", RFC3532, May 2003.=20 =20 [9] M. Leelanivas, et. al., =91=91Graceful Restart Mechanism = for Label=20 Distribution Protocol=92=92, RFC 3478, Feb. 2003.=20 =20 [10] J. Moy, et. al., =91=91Graceful OSPF Restart=92=92, work = in progress,=20 March 2003, .=20 =20 [11] S. R. Sangli, et. al., =91=91Graceful Restart Mechanism = for BGP=92=92,=20 work in progress, Jan 203, < draft-ietf-idr-restart-06.txt>.=20 =20 [12] M. Shand and L. Ginsberg, =91=91Restart Signaling for = IS-IS=92=92, work=20 in progress, March 2003, .=20 =20 [13] T. Dierks and C. Allen, =91=91The TLS Protocol, version = 1.0=92=92,=20 RFC2246, Jan. 1999.=20 =20 [14] S. Kent and R. Atkinson, =91=91Security Architecture for = the=20 Internet Protocol=92=92, RFC2401, Nov. 1998.=20 =20 [15] D. Harkins and D. Carrel, =91=91The Internet Key Exchange = (IKE)=92=92,=20 RFC2409, Nov. 1998.=20 =20 [16] S. M. Bellovin, =91=91Guidelines for Mandating the Use of = Ipsec=92=92,=20 work in progress, Oct. 2002, .=20 =20 10. Acknowledgement=20 =20 Joel M. Halpern gave us many insightful comments and = suggestions and=20 pointed out several major issues. T. Sridhar suggested that = the=20 AgentX protocol could be used with SNMP to manage the ForCES = network=20 elements. Many of our colleagues and people in the ForCES = mailing=20 list also provided valuable feedback.=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 32] =0C Internet Draft ForCES Framework June 2003 = =20 =20 11. Authors' Addresses=20 =20 Lily L. Yang=20 Intel Corp., MS JF3-206,=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 Department of Computer Science,=20 University of North Texas,=20 Denton, Texas, 76203=20 Phone: +1 940 565 2822=20 Email: rdantu@unt.edu=20 =20 Todd A. Anderson=20 Intel Corp.=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 Ram Gopal=20 Nokia Research Center=20 5, Wayside Road,=20 Burlington, MA 01803=20 Phone: +1 781 993 3685=20 Email: ram.gopal@nokia.com=20 =20 12. Intellectual Property Right=20 =20 The authors are not aware of any intellectual property right = issues=20 pertaining to this document.=20 =20 13. Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2002). All Rights Reserved. = =20 This document and translations of it may be copied and = furnished to=20 others, and derivative works that comment on or otherwise = explain it=20 or assist in its implementation may be prepared, copied, = published=20 and distributed, in whole or in part, without restriction of = any=20 kind, provided that the above copyright notice and this = paragraph=20 are included on all such copies and derivative works. However, = this=20 document itself may not be modified in any way, such as by = removing=20 the copyright notice or references to the Internet Society or = other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other = than=20 English.=20 =20 Yang, et. al. Expires Dec 2003 [Page 33] =0C Internet Draft ForCES Framework June 2003 = =20 =20 =20 The limited permissions granted above are perpetual and will = not be=20 revoked by the Internet Society or its successors or assigns.=20 This document and the information contained herein is provided = on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION = HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES = OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 =20 =20 Yang, et. al. Expires Dec 2003 [Page 34] =0C ------_=_NextPart_000_01C32ED0.2E37F400-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 10 00:01:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00088 for ; Tue, 10 Jun 2003 00:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PaHx-0001Ii-00 for forces-archive@IETF.ORG; Mon, 09 Jun 2003 23:59:13 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19PaHk-0001Ic-00 for forces-archive@IETF.ORG; Mon, 09 Jun 2003 23:59:04 -0400 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.00A094F4@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 0:00:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45120121 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 9 Jun 2003 23:59:52 -0400 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Jun 2003 23:59:51 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5A3psv19885 for ; Tue, 10 Jun 2003 03:51:55 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5A40Rl03646 for ; Tue, 10 Jun 2003 04:00:27 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003060920553911713 ; Mon, 09 Jun 2003 20:56:19 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 20:58:55 -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, 9 Jun 2003 20:58:53 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: AD/Routing Directorate Feedback, ForCES Framework Draft Comments: To: "Yang, Lily L" , dro@zurich.ibm.com, Alex Zinin Comments: cc: rdantu@unt.edu, "Anderson, Todd A" , ram.gopal@nokia.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, Barring any objections, I plan to forward this information to the mailing list and include it on the forces website on Tuesday evening. Please email me before then if you prefer that I take some alternate action. Thanks, David > -----Original Message----- > From: Yang, Lily L > Sent: Monday, June 09, 2003 2:44 PM > To: Putzolu, David; dro@zurich.ibm.com; Alex Zinin > Cc: forces@peach.ease.lsoft.com; rdantu@unt.edu; Anderson, > Todd A; ram.gopal@nokia.com > Subject: RE: AD/Routing Directorate Feedback, ForCES Framework Draft > > > Hi, David, Patrick and Alex -- > In early April, we received some feedback on the ForCES > framework draft from the ADs and the routing directorate. A > summary of the authors' responds is provided here. Attached > you find the new version of the draft that we just submitted. > Please review the new document and let us know our next steps > in the RFC process. > > Lily > > --------------summary of our respond------------- > > The following format is used to address each comment/concern > listed in David Putzolu's original posting. > [summary of comments]... > [summary of authors' discussion] ... > [document change] ... > > 1) FE Virtualization > [summary of comments] > A single physical FE might be partitioned into multiple virtual > FEs. I think the requirements talks abut this but the framework > doesn't explicitly call out how this is handled. I believe the > approach being taken is one where each FE (where FE is defined as > the slave endpoint of an Fp connection) is a single logical > entity, and partitioning of a physical FE into multiple such > entities is beyond the scope of Fp and is instead a pre-association > phase issue. The framework should explicitly call this > out and may also want to include a reference to the new > informational RFC that just issued on requirements for > accomplishing this from the GSMP wg. RFC-Editor has not yet > gotten around to it, so here is the URL for the draft: > http://www.ietf.org/internet-drafts/draft-ietf-gsmp-dyn-part-r > eqs-03.txt > [summary of authors' discussion] > FE partition should be done in the pre-association phase and > hence ForCES is agnostic to the FE partitioning. > [document change] > Section 3.2 first paragraph is modified to point this out. > > 2) Multiple FEMgrs > [summary of comments] > The framework seems to say that there is one FE manager. > It is possible that in some architectures each FE may have > associated with it a FEMgr, thus necessitating selection > of a single FEMgr among many. The rtg-dir questioned > where such an interaction fits in the framework. Initial > impression was that this would be a Fi interaction (if > the FEMgrs are collocated with the FEs). Is this the > right place, and if so, it should be documented. > [summary of authors' discussion] > We believe this is not an issue. It is perfectly ok for each > FE has its own FEMgr, and as long as each FEMgr does its job > by telling its FE which CE it belongs to, we see no any need > to coordinate among the multiple FEMgrs, nor any need to > elect only single FEMgr among many. > [document change] > None. > > 3) DoS attacks > [summary of comments] > 4.2.4 should explicitly call out that Fp could be a vector > used by adversaries for DoS attacks on the NE. As such, > it should explicitly be said that the combination of packet > filterings on FEs, plus prioritization of specific packets > being sent across Fp, helps to combat such attacks. Also - > probably add a SHOULD that FEs should support the ability > to do rate limiting of packets to CE. This is necessary to > prevent flooding of the CE w/packets from FE. > [summary of authors' discussion] > Agree. This is an important point that should be captured in > the security consideration section. > [document change] > Section 7 (security consideration) is rewritten with detailed > threat analysis including DoS attack. > > 4) OSPF Offload > [summary of comments] > The ADs and the rtg-dir where both concerned that features > such as OSPF offload, while useful, are probably so new > that standardizing support for them is not practical in > the first rev of forces. They suggested that support for > that be removed from sections 5, 5.2, and 5.6. > [summary of authors' discussion] > This is entirely requirements-driven. The mailing list had > some discussion long ago on this and the requirement draft > reflected it. Since the new requirement draft still calls for > such support, we maintain the same stand on this. > [document change] > None. > > 5) Non-stop forwarding/Graceful restart > [summary of comments] > Section 4.3 talks a bit about features needed for graceful > restart, and requirements section 5 item 7 discusses this > topic. The framework should explicitly spell out the need > to support this and name it appropriately ("graceful restart") > in its own section. In that section the framework should > indicate the specific capabilities that FEs are expected to > provide to enable graceful restart, i.e. "In order to enable > graceful restart, FEs MAY choose to cash forwarding and QoS > state across CE restarts. If they do so, they MUST include > timers that eventually cause such cached state to expire. > Those timers SHOULD be settable by CEs." (Note: this is just > an example, need to be more specific about this. Include > justifications & refs to appropriate RFCs, WGs, and drafts). > [summary of authors' discussion] > Agree. > [document change] > Section 4.3 "Association Re-establishment" is rewritten and > reorganized into 2 subsections. 4.3.1 "CE graceful Restart" > is devoted to this issue. References to graceful restart > [9-12] are also added. > > 6) Terminology issue: route vs. forward > [summary of comments] > Section 4.2.3 shows a "route to this port instead" message > going from CE to FE. Would be more accurate to indicate > that the CE is downloading a new FIB to the FE here. > [summary of authors' discussion] > Agree. > [document change] > Figure 10 is fixed. > > 7) Vagueness of CE action in response to FE loss/reestablishment > [summary of comments] > Section 4.3 says a CE would "note" the event of FE loss or > reestablishment. Would be more informative to say that the > CE would inform routing protocols of such an event, most > likely prompting a reachability and SPF recalculation and > associated downloading of new FIB and other calculations. > [summary of authors' discussion] > Agree. > [document change] > Section 4.3.2 "FE restart" is rewritten with such clarification. > > 8) Security handshakes as part of association establishment > and re-establishment > [summary of comments] > Sections 4.2.2 and 4.2.4 should explicitly call out the > fact that FEs and CEs will perform a security handshake > as part of the association establishment/re-establishment > interaction. Need to make sure that the association is > the intended one. Authentication mechanism (IPSec? TLS? > other?) to be used to accomplish this should be identified. > [summary of authors' discussion] > Agree. Security handshake should be called out explicitly in > 4.2.2, but the details of such handshake is left to Security > Consideration section. > [document change] > Sections 4.2.2, 4.3 and Figure 7 are fixed to call out the > security handshake and re-establishment explicitly. More > details on this is provided in Section 7.2. > > 9) Cached state in re-establishment > [summary of comments] > The end of section 4.3 mentions the possibility that a FE > may reuse cached state to save Fp interactions during a > connection re-establishment. While it is ok for the > framework to call out such a possibility, it should also > make it clear that whether such a feature is actually part > of Fp will depend on protocol selection/definition. Also, > a checksum is a poor choice as it is rather unreliable. > FIBs are very important and as such a more reliable > mechanism (e.g. CRC-32) should be used. > [summary of authors' discussion] > Agree. > [document change] > Section 4.3.2 clarifies this. > > 10) Security Considerations > [summary of comments] > This is where the IESG expects the security analysis of > the framework and outlining the actual security mechanisms > that should be present in the architecture. The document should > provide vulnerability analysis of the framework, and how > identified vulnerabilities should be covered. > [summary of authors' discussion] > Agree. > [document change] > Section 7 is rewritten entirely to provide detailed threat > analysis and security recommendation based on TLS and IPsec. > We didn't choose one over the other here because we believe > it is best to delay the decision of choosing a specific > security mechanism to protocol design phase, when the proper > choice of transport should be debated first before we can > debate the right choice for security. > > 11) Editorial changes > [summary of comments] > Security considerations belongs before references. > There are 8 bit characters in the draft that need to be excised. > [summary of authors' discussion] > Agree. > [document change] > Fixed. > > > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 10 13:47:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10628 for ; Tue, 10 Jun 2003 13:47:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PnBe-0000vC-00 for forces-archive@IETF.ORG; Tue, 10 Jun 2003 13:45:34 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19PnBc-0000v9-00 for forces-archive@IETF.ORG; Tue, 10 Jun 2003 13:45:32 -0400 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.00A0A9B9@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 13:47:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45189106 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 10 Jun 2003 13:47:33 -0400 Received: from 194.196.100.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Jun 2003 13:47:32 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5AHlVsn088094 for ; Tue, 10 Jun 2003 19:47:31 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5AHlUNQ111754 for ; Tue, 10 Jun 2003 19:47:30 +0200 Received: from dhcp70-38.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56368 from ; Tue, 10 Jun 2003 19:47:30 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Mime-Version: 1.0 References: <42050DF556283A4D977B111EB706320812FE0B@orsmsx407.jf.intel.com> Content-Type: multipart/alternative; boundary="------------010000040603080002080800" Approved-By: Robert Haas Message-ID: <3EE619B2.9090309@zurich.ibm.com> Date: Tue, 10 Jun 2003 19:47:30 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: ForCES Requirements draft updated (v-09) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --------------010000040603080002080800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate-3.de.ibm.com id h5AHlVsn088094 Content-Transfer-Encoding: quoted-printable Hormuzd, To me, the following two sentences have the same meaning: "ForCES MUST NOT impose strict reliability" "ForCES MUST NOT be restricted to strict reliability ..." So I am fine with your proposal of replacing in section 7 point 6): "ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT be restric= ted to strict reliability" -Robert Khosravi, Hormuzd M wrote: >Patrick, > >The exact meaning of that text is brought out in the wording that I sugg= ested i.e. >"ForCES MUST NOT be restricted to strict reliability for that particular= case" >This was the intended meaning of the text. Does this make things clear ?= =20 > >Let me know. > >Thanks >Hormuzd >-----Original Message----- >From: Patrick Droz [mailto:dro@zurich.ibm.com]=20 >Sent: Friday, June 06, 2003 2:07 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) > > >Hormuzd, > >I did not suggest the MAY NOT. What I said is that the SHOULD >NOT phrasing is a non recommended term. I also asked the DT >if they are happy with the new wording but nobody responded >to it. My take is we should use terms that are approved and >do have a very clear meaning. Therefore, I ask again what is >the exact meaning of that particular phrase. What is the >protocol exactly expecting to use? > >Thanks, >Patrick > >Khosravi, Hormuzd M wrote: > =20 > >>Hi Robert, >>=20 >>The intent of the text is NOT "ForCES prohibits strict reliability for=20 >>that case" which is why Patrick suggested using MAY NOT for the wording= .=20 >>Using "MUST NOT" changes the meaning of the text to what you have=20 >>stated, which is not the intent. If using MAY NOT was such a big issue,= =20 >>I am sure that the chairs would have pointed that out earlier. However,= =20 >>if the text must be changed to remove "MAY NOT", I would suggest the=20 >>following wording..."ForCES MUST NOT be restricted to strict=20 >>reliability" which would bring out the correct intent of the text i.e.=20 >>both strictly reliable & non-strictly reliable are fine for that case. >>=20 >>Thanks >>Hormuzd >> >> -----Original Message----- >> From: Robert Haas [mailto:rha@zurich.ibm.com] >> Sent: Friday, June 06, 2003 1:53 AM >> To: FORCES@PEACH.EASE.LSOFT.COM >> Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) >> >> Hi Hormuzd, >> >> Khosravi, Hormuzd M wrote: >> >> =20 >> >>>Hi Robert, >>> >>>Using "MAY NOT" for that sentence was suggested by Patrick, >>>our initial wording for that sentence was >>>"ForCES SHOULD NOT impose strict reliability". >>>However, Patrick pointed out that "SHOULD NOT" has a >>>"NOT RECOMMENDED" tag, which was not our intent with the text. >>>Hence it was changed. Using "MUST NOT" also has the >>>"NOT RECOMMENDED" tag and therefore I don't think this >>>would bring out the correct intent for the text. >>> =20 >>> >> "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the >> excerpt from RFC 2119. >> >> This is why I think it is more appropriate to use "MUST NOT" instea= d >> of "MAY NOT". The meaning remains as intended and there is no room >> for confusion: >> >>"ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose s= trict reliability" >> >> means that it is prohibited that ForCES imposes strict reliability. >> Or do you mean sth else ? >> >> Thanks, >> -Robert >> >> >>1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >> definition is an absolute requirement of the specification. >> >>2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the >> definition is an absolute prohibition of the specification. >> >>3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. >> >>4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that >> there may exist valid reasons in particular circumstances when the >> particular behavior is acceptable or even useful, but the full >> implications should be understood and the case carefully weighed >> before implementing any behavior described with this label. >> >>5. MAY This word, or the adjective "OPTIONAL", mean that an item is >> truly optional. >> >> >> >> =20 >> >>>Thanks >>>Hormuzd >>>-----Original Message----- >>>From: Robert Haas [mailto:rha@zurich.ibm.com] >>>Sent: Thursday, June 05, 2003 8:41 AM >>>To: FORCES@PEACH.EASE.LSOFT.COM >>>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) >>> >>> >>>Hi all, >>>The requirements draft uses non-conforming wording in section 7 point = 6). >>>I checked in RFC 2119, and the words "MAY NOT" do not exist there. >>>So the sentence "ForCES MAY NOT impose strict reliability" should be >>>changed to "MUST NOT". >>> >>>Regards, >>>-Robert >>> >>> >>>Khosravi, Hormuzd M wrote: >>> >>>=20 >>> >>> =20 >>> >>>>Hi Folks, >>>> >>>>Continuing from my last email......... >>>>Here is the brief summary of IESG comments/discussion/changes in the >>>>draft: >>>>Chairs, IESG can provide more details on their comments... ? >>>> >>>>1. comment - Reliability - IESG was not satisfied with the Reliabilit= y >>>>text, >>>>especially in context with the Security requirement (TLS can only be >>>>used >>>>with reliable transport). IESG was leaning towards use of reliable >>>>transport >>>>which would also simplify the Security requirement. Chairs, can add m= ore >>>>details here ? >>>>Discussion - This topic was most heavily discussed in the Design team >>>>for more >>>>than a month over several emails. I cannot go thru all the details he= re, >>>>but >>>>essentially the team came up with this text which tries to capture al= l >>>>the >>>>different thoughts of the team. >>>>New Text - >>>>A) The ForCES protocol will be used to transport information that >>>>requires varying levels of reliability. By strict or robust reliabili= ty >>>>in this requirement we mean, no losses, no corruption, no re-ordering= of >>>> >>>>information being transported and delivery in a timely fashion. >>>>B) Some information or payloads, such as redirected packets or packet >>>>sampling, may not require robust reliability (can tolerate some degre= e >>>>of losses). >>>>For information of this sort, ForCES MAY NOT impose strict reliabilit= y. >>>>C) Payloads such as configuration information, e.g. ACLs, FIB entries= , >>>>or FE capability information (described in section 7, (1))are mission >>>>critical and must be delivered in a robust reliable fashion. Thus, fo= r >>>>information >>>>of this sort, ForCES MUST either provide built-in protocol mechanisms= or >>>>use a >>>>reliable transport protocol for achieving robust/strict reliability. >>>>D) Some information or payloads, such as heartbeat packets that may b= e >>>>used to detect loss of association between CE and FEs (see section 7, >>>>(8)), may >>>>prefer timeliness over reliable delivery. For information of this sor= t, >>>>ForCES >>>>MAY NOT impose strict reliability. >>>>E) When ForCES is carried over multi-hop IP networks, it is a >>>>requirement >>>>that ForCES MUST use a [RFC2914]-compliant transport protocol. >>>>F) In cases where ForCES is not running over an IP network such as an >>>>Ethernet or cell fabric between CE and FE, then reliability still MUS= T >>>>be provided >>>>when carrying critical information of the types specified in (C) abov= e, >>>>either >>>>by the underlying link/network/transport layers or by built-in protoc= ol >>>>mechanisms. >>>> >>>>2. comment - Security - TLS can only work with reliable transport whi= ch >>>>was >>>>the cause of some confusion to the IESG. Also, the Sec. directorate >>>>wanted >>>>us to have text which described all the different attacks which were >>>>possible >>>>on a ForCES box & come up with requirements after some analysis from >>>>that angle. >>>>The Design team agreed and came up with the new text. >>>>New Text - >>>>a) FE configuration will contain information critical to the >>>>functioning of a network (e.g. IP Forwarding Tables). As such, it MUS= T >>>>be >>>>possible to ensure the integrity of all ForCES protocol messages and >>>>protect >>>>against man-in-the-middle attacks. >>>>b) FE configuration information may also contain information derived >>>> =20 >>>> =20 >>>> >>>>from business relationships (e.g. service >>>=20 >>> >>> =20 >>> >>>>level agreements). Because of the confidential nature of the >>>>information, >>>>it MUST be possible to secure (make private) all ForCES protocol >>>>messages. >>>>c) In order to ensure that authorized CEs and FEs are participating i= n >>>>a NE and defend against CE or FE impersonation attacks, the ForCES >>>>architecture MUST select a means of authentication for CEs and FEs. >>>>d) In some deployments ForCES is expected to be deployed between CEs >>>>and FEs connected to each other inside a box >>>>over a backplane, where physical security of the box ensures that >>>>man-in-the-middle, snooping, and impersonation attacks are not possib= le. >>>>In >>>>such scenarios the ForCES architecture MAY rely on the physical secur= ity >>>>of >>>>the box to defend against these attacks and protocol mechanisms May b= e >>>>turned off. >>>>e) In the case when CEs and FEs are connected over a network, securit= y >>>>mechanisms MUST be specified or selected that protect the ForCES >>>>protocol >>>>against such attacks. Any security solution used for ForCES MUST >>>>specify >>>>how it deals with such attacks. >>>> >>>>3. comment - The IESG suggested that it was important for ForCES to >>>>think >>>>about DoS attacks to the protocol. The ForCES protocol could be attac= ked >>>>with bogus routing packets which could lead to the protocol >>>>disfunctioning. >>>>Alex, could provide more details here ? >>>>The Design team agreed and came up with the new text. >>>>New Text - >>>>Protection against Denial of Service Attacks (based on CPU overload o= r >>>>queue overflow) >>>>Systems utilizing the ForCES protocol can be attacked using denial of >>>>service attacks based on CPU overload or queue overflow. >>>>The ForCES protocol could be exploited by such attacks to >>>>cause the CE to become unable to control the FE or appropriately >>>>communicate >>>>with other routers and systems. The ForCES protocol MUST therefore >>>>provide >>>>mechanisms for controlling FE capabilities that can be used to protec= t >>>>against such attacks. FE capabilities that Must be manipulated >>>>via ForCES include the ability to install classifiers and filters to >>>>detect >>>>and drop attack packets, as well as to be able to install rate limite= rs >>>>that >>>>limit the rate of packets which appear to be valid but may be part of= an >>>>attack (e.g. bogus BGP packets). >>>> >>>>4. comment - The IESG suggested that it was important for ForCES to t= alk >>>>about IPFLOW/PSAMP functions which have been widely deployed in >>>>networks. >>>>The Design team agreed and came up with the new text. >>>>New Text - >>>>IPFLOW/PSAMP Functions >>>>Several applications such as, Usage-based Accounting, Traffic >>>>engineering, >>>>require flow-based IP traffic measurements from Network Elements. >>>>[IPFLOW] >>>>defines architecture for IP traffic flow monitoring, measuring and >>>>exporting. The FE model SHOULD be able to express metering functions = and >>>>flow accounting needed for exporting IP traffic flow information. >>>>Similarly to support measurement-based applications, [PSAMP] describe= s a >>>>framework to define a standard set of capabilities for network elemen= ts >>>>to >>>>sample subsets of packets by statistical and other methods. The FE mo= del >>>>SHOULD be able to express statistical packet filtering functions and >>>>packet >>>>information needed for supporting packet sampling applications. >>>> >>>>Pls do let us know if you have any comments. >>>> >>>>Thanks >>>>Hormuzd >>>> >>>>-----Original Message----- >>>>From: Alex Zinin [mailto:zinin@psg.com] >>>>Sent: Wednesday, May 21, 2003 7:02 PM >>>>To: Khosravi, Hormuzd M >>>>Cc: Forwarding and Control Element Separation >>>>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09) >>>> >>>> >>>>Folks- >>>> >>>>I've just updated the ID tracker to include the comments from the >>>>IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should >>>>have been done before.) >>>> >>>>There were also some comments from the ops-dir proxied by Randy, >>>>which resulted in a discussion between the WG chairs and Pekka. I'd >>>>like to ask the chairs to send a summary of the discussion to the >>>>list. >>>> >>>>Hormuzd, to make sure the WG can follow the discussion, could you >>>>please come up with a summary in a form similar to the following: >>>> >>>> Comment: ... >>>> >>>> Summary of discussion: ... >>>> >>>> Changes in document: ... >>>> >>>>Thanks. >>>> >>>> >>>> >>>> =20 >>>> =20 >>>> >>>=20 >>> =20 >>> >>-- >>Robert Haas >>IBM Zurich Research Laboratory >>S=E4umerstrasse 4 >>CH-8803 R=FCschlikon/Switzerland >>phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rh= a >> >> >> =20 >> > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------010000040603080002080800 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hormuzd,
To me, the following two sentences have the same meaning:
"ForCES MUST NOT impose strict reliability"
"ForCES MUST NOT be restricted to strict reliability ..."
So I am fine with your proposal of replacing in section 7 point 6):
"ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT be restricted to strict reliability"
-Robert

Khosravi, Hormuzd M wrote:
Patrick,

The exact meaning of that text is brought out in the wording that I suggested i.e.
"ForCES MUST NOT be restricted to strict reliability for that particular case"
This was the intended meaning of the text. Does this make things clear ?

Let me know.

Thanks
Hormuzd
-----Original Message-----
From: Patrick Droz [mailto:dro@zurich.ibm.com]
Sent: Friday, June 06, 2003 2:07 PM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)


Hormuzd,

I did not suggest the MAY NOT. What I said is that the SHOULD
NOT phrasing is a non recommended term. I also asked the DT
if they are happy with the new wording but nobody responded
to it. My take is we should use terms that are approved and
do have a very clear meaning. Therefore, I ask again what is
the exact meaning of that particular phrase. What is the
protocol exactly expecting to use?

Thanks,
Patrick

Khosravi, Hormuzd M wrote:
  
Hi Robert,

The intent of the text is NOT "ForCES prohibits strict reliability for
that case" which is why Patrick suggested using MAY NOT for the wording.
Using "MUST NOT" changes the meaning of the text to what you have
stated, which is not the intent. If using MAY NOT was such a big issue,
I am sure that the chairs would have pointed that out earlier. However,
if the text must be changed to remove "MAY NOT", I would suggest the
following wording..."ForCES MUST NOT be restricted to strict
reliability" which would bring out the correct intent of the text i.e.
both strictly reliable & non-strictly reliable are fine for that case.

Thanks
Hormuzd

    -----Original Message-----
    From: Robert Haas [mailto:rha@zurich.ibm.com]
    Sent: Friday, June 06, 2003 1:53 AM
    To: FORCES@PEACH.EASE.LSOFT.COM
    Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)

    Hi Hormuzd,

    Khosravi, Hormuzd M wrote:

    
Hi Robert,

Using "MAY NOT" for that sentence was suggested by Patrick,
our initial wording for that sentence was
"ForCES SHOULD NOT impose strict reliability".
However, Patrick pointed out that "SHOULD NOT" has a
"NOT RECOMMENDED" tag, which was not our intent with the text.
Hence it was changed. Using "MUST NOT" also has the
"NOT RECOMMENDED" tag and therefore I don't think this
would bring out the correct intent for the text.
      
    "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the
    excerpt from RFC 2119.

    This is why I think it is more appropriate to use "MUST NOT" instead
    of "MAY NOT". The meaning remains as intended and there is no room
    for confusion:

"ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose strict reliability"

    means that it is prohibited that ForCES imposes strict reliability.
    Or do you mean sth else ?

    Thanks,
    -Robert


1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.



    
Thanks
Hormuzd
-----Original Message-----
From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, June 05, 2003 8:41 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)


Hi all,
The requirements draft uses non-conforming wording in section 7 point 6).
I checked in RFC 2119, and the words "MAY NOT" do not exist there.
So the sentence "ForCES MAY NOT impose strict reliability" should be
changed to "MUST NOT".

Regards,
-Robert


Khosravi, Hormuzd M wrote:



      
Hi Folks,

Continuing from my last email.........
Here is the brief summary of IESG comments/discussion/changes in the
draft:
Chairs, IESG can provide more details on their comments... ?

1. comment - Reliability - IESG was not satisfied with the Reliability
text,
especially in context with the Security requirement (TLS can only be
used
with reliable transport). IESG was leaning towards use of reliable
transport
which would also simplify the Security requirement. Chairs, can add more
details here ?
Discussion - This topic was most heavily discussed in the Design team
for more
than a month over several emails. I cannot go thru all the details here,
but
essentially the team came up with this text which tries to capture all
the
different thoughts of the team.
New Text -
A) The ForCES protocol will be used to transport information that
requires varying levels of reliability. By strict or robust reliability
in this requirement we mean, no losses, no corruption, no re-ordering of

information being transported and delivery in a timely fashion.
B) Some information or payloads, such as redirected packets or packet
sampling, may not require robust reliability (can tolerate some degree
of losses).
For information of this sort, ForCES MAY NOT impose strict reliability.
C) Payloads such as configuration information, e.g. ACLs, FIB entries,
or FE capability information (described in section 7, (1))are mission
critical and must be delivered in a robust reliable fashion. Thus, for
information
of this sort, ForCES MUST either provide built-in protocol mechanisms or
use a
reliable transport protocol for achieving robust/strict reliability.
D) Some information or payloads, such as heartbeat packets that may be
used to detect loss of association between CE and FEs (see section 7,
(8)), may
prefer timeliness over reliable delivery. For information of this sort,
ForCES
MAY NOT impose strict reliability.
E) When ForCES is carried over multi-hop IP networks, it is a
requirement
that ForCES MUST use a [RFC2914]-compliant transport protocol.
F) In cases where ForCES is not running over an IP network such as an
Ethernet or cell fabric between CE and FE, then reliability still MUST
be provided
when carrying critical information of the types specified in (C) above,
either
by the underlying link/network/transport layers or by built-in protocol
mechanisms.

2. comment - Security - TLS can only work with reliable transport which
was
the cause of some confusion to the IESG. Also, the Sec. directorate
wanted
us to have text which described all the different attacks which were
possible
on a ForCES box & come up with requirements after some analysis from
that angle.
The Design team agreed and came up with the new text.
New Text -
a) FE configuration will contain information critical to the
functioning of a network (e.g. IP Forwarding Tables). As such, it MUST
be
possible to ensure the integrity of all ForCES protocol messages and
protect
against man-in-the-middle attacks.
b) FE configuration information may also contain information derived

        
>from business relationships (e.g. service


      
level agreements). Because of the confidential nature of the
information,
it MUST be possible to secure (make private) all ForCES protocol
messages.
c) In order to ensure that authorized CEs and FEs are participating in
a NE and defend against CE or FE impersonation attacks, the ForCES
architecture MUST select a means of authentication for CEs and FEs.
d) In some deployments ForCES is expected to be deployed between CEs
and FEs connected to each other inside a box
over a backplane, where physical security of the box ensures that
man-in-the-middle, snooping, and impersonation attacks are not possible.
In
such scenarios the ForCES architecture MAY rely on the physical security
of
the box to defend against these attacks and protocol mechanisms May be
turned off.
e) In the case when CEs and FEs are connected over a network, security
mechanisms MUST be specified or selected that protect the ForCES
protocol
against such attacks.  Any security solution used for ForCES MUST
specify
how it deals with such attacks.

3. comment - The IESG suggested that it was important for ForCES to
think
about DoS attacks to the protocol. The ForCES protocol could be attacked
with bogus routing packets which could lead to the protocol
disfunctioning.
Alex, could provide more details here ?
The Design team agreed and came up with the new text.
New Text -
Protection against Denial of Service Attacks (based on CPU overload or
queue overflow)
Systems utilizing the ForCES protocol can be attacked using denial of
service attacks based on CPU overload or queue overflow.
The ForCES protocol could be exploited by such attacks to
cause the CE to become unable to control the FE or appropriately
communicate
with other routers and systems.  The ForCES protocol MUST therefore
provide
mechanisms for controlling FE capabilities that can be used to protect
against such attacks. FE capabilities that Must be manipulated
via ForCES include the ability to install classifiers and filters to
detect
and drop attack packets, as well as to be able to install rate limiters
that
limit the rate of packets which appear to be valid but may be part of an
attack (e.g. bogus BGP packets).

4. comment - The IESG suggested that it was important for ForCES to talk
about IPFLOW/PSAMP functions which have been widely deployed in
networks.
The Design team agreed and came up with the new text.
New Text -
IPFLOW/PSAMP Functions
Several applications such as, Usage-based Accounting, Traffic
engineering,
require flow-based IP traffic measurements from Network Elements.
[IPFLOW]
defines architecture for IP traffic flow monitoring, measuring and
exporting. The FE model SHOULD be able to express metering functions and
flow accounting needed for exporting IP traffic flow information.
Similarly to support measurement-based applications, [PSAMP] describes a
framework to define a standard set of capabilities for network elements
to
sample subsets of packets by statistical and other methods. The FE model
SHOULD be able to express statistical packet filtering functions and
packet
information needed for supporting packet sampling applications.

Pls do let us know if you have any comments.

Thanks
Hormuzd

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Wednesday, May 21, 2003 7:02 PM
To: Khosravi, Hormuzd M
Cc: Forwarding and Control Element Separation
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)


Folks-

I've just updated the ID tracker to include the comments from the
IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should
have been done before.)

There were also some comments from the ops-dir proxied by Randy,
which resulted in a discussion between the WG chairs and Pekka. I'd
like to ask the chairs to send a summary of the discussion to the
list.

Hormuzd, to make sure the WG can follow the discussion, could you
please come up with a summary in a form similar to the following:

 Comment: ...

   Summary of discussion: ...

   Changes in document: ...

Thanks.




        

      
--
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

--------------010000040603080002080800-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 11 08:04:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04300 for ; Wed, 11 Jun 2003 08:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q4JE-0006vJ-00 for forces-archive@IETF.ORG; Wed, 11 Jun 2003 08:02:32 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19Q4JD-0006uw-00 for forces-archive@IETF.ORG; Wed, 11 Jun 2003 08:02:31 -0400 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.00A0D4CC@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 8:04:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45293868 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 11 Jun 2003 08:04:11 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Jun 2003 07:54:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03723; Wed, 11 Jun 2003 07:54:09 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200306111154.HAA03723@ietf.org> Date: Wed, 11 Jun 2003 07:54:08 -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-05.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 : Forwarding and Control Element Separation (ForCES) Framework Author(s) : L. Yang et al. Filename : draft-ietf-forces-framework-05.txt Pages : 34 Date : 2003-6-10 This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and the interaction among them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-05.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-05.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-05.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: <2003-6-10110900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-10110900.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 11 19:27:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09245 for ; Wed, 11 Jun 2003 19:27:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QExm-0005FI-00 for forces-archive@IETF.ORG; Wed, 11 Jun 2003 19:25:06 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19QExk-0005FD-00 for forces-archive@IETF.ORG; Wed, 11 Jun 2003 19:25:05 -0400 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.00A0EDDA@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 19:27:08 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45346889 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 11 Jun 2003 19:27:07 -0400 Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Jun 2003 19:27:06 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5BNMRW15162 for ; Wed, 11 Jun 2003 23:22:28 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5BNRcl07607 for ; Wed, 11 Jun 2003 23:27:38 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003061116270105342 for ; Wed, 11 Jun 2003 16:27:01 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Jun 2003 16:27:01 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: mechanical problems with draft-ietf-forces-framework-05.txt Thread-Index: AcMwQh2TxBui1VGgSSqOsXeZDvKR1AALmqrw X-OriginalArrivalTime: 11 Jun 2003 23:27:01.0409 (UTC) FILETIME=[F5C1B910:01C33070] Approved-By: "Yang, Lily L" Message-ID: Date: Wed, 11 Jun 2003 16:27:01 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: FW: mechanical problems with draft-ietf-forces-framework-05.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA09245 Thanks Randy, for pointing this out. I will fix this right away! Lily -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, June 11, 2003 10:45 AM To: ram.gopal@nokia.com; Anderson, Todd A; rdantu@unt.edu; Yang, Lily L Cc: Putzolu, David; dro@zurich.ibm.com Subject: mechanical problems with draft-ietf-forces-framework-05.txt Hi - (Feel free to forward these comments to the WG if you feel it necessary.) There are a lot of mechanical problems with the draft-ietf-forces-framework-05.txt document; see http://www.ietf.org/ietf/1id-guidelines.txt for detailed rules on line length, permitted characters, and form feed placement. In my experience, it's a good idea to fix this stuff before things get to the RFC editor. Otherwise, the number of deltas during the "author's 48 hours" can be overwhelming, and inadvertant errors can easliy creep in. Specifically: line 3 too long (77 characters) line 4 too long (77 characters) line 5 too long (77 characters) line 6 too long (78 characters) line 7 too long (77 characters) line 8 too long (77 characters) line 9 too long (77 characters) line 10 too long (79 characters) line 11 too long (86 characters) trailing blanks make line 14 too long (73 characters) line 26 too long (75 characters) line 28 too long (77 characters) line 33 too long (77 characters) trailing blanks make line 41 too long (74 characters) trailing blanks make line 46 too long (73 characters) trailing blanks make line 50 too long (73 characters) line 51 too long (74 characters) line 52 too long (75 characters) bad FF at line 56 line 61 too long (77 characters) line 63 too long (77 characters) line 64 too long (77 characters) line 65 too long (77 characters) line 66 too long (77 characters) line 67 too long (77 characters) line 68 too long (77 characters) line 69 too long (77 characters) line 70 too long (77 characters) line 71 too long (77 characters) line 72 too long (77 characters) line 73 too long (77 characters) line 74 too long (77 characters) line 75 too long (77 characters) line 76 too long (77 characters) line 77 too long (77 characters) line 78 too long (77 characters) line 79 too long (77 characters) line 80 too long (77 characters) line 81 too long (77 characters) line 82 too long (77 characters) line 83 too long (77 characters) line 84 too long (77 characters) line 85 too long (77 characters) line 86 too long (77 characters) line 87 too long (77 characters) line 88 too long (77 characters) line 89 too long (77 characters) line 90 too long (77 characters) line 91 too long (77 characters) line 92 too long (77 characters) line 93 too long (77 characters) 0xe6 at line 94 position 22 0xe6 at line 94 position 23 0xc6 at line 94 position 28 0xc6 at line 94 position 29 0xe6 at line 94 position 34 0xe6 at line 94 position 35 0xc6 at line 94 position 42 0xc6 at line 94 position 43 line 94 too long (81 characters) line 95 too long (77 characters) line 96 too long (77 characters) line 97 too long (77 characters) line 98 too long (77 characters) line 99 too long (77 characters) line 100 too long (77 characters) line 101 too long (77 characters) line 102 too long (77 characters) line 103 too long (77 characters) line 104 too long (77 characters) line 105 too long (77 characters) line 106 too long (77 characters) line 107 too long (77 characters) line 108 too long (77 characters) line 109 too long (77 characters) line 110 too long (77 characters) line 111 too long (77 characters) bad FF at line 114 line 120 too long (77 characters) trailing blanks make line 121 too long (73 characters) line 127 too long (75 characters) line 130 too long (106 characters) line 131 too long (77 characters) line 132 too long (76 characters) line 133 too long (76 characters) trailing blanks make line 136 too long (73 characters) line 137 too long (75 characters) line 138 too long (77 characters) trailing blanks make line 143 too long (73 characters) line 144 too long (75 characters) trailing blanks make line 145 too long (73 characters) line 148 too long (75 characters) line 149 too long (76 characters) line 156 too long (73 characters) line 157 too long (74 characters) line 158 too long (77 characters) line 161 too long (75 characters) line 163 too long (77 characters) line 164 too long (77 characters) line 167 too long (76 characters) line 168 too long (76 characters) bad FF at line 172 line 177 too long (77 characters) line 178 too long (74 characters) line 181 too long (75 characters) line 182 too long (74 characters) line 183 too long (75 characters) line 186 too long (76 characters) line 187 too long (75 characters) trailing blanks make line 188 too long (73 characters) line 190 too long (76 characters) line 191 too long (76 characters) line 192 too long (77 characters) line 193 too long (77 characters) line 194 too long (79 characters) line 196 too long (77 characters) line 197 too long (74 characters) line 200 too long (75 characters) line 201 too long (76 characters) line 202 too long (74 characters) trailing blanks make line 203 too long (73 characters) line 205 too long (75 characters) line 207 too long (74 characters) line 210 too long (76 characters) line 211 too long (79 characters) line 212 too long (74 characters) trailing blanks make line 213 too long (73 characters) line 215 too long (77 characters) line 216 too long (76 characters) line 220 too long (76 characters) line 221 too long (74 characters) line 222 too long (77 characters) line 223 too long (77 characters) trailing blanks make line 224 too long (73 characters) line 225 too long (75 characters) bad FF at line 229 line 233 too long (75 characters) line 238 too long (77 characters) line 239 too long (77 characters) line 240 too long (76 characters) line 245 too long (76 characters) line 250 too long (74 characters) line 251 too long (75 characters) line 252 too long (75 characters) line 253 too long (77 characters) line 254 too long (77 characters) line 255 too long (76 characters) line 256 too long (76 characters) line 261 too long (76 characters) line 263 too long (76 characters) line 269 too long (74 characters) line 270 too long (75 characters) trailing blanks make line 271 too long (73 characters) trailing blanks make line 272 too long (73 characters) line 275 too long (75 characters) line 276 too long (76 characters) bad FF at line 287 0xe0 at line 295 position 51 0xe0 at line 303 position 51 line 306 too long (76 characters) line 309 too long (75 characters) line 314 too long (74 characters) line 316 too long (75 characters) line 318 too long (74 characters) line 320 too long (75 characters) line 321 too long (74 characters) 0xe0 at line 333 position 30 line 343 too long (75 characters) bad FF at line 345 line 350 too long (76 characters) line 351 too long (74 characters) line 352 too long (74 characters) line 353 too long (75 characters) line 354 too long (74 characters) line 356 too long (76 characters) line 357 too long (76 characters) line 359 too long (76 characters) line 360 too long (74 characters) line 361 too long (75 characters) line 362 too long (76 characters) line 363 too long (74 characters) line 367 too long (77 characters) line 369 too long (75 characters) line 370 too long (77 characters) line 373 too long (75 characters) line 374 too long (74 characters) trailing blanks make line 375 too long (73 characters) 0xe0 at line 382 position 55 0xe0 at line 396 position 55 bad FF at line 403 line 411 too long (74 characters) line 412 too long (75 characters) line 413 too long (75 characters) trailing blanks make line 414 too long (73 characters) trailing blanks make line 415 too long (73 characters) trailing blanks make line 416 too long (73 characters) line 417 too long (76 characters) line 418 too long (77 characters) trailing blanks make line 426 too long (74 characters) line 427 too long (75 characters) trailing blanks make line 444 too long (86 characters) line 454 too long (75 characters) line 456 too long (77 characters) line 457 too long (77 characters) line 459 too long (76 characters) bad FF at line 461 line 465 too long (76 characters) 0xc6 at line 466 position 11 line 466 too long (75 characters) trailing blanks make line 467 too long (73 characters) line 468 too long (75 characters) line 469 too long (76 characters) line 471 too long (76 characters) line 472 too long (75 characters) line 473 too long (76 characters) line 476 too long (75 characters) line 477 too long (77 characters) line 478 too long (75 characters) line 479 too long (74 characters) line 480 too long (75 characters) line 484 too long (75 characters) line 486 too long (74 characters) line 491 too long (76 characters) line 495 too long (74 characters) line 496 too long (75 characters) line 499 too long (75 characters) trailing blanks make line 500 too long (73 characters) line 501 too long (75 characters) line 502 too long (74 characters) line 503 too long (75 characters) line 506 too long (74 characters) line 507 too long (74 characters) line 512 too long (74 characters) trailing blanks make line 513 too long (73 characters) line 514 too long (77 characters) line 516 too long (77 characters) line 517 too long (74 characters) bad FF at line 519 line 524 too long (77 characters) line 530 too long (76 characters) line 533 too long (76 characters) line 534 too long (77 characters) line 535 too long (77 characters) line 536 too long (76 characters) line 537 too long (74 characters) line 538 too long (75 characters) line 539 too long (74 characters) trailing blanks make line 540 too long (73 characters) line 541 too long (75 characters) trailing blanks make line 544 too long (73 characters) line 545 too long (74 characters) line 546 too long (76 characters) line 547 too long (74 characters) line 549 too long (77 characters) trailing blanks make line 550 too long (73 characters) trailing blanks make line 551 too long (73 characters) line 552 too long (74 characters) line 572 too long (74 characters) trailing blanks make line 573 too long (74 characters) line 574 too long (77 characters) bad FF at line 576 line 580 too long (74 characters) line 583 too long (76 characters) line 585 too long (77 characters) trailing blanks make line 586 too long (73 characters) line 587 too long (76 characters) line 589 too long (74 characters) line 590 too long (76 characters) line 591 too long (77 characters) line 593 too long (77 characters) line 594 too long (74 characters) line 595 too long (77 characters) line 596 too long (75 characters) trailing blanks make line 597 too long (73 characters) 0xc6 at line 598 position 26 0xc6 at line 598 position 27 line 601 too long (76 characters) line 602 too long (76 characters) line 603 too long (76 characters) line 605 too long (77 characters) line 607 too long (76 characters) line 608 too long (77 characters) bad FF at line 633 line 683 too long (75 characters) line 684 too long (74 characters) line 686 too long (75 characters) bad FF at line 691 line 697 too long (74 characters) line 698 too long (77 characters) line 700 too long (77 characters) line 701 too long (74 characters) line 702 too long (75 characters) line 709 too long (74 characters) line 710 too long (76 characters) line 712 too long (75 characters) line 719 too long (77 characters) line 721 too long (77 characters) line 727 too long (75 characters) line 728 too long (74 characters) line 729 too long (74 characters) trailing blanks make line 730 too long (73 characters) line 735 too long (76 characters) line 736 too long (75 characters) line 737 too long (74 characters) line 741 too long (77 characters) line 742 too long (74 characters) line 743 too long (76 characters) line 744 too long (77 characters) trailing blanks make line 746 too long (73 characters) trailing blanks make line 747 too long (73 characters) bad FF at line 749 line 753 too long (75 characters) line 771 too long (75 characters) line 773 too long (74 characters) line 774 too long (74 characters) trailing blanks make line 775 too long (73 characters) trailing blanks make line 776 too long (73 characters) line 777 too long (75 characters) trailing blanks make line 778 too long (73 characters) line 779 too long (74 characters) line 780 too long (76 characters) line 784 too long (76 characters) line 786 too long (75 characters) line 788 too long (75 characters) line 790 too long (76 characters) trailing blanks make line 792 too long (73 characters) line 793 too long (77 characters) line 799 too long (77 characters) bad FF at line 805 line 811 too long (76 characters) trailing blanks make line 828 too long (73 characters) line 829 too long (79 characters) line 830 too long (77 characters) line 832 too long (77 characters) line 833 too long (74 characters) line 834 too long (77 characters) trailing blanks make line 835 too long (73 characters) line 838 too long (74 characters) trailing blanks make line 839 too long (73 characters) line 844 too long (75 characters) line 845 too long (75 characters) line 846 too long (75 characters) trailing blanks make line 847 too long (73 characters) trailing blanks make line 849 too long (73 characters) line 856 too long (74 characters) line 857 too long (75 characters) line 860 too long (76 characters) bad FF at line 863 line 869 too long (77 characters) line 871 too long (77 characters) line 872 too long (77 characters) line 873 too long (74 characters) line 890 too long (77 characters) line 912 too long (76 characters) trailing blanks make line 916 too long (73 characters) trailing blanks make line 917 too long (73 characters) line 918 too long (74 characters) bad FF at line 921 trailing blanks make line 925 too long (74 characters) line 926 too long (76 characters) line 927 too long (77 characters) line 928 too long (75 characters) line 929 too long (77 characters) line 930 too long (75 characters) line 931 too long (77 characters) trailing blanks make line 932 too long (74 characters) line 933 too long (75 characters) line 934 too long (76 characters) line 936 too long (74 characters) line 938 too long (76 characters) line 939 too long (75 characters) line 945 too long (77 characters) trailing blanks make line 966 too long (74 characters) bad FF at line 978 line 982 too long (75 characters) line 985 too long (75 characters) line 987 too long (76 characters) line 988 too long (75 characters) line 994 too long (76 characters) line 995 too long (77 characters) line 996 too long (75 characters) line 997 too long (74 characters) line 998 too long (78 characters) line 999 too long (75 characters) line 1000 too long (76 characters) line 1001 too long (76 characters) line 1002 too long (75 characters) line 1003 too long (78 characters) line 1004 too long (74 characters) trailing blanks make line 1027 too long (73 characters) trailing blanks make line 1029 too long (73 characters) line 1032 too long (77 characters) line 1034 too long (76 characters) bad FF at line 1036 line 1040 too long (76 characters) line 1045 too long (75 characters) line 1046 too long (77 characters) line 1047 too long (77 characters) trailing blanks make line 1048 too long (73 characters) line 1049 too long (76 characters) line 1050 too long (77 characters) line 1051 too long (76 characters) line 1056 too long (75 characters) line 1057 too long (75 characters) line 1058 too long (76 characters) line 1059 too long (77 characters) line 1061 too long (73 characters) line 1063 too long (77 characters) trailing blanks make line 1065 too long (73 characters) line 1066 too long (74 characters) line 1067 too long (77 characters) line 1068 too long (75 characters) line 1069 too long (74 characters) line 1070 too long (75 characters) line 1075 too long (76 characters) line 1081 too long (77 characters) line 1082 too long (74 characters) 0xc6 at line 1084 position 60 trailing blanks make line 1084 too long (73 characters) line 1085 too long (76 characters) line 1088 too long (77 characters) trailing blanks make line 1089 too long (73 characters) line 1090 too long (75 characters) line 1091 too long (76 characters) bad FF at line 1094 line 1099 too long (74 characters) line 1103 too long (74 characters) line 1104 too long (76 characters) line 1107 too long (77 characters) line 1108 too long (74 characters) line 1109 too long (76 characters) line 1110 too long (77 characters) trailing blanks make line 1111 too long (74 characters) line 1113 too long (77 characters) 0xc6 at line 1114 position 60 line 1114 too long (75 characters) line 1115 too long (75 characters) line 1116 too long (76 characters) line 1117 too long (74 characters) line 1118 too long (75 characters) line 1120 too long (74 characters) line 1123 too long (74 characters) line 1124 too long (74 characters) line 1125 too long (74 characters) line 1126 too long (74 characters) line 1127 too long (76 characters) trailing blanks make line 1128 too long (73 characters) trailing blanks make line 1129 too long (73 characters) line 1130 too long (74 characters) line 1133 too long (75 characters) line 1134 too long (74 characters) line 1135 too long (75 characters) line 1136 too long (76 characters) line 1137 too long (77 characters) line 1138 too long (74 characters) line 1139 too long (76 characters) trailing blanks make line 1140 too long (73 characters) line 1145 too long (76 characters) line 1146 too long (77 characters) line 1148 too long (76 characters) bad FF at line 1151 line 1156 too long (76 characters) line 1159 too long (75 characters) line 1160 too long (75 characters) line 1164 too long (77 characters) line 1167 too long (77 characters) line 1168 too long (75 characters) line 1169 too long (76 characters) line 1170 too long (77 characters) line 1172 too long (77 characters) trailing blanks make line 1173 too long (73 characters) line 1174 too long (74 characters) line 1175 too long (75 characters) line 1176 too long (75 characters) line 1177 too long (77 characters) line 1178 too long (75 characters) line 1181 too long (74 characters) trailing blanks make line 1187 too long (73 characters) line 1188 too long (76 characters) trailing blanks make line 1189 too long (73 characters) line 1190 too long (75 characters) line 1191 too long (77 characters) line 1193 too long (77 characters) line 1194 too long (77 characters) line 1197 too long (73 characters) line 1198 too long (76 characters) line 1199 too long (74 characters) line 1200 too long (76 characters) line 1201 too long (74 characters) line 1203 too long (75 characters) line 1204 too long (75 characters) line 1205 too long (74 characters) line 1206 too long (74 characters) line 1207 too long (75 characters) bad FF at line 1209 trailing blanks make line 1214 too long (73 characters) line 1215 too long (75 characters) line 1216 too long (76 characters) line 1217 too long (77 characters) line 1223 too long (76 characters) line 1225 too long (76 characters) line 1226 too long (78 characters) line 1227 too long (76 characters) line 1228 too long (76 characters) line 1229 too long (77 characters) line 1230 too long (75 characters) line 1232 too long (76 characters) line 1253 too long (74 characters) line 1256 too long (77 characters) line 1258 too long (76 characters) line 1260 too long (76 characters) line 1264 too long (76 characters) line 1265 too long (78 characters) bad FF at line 1267 line 1271 too long (76 characters) line 1272 too long (77 characters) line 1275 too long (76 characters) line 1280 too long (75 characters) line 1281 too long (77 characters) trailing blanks make line 1282 too long (73 characters) line 1283 too long (74 characters) line 1284 too long (76 characters) line 1285 too long (74 characters) line 1286 too long (75 characters) line 1289 too long (75 characters) line 1290 too long (77 characters) line 1294 too long (75 characters) line 1301 too long (74 characters) line 1302 too long (77 characters) trailing blanks make line 1303 too long (73 characters) line 1305 too long (76 characters) line 1306 too long (75 characters) line 1307 too long (74 characters) line 1311 too long (77 characters) line 1312 too long (74 characters) trailing blanks make line 1314 too long (73 characters) line 1317 too long (75 characters) line 1320 too long (76 characters) bad FF at line 1325 line 1335 too long (74 characters) line 1339 too long (75 characters) line 1340 too long (76 characters) line 1342 too long (74 characters) line 1343 too long (74 characters) line 1345 too long (77 characters) line 1346 too long (75 characters) line 1347 too long (77 characters) line 1349 too long (75 characters) trailing blanks make line 1350 too long (73 characters) line 1352 too long (76 characters) trailing blanks make line 1353 too long (73 characters) line 1354 too long (77 characters) trailing blanks make line 1357 too long (73 characters) line 1360 too long (77 characters) trailing blanks make line 1361 too long (73 characters) line 1362 too long (77 characters) line 1363 too long (77 characters) line 1364 too long (74 characters) line 1365 too long (75 characters) line 1366 too long (75 characters) line 1367 too long (75 characters) line 1369 too long (76 characters) line 1370 too long (74 characters) line 1375 too long (74 characters) line 1376 too long (78 characters) line 1380 too long (74 characters) line 1381 too long (74 characters) bad FF at line 1383 trailing blanks make line 1387 too long (73 characters) line 1390 too long (77 characters) line 1391 too long (75 characters) line 1396 too long (77 characters) line 1397 too long (78 characters) line 1398 too long (74 characters) line 1402 too long (76 characters) trailing blanks make line 1404 too long (73 characters) trailing blanks make line 1405 too long (73 characters) trailing blanks make line 1406 too long (73 characters) line 1407 too long (76 characters) line 1409 too long (77 characters) line 1410 too long (75 characters) line 1411 too long (76 characters) line 1412 too long (74 characters) line 1418 too long (74 characters) line 1419 too long (77 characters) line 1420 too long (77 characters) line 1425 too long (74 characters) line 1426 too long (77 characters) trailing blanks make line 1427 too long (73 characters) line 1428 too long (76 characters) trailing blanks make line 1435 too long (73 characters) trailing blanks make line 1436 too long (73 characters) bad FF at line 1441 line 1445 too long (76 characters) line 1448 too long (75 characters) line 1449 too long (76 characters) line 1450 too long (75 characters) line 1453 too long (76 characters) line 1457 too long (76 characters) line 1458 too long (74 characters) line 1459 too long (75 characters) trailing blanks make line 1460 too long (73 characters) line 1463 too long (74 characters) line 1464 too long (76 characters) trailing blanks make line 1466 too long (73 characters) line 1467 too long (77 characters) line 1472 too long (75 characters) line 1474 too long (74 characters) line 1475 too long (76 characters) 0xe6 at line 1478 position 13 0xe6 at line 1478 position 14 0xc6 at line 1478 position 19 0xc6 at line 1478 position 20 0xe6 at line 1478 position 25 0xe6 at line 1478 position 26 0xc6 at line 1478 position 33 0xc6 at line 1478 position 34 0xe6 at line 1480 position 65 0xe6 at line 1480 position 66 0xc6 at line 1480 position 74 0xc6 at line 1480 position 75 line 1480 too long (79 characters) 0xe6 at line 1481 position 9 0xe6 at line 1481 position 10 0xc6 at line 1481 position 25 0xc6 at line 1481 position 26 line 1481 too long (78 characters) line 1485 too long (74 characters) line 1487 too long (74 characters) line 1488 too long (77 characters) line 1489 too long (74 characters) line 1490 too long (76 characters) 0xe6 at line 1493 position 44 0xe6 at line 1493 position 45 0xc6 at line 1493 position 50 0xc6 at line 1493 position 51 0xe6 at line 1493 position 56 0xe6 at line 1493 position 57 0xc6 at line 1493 position 64 0xc6 at line 1493 position 65 line 1493 too long (81 characters) line 1494 too long (75 characters) bad FF at line 1499 line 1505 too long (74 characters) line 1516 too long (76 characters) line 1521 too long (74 characters) line 1526 too long (75 characters) 0xc6 at line 1527 position 65 line 1527 too long (77 characters) 0xc6 at line 1528 position 45 line 1528 too long (75 characters) line 1530 too long (77 characters) line 1531 too long (76 characters) line 1532 too long (76 characters) trailing blanks make line 1536 too long (73 characters) line 1538 too long (75 characters) line 1539 too long (74 characters) line 1540 too long (74 characters) line 1545 too long (77 characters) bad FF at line 1556 line 1560 too long (74 characters) line 1562 too long (75 characters) line 1563 too long (76 characters) line 1566 too long (74 characters) line 1573 too long (75 characters) line 1574 too long (76 characters) line 1575 too long (77 characters) 0xc6 at line 1579 position 51 trailing blanks make line 1579 too long (73 characters) line 1580 too long (75 characters) line 1585 too long (74 characters) line 1586 too long (77 characters) line 1588 too long (74 characters) line 1591 too long (75 characters) line 1592 too long (75 characters) line 1594 too long (77 characters) line 1595 too long (75 characters) line 1600 too long (76 characters) line 1601 too long (75 characters) line 1602 too long (75 characters) trailing blanks make line 1603 too long (73 characters) line 1604 too long (74 characters) line 1605 too long (76 characters) line 1608 too long (76 characters) line 1609 too long (77 characters) trailing blanks make line 1610 too long (73 characters) line 1611 too long (76 characters) bad FF at line 1613 trailing blanks make line 1617 too long (73 characters) line 1620 too long (75 characters) line 1623 too long (74 characters) line 1628 too long (77 characters) trailing blanks make line 1630 too long (73 characters) line 1632 too long (75 characters) line 1633 too long (76 characters) line 1634 too long (75 characters) line 1635 too long (76 characters) trailing blanks make line 1636 too long (73 characters) line 1637 too long (77 characters) 0xe6 at line 1638 position 42 0xe6 at line 1638 position 43 0xc6 at line 1638 position 58 0xc6 at line 1638 position 59 line 1639 too long (76 characters) line 1640 too long (76 characters) line 1648 too long (76 characters) trailing blanks make line 1649 too long (73 characters) line 1650 too long (75 characters) line 1651 too long (76 characters) line 1658 too long (76 characters) line 1659 too long (76 characters) line 1662 too long (76 characters) line 1666 too long (76 characters) bad FF at line 1670 trailing blanks make line 1674 too long (73 characters) 0xe6 at line 1680 position 27 0xe6 at line 1680 position 28 0xc6 at line 1680 position 36 0xc6 at line 1680 position 37 line 1683 too long (75 characters) line 1684 too long (75 characters) line 1685 too long (75 characters) line 1686 too long (74 characters) line 1691 too long (76 characters) line 1692 too long (74 characters) line 1693 too long (76 characters) line 1694 too long (77 characters) trailing blanks make line 1700 too long (73 characters) line 1701 too long (75 characters) line 1703 too long (75 characters) 0xc6 at line 1707 position 49 line 1709 too long (76 characters) line 1711 too long (74 characters) line 1712 too long (77 characters) line 1715 too long (75 characters) line 1716 too long (76 characters) 0xe6 at line 1717 position 24 0xe6 at line 1717 position 25 0xc6 at line 1717 position 31 0xc6 at line 1717 position 32 line 1717 too long (74 characters) line 1720 too long (76 characters) trailing blanks make line 1721 too long (73 characters) 0xe6 at line 1722 position 27 0xe6 at line 1722 position 28 0xc6 at line 1722 position 36 0xc6 at line 1722 position 37 line 1722 too long (79 characters) line 1723 too long (74 characters) line 1724 too long (74 characters) bad FF at line 1728 line 1732 too long (74 characters) line 1733 too long (76 characters) line 1734 too long (77 characters) line 1737 too long (77 characters) line 1739 too long (76 characters) trailing blanks make line 1740 too long (73 characters) line 1741 too long (75 characters) line 1744 too long (76 characters) line 1746 too long (75 characters) line 1747 too long (77 characters) trailing blanks make line 1750 too long (73 characters) line 1752 too long (76 characters) 0xe6 at line 1756 position 27 0xe6 at line 1756 position 28 0xc6 at line 1756 position 36 0xc6 at line 1756 position 37 line 1756 too long (78 characters) line 1758 too long (74 characters) line 1760 too long (75 characters) trailing blanks make line 1761 too long (74 characters) line 1762 too long (75 characters) line 1767 too long (76 characters) line 1768 too long (77 characters) line 1769 too long (74 characters) line 1770 too long (75 characters) 0xc6 at line 1771 position 28 0xe6 at line 1777 position 23 0xe6 at line 1777 position 24 line 1777 too long (78 characters) 0xe6 at line 1780 position 23 0xe6 at line 1780 position 24 line 1780 too long (75 characters) bad FF at line 1784 0xe6 at line 1788 position 35 0xe6 at line 1788 position 36 line 1788 too long (78 characters) 0xe6 at line 1794 position 31 0xe6 at line 1794 position 32 line 1794 too long (78 characters) 0xe6 at line 1797 position 34 0xe6 at line 1797 position 35 trailing blanks make line 1797 too long (73 characters) 0xe6 at line 1800 position 31 0xe6 at line 1800 position 32 line 1800 too long (73 characters) 0xe6 at line 1803 position 33 0xe6 at line 1803 position 34 line 1803 too long (75 characters) 0xe6 at line 1806 position 38 0xe6 at line 1806 position 39 0xe6 at line 1809 position 37 0xe6 at line 1809 position 38 line 1809 too long (75 characters) 0xc6 at line 1810 position 30 0xc6 at line 1810 position 31 0xe6 at line 1812 position 31 0xe6 at line 1812 position 32 0xc6 at line 1812 position 54 0xc6 at line 1812 position 55 line 1812 too long (75 characters) 0xe6 at line 1815 position 37 0xe6 at line 1815 position 38 0xc6 at line 1815 position 73 0xc6 at line 1815 position 74 line 1815 too long (76 characters) 0xe6 at line 1818 position 40 0xe6 at line 1818 position 41 0xc6 at line 1818 position 69 0xc6 at line 1818 position 70 line 1818 too long (77 characters) 0xe6 at line 1821 position 38 0xe6 at line 1821 position 39 0xc6 at line 1821 position 69 0xc6 at line 1821 position 70 0xe6 at line 1824 position 39 0xe6 at line 1824 position 40 0xc6 at line 1825 position 26 0xc6 at line 1825 position 27 0xe6 at line 1827 position 40 0xe6 at line 1827 position 41 0xc6 at line 1827 position 73 0xc6 at line 1827 position 74 line 1827 too long (76 characters) 0xe6 at line 1830 position 30 0xe6 at line 1830 position 31 0xc6 at line 1830 position 73 0xc6 at line 1830 position 74 line 1830 too long (76 characters) line 1835 too long (77 characters) trailing blanks make line 1836 too long (73 characters) line 1837 too long (77 characters) line 1838 too long (75 characters) bad FF at line 1842 line 1878 too long (76 characters) line 1885 too long (76 characters) line 1886 too long (77 characters) line 1887 too long (75 characters) trailing blanks make line 1888 too long (73 characters) line 1889 too long (74 characters) line 1890 too long (77 characters) line 1891 too long (76 characters) line 1892 too long (76 characters) line 1896 too long (75 characters) bad FF at line 1899 line 1904 too long (76 characters) line 1906 too long (77 characters) line 1907 too long (76 characters) line 1908 too long (75 characters) trailing blanks make line 1910 too long (73 characters) bad FF at line 1914 Randy From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 11 19:29:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09343 for ; Wed, 11 Jun 2003 19:29:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QF0P-0005G6-00 for forces-archive@IETF.ORG; Wed, 11 Jun 2003 19:27:49 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19QF0O-0005G3-00 for forces-archive@IETF.ORG; Wed, 11 Jun 2003 19:27:48 -0400 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.00A0EB83@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 19:29:52 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45346958 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 11 Jun 2003 19:29:51 -0400 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Jun 2003 19:29:51 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5BNLrV21677 for ; Wed, 11 Jun 2003 23:21:53 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5BNUQl10354 for ; Wed, 11 Jun 2003 23:30:26 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003061116295020638 for ; Wed, 11 Jun 2003 16:29:50 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Jun 2003 16:29:50 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: minor editorial comments on draft-ietf-forces-framework-05.txt Thread-Index: AcMwVt7KjOxoOwIoRd6Zf/y6np0j5QAGh6pQ X-OriginalArrivalTime: 11 Jun 2003 23:29:50.0247 (UTC) FILETIME=[5A645B70:01C33071] Approved-By: "Yang, Lily L" Message-ID: Date: Wed, 11 Jun 2003 16:29:50 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: FW: minor editorial comments on draft-ietf-forces-framework-05.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA09343 Thanks again, Randy. All these shall be fixed in the next version. I expect to send v06 out very soon. Meanwhile, if anybody has had a chance to review v05, please do send me your comments so that I can incorporate them into v06. Lily -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, June 11, 2003 1:11 PM To: Yang, Lily L; rdantu@unt.edu; Anderson, Todd A; ram.gopal@nokia.com Cc: dro@zurich.ibm.com; Putzolu, David Subject: minor editorial comments on draft-ietf-forces-framework-05.txt Hi - Here are a few minor editorial comments on draft-ietf-forces-framework-05.txt; feel free to forward these to the WG if you feel it necessary. I didn't do a close reading / review; this is just stuff that jumped out at me. All footers: "et. al." -> "et al." ("et" is not an abbreviation) Cover page: copyright should be updated to 2003, and year would not normally be in parenthesis. Page 3: RFC 2119 is absent from the normative references. None of the key words is used (although "MUST" appears in one quote), so I'm left wondering why this is even here. Section 1: first paragraph: the grammatical referent for "the ones" would be "requirements", which is clearly not the intent. Suggest replacing "the ones that are" with "the definitions" Forgive me if I find the definition of "addressable entity" as "an entity that is directly addressable" to be a bit circular. :-) Most of the definitions suffer from the same problem. The term "blade" should probably be defined if it's not intended to be understood as a synonym for PFE, particularly since it's important to understanding section 2. "; and on" -> "; on" (the semicolon takes the place of the conjunction) "ASICs": acronyms / abbreviations should be expanded on first use "a NE" -> "an NE" (multiple times) "a FE" -> "an FE" (multiple times) ForCES Post-Association Phase Protocol: "or" -> "nor" Section 2: "NAT" acronym should be expanded on first use "flexibility to" -> "flexibility for" "In such chassis configuration" -> "In such a chassis configuration" "blade B is the backup" -> "blade B might be the backup" "use proprietary interface" -> "use a proprietary interface" or possibly "use proprietary interfaces" "such proprietary interface" -> "such proprietary interfaces" "use different interconnect" -> "use different interconnects" "is that CE-to-FE interconnect does" -> "is that the CE-to-FE interconnect does" "saved for FE-to-FE only" -> "saved for FE-to-FE" "functions in FE include" -> "functions in the FE include" "Figure 3 shows a diagram with examples" -> "Figure 3 provides examples" Section 3.2: "FE is a logical entity" -> "An FE is a logical entity" "that FEs can focus its resource" -> "that FEs can focus their resources" "of with which FEs its CEs should communicate" -> "of which FEs its CEs should communicate with" Section 3.4: "to which CE any particular FE should initially communicate" -> "which CE any particular FE should initially communicate with" or, to use really stilted English, "with which CE..." Same problem in next sentence. "independent" -> "independently" Section 4.1.1: "may or may not" -> "may" (and elsewhere) Section 4.1.3: "Figure 7 shows example of message exchange over Fc reference point." ??? That's not what figure 7 shows. Figure 8 is probably what's intended. Section 5, first sentence: the quote is grammatically broken. Replacing "All" with "Any" would be one way to fix the original. Section 5.3: "Timestamp option" -> "The timestamp option" "FE must interpret" -> "The FE must interpret" Section 5.4: "Upon receiving IP packets, FE" -> "Upon receiving IP packets, the FE" "Routing decision is made" -> "The routing decision is made" "Otherwise, FE determines" -> "Otherwise, the FE determines" "FE also determines" -> "The FE also determines" "Sometimes FE may" -> "Sometimes an FE may" etc., etc., etc. Section 8: (Please see reference format in http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-05.txt) "F. Baker" -> "Baker, F." "RFC1812" -> "RFC 1812" "S. Floyd" -> "Floyd, S." "RFC2914" -> "RFC 2914" "H. Khosravi" -> "Khosravi. H." Section 9: "J. Case" -> "Case, J." "RFC1157" -> "RFC 1157" (It looks like this should be replaced with a current reference) "M. Daniele" -> "Daniele, M." "RFC2741" -> "RFC 2741" "Jan" -> "January" "K. Chan" -> "Chan, K." "RFC3084" -> "RFC 3084" "A. Crouch" -> "Crouch, A." "T. Anderson, J. Buerkle" -> "Anderson, T., and J. Buerkle" "RFC3532" -> "RFC 3532" "M. Leelanivas" -> "Leelanivas, M." "Feb." -> "February" "J. Moy" -> "Moy, J." "S. R. Sangli" -> "Sangli, S." "Jan 203" -> "January 2003" "M. Shand and L. Ginsberg" -> "Shand, M. and L. Ginsberg" "T. Dierks and C. Allen" -> "Dierks, T. and C. Allen" "RFC2246" -> "RFC 2246" "Jan." -> "January" "S. Kent and R. Atkinson" -> "Kent, S. and R. Atkinson" "RFC2401" -> "RFC 2401" "Nov." -> "November" "D. Harkins and D. Carrel" -> "Harkins, D. and D. Carrel" "RFC2409" -> "RFC 2409" "Nov." -> "November" "S. M. Bellovin" -> "Bellovin, S." "Oct." -> "October" Section 10: title should probably be "Acknowledgements" Section 11: some of the authors lack countries; entries are inconsistant in use of state names or US two-letter state codes. Section 12: RFC 2026 section 10 provides the boilerplate for this section. Section 13: "2002" -> "2003" Superfluous trailing '"' on page 34 Page 34's footer is in the middle of the page. Randy From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 12 04:04:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29729 for ; Thu, 12 Jun 2003 04:04:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QN2Y-0007be-00 for forces-archive@IETF.ORG; Thu, 12 Jun 2003 04:02:34 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19QN2X-0007bb-00 for forces-archive@IETF.ORG; Thu, 12 Jun 2003 04:02:33 -0400 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.00A1002E@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 4:04:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45392218 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 12 Jun 2003 04:04:25 -0400 Received: from 194.196.100.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 12 Jun 2003 04:04:25 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5C84NZX108636 for ; Thu, 12 Jun 2003 10:04:23 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5C84MEX246642 for ; Thu, 12 Jun 2003 10:04:22 +0200 Received: from dhcp70-38.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA99614 from ; Thu, 12 Jun 2003 10:04:22 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Mime-Version: 1.0 References: <200306111154.HAA03723@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate-4.de.ibm.com id h5C84NZX108636 Approved-By: Robert Haas Message-ID: <3EE83406.60304@zurich.ibm.com> Date: Thu, 12 Jun 2003 10:04:22 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: I-D ACTION:draft-ietf-forces-framework-05.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA29729 Lily, Now that we have updated the requirements draft regarding strict reliability, I think the framework draft should also be updated accordingly in section 4.2.1 (see below). In addition, in the local scope case with directly-attached CEs and FEs (such as PCI bus), I do not see the need for congestion avoidance mechanisms. [excerpt of framework draft sec. 4.2.1] "ForCES will make use of an existing RFC2914 ([2]) compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. " Regards, -Robert -- 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*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Fri Jun 13 08:00:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29429 for ; Fri, 13 Jun 2003 08:00:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QnC5-0003rI-00 for forces-archive@IETF.ORG; Fri, 13 Jun 2003 07:58:09 -0400 Received: from grape.ease.lsoft.com ([209.119.1.39]) by ietf-mx with esmtp (Exim 4.12) id 19QnC4-0003rE-00 for forces-archive@IETF.ORG; Fri, 13 Jun 2003 07:58:08 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <13.0036206F@grape.ease.lsoft.com>; Fri, 13 Jun 2003 8:00:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45530055 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 13 Jun 2003 08:00:16 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Jun 2003 07:50:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28862; Fri, 13 Jun 2003 07:50:15 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200306131150.HAA28862@ietf.org> Date: Fri, 13 Jun 2003 07:50:15 -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-06.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 : Forwarding and Control Element Separation (ForCES) Framework Author(s) : L. Yang et al. Filename : draft-ietf-forces-framework-06.txt Pages : 38 Date : 2003-6-12 This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and the interaction among them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-06.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-06.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-06.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: <2003-6-12132116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132116.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 13 12:45:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11587 for ; Fri, 13 Jun 2003 12:45:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QreV-0006bH-00 for forces-archive@IETF.ORG; Fri, 13 Jun 2003 12:43:47 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19QreU-0006bE-00 for forces-archive@IETF.ORG; Fri, 13 Jun 2003 12:43:46 -0400 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.00A13296@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 12:45:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45546049 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 13 Jun 2003 12:45:44 -0400 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Jun 2003 12:45:44 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5DGbhJ02525 for ; Fri, 13 Jun 2003 16:37:43 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5DGcwe28601 for ; Fri, 13 Jun 2003 16:38:59 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003061309454217981 for ; Fri, 13 Jun 2003 09:45:42 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Jun 2003 09:45:42 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: I-D ACTION:draft-ietf-forces-framework-05.txt Thread-Index: AcMwuVpF2sF1j6SKReyxeWHv5u2IRwBEdUFg X-OriginalArrivalTime: 13 Jun 2003 16:45:42.0299 (UTC) FILETIME=[3A509EB0:01C331CB] Approved-By: "Yang, Lily L" Message-ID: Date: Fri, 13 Jun 2003 09:45:42 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: I-D ACTION:draft-ietf-forces-framework-05.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11587 Robert -- Thanks for catching this. Lily -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com] Sent: Thursday, June 12, 2003 1:04 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: I-D ACTION:draft-ietf-forces-framework-05.txt Lily, Now that we have updated the requirements draft regarding strict reliability, I think the framework draft should also be updated accordingly in section 4.2.1 (see below). In addition, in the local scope case with directly-attached CEs and FEs (such as PCI bus), I do not see the need for congestion avoidance mechanisms. [excerpt of framework draft sec. 4.2.1] "ForCES will make use of an existing RFC2914 ([2]) compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. " Regards, -Robert -- 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 13 13:13:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13469 for ; Fri, 13 Jun 2003 13:13:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qs51-00073v-00 for forces-archive@IETF.ORG; Fri, 13 Jun 2003 13:11:11 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19Qs50-00073s-00 for forces-archive@IETF.ORG; Fri, 13 Jun 2003 13:11:10 -0400 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.00A132D1@cherry.ease.lsoft.com>; Fri, 13 Jun 2003 13:13:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45548314 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 13 Jun 2003 13:13:17 -0400 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Jun 2003 13:13:17 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5DH7se28491 for ; Fri, 13 Jun 2003 17:07:54 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5DGfMM00654 for ; Fri, 13 Jun 2003 16:41:22 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003061310235126198 ; Fri, 13 Jun 2003 10:23:51 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Jun 2003 10:13:15 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: I-D ACTION:draft-ietf-forces-framework-06.txt Thread-Index: AcMxo4G9Z49KqyguSDKpSdYvmMXAhwAKsZxA X-OriginalArrivalTime: 13 Jun 2003 17:13:15.0590 (UTC) FILETIME=[13C0CE60:01C331CF] Approved-By: "Yang, Lily L" Message-ID: Date: Fri, 13 Jun 2003 10:13:14 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: I-D ACTION:draft-ietf-forces-framework-06.txt Comments: To: "Putzolu, David" , dro@zurich.ibm.com, Alex Zinin To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA13469 Hi, Alex, David and Patrick -- This is the new version with formatting and editorial changes, thanks to Randy's comments. Please use this new version for the review process. Thanks, Lily > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, June 13, 2003 4:50 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: I-D ACTION:draft-ietf-forces-framework-06.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Forwarding and Control > Element Separation Working Group of the IETF. > > Title : Forwarding and Control Element > Separation (ForCES) > Framework > Author(s) : L. Yang et al. > Filename : draft-ietf-forces-framework-06.txt > Pages : 38 > Date : 2003-6-12 > > This document defines the architectural framework for the ForCES > (Forwarding and Control Element Separation) network elements, and > identifies the associated entities and the interaction among them. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-06.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-06.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-06.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. > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 24 16:33:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09972 for ; Tue, 24 Jun 2003 16:33:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UuU9-00073L-00 for forces-archive@IETF.ORG; Tue, 24 Jun 2003 16:33:49 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19UuTy-00072o-00 for forces-archive@IETF.ORG; Tue, 24 Jun 2003 16:33:39 -0400 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.00A2EECE@cherry.ease.lsoft.com>; Tue, 24 Jun 2003 16:32:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46499889 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 24 Jun 2003 16:32:57 -0400 Received: from 143.183.121.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 24 Jun 2003 16:32:57 -0400 Received: from talaria.sc.intel.com (talaria.sc.intel.com [10.3.253.5]) by hermes.sc.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5OKT1J20810 for ; Tue, 24 Jun 2003 20:29:01 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.sc.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5OKRCl10626 for ; Tue, 24 Jun 2003 20:27:12 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003062413372124336 ; Tue, 24 Jun 2003 13:37:21 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 13:32:56 -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, 24 Jun 2003 13:32:54 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Call for Agenda Items, ForCES meeting at IETF 57 Comments: cc: Patrick Droz To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, ForCES will be meeting at IETF 57 on Monday, July 14th, from 1300-1500. Please send any requests for time during the ForCES meeting to myself and Patrick. Include in all requests the desired amount of time and pointers to any relevant IDs. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 25 13:50:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22814 for ; Wed, 25 Jun 2003 13:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VEPF-0005fO-00 for forces-archive@IETF.ORG; Wed, 25 Jun 2003 13:50:05 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19VEP3-0005fJ-00 for forces-archive@IETF.ORG; Wed, 25 Jun 2003 13:49:53 -0400 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.00A3179C@cherry.ease.lsoft.com>; Wed, 25 Jun 2003 13:49:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46611793 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 25 Jun 2003 13:49:15 -0400 Received: from 208.237.135.240 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 25 Jun 2003 13:49:14 -0400 Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h5PHnEZd000244 for ; Wed, 25 Jun 2003 12:49:14 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h5PHnDQB008837 for ; Wed, 25 Jun 2003 12:49:13 -0500 (CDT) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h5PHnDwP003377 for ; Wed, 25 Jun 2003 13:49:13 -0400 (EDT) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 25 Jun 2003 13:49:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C33B42.14FC8680" Approved-By: "Rachid Nait Takourout (LMC)" Message-ID: <7B2A7784F4B7F0409947481F3F3FEF8304C310EB@eammlex037.lmc.ericsson.se> Date: Wed, 25 Jun 2003 13:49:10 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Rachid Nait Takourout (LMC)" Subject: Drafts about pre-association phase and xml modeling 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_01C33B42.14FC8680 Content-Type: text/plain; charset="ISO-8859-1" Hi, I would like to propose two drafts for the ForCES Working Group: - The first one (draft-nait-forces-pap-00.txt) is a document on a protocol for the pre-association phase. - The second one (draft-nait-forces-xml-model-00.txt) is about a XML based model for FE and CE representation. You can find the drafts in attachment. I will be very interested to exchange comments on those documents. Best regards Rachid Nait Takourout ------_=_NextPart_000_01C33B42.14FC8680 Content-Type: text/plain; name="draft-nait-forces-pap-00.txt" Content-Disposition: attachment; filename="draft-nait-forces-pap-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft R, Nait Takourout Expiration: November 2003 Ericsson Research Canada = File: draft-nait-forces-pap-00.txt June 2003=20 Working Group: ForCES=20 =20 =20 =20 =20 Pre Association Phase Protocol (PAP) draft-nait-forces-pap-00.txt =20 =20 =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), =20 its areas, and its working groups. Note that other groups may =20 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 =20 documents at any time. It is inappropriate to use Internet-Drafts =20 as 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", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in =20 this document are to be interpreted as described in [RFC-2119].=20 =20 1. Abstract=20 =20 This document introduces a protocol for the pre-association phase as = defined in the ForCES (Forwarding and Control Element Separation) requirements documents [1]. The main purpose of this protocol is to=20 bring mechanisms to automate the discovery and the configuration of=20 logical elements in the ForCES architecture.=20 Table of Contents=20 =20 Nait Takourout Expires November 2003 [Page 1] Internet Draft Pre-association Phase Protocol June 2003=20 1. Abstract........................................................1 = 2. Definitions.....................................................2 = 3. Introduction....................................................4 = 4. Protocol Overview...............................................5 = 5. Message overview................................................7 = 5.1. Message header structure......................................7 = 5.1.1. Version. ...................................................7 = 5.1.2. MsgType.....................................................7 = 5.1.3. Length......................................................8 = 5.1.4. Identifier..................................................8 = 5.1.5. F bit.......................................................8 = 5.1.6. Fragment OffSet.............................................8 = 5.2. Message payload structure.....................................8 = 5.2.1. EncapType...................................................9 = 5.2.2. Param Length................................................9 = 6. Message Types...................................................9 = 6.1. INIT_CE message...............................................9 = 6.2. INIT_FE message..............................................10 = 6.3. INIT_MANAGER message.........................................10 = 6.4. INIT_ACC message.............................................10 = 6.5. INIT_REJ message.............................................10 = 6.6. MODEL message................................................11 = 6.7. MODEL_ACK message............................................11 = 6.8. LIST message.................................................11 = 6.9. LIST_ACK message.............................................12 = 6.10. EVENT_INACTIVE message......................................12 = 6.11. EVENT_INACTIVE_ACK message..................................12 = 6.12. EVENT_LEAVE message.........................................12 = 6.13. EVENT_LEAVE_ACK message.....................................13 = 7. References.....................................................13 = 7.1. Normative References.........................................13 = 7.2. Informative References.......................................13 = 8. Security Considerations........................................13 = 9. Authors' Addresses & Acknowledgments...........................13 = =20 2. Definitions=20 The following definitions are taken from [1]: =20 Addressable Entity (AE) - A physical device that is directly=20 addressable given some interconnect technology. For example, on IP=20 networks, it is a device to which we can communicate using an IP=20 address; and on a switch fabric, it is a device to which we can=20 communicate using a switch fabric port number.=20 =20 Physical Forwarding Element (PFE) - An AE that includes hardware=20 used to provide per-packet processing and handling. This hardware=20 may consist of (but is not limited to) network processors, ASIC's,=20 line cards with multiple chips or stand alone box with general- purpose processors. =20 =20 Nait Takourout Expires November 2003 [Page 2] Internet Draft Pre-association Phase Protocol June 2003=20 =20 Physical Control Element (PCE) - An AE that includes hardware used=20 to provide control functionality. This hardware typically includes=20 a general-purpose processor.=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/controlled by a CE via=20 the ForCES protocol. FEs may happen to be a single blade(or PFE), a = partition of a PFE or multiple PFEs.=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=20 packets. CEs handle functionality such as the execution of control=20 and signaling protocols. CEs may consist of PCE partitions or whole = PCEs.=20 =20 Pre-association Phase - The period of time during which a FE Manager = (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 = to communication between FE and CE managers. The ForCES protocol is = a master-slave protocol in which FEs are slaves and CEs are masters. = =20 This protocol includes both the management of the communication=20 channel (e.g., connection establishment, heartbeats) and the control = messages themselves. This protocol could be a single protocol or=20 could consist of multiple protocols working together.=20 =20 FE Model - A model that describes the logical processing functions=20 of a FE.=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, however this is currently out of scope. Being a logical=20 entity, a FE manager might be physically combined with any of the=20 other logical entities mentioned in this section.=20 =20 Nait Takourout Expires November 2003 [Page 3] Internet Draft Pre-association Phase Protocol June 2003=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, = however this is currently out of scope. Being a logical entity, a=20 CE manager might be physically combined with any of the other=20 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 =20 pre-association phase protocol may include a CE and/or FE capability = discovery mechanism. Note that this capability discovery process is = 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 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 ForCES Protocol Element - A FE or CE.=20 =20 This document defines this terminology: =20 CE Specification - A model that describes the capabilities and the=20 needed logical processing functions of a CE.=20 =20 Telecom Inter Process Communication (TIPC) - The TIPC [4] protocol=20 is specially designed for intra cluster communication. The main=20 feature of TIPC is Full location transparency hiding all aspects of=20 the cluster's physical topology for the application programs. 3. Introduction=20 =20 The ForCES architecture introduces the pre-association phase [2].=20 During this phase, any Protocol Element (PE) has to declare itself=20 to its Manager in order to join a Network Element (NE). But, this=20 mechanism has to be dynamic, interface technologies independent=20 and scalable.=20 This phase takes care of four operations: o Accept or reject a PE inside a Network Element. o Give an identifier to a PE if it is not defined. o Allow a Manager to discover the PE attributes. o Allow a CE (or a FE) to discover the FEs (or CE) and theirs=20 attributes. Nait Takourout Expires November 2003 [Page 4] Internet Draft Pre-association Phase Protocol June 2003=20 The representation of CE or FE attributes could be done with XML=20 documents, OIDs, etc.. 4. Protocol Overview The Pre-Association phase protocol is a communication protocol for=20 the management of a network element. Its purpose is to provide an=20 automatic discovery of the PEs. This protocol is designed to ensure the communications between PEs and CE / FE Manager, and between=20 Managers.=20 The interaction between a PE and a Manager are subdivided into=20 three phases. The first one represents the pre-association phase as=20 defined in the ForCES framework [2]. The second is an event-based=20 phase.=20 In fact, if a PE doesn't succeed to join one PE of the list provided = by the Manager during the pre-association phase, this one has to=20 communicate with the Manager to obtain another list of PEs in an=20 asynchronous way. And the last phase, it is just to indicate to=20 the Manager that a PE wants to leave the NE. Those three phases are represented in the figure below: CE CE Manager FE FE Manager | | | | | Phase I | | Phase I | | | | | | INIT_CE | | INIT_FE | |------------------->| |------------------->| | INIT_ACC | | INIT_ACC | | or | | or | | INIT_REJ | | INIT_REJ | |<-------------------| |<-------------------| | | | | | MODEL | | MODEL | |------------------->| |------------------->| | | | | | MODEL_ACK | | MODEL_ACK | |<-------------------| |<-------------------| | | | | | Phase II | | Phase II | | | | | | EVENT_INACTIVE | | EVENT_INACTIVE | |------------------->| |------------------->| | | | | | EVENT_INACTIVE_ACK | | EVENT_INACTIVE_ACK | | or | | or | | MODEL_ACK | | MODEL_ACK | |<-------------------| |<-------------------| | | | | Nait Takourout Expires November 2003 [Page 5] Internet Draft Pre-association Phase Protocol June 2003=20 | | | | | Phase III | | Phase III | | | | | | EVENT_LEAVE | | EVENT_LEAVE | |------------------->| |------------------->| | | | | | EVENT_LEAVE_ACK | | EVENT_LEAVE_ACK | |<-------------------| |<-------------------| | | | | In a same way, the interactions between CE Manager and FE Manager=20 are represented with three phases. The second phase is always=20 for asynchronous interactions. For example, if a CE indicates to=20 the CE Manager that it wants to join the NE, the CE manager has to=20 update the PE list of the FE Manager. =20 The figure following illustrates it: CE Manager FE Manager | | | Phase I | | | | INIT_MANAGER | |<-------------------->| | INIT_ACC | | or | | INIT_REJ | |<-------------------->| | | | Phase II | | | | LIST | |<-------------------->| | | | LIST_ACK | |<-------------------->| | | | Phase III | | | | EVENT_LEAVE | |<-------------------->| | | | EVENT_LEAVE_ACK | |<-------------------->| | | =20 In the previous figure, the arrows are bi-directional because=20 the communication could be initiated by the CE or the FE Manager. The types of message defined in this example are: Message Type Description INIT_CE A CE wants to join the NE Nait Takourout Expires November 2003 [Page 6] Internet Draft Pre-association Phase Protocol June 2003=20 INIT_FE A FE wants to join the NE INIT_MANAGER A Manager wants to join a Manager INIT_ACC The request for joining the NE is accepted INIT_REJ The request for joining the NE is refused MODEL A PE sends its model.=20 MODEL_ACK The Manager sends to a PE the list of other = PEs, which can be reached for the post- association phase. LIST A CE (or FE) Manager sends to a FE (or a=20 CE) Manager its list of PEs models and the=20 list of theirs addresses.=20 LIST_ACK The other Manager sends an acknowledgment=20 EVENT_INACTIVE A PE is inactive and wants another list of=20 PE to communicate EVENT_INACTIVE_ACK The inactive PE has to stay in an inactive=20 state for a defined period [TBD] EVENT_LEAVE A PE or a Manager wants to leave the NE EVENT_INACTIVE_ACK An acknowledgment for an EVENT_LEAVE=20 message =20 In the next sections, we describe the messages of this protocol that = are split into two parts: the header and the message payload part.=20 =20 5. Message Overview 5.1. Message Header Structure The messages have the header format illustrated in the following figure.=20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MsgType | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Identifier |F| Fragment Offset |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.1 Version This is a 5 bits field representing the version of this protocol.=20 The current version is 0x01 5.1.2 MsgType This 11 bits field indicates the type of the messages. As we saw=20 previously, the types could be: Message type Value INIT_CE 0x1 INIT_FE 0x2 INIT_MANAGER 0x3 INIT_ACC 0x4 Nait Takourout Expires November 2003 [Page 7] Internet Draft Pre-association Phase Protocol June 2003=20 INIT_REJ 0x5 MODEL 0x6 MODEL_ACK 0x7 LIST 0x8 LIST_ACK 0x9 EVENT_INACTIVE 0x10 EVENT_INACTIVE_ACK 0x11 EVENT_LEAVE 0x12 EVENT_LEAVE_ACK 0x13 5.1.3 Length This is the total length of the message in octets. 5.1.4 Identifier This is a 16 bits field to identify a message. Messages can be up=20 to 64kb, so it is possible to split message into multiples = fragments. If a message has to be fragmented, the different messages have to=20 keep the same identification field to match up with other fragments. 5.1.5 F bit This bit indicates if the message is fragmented. Indeed, if this bit = is set to 0, there is no other fragmented message following. Value Description 0 No Next fragments=20 1 There are more fragments=20 5.1.6 Fragment OffSet This 15 bits field indicates where this fragment lies in the global=20 data payload.=20 5.2. Message Payload Structure The message payload structure is based on by a list of zero or more=20 variable length parameters. 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | EncapType | Param Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 / /=20 \ Value \=20 / /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nait Takourout Expires November 2003 [Page 8] Internet Draft Pre-association Phase Protocol June 2003=20 5.2.1. EncapType This 16 bits field indicates the encapsulation type used in the=20 payload. Value Description 0x1 BIN 0x2 XML 0x3 OID 5.2.2. Param Length This field indicates the length of this parameter in octets. 6. Message Types In this section, we define the value of the parameter of each=20 message type. 6.1 INIT_CE message =20 The format of the payload for INIT_CE message type, is as follows : =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AddressType | Element Id |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 / /=20 \ Address \=20 / /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ModelingType |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 / /=20 \ Authentication Options \=20 / /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AdressType: These 16 bits field indicates the type of address. Value Address type 0x1 No address 0x2 IPv4 0x3 IPv6 0x4 TIPC Element Id: Identifier of the CE.=20 Address: Address of the CE.=20 Nait Takourout Expires November 2003 [Page 9] Internet Draft Pre-association Phase Protocol June 2003=20 ModelingType: This 32 bits field indicates the type of=20 representation for the CE Specification. Value Representation type 0x1 XML 0x2 OID 6.2 INIT_FE message =20 The format for the message type payload is same as in INIT_CE=20 Message. But the Element Id field contents the FE Identifier or=20 0 if it is not defined. 6.3 INIT_MANAGER message The format for the message type payload is same as in INIT_FE=20 Message. But the Element Id field contents the Manager identifier. 6.4 INIT_ACC message The format of the payload for INIT_CE message type, is as follows : 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Network Element Id |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 6.5 INIT_REJ message The format of the payload for INIT_REJ message type, is as follows: 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Reason |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 / /=20 \ INFO * \=20 / /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reason: These 32 bits field indicates the reason of the reject. Value Reason 0x1 Authentication Fail 0x2 Management Inhibit (Manual Removal)=20 0x3 NE busy 0x4 Model representation not supported INFO: It is an optional field. Nait Takourout Expires November 2003 [Page 10] Internet Draft Pre-association Phase Protocol June 2003=20 6.6 MODEL message The payload for this type contains the CE Specification or the=20 FE Model. 6.7 MODEL_ACK message The format of the payload for MODEL_ACK message type, is as follows: 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | AddressType | Element Id |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 / /=20 \ Address \=20 / /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Others addresses of the list /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.8 LIST message The payload for this message type contains the list of CE=20 Specifications or FE Models and the list of addresses, which are=20 represented by two parameters: =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | EncapType | Param Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 / /=20 \ List of models \=20 / /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | BIN | Param Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddressType | Element Id |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 / /=20 \ Address \=20 / /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Others addresses of the list /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The values for the fields of this message type are the same as in=20 MODEL and MODEL_ACK messages. Nait Takourout Expires November 2003 [Page 11] Internet Draft Pre-association Phase Protocol June 2003=20 6.9 LIST_ACK message This message type is just an acknowledgement and doesn't contain=20 payload. =20 6.10 EVENT_INACTIVE message The format of the payload for EVENT_INACTIVE message type, is as follows: 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Reason |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 / /=20 \ INFO * \=20 / /=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reason: These 32 bits field indicates the reason of the inactivity. Value Reason 0x1 No PE could be reached. 0x2 Manual Inhibit.=20 0x3 PE busy INFO: It is an optional field. 6.11 EVENT_INACTIVE_ACK message The EVENT_INACTIVE_ACK message doesn't contain payload, but=20 indicates to the PE to remain on standby for a given period=20 of time [TBD].=20 6.12 EVENT_LEAVE message=20 The EVENT_LEAVE message contains the following parameters:=20 Reason=20 Info String (optional)=20 The format for the message type payload is same as in EVENT_INACTIVE = message but the values for the Reason field are: Value Description=20 0x1 Management Inhibit (Manual Removal)=20 0x2 Invalid NE group =20 0x3 FE or CE not ready =20 0x4 Max number of FEs reached 0x5 Physical Layer fault=20 0x6 Fail-over switching Those values are the same than for the Leave Request in the FACT=20 protocol [3]. Nait Takourout Expires November 2003 [Page 12] Internet Draft Pre-association Phase Protocol June 2003=20 6.13 EVENT_LEAVE_ACK message=20 The EVENT_LEAVE_ACK message contains the following parameters:=20 Reason=20 Info String (optional)=20 The format for the message type payload and the values of field are=20 the same as in EVENT_LEAVE message=20 7. References=20 7.1. Normative References=20 =20 [1] Khosravi, H. et al., "Requirements for Separation of IP Control=20 and Forwarding", work in progress, May 2003,. [2] Yang, L. et al., "Forwarding and Control Element Separation=20 (ForCES) Framework ", work in progress, June 2003, . =20 [3] Khosravi, H. et al., " ForwArding and Control ElemenT protocol=20 (FACT)", work in progress, March 2003, . 7.2.Informative References=20 =20 [4] Maloy, J., "Telecom Inter Process Communication", work in=20 progress, Jan 2002, =20 8. Security Considerations=20 =20 If the PEs and the Managers are in an untrusted domain, the pre- association protocol MUST be used over an appropriate security=20 protocol like IPSec to ensure the encryption level needed. =20 9. Author's Address & Acknowledgments=20 =20 Rachid Nait Takourout (Editor)=20 =20 Ecole Polytechnique de Montreal 2500, chemin de Polytechnique Montreal, H3T 1J4, Quebec, Canada=20 Phone: +1 514 340 4711=20 email: rachid.nait-takourout@polymtl.ca=20 Rachid.Nait.Takourout@ericsson.ca =20 The author would like to thank Jon Maloy, Laurent Marchand and=20 Samuel Pierre for their valuable contributions.=20 =20 Nait Takourout Expires November 2003 [Page 13] ------_=_NextPart_000_01C33B42.14FC8680 Content-Type: text/plain; name="draft-nait-forces-xml-model-00.txt" Content-Disposition: attachment; filename="draft-nait-forces-xml-model-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft R, Nait Takourout Expiration: November 2003 Ericsson Research Canada = File: draft-nait-xml-model-00.txt June 2003=20 Working Group: ForCES=20 =20 =20 =20 =20 XML based Model for Control and Forward Element Separation draft-nait-forces-xml-model-00.txt =20 =20 =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), =20 its areas, and its working groups. Note that other groups may =20 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 =20 documents at any time. It is inappropriate to use Internet-Drafts =20 as 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", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in =20 this document are to be interpreted as described in [RFC-2119].=20 =20 1. Abstract=20 =20 This document introduces a set of modeling requirements for the=20 logical elements between the control and data forwarding planes=20 of a network element. This document presents a model representation=20 of ForCES logical elements with the W3C Extensible Markup Language=20 [3].=20 Table of Contents=20 Nait Takourout Expires November 2003 [Page 1] Internet Draft ForCES XML based model June 2003=20 =20 1. Abstract........................................................1 = 2. Definitions.. ..................................................2 = 3. Introduction ...................................................4 = 4. XML based Modeling..............................................4 = 4.1. CE Specification................................................5 = 4.2. FE Model........................................................6 = 5. References......................................................8 = 5.1. Normative References............................................8 = 5.2. Informative References..........................................8 = 6. Security Considerations.........................................8 = 7. Authors' Addresses & Acknowledgments............................8 = Appendix-1.........................................................9 Appendix-2........................................................11 =20 2. Definitions=20 The following definitions are taken from [1] =20 Addressable Entity (AE) - A physical device that is directly=20 addressable given some interconnect technology. For example, on IP=20 networks, it is a device to which we can communicate using an IP=20 address; and on a switch fabric, it is a device to which we can=20 communicate using a switch fabric port number.=20 =20 Physical Forwarding Element (PFE) - An AE that includes hardware=20 used to provide per-packet processing and handling. This hardware=20 may consist of (but is not limited to) network processors, ASIC's,=20 line cards with multiple chips or stand alone box with general- purpose processors. =20 =20 Physical Control Element (PCE) - An AE that includes hardware used=20 to provide control functionality. This hardware typically includes=20 a general-purpose processor.=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/controlled by a CE via=20 the ForCES protocol. FEs may happen to be a single blade(or PFE), a = partition of a PFE or multiple PFEs.=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=20 packets. CEs handle functionality such as the execution of control=20 and signaling protocols. CEs may consist of PCE partitions or whole = PCEs.=20 =20 Pre-association Phase - The period of time during which a FE Manager = (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 Nait Takourout Expires November 2003 [Page 2] Internet Draft ForCES XML based model June 2003=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 = to communication between FE and CE managers. The ForCES protocol is = a master-slave protocol in which FEs are slaves and CEs are masters. = =20 This protocol includes both the management of the communication=20 channel (e.g., connection establishment, heartbeats) and the control = messages themselves. This protocol could be a single protocol or=20 could consist of multiple protocols working together.=20 =20 FE Model - A model that describes the logical processing functions=20 of a FE.=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, however this is currently out of scope. Being a logical=20 entity, a FE manager might be physically combined with any of the=20 other logical entities mentioned in this 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, = however this is currently out of scope. Being a logical entity, a=20 CE manager might be physically combined with any of the other=20 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 = discovery mechanism. Note that this capability discovery process is = 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 ForCES Network Element (NE) - An entity composed of one or more CEs=20 Nait Takourout Expires November 2003 [Page 3] Internet Draft ForCES XML based model June 2003=20 =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 ForCES Protocol Element - A FE or CE.=20 This document defines this terminology: CE Specification - A model that describes the capabilities and the=20 needed logical processing functions of a CE=20 =20 3. Introduction=20 =20 The ForCES architecture [2] introduces a large set of components=20 like CE an FE in order to develop a flexible framework for future=20 high performance network element. So, the architecture has to=20 provide a scalable base that enables to manage the diversity of=20 functionalities inside FE and CE. =20 Those requirements introduce the modeling problematic. Inside=20 this document, we provide a XML [3] based model for FE (FE Model)=20 and for CE specifications. In fact, a CE implements a part of=20 protocol stacks, so it has to declare to its manager its data=20 processing limitations and its need in logical functions terms=20 (Ethernet Ports, DiffServ conditioning functions) to process = packets. 4. XML based Modeling The choice to use XML to represent the modeling of PEs is based on=20 the fact that the diversity between the physical implementations=20 of FEs and the needs of CEs requires a global interaction solution. The design goals for XML, taken from [3], are: o XML shall be straightforwardly usable over the Internet. o XML shall support a wide variety of applications. o XML shall be compatible with SGML. o It shall be easy to write programs which process XML documents. o The number of optional features in XML is to be kept to the=20 absolute minimum, ideally zero. o XML documents should be human-legible and reasonably clear. o The XML design should be prepared quickly. o The design of XML shall be formal and concise. o XML documents shall be easy to create. o Terseness in XML markup is of minimal importance. XML is a flexible language for modeling CE and FE. The choice of=20 this language optimizes the interoperability of the architecture=20 and its scalability. Nait Takourout Expires November 2003 [Page 4] Internet Draft ForCES XML based model June 2003=20 =20 =20 4.1 CE Specification A CE has to declare its needs and its restrictions (of processing=20 capacities for example) to see whether these services are available=20 among FEs pertaining to the network element. The types of service=20 required by CE could be based on ForCES requirements.=20 So, A CE has to provide two types of information to its CE Manager.=20 Firstly, The CE provides its capabilities.=20 This list provides a minimal list of capabilities: o The maximum number of FE that could be supported. o The types of encapsulation supported for the post-association phase. o Its support of Failover mechanisms. Secondly, it indicates its needs in term of FE functionalities.=20 This list provides a minimal list of functionalities: o Port functions (ethernet, frame-relay, etc.) o Forwarding functions (IPv4, IPv6, unicast, multicast, etc.) o Quality of Services (IntServ, DiffServ) o Encapsulation functions (NAT, IPv6-in-IPv4, etc.) o Security functions (IPSec, etc.) The XML Document Type Definition (DTD) is available in the = Appendix-1.=20 From the CE Manager point of view, this CE Specification allows to=20 provide a pertinent list of FEs to begin the post-association phase = and=20 to manage the CE redundancy functionalities in regrouping CE who=20 have the same specifications. Below is a XML representation of a simple CE Specification=20 for a DiffServ enabled CE: 3 XML Enable=20 Ethernet=20 Nait Takourout Expires November 2003 [Page 5] Internet Draft ForCES XML based model June 2003=20 =20 DiffServ=20 4.2 FE Model The ForCES requirements indicate that the FE Model MUST define both=20 a capability model and a state model, which expresses the current=20 configuration of the device. =20 Moreover, those requirements define a minimum set of Logical = Function=20 available inside a FE: 1)Port Functions=20 2)Forwarding Functions=20 3)QoS Functions=20 4)Generic Filtering Functions=20 5)Vendor-Specific Functions=20 6)High-Touch Functions=20 7)Security Functions=20 8)Off-loaded Functions=20 9)IPFLOW/PSAMP Functions=20 Below is an example of a XML representation. In this example, the FE Model is split into the Capability Model=20 represented by a list of Logical Bloc (LB) and the State Model=20 represented by a list of Links. ... ... Each logical bloc presents it-self as below with a handle and a=20 description of its capabilities Nait Takourout Expires November 2003 [Page 6] Internet Draft ForCES XML based model June 2003=20 =20 5=20 ethernet-csmacd=20 1500=20 100=20 And each Link markup indicates how logical blocs are linked=20 the ones to the others: 1=20 2=20 The XML Document Type Definition of the FE Model is available in=20 the Appendix-2. Currently, the list of Logical Bloc supported are: o Interface o IpPrefixForwarder logical representation of a IP Prefix forwarder o IpNHForwarder logical representation of a IP Next Hop forwarder o IptoL2 logical representation of the entity linking L3 addresses=20 and L2 addresses like ARP o DS_Classifier logical representation of a DiffServ Classifier o DS_Meter logical representation of a DiffServ Meter o DS_Action logical representation of a DiffServ Action (Counter, Dropper, etc.) o DS_Queue logical representation of a DiffServ Queue o DS_Scheduler logical representation of a DiffServ Scheduler This list of logical blocs is based on RFC 3289 [4] and the work of = the=20 Network Processing Forum [5]. =20 [[ Remarks: Some points have to be clarified: Nait Takourout Expires November 2003 [Page 7] Internet Draft ForCES XML based model June 2003=20 =20 o the statistic representation problematic. o the possibility to use XML namespace. o to complete the Function markup in the CE Specification with new requirements of [1]. ]] 5. References=20 5.1. Normative References=20 =20 [1] Khosravi, H. et al., "Requirements for Separation of IP Control=20 and Forwarding", work in progress, May 2003,. [2] Yang, L. et al., "Forwarding and Control Element Separation=20 (ForCES) Framework ", work in progress, June 2003,. =20 [3] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 (Second Edition)", , October 2000, . =20 [4] Baker, F et. al., "Management Information Base for the Differentiated Services Architecture", RFC3292, May 2002.=20 =20 5.2.Informative References=20 =20 [5] Network Processing Forum, . =20 6. Security Considerations=20 =20 The data inside the models could be significant for the CE and FE=20 Managers that could want to guarantee the confidentiality of the=20 attributes of theirs PEs. So, an appropriate security protocol=20 like IPSec to ensure the encryption level needed is required.=20 =20 Moreover, some Managers could need to ensure the authentication of=20 the model of theirs PEs. =20 7. Author's Address & Acknowledgments=20 =20 Rachid Nait Takourout (Editor)=20 =20 Ecole Polytechnique de Montreal 2500, chemin de Polytechnique Montreal, H3T 1J4, Quebec, Canada=20 Phone: +1 514 340 4711=20 email: rachid.nait-takourout@polymtl.ca=20 Rachid.Nait.Takourout@ericsson.ca =20 The author would like to thank Jon Maloy, Laurent Marchand and=20 Samuel Pierre for their valuable contributions.=20 =20 Nait Takourout Expires November 2003 [Page 8] Internet Draft ForCES XML based model June 2003=20 =20 Appendix-1: XML DTD for CE Specification =20 Nait Takourout Expires November 2003 [Page 9] Internet Draft ForCES XML based model June 2003=20 Nait Takourout Expires November 2003 [Page 10] Internet Draft ForCES XML based model June 2003=20 Appendix-2: XML DTD for FE Model =20 =20 Nait Takourout Expires November 2003 [Page 11] Internet Draft ForCES XML based model June 2003=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Nait Takourout Expires November 2003 [Page 12] Internet Draft ForCES XML based model June 2003=20 =20 =20 =20 Nait Takourout Expires November 2003 [Page 13] ------_=_NextPart_000_01C33B42.14FC8680-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 25 17:09:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02537 for ; Wed, 25 Jun 2003 17:09:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VHQ7-00008O-00 for forces-archive@IETF.ORG; Wed, 25 Jun 2003 17:03:11 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19VHPw-00001R-00 for forces-archive@IETF.ORG; Wed, 25 Jun 2003 17:03:00 -0400 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.00A32075@cherry.ease.lsoft.com>; Wed, 25 Jun 2003 17:02:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46626819 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 25 Jun 2003 17:00:37 -0400 Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 25 Jun 2003 17:00:37 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5PKtow27349 for ; Wed, 25 Jun 2003 20:55:50 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5PL14504196 for ; Wed, 25 Jun 2003 21:01:04 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003062513570525661 for ; Wed, 25 Jun 2003 13:57:05 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 14:00:36 -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: Wed, 25 Jun 2003 14:00:35 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Reminder: Final draft cutoff date Monday, June 30, 0900 ET To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, This note is a reminder that the draft cutoff deadline for ForCES WG drafts is Monday, June 30, at 0900 ET. Please submit any updates to WG drafts before that time - preferably well before then - so as to avoid the last minute rush! Cheers, David From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 26 17:21:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22311 for ; Thu, 26 Jun 2003 17:21:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VeBR-00068A-00 for forces-archive@IETF.ORG; Thu, 26 Jun 2003 17:21:33 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19VeBH-00067s-00 for forces-archive@IETF.ORG; Thu, 26 Jun 2003 17:21:23 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00A34F0F@cherry.ease.lsoft.com>; Thu, 26 Jun 2003 17:20:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46756813 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 26 Jun 2003 17:19:43 -0400 Received: from 143.183.121.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 26 Jun 2003 17:19:43 -0400 Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by hermes.sc.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5QLFjD28726 for ; Thu, 26 Jun 2003 21:15:45 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.sc.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5QLIMs23661 for ; Thu, 26 Jun 2003 21:18:22 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003062614240823800 for ; Thu, 26 Jun 2003 14:24:08 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 14:19:41 -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, 26 Jun 2003 14:19:39 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: FW: 57th IETF - Pre-Registration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list FYI - the pre-registration deadline is coming up fast. Cheers, David > -----Original Message----- > From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org] > Sent: Thursday, June 26, 2003 7:43 AM > Subject: 57th IETF - Pre-Registration > > > REMINDER - pre-registration and pre-payment for the upcoming > IETF meeting in Vienna, Austria will close on Monday, 30 June > at 12:00 noon ET. After this time you will have to register > on-site in Vienna. > > You can register at http://www.ietf.org/meetings/notewell.html > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 27 10:24:26 2003 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 KAA29972 for ; Fri, 27 Jun 2003 10:24: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 <17.00A36ACC@cherry.ease.lsoft.com>; Fri, 27 Jun 2003 10:24:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46851062 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 27 Jun 2003 10:24:07 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Jun 2003 10:24:07 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4886272 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 27 Jun 2003 10:24:06 -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.20030627102245.018a2ff0@mail.stevecrocker.com> Date: Fri, 27 Jun 2003 10:23:13 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Drafts about pre-association phase and xml modeling To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF8304C310EB@eammlex037.lmc.er icsson.se> Precedence: list I just saw the announcement of these from the internet drafts directory. Thank you for ensuring that they are available there. Yours, Joel M. Halpern At 01:49 PM 6/25/2003 -0400, you wrote: >Hi, > > I would like to propose two drafts for the ForCES Working Group: >- The first one (draft-nait-forces-pap-00.txt) is a document on a protocol > for the pre-association phase. >- The second one (draft-nait-forces-xml-model-00.txt) is about a XML based > model for FE and CE representation. > You can find the drafts in attachment. I will be very interested to >exchange comments on those documents. > > >Best regards > >Rachid Nait Takourout > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 30 07:49:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11463 for ; Mon, 30 Jun 2003 07:49:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wx9r-00064S-00 for forces-archive@IETF.ORG; Mon, 30 Jun 2003 07:49:19 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19Wx9g-00064D-00 for forces-archive@IETF.ORG; Mon, 30 Jun 2003 07:49:08 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A3CC46@cherry.ease.lsoft.com>; Mon, 30 Jun 2003 7:48:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47093884 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 30 Jun 2003 07:48:40 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 30 Jun 2003 07:38:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10782; Mon, 30 Jun 2003 07:37:49 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200306301137.HAA10782@ietf.org> Date: Mon, 30 Jun 2003 07:37:49 -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-02.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-02.txt Pages : 9 Date : 2003-6-27 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-02.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-02.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-02.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: <2003-6-27150131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-applicability-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-applicability-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150131.I-D@ietf.org> --OtherAccess-- --NextPart--