2002 Message-Id: Date: Tue, 25 Jun 2002 14:10:16 +0200 From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs andoff-loadofsignalingfunctions Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Jamal, Hormuzd, Here is a suggestion that could fit into section 6.5 "Minimal Set of Logi= cal Functions". The idea is to ensure that the FE model remains flexible and = it does not imply that FEs must support such functionalities. 8) Off-loaded Functions Per-packet processing can leave state in the FE, so that logical functions executed during packet processing can perform in a consistent manner (for instance, each packet may update the state of the token bucket occupancy of a given policer). In addition, FEs MUST allow logical functions to execute asynchronously from packet processing, according to a certain finite-state machine, in order to perform functions that are, for instance, off-loaded from the CE to the FE. The FE model MUST be capable of expressing these asynchronous functions. Examples of such functions include the finite-state machine execution required by TCP termination or OSPF Hello processing, triggered not only by packet events, but timer events as well. Regards, -Robert Jamal Hadi Salim wrote: > Robert, > Please come up with the appropriate text. > > cheers, > jamal > > On Tuesday 18 June 2002 12:07, Robert Haas wrote: > > Jamal, > > My concern is the limitation of the scope of FEs capabilities to what= ever > > can be done to "the packet as it passes through the FE", as the draft > > mentions it repeatedly. > > If there are other capabilities planned for ForCES besides Forwarding= +QoS, > > then the requirements draft should avoid being so restrictive, IMHO. = The > > TCP termination being just one example out of today's FEs capabilitie= s that > > go beyond the current scope, as I understand now. > > > > If you think it's acceptable, then I'll try to come up with a concret= e > > suggestion how to formulate this, that you could then consider includ= ing in > > the draft. > > > > Cheers, > > -Robert > > > > Jamal Hadi Salim wrote: > > > On Monday 10 June 2002 15:34, Robert Haas wrote: > > > > Jamal Hadi Salim wrote: > > > > > On Mon, 10 Jun 2002, Robert Haas wrote: > > > > > > Jamal, > > > > > > > > > > > > Thanks for your response. Let me clarify: the Requirements dr= aft > > > > > > limits the FE model to express what logical functions can be > > > > > > applied to packets "as they pass through the FE" (see sect. 6= .1). > > > > > > "High-Touch" is defined as a category of such logical functio= ns. > > > > > > > > > > > > In my opinion, this model rules out functions such as TCP > > > > > > termination, that require processing not only as a packet "pa= sses > > > > > > through the FE" (for instance, handling timers). Functions su= ch as > > > > > > TCP termination are usually performed by the CE and could be > > > > > > "off-loaded" into the FEs for performance reasons. > > > > > > > > > > > > Therefore, it seems to me that this issue is not a naming iss= ue, > > > > > > but rather a design choice defining what the FE model must in= clude > > > > > > or not. Do you agree ? > > > > > > > > > > It depends on how you look at it. And it does become a design i= ssue, > > > > > but the model doesnt stop you; > > > > > lets take TCP termination, for example: > > > > > I would think that the setup phase where the splicing is being = set up > > > > > is a control plane activity. So is the termination. With the cu= rrent > > > > > model you could redirect specific packets to the control plane = (eg in > > > > > this case, If i understood correctly, would be SYN/FIN packets). > > > > > Activity after the connection is "nailed" seems to me belongs t= o the > > > > > FE (such as munging the ACKs and splicing). > > > > > On the same token, timers to generate FE events seem to me also= to be > > > > > control activity. > > > > > Did i understand you correctly? > > > > > > > > Let's see: > > > > > > > > TCP splicing, after the setup phase, boils down to converting seq= uence > > > > numbers back and forth, and this is indeed a function that takes = place > > > > "as packets pass through the FE". An ideal candidate for a "High-= Touch > > > > Function". > > > > > > > > But what if I'd like to have some sort of control activity take p= lace > > > > in the FE as well, such as TCP setup or timers handling ? The re= ason > > > > is to avoid overloading the CE with TCP processing, if the FEs ar= e > > > > smart enough to handle this directly. This goes beyond the curren= t FE > > > > model. > > > > > > > > Do you also think that some sort of control activity should be al= lowed > > > > to be "off-loaded" into the FEs ? > > > > > > Robert, > > > I think it would be wrong to limit what functionality goes onto the= FE. I > > > worked on the requirements team and tried hard to make sure this is > > > clear. > > > > > > > > > If you find that this is not reflected properly, i think it should = be > > > clarified. > > > > > > I cant remember who came up with the term "high-touch" and it may a= lready > > > be used by some organizations as marketing cliche and so may alread= y be > > > polluted to mean something else than intended focus. > > > The caveat to note is that while Forces MUST not restrict what > > > functionality goes into the FE vs CE, the charter says the immediat= e > > > focus (in my opinion it is just an example) is Forwarding + QoS. Th= is may > > > be confusing the other side of the coin where people seem to think = the > > > protocol is based on Diffserv configuration. > > > > > > cheers, > > > jamal > > > > > > > Thanks > > > > > > > > > cheers, > > > > > jamal > > > > > > > > > > > Thanks, > > > > > > -Robert > > > > > > > > > > > > Jamal Hadi Salim wrote: > > > > > > > Robert, > > > > > > > > > > > > > > Maybe i misunderstood: How does "High-touch" not cover what= you > > > > > > > are addressing? Is it the naming that bothers you? > > > > > > > > > > > > > > cheers, > > > > > > > jamal > > > > > > > > > > > > > > On Wednesday 05 June 2002 10:27, Robert Haas wrote: > > > > > > > > I'd like to have the opinion of the list/design team rega= rding > > > > > > > > the issue below, which might impact the requirements draf= t to > > > > > > > > some extent (sorry for popping up just before the last ca= ll > > > > > > > > extended deadline): > > > > > > > > > > > > > > > > Certain FEs begin to provide functions that go beyond > > > > > > > > per-packet processing, such as TCP termination, where par= t of > > > > > > > > the signaling is off-loaded to the FE. The definition of > > > > > > > > "High-Touch Functions" in the draft does not seem to incl= ude > > > > > > > > such functions. > > > > > > > > > > > > > > > > Would it be wise to consider an additional category, such= as > > > > > > > > "Off-load Functions", with an appropriate model ? I belie= ve > > > > > > > > leaving this up to a "Vendor-Specific Function" would > > > > > > > > considerably reduce the > > > > > > > > attractivity/interoperability guaranteed by ForCES. > > > > > > > > > > > > > > > > Regards, > > > > > > > > -- > > > > > > > > Robert Haas > > > > > > > > IBM Zurich Research Laboratory > > > > > > > > S=E4umerstrasse 4 > > > > > > > > CH-8803 R=FCschlikon/Switzerland > > > > > > > > phone +41-1-724-8698 fax +41-1-724-8578 > > > > > > > > http://www.zurich.ibm.com/~rha -- 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 2002 Message-Id: Date: Tue, 25 Jun 2002 10:55:37 -0700 From: "Putzolu, David" Subject: ForCES Agenda Slot Finalized: Monday July 15, 0900-1130 MIME-Version: 1.0 Content-Type: text/plain All, The agenda for IETF 54 has been finalized. ForCES will meet on Monday, July 15, 2002, from 0900-1130. See you there! Cheers, David 2002 Message-Id: Date: Tue, 25 Jun 2002 07:01:58 -0400 Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-yang-forces-model-00.txt Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ForCES Forwarding Element Functional Model Author(s) : L. Yang et al. Filename : draft-yang-forces-model-00.txt Pages : 12 Date : 24-Jun-02 This document defines a functional model for ForCES forwarding elements (FEs). This model is used to describe the state of ForCES forwarding elements within the context of the ForCES protocol, so that ForCES control elements (CEs) can control the FEs accordingly. The model is to specify what logical function instances are present in the FEs and in what order these functions are performed. The forwarding element model defined herein is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES- REQ]. Using this model, predefined or vendor specific logical functions can be expressed and configured. However, the definition of these components are not described and defined in this document. Definitions A set of terminology associated with the ForCES requirements is defined in [FORCES-REQ] and is not copied here. The following list of terminology is relevant to the FE model defined in this document. Datapath -- A conceptual path taken by packets within the forwarding plane, inside an FE. There might exist more than one datapath within an FE. Forwarding Element (FE) Block -- An abstraction of the basic packet processing functions in the datapath. It is the building block of FE functionality. This concept abstracts away implementation details from the parameters of interest for configuration, control and management by CE. The general rule of thumb on the granularity of FE blocks is that FE blocks should be coarse grained, stateful and focus on a particular domain. For example, RFC1812 compliant IPv4 forwarder, classifiers, meters, etc.. Forwarding Element (FE) Stage -- Representation of a FE block instance in a FE's datapath. As a packet flows through an FE along a datapath, it flows through one or multiple distinct stages, with each stage implementing an instance of a certain logical function. There may be one or more combination of such instances in a FE's datapath. Using NAT as A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yang-forces-model-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yang-forces-model-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yang-forces-model-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020624143732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yang-forces-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-yang-forces-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143732.I-D@ietf.org> --OtherAccess-- --NextPart-- 2002 Message-Id: Date: Tue, 25 Jun 2002 07:00:44 -0400 Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-framework-00.txt Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Architectural Framework Author(s) : L. Yang et al. Filename : draft-ietf-forces-framework-00.txt Pages : 23 Date : 24-Jun-02 This document defines the architectural framework for ForCES network elements (NE), and identifies the associated entities and the interaction among them. This framework is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES- REQ]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020624143527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143527.I-D@ietf.org> --OtherAccess-- --NextPart-- 2002 Message-Id: Date: Mon, 24 Jun 2002 11:05:56 -0700 From: "Khosravi, Hormuzd M" Subject: Re: new netlink draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I would like to last call the latest version of the Netlink draft. Please do send us any comments/suggestions on the draft. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Sent: Friday, June 07, 2002 3:47 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] new netlink draft An updated draft posted at: ftp://openarchitect.znyx.com/pub/jamal/draft-forces-netlink-03.txt Please provide comments; we are hoping to last call this. cheers, jamal 2002 Message-Id: Date: Fri, 21 Jun 2002 15:43:42 -0700 From: "Yang, Lily L" Subject: New WG document on ForCES framework Comments: To: "Putzolu, David" , Internet-Drafts Administrator MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C21975.18212A90" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C21975.18212A90 Content-Type: text/plain; charset="iso-8859-1" <> David -- Please approve so that the attached draft can be submitted as ForCES WG document. Thanks, Lily ------_=_NextPart_000_01C21975.18212A90 Content-Type: text/plain; name="draft-ietf-forces-framework-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-forces-framework-00.txt" Internet Draft L. Yang=20 Expiration: December 2002 Intel Labs=20 File: draft-ietf-forces-framework-00.txt R. Dantu=20 Working Group: ForCES Netrake = Corp. =20 T. Anderson=20 Intel Labs = =20 June 2002 = =20 =20 =20 ForCES Architectural Framework=20 =20 =20 =20 draft-ietf-forces-framework-00.txt=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance = with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are=20 working documents of the Internet Engineering Task Force = (IETF), its=20 areas, and its working groups. Note that other groups may also = distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other = documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as ``work in=20 progress.''=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed = at =20 http://www.ietf.org/shadow.html.=20 =20 Conventions used in this document =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in=20 this document are to be interpreted as described in [RFC-2119]. = =20 1. Abstract=20 =20 This document defines the architectural framework for ForCES = network=20 elements (NE), and identifies the associated entities and the=20 interaction among them. This framework is intended to satisfy = the=20 requirements specified in the ForCES requirements draft = [FORCES- REQ].=20 =20 2. Definitions=20 =20 =0C Internet Draft ForCES Framework June 2002 = =20 =20 =20 =20 A set of terminology associated with the ForCES requirements is = defined in [FORCES-REQ] and we only include the ones that are = most=20 relevant to this document here. =20 =20 Forwarding Element (FE) - A logical entity that implements the=20 ForCES protocol. FEs use the underlying hardware to provide = per- packet processing and handling as directed by a CE via the = ForCES=20 protocol. =20 =20 Control Element (CE) - A logical entity that implements the = ForCES=20 protocol and uses it to instruct one or more FEs how to process = packets. CEs handle functionality such as the execution of = control =20 and signaling protocols. =20 =20 ForCES Network Element (NE) - An entity composed of one or more = CEs=20 and one or more FEs. To entities outside a NE, the NE = represents a=20 single point of management. Similarly, a NE usually hides its=20 internal organization from external entities. =20 =20 Pre-association Phase - The period of time during which a FE = Manager=20 (see below) and a CE Manager (see below) are determining which = FE=20 and CE should be part of the same network element. Any = partitioning=20 of PFEs and PCEs occurs during this phase. =20 =20 Post-association Phase - The period of time during which a FE = does=20 know which CE is to control it and vice versa, including the = time=20 during which the CE and FE are establishing communication with = one=20 another. =20 =20 ForCES Protocol - While there may be multiple protocols used = within=20 the overall ForCES architecture, the term "ForCES protocol" = refers=20 only to the ForCES post-association phase protocol (see below). = =20 =20 ForCES Post-Association Phase Protocol - The protocol used for = post- association phase communication between CEs and FEs. This = protocol=20 does not apply to CE-to-CE communication, FE-to-FE = communication, or=20 to communication between FE and CE managers. The ForCES = protocol is=20 a master-slave protocol in which FEs are slaves and CEs are = masters. =20 This protocol includes both the management of the communication = channel (e.g., connection establishment, heartbeats) and the = control=20 messages themselves. This protocol could be a single protocol = or=20 could consist of multiple protocols working together. =20 =20 FE Manager - A logical entity that operates in the = pre-association=20 phase and is responsible for determining to which CE(s) a FE = should=20 communicate. This process is called CE discovery and may = involve=20 the FE manager learning the capabilities of available CEs. A = FE=20 manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which CE(s) = to=20 use. Being a logical entity, a FE manager might be physically=20 =20 Yang, et. al. Expires December 2002 [Page 2] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 combined with any of the other logical entities mentioned in = this=20 section. =20 =20 CE Manager - A logical entity that operates in the = pre-association =20 phase and is responsible for determining to which FE(s) a CE = should =20 communicate. This process is called FE discovery and may = involve=20 the CE manager learning the capabilities of available FEs. A = CE=20 manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which FE to = use. =20 Being a logical entity, a CE manager might be physically = combined=20 with any of the other logical entities mentioned in this = section. =20 =20 Pre-association Phase Protocol - A protocol between FE managers = and=20 CE managers that is used to determine which CEs or FEs to use. = A=20 pre-association phase protocol may include a CE and/or FE = capability=20 discovery mechanism. Note that this capability discovery = process is=20 wholly separate from (and does not replace) that used within = the=20 ForCES protocol. However, the two capability discovery = mechanisms=20 may utilize the same FE model. =20 =20 FE Model - A model that describes the logical processing = functions=20 of a FE. =20 =20 ForCES Protocol Element - A FE or CE. =20 =20 3. Introduction to Forwarding and Control Element Separation = (ForCES) =20 =20 An IP network element (NE) appears to external entities as a=20 monolithic piece of network equipment, e.g., a router, NAT,=20 firewall, or load balancer. Internally, however, an IP network=20 element (NE) (such as a router or switch) is composed of = numerous=20 logically separated entities that cooperate to provide a given=20 functionality (such as routing or IP switching). Two types of=20 network element components exist: control element (CE) in = control=20 plane and forwarding element (FE) in forwarding plane (or data=20 plane). Forwarding elements typically are ASIC, = network-processor,=20 or general-purpose processor-based devices that handle data = path=20 operations for each packet. Control elements are typically = based on=20 general-purpose processors that provide control functionality = like=20 routing and signaling protocols. =20 =20 ForCES aims to define a framework and associated protocol(s) to = standardize the exchange of information between the control = plane=20 and the forwarding plane. Having standard mechanisms between = the CEs=20 and FEs allow these components to be physically separated. This = physical separation accrues several benefits to the ForCES=20 architecture. Separate components would allow component vendors = to=20 specialize in one component without having to become experts in = all=20 components. It also allows CEs and FEs from different component = vendors to interoperate with each other and hence it becomes=20 possible for system vendors to integrate together CEs and FEs = from=20 different component vendors. This translates into a lot more = design=20 choices and flexibility to the system vendors. Overall, ForCES = will=20 =20 Yang, et. al. Expires December 2002 [Page 3] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 enable rapid innovation in both the control and forwarding = planes=20 while maintaining interoperability. Scalability is also easily=20 provided by this architecture in that additional forwarding or=20 control capacity can be added to existing network elements = without=20 the need for forklift upgrades.=20 =20 One example of such physical separation is at the blade level.=20 Figure 1 shows an example configuration of a router, with two=20 control blades and multiple router (forwarding) blades, all=20 interconnected into a switch fabric backplane. In such chassis=20 configuration, the control blades are the CEs while the router=20 blades are FEs, and the switch fabric backplane provides the=20 physical interconnect for all the blades. Routers today with = this=20 kind of configuration use proprietary interface for messaging=20 between CEs and FEs. The goal of ForCES is to replace such=20 proprietary interface with a standard protocol. With a standard = protocol like ForCES implemented on all blades, it becomes = possible=20 for control blades from vendor X and routing blades from vendor = Y to=20 work seamlessly together in one chassis. =20 =20 =20 ------------------------- -------------------------=20 | Control Blade A | | Control Blade B |=20 | (CE) | | (CE) |=20 ------------------------- -------------------------=20 ^ | ^ |=20 | | | |=20 | V | V=20 ---------------------------------------------------------=20 | Switch Fabric Backplane |=20 ---------------------------------------------------------=20 ^ | ^ | ^ | = | | | | =85 | | = =20 | V | V | V = ------------ ------------ ------------ = |Router | |Router | |Router |=20 |Blade #1 | |Blade #2 | |Blade #N |=20 | (FE) | | (FE) | | (FE) |=20 ------------ ------------ ------------ = ^ | ^ | ^ | = | | | | =85 | | = =20 | V | V | V = =20 Figure 1. A router configuration example with separate = blades.=20 =20 Another level of physical separation between the CEs and FEs = can be=20 at the box level. In such configuration, all the CEs and FEs = are=20 physically separated boxes, interconnected with some kind of = high=20 speed LAN connection (like Gigabit Ethernet). These separated = CEs=20 and FEs are only one hop away from each other within a local = area=20 network. The CEs and FEs communicate to each other by running=20 ForCES, and the collection of these CEs and FEs together become = one=20 routing unit to the external world. Figure 2 shows such an = example.=20 =20 Yang, et. al. Expires December 2002 [Page 4] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 In this example, the same physical interconnect (Ethernet) is = shared=20 for both CE-to-FE and FE-to-FE communication. However, that = does not=20 have to be the case. One reason to use different interconnect = might=20 be that CE-to-FE interconnect does not have to be as fast as = the FE- to-FE interconnect, so the more expensive fast ports can be = saved=20 for FE-to-FE. There may also be reliability and redundancy = benefits=20 for the NE.=20 =20 ------- -------=20 | CE1 | | CE2 |=20 ------- -------=20 ^ ^=20 | |=20 V V=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ethernet=20 ^ ^ =85 ^=20 | | |=20 V V V=20 ------- ------- --------=20 | FE#1| | FE#2| | FE#n |=20 ------- ------- --------=20 ^ | ^ | ^ | =20 | | | | | | =20 | V | V | V =20 =20 Figure 2. A router configuration example with separate = boxes.=20 =20 =20 -------------------------------------------------=20 | | | | | | |=20 |OSPF |RIP |BGP |CAC |LDP |=85 |=20 | | | | | | |=20 -------------------------------------------------=20 | ForCES Interface |=20 -------------------------------------------------=20 ^ ^ =20 ForCES | |data =20 control | |packets =20 messages| |(e.g., routing packets) =20 v v=20 -------------------------------------------------=20 | ForCES Interface |=20 -------------------------------------------------=20 | | | | | | |=20 |LPM Fwd|Meter |Shaper |NAT |Classi-|=85 |=20 | | | | |fier | |=20 -------------------------------------------------=20 | FE resources |=20 -------------------------------------------------=20 =20 Figure 3. Examples of CE and FE functions=20 =20 =20 Yang, et. al. Expires December 2002 [Page 5] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 Some examples of control functions that can be implemented in = the CE=20 include routing protocols like RIP, OSPF and BGP, control and=20 signaling protocols like CAC (Call Admission Control), LDP = (Label=20 Distribution Protocol) for MPLS, etc. Examples of forwarding functions in FE include LPM (longest prefix match) forwarder,=20 classifiers, traffic shaper, meter, NAT, etc. Figure 3 shows a=20 diagram with examples in both CE and FE. Any given NE may = contain=20 one or many of these CE and FE functions in it. The diagram = also=20 shows that ForCES protocol is used to transport both the = control=20 messages for ForCES itself and the data packets that are=20 originated/destined from/to the control functions in CE (e.g.,=20 routing packets). Section 5.2 provides more detail on this. =20 =20 A set of requirements for control and forwarding separation is=20 identified in [FORCES-REQ]. This document describes a ForCES=20 architecture that satisfies the architectural requirements of = that=20 document and defines a framework for ForCES network elements = and=20 associated entities to facilitate protocol definition.=20 =20 4. Architecture=20 =20 This section defines the ForCES architectural framework and=20 associated logical components. This ForCES framework defines=20 components of ForCES NEs and also includes several ancillary=20 components. These components can be connected in different = kinds of=20 topologies for flexible packet processing. =20 =20 --------------------------------------- = | ForCES Network Element | = -------------- Fc | -------------- -------------- | = | CE Manager |---------+-| CE 1 |------| CE 2 | | = -------------- | | | Fr | | | = | | -------------- -------------- | = | Fl | | | Fp / | = | | Fp| |----------| / | = | | | |/ | = | | | | | = | | | Fp /|----| | = | | | /--------/ | | = -------------- Ff | -------------- -------------- | = | FE Manager |---------+-| FE 1 | Fi | FE 2 | | = -------------- | | |------| | | = =20 | -------------- -------------- | = | | | | | | | | | | = ----+--+--+--+----------+--+--+--+----- = | | | | | | | |=20 | | | | | | | |=20 Fi/f Fi/f=20 =20 Figure 4. ForCES Architectural Diagram=20 =20 The diagram in Figure 4 shows the logical components of the = ForCES=20 architecture and their relationships. There are two kinds of=20 =20 Yang, et. al. Expires December 2002 [Page 6] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 components inside a ForCES network element: control element = (CE) and=20 forwarding element (FE). The framework allows multiple = instances of=20 CE and FE inside one NE. Each FE contains one or more physical = media=20 interfaces for receiving and transmitting packets from/to the=20 external world. The aggregation of these FE interfaces becomes = the=20 NE=92s external interfaces. In addition to the external = interfaces,=20 there must also exist some kind of interconnect within the NE = so=20 that the CE and FE can communicate with each other, and one FE = can=20 forward packets to another FE. The diagram also shows two = entities=20 outside of the ForCES NE: CE Manager and FE Manager. These two=20 entities provide configuration to the corresponding CE or FE in = the=20 pre-association phase (see Section 5.1). There is no defined = role=20 for FE Manager and CE Manager in post-association phase, thus = these=20 logical components are not considered part of the ForCES NE. =20 =20 For convenience, the logical interactions between these = components=20 are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi. The = FE=20 interface is labeled as Fi/f. More detail is provided in = Section 4=20 and 5 for each of these reference points. It is important to=20 understand all these reference points from the architecture = point of=20 view, however, the ForCES protocol is only defined for one = reference=20 point (Fp). =20 =20 The interface between two ForCES NEs is identical to the = interface=20 between two conventional routers and these two NEs exchange the = protocol packets through the interfaces at Fi/f. ForCES NEs = connect=20 to existing routers transparently.=20 =20 4.1. Control Elements and Fr Reference Point=20 =20 It is not necessary to define any protocols across the Fr = reference=20 point to enable control and forwarding separation for simple=20 configurations like single CE and multiple FEs. However, this=20 architecture permits multiple CEs to be present in a network=20 element. In cases where an implementation uses multiple CEs, it = is=20 expected the invariant that the CEs and FEs together appear as = a=20 single NE MUST be maintained.=20 =20 Multiple CEs may be used for redundancy, load sharing, = distributed=20 control, or other purposes. Redundancy is the case where one = or=20 more CEs are prepared to take over should an active CE fail. = Load=20 sharing is the case where two or more CEs are concurrently = active=20 and where any request that can be serviced by one of the CEs = can=20 also be serviced by any of the other CEs. In both redundancy = and=20 load sharing, the CEs involved are equivalently capable. The = only=20 difference between these two cases is in terms of how many = active=20 CEs there are. Distributed control is the case where two or = more=20 CEs are concurrently active but where certain requests can only = be=20 serviced by certain CEs.=20 =20 When multiple CEs are employed in a ForCES NE, their internal=20 organization is considered an implementation issue that is = beyond=20 the scope of the ForCES effort. CEs are wholly responsible for=20 =20 Yang, et. al. Expires December 2002 [Page 7] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 coordinating amongst themselves via the Fr reference point to=20 provide consistency and synchronization. However, ForCES does = not=20 define the implementation or protocols used between CEs, nor = does it=20 define how to distribute functionality among CEs. Nevertheless, = ForCES will support mechanisms for CE redundancy or fail over, = and=20 it is expected that vendors will provide redundancy or fail = over=20 solutions within this framework.=20 =20 =20 4.2. Forwarding Elements and Fi reference point=20 =20 FEs perform per-packet processing and handling as directed by = CEs.=20 FEs have no initiative of their own. Instead, FEs are slaves = and=20 only do as they are told. FEs may communicate with one or more = CEs=20 concurrently across reference point Fp. FEs have no notion of = CE=20 redundancy, load sharing, or distributed control. Instead, FEs = accept commands from any CE authorized to control them, and it = is up=20 to the CEs to coordinate among themselves to achieve = redundancy,=20 load sharing or distributed control. The idea is to keep FEs as = simple and dumb as possible so that FEs can focus its resource = on=20 the packet processing functions. =20 =20 =20 ------- Fr -------=20 | CE1 | ------| CE2 |=20 ------- -------=20 | \ / |=20 | \ / |=20 | \ / |=20 | \/Fp |=20 | /\ |=20 | / \ |=20 | / \ |=20 ------- Fi -------=20 | FE1 |<----->| FE2 |=20 ------- -------=20 =20 Figure 5. CE redundancy example.=20 =20 For example, in Figure 5, FE1 and FE2 can be configured to = accept=20 commands from both the primary CE (CE1) and the backup CE = (CE2). At=20 the beginning, CE1 issues commands to FEs while CE2 silently = remains=20 in sync with CE1 via CE to CE protocol over Fr reference point. = When=20 CE1 fails, CE2 detects it and starts to take over. Before CE2 = starts=20 issuing commands to the FEs, it might need to recheck the FEs' = state=20 and instruct FEs whether or not it is ok to preserve their = current=20 state. =20 =20 Distributed control can be achieved in the similar fashion, = without=20 much intelligence on the part of FEs. For example, FEs can be=20 configured to detect RSVP and BGP protocol packets, and forward = RSVP=20 packets to one CE and BGP packets to another CE. Hence, FEs may = need=20 to do packet filtering for forwarding packets to specific CEs.=20 =20 Yang, et. al. Expires December 2002 [Page 8] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 =20 This architecture permits multiple FEs to be present in a NE.=20 [FORCES-REQ] dictates that the ForCES protocol MUST be able to = scale=20 to at least hundreds of FEs (see [FORCES-REQ] Section 5, = requirement=20 #11). Each of these FEs may potentially have a different set of = packet processing functions, with different media interfaces. = FEs=20 are responsible for basic maintenance of layer-2 connectivity = with=20 other FEs and with external entities. Many layer-2 media = include=20 sophisticated control protocols. The FORCES protocol (over the = Fp=20 reference point) will be able to carry messages for such = protools so=20 that, in keeping with the "dumb FE model" the CE can provide=20 appropriate intelligence and control over these media.=20 =20 When multiple FEs are present, ForCES requires that packets = MUST be=20 able to arrive at the NE by one FE and leave the NE via a = different=20 FE (See [FORCES-REQ], Section 5, Requirement #3). Packets that = enter the NE via one FE and leave the NE via a different FE are = transferred between FEs across the Fi reference point. The Fi=20 reference point is a separate protocol from the Fp reference = point=20 and is not currently defined by the ForCES architecture.=20 =20 FEs could be connected in different kinds of topologies and = packet=20 processing may spread across several FEs in the topology. = Hence,=20 logical packet flow may be different from physical FE topology. = Figure 6 provides some topology examples. When it is necessary = to=20 forward packets between FEs, CE needs to understand the FE = topology.=20 The FE topology can be queried from FEs by CEs. If the most = common=20 FE topology is full mesh among FEs, ForCES can assume it as the = default topology for FEs and hence no query is needed for such=20 default cases.=20 =20 ----------------- =20 | CE | =20 ----------------- =20 ^ ^ ^=20 / | \=20 / v \=20 / ----- \=20 / +->|FE3|<-+ \=20 v | ----- | v=20 ------- | | -------=20 | FE1 |<-+ +->| FE2 |=20 ------- -------=20 ^ | ^ |=20 | | | |=20 | v | v=20 =20 (a) Full mesh among FE1, FE2 and FE3.=20 =20 ----------- =20 | CE | =20 ----------- =20 =20 Yang, et. al. Expires December 2002 [Page 9] = =0C Internet Draft ForCES Framework June 2002 = =20 =20 ^ ^ ^ ^=20 / | | \=20 /------ | | ------\=20 v v v v=20 ------- ------- ------- -------=20 | FE1 |<->| FE2 |<->| FE3 |<->| FE4 |=20 ------- ------- ------- -------=20 ^ | ^ | ^ | ^ |=20 | | | | | | | |=20 | v | v | v | v=20 =20 (b) Multiple FEs in a daisy chain=20 =20 =20 ^ |=20 | v=20 ----------- =20 | FE1 |<-----------------------| =20 ----------- |=20 ^ ^ |=20 / \ | =20 | ^ / \ ^ | V=20 v | v v | v ---------- = --------- --------- | | = | FE2 | | FE3 |<------------>| CE | = --------- --------- | | = ^ ^ ^ ---------- = | \ / ^ ^=20 | \ / | |=20 | v v | |=20 | ----------- | |=20 | | FE4 |<----------------------| | =20 | ----------- |=20 | | ^ |=20 | v | |=20 | |=20 |----------------------------------------|=20 =20 (c) Multiple FEs connected by a ring=20 =20 Figure 6. Some examples of FE topology.=20 =20 4.3. CE Managers=20 =20 CE managers are responsible for determining which FEs a CE = should=20 control. It is legitimate for CE managers to be hard-coded = with the=20 knowledge of with which FEs its CEs should communicate. A CE = manager=20 may also be physically embedded into a CE and be implemented as = a=20 simple keypad or other direct configuration mechanism on the = CE. =20 Finally, CE managers may be physically and logically separate=20 entities that configure the CE with FE information via such=20 mechanisms as COPS-PR [RFC3084] or SNMP [RFC1157].=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 10] =0C Internet Draft ForCES Framework June 2002 = =20 =20 4.4. FE Managers=20 =20 FE managers are responsible for determining to which CE any=20 particular FE should initially communicate. Like CE managers, = no=20 restrictions are placed on how a FE manager decides to which = CEs its=20 FEs should communicate, nor are restrictions placed on how FE=20 managers are implemented.=20 =20 5. Operational Phases=20 =20 Both FEs and CEs require some configuration in place before = they can=20 start information exchange and function as a coherent network=20 element. Two operational phases are identified in this = framework --=20 pre-association and post-association. =20 =20 5.1.Pre-association Phase=20 =20 Pre-association phase is the period of time during which a FE=20 Manager and a CE Manager are determining which FE and CE should = be=20 part of the same network element. The protocols used during = this=20 phase may include all or some of the message exchange over Fl, = Ff=20 and Fc reference points. However, all these may be optional and = none=20 of this is within the scope of ForCES protocol.=20 =20 5.1.1. Fl Reference Point=20 =20 =20 FE Manager FE CE Manager CE=20 | | | |=20 | | | |=20 |(security exchange) | |=20 1|<------------------------------>| |=20 | | | |=20 |(a list of CEs and their attributes) |=20 2|<-------------------------------| |=20 | | | |=20 |(a list of FEs and their attributes) |=20 3|------------------------------->| |=20 | | | |=20 | | | |=20 |<----------------Fl------------>| |=20 =20 Figure 7. An example of message exchange over Fl reference = point=20 =20 CE managers and FE managers may communicate across the Fl = reference=20 point in the pre-association phase in order to determine which = CEs=20 and FEs should communicate with each other. Communication = across=20 the Fl reference point is optional in this architecture. No=20 requirements are placed on this reference point.=20 =20 CE managers and FE managers may be operated by different = entities. =20 The operator of the CE manager may not want to divulge, except = to=20 specified FE managers, any characteristics of the CEs it = manages. =20 =20 Yang, et. al. Expires December 2002 [Page = 11] =0C Internet Draft ForCES Framework June 2002 = =20 =20 Similarly, the operator of the FE manager may not want to = divulge FE=20 characteristics, except to authorized entities. As such, CE=20 managers and FE managers may need to authenticate one another. = Subsequent communication between CE managers and FE managers = may=20 require other security functions such as privacy, = non-repudiation,=20 freshness, and integrity.=20 =20 Once the necessary security functions have been performed, the = CE=20 and FE managers communicate to determine which CEs and FEs = should=20 communicate with each other. At the very minimum, the CE and = FE=20 managers need to learn of the existence of available FEs and = CEs=20 respectively. This discovery process may or may not entail one = or=20 both managers learning the capabilities of the discovered = ForCES=20 protocol elements. Figure 7 shows an example of possible = message=20 exchange between CE manager and FE manager over Fl reference = point.=20 =20 5.1.2. Ff Reference Point=20 =20 FE Manager FE CE Manager CE=20 | | | |=20 | | | |=20 |(security exchange) |(security exchange)=20 1|<------------>|authentication = 1|<----------->|authentication | | | |=20 |(FE ID, attributes) |(CE ID, attributes)=20 2|<-------------|request 2|<------------|request=20 | | | |=20 3|------------->|response 3|------------>|response=20 |(corresponding CE ID) |(corresponding FE ID)=20 | | | |=20 | | | |=20 |<-----Ff----->| |<-----Fc---->|=20 =20 Figure 8. Examples of message exchange=20 over Ff and Fc reference points.=20 =20 The Ff reference point is used to inform forwarding elements of = the=20 association decisions made by FE managers in pre-association = phase. =20 Only authorized entities may instruct a FE with respect to = which CE=20 should control it. Therefore, privacy, integrity, freshness, = and=20 authentication are necessary between FE manager and FEs when = the FE=20 manager is remote to the FE. Once the appropriate security has = been=20 established, FE manager instructs FEs across this reference = point to=20 join a new NE or to disconnect from an existing NE. Figure 8 = shows=20 example of message exchange over Ff reference point.=20 =20 Note that when the FE manager function may be co-located with = the FE=20 (such as by manual keypad entry of the CE IP address), in which = case=20 this reference point is reduced to a built-in function.=20 =20 5.1.3. Fc Reference Point=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 12] =0C Internet Draft ForCES Framework June 2002 = =20 =20 The Fc reference point is used to inform control elements of = the=20 association decisions made by CE managers in pre-association = phase. =20 When the CE manager is remote, only authorized entities may = instruct=20 a CE to control certain FEs. Privacy, integrity, freshness and = authentication are also required across this reference point in = such=20 a configuration. Once appropriate security has been = established,=20 the CE manager instructs CEs as to which FEs they should = control and=20 how they should control them. Figure 7 shows example of message = exchange over Fc reference point.=20 =20 As with the FE manager and FEs, configurations are possible = where=20 the CE manager and CE are co-located and no protocol is used = for=20 this function.=20 =20 5.2. Post-association Phase and Fp reference point=20 =20 Post-association phase is the period of time during which a FE = and=20 CE have been configured with information necessary to contact = each=20 other and includes both communication establishment and = steady-state=20 communication. The communication between CE and FE is performed = across the Fp ("p" meaning protocol) reference point. ForCES=20 protocol is exclusively used for all communication across the = Fp=20 reference point. =20 =20 5.2.1. Proximity and Interconnect between CEs and FEs=20 The ForCES Working Group has made a conscious decision that the = first version of ForCES will not be designed to support=20 configurations where the CE and FE are located arbitrarily in = the=20 network. In particular, ForCES is intended for "very close" = CE/FE=20 localities in IP networks, as defined by ForCES Applicability=20 Statement ([FORCES-APP]). Very Close localities consist of = control=20 and forwarding elements that either are components in the same=20 physical box, or are separated at most by one local network = hop. =20 =20 CEs and FEs can be connected by a variety of interconnect=20 technologies, including Ethernet connections, backplanes, ATM = (cell)=20 fabrics, etc. ForCES should be able to support each of these=20 interconnects (see [FORCES-REQ] Section 5, requirement #1). = ForCES=20 will make use of an existing RFC2914 compliant L4 protocol with = adequate reliability, security and congestion control (e.g. = TCP,=20 SCTP) for transport purposes.=20 =20 5.2.2. Association Establishment=20 =20 As an example, figure 9 shows some of the message exchange that = need=20 to happen before the association between CE and FE is fully=20 established. Typically, FE would need to inform the CE of its = own=20 capability and its topology in relation to other FEs. The = capability=20 of FE is represented by FE model, described in another separate = document. The model would allow FE to describe what kind of = packet=20 processing functions it contains, in what order these = processing=20 happen, what kind of configurable parameters it allows, what=20 =20 Yang, et. al. Expires December 2002 [Page = 13] =0C Internet Draft ForCES Framework June 2002 = =20 =20 statistics it collects and what events it might throw, etc. = Once=20 such information is available to CE, CE sends all the necessary = configuration to FE so that FE can start receiving and = processing=20 packets. For example, CE might need to send a snapshot of the=20 current routing table to FE so that FE can start routing = packets=20 correctly. Once FE starts accepting packets for processing, we = say=20 the association of this FE with its CE is now established. From = then=20 on, CE and FE enter steady-state communication as described in=20 5.2.2.=20 =20 =20 =20 =20 FE CE=20 | |=20 |(Hello, are you there?)|=20 1|<----------------------|=20 | |=20 |(Yes. let me join the NE please.) =20 2|---------------------->|=20 | |=20 |(Security exchange.) |=20 3|<--------------------->|=20 | |=20 |(What kind of FE are you? -- capability query)=20 4|<----------------------|=20 | |=20 |(Here is my FE functions/state: use model to = describe)=20 5|---------------------->|=20 | |=20 |(How are you connected with others? -- topology = query)=20 6|<----------------------|=20 | |=20 |(Here is the topology info)=20 7|---------------------->|=20 | |=20 |(Config for FE initialization, e.g. routing = table)=20 8|<----------------------|=20 | |=20 |(I am ready to go. Shall I?) =20 9|---------------------->|=20 | |=20 |(Go ahead!) |=20 10|<----------------------|=20 | |=20 =20 Figure 9. Example of message exchange between CE and FE=20 over Fp to establish NE association=20 =20 =20 5.2.3. Steady-state Communication=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 14] =0C Internet Draft ForCES Framework June 2002 = =20 =20 Once an association is established between the CE and the FE, = the=20 ForCES protocol is used by the CE and the FE over Fp reference = point=20 to exchange information to facilitate packet processing. =20 =20 FE CE=20 | |=20 |(Add these new routes.)|=20 1|<----------------------|=20 | |=20 |(Successful.) |=20 2|---------------------->|=20 | |=20 | |=20 | |=20 |(Query some stats.) |=20 1|<----------------------|=20 | |=20 |(Reply with stats collected.) =20 2|---------------------->|=20 | |=20 | |=20 | |=20 |(My port is down, with port #.) = =20 1|---------------------->|=20 | |=20 |(Route to this port instead...) =20 2|<----------------------|=20 | |=20 | |=20 =20 Figure 10. Examples of message exchange between CE and FE = over Fp during steady-state communication=20 =20 Based on the information acquired through CEs' control = processing,=20 CEs will frequently need to manipulate the packet-forwarding=20 behaviors of their FE(s) by sending instructions to FEs. For=20 example, Figure 10 shows one such message exchange in which CE = sends=20 new routes to FE so that FE can add them to its routing table. = CE=20 can also query FE for statistics collected by FE and FE can = also=20 notify CE of some important events, like interface up and down, = etc.=20 Figure 8 also shows such examples.=20 =20 5.2.4. Data Packets across Fp reference point=20 =20 Control packets (such as RIP, OSPF messages) addressed to any = of=20 NE's interfaces are typically redirected by the receiving FE to = its=20 CE, and CE may originate packets and have its FE deliver them = to=20 other NEs. Therefore, the communication across the Fp reference = point includes not only the control messages from CEs to FEs = and the=20 status or statistics report from FEs to CEs, but also the data=20 packets that are redirected between them. Moreover, one FE may = be=20 controlled by multiple CEs. In this configuration, the control=20 protocols supported by the FORCES NEs may spread across = multiple=20 =20 Yang, et. al. Expires December 2002 [Page = 15] =0C Internet Draft ForCES Framework June 2002 = =20 =20 CEs. For example, one CE may support OSPF and another supports = BGP.=20 FEs are configured to recognize these protocol packets and = forward=20 them to the corresponding CE. =20 =20 Figure 11 shows one example of how the OSPF packets originated = by=20 router A are passed to router B. In this example, ForCES = protocol is=20 used to transport the packets from CE to FE inside router A, = and=20 then from FE to CE inside router B. In light of the fact that = ForCES=20 protocol is responsible to transport both the control messages = and=20 the data packets between CE and FE over Fp reference point, it = is=20 possible to use either a single protocol or multiple protocols = to=20 achieve that.=20 =20 =20 --------------------- ----------------------=20 | | | |=20 | +--------+ | | +--------+ |=20 | |CE(OSPF)| | | |CE(OSPF)| |=20 | +--------+ | | +--------+ |=20 | | | | ^ |=20 | |Fp | | |Fp |=20 | v | | | |=20 | +--------+ | | +--------+ |=20 | | FE | | | | FE | |=20 | +--------+ | | +--------+ |=20 | | | | ^ |=20 | Router | | | Router | |=20 | A | | | B | |=20 ---------+----------- -----------+----------=20 v ^=20 | |=20 | |=20 ------------------->--------------- =20 =20 Figure 11. Example to show data packet flow between two = NEs.=20 =20 =20 5.2.5. Proxy FE=20 =20 In the case where a physical FE cannot implement (e.g., due to = the=20 lack of a general purpose CPU) the ForCES protocol directly, a = proxy=20 FE can be used in the middle of Fp reference point. This allows = the=20 CE communicate to the physical FE via the proxy by using = ForCES,=20 while the proxy manipulates the physical FE using some = intermediary=20 form of communication (e.g., a non-ForCES protocol or DMA). In = such=20 an implementation, the combination of the proxy and the = physical FE=20 becomes one logical FE entity. =20 =20 5.3. Association Re-establishment=20 =20 FEs and CEs may join and leave NEs dynamically (see = [FORCES-REQ]=20 Section 5, requirements #12 and #13). When a FE or CE leaves = the NE,=20 the association with the NE is broken. If the leaving party = rejoins=20 =20 Yang, et. al. Expires December 2002 [Page = 16] =0C Internet Draft ForCES Framework June 2002 = =20 =20 a NE later, to re-establish the association, it may or may not = need=20 to re-enter the pre-association phase. Loss of association can = also=20 happen unexpectedly due to loss of connection between the CE = and the=20 FE. Therefore, the framework allows the bi-directional = transition=20 between these two phases, but the ForCES protocol is only = applicable=20 for the post-association phase. However, the protocol should = provide=20 mechanisms to support association re-establishment (see = [FORCES-REQ]=20 Section 5, requirement #7).=20 =20 Let's use the example in Figure 5 to see what happens when the=20 association is broken and later re-established again. Section = 4.2=20 already explains what happens if CE1 fails and how CE2 can take = over. Note that if no CE redundancy is provided, FEs need to be = told=20 at the association establishment time what to do in the case of = CE=20 failure. FEs may be told to stop packet processing all together = if=20 its CE fails. Or, FEs may be told to continue forwarding = packets=20 even in the face of CE failure. No matter what, it needs to be = part=20 of the configuration when the association is established. =20 =20 Let's now look at the case when FE1 leaves the NE temporarily,=20 assuming CE1 is the working CE for the moment. FE1 may = voluntarily=20 decides to leave the association. Or, it is more likely that = FE1=20 stops functioning simply due to unexpected failure. In former = case,=20 CE1 receives a "leave-association request" from FE1. In the = latter,=20 CE1 detects the failure of FE1 by some other mean. In both = cases,=20 CE1 would keep a note of such event for FE1 while continue=20 commanding FE2. When FE1 decides to rejoin again, or when it is = back=20 up again from the failure, FE1 would need to re-discover its = master=20 (CE). This can be achieved by several means. It may re-enter = the=20 pre-association phase and get that information from its FE = manager.=20 It may retrieve the previous CE information from its cache, if = it=20 decides that the information is still valid. Or, that = information=20 can be simply hard-coded or pre-configured into it. Once it=20 discovers its CE, it starts message exchange with CE to = re-establish=20 the association just as outlined in Figure 9, with the possible = exception that it might be able to bypass the transport of the=20 complete initialization information. Suppose that FE1 still = have its=20 routing table and other state information from the last = association,=20 instead of sending all the information again from scratch, it = can=20 choose to use more efficient mechanism to re-sync up the state = with=20 its CE. For example, a checksum of the state might give a quick = indication of whether or not the state is in-sync with its CE. = By=20 comparing its state with CE first, it sends information update = only=20 if it is needed.=20 =20 =20 6. Applicability to RFC1812 =20 =20 [FORCES-REQ] Section 5, requirement #9 dictates that "All = proposed=20 ForCES architecture MUST explain how that architecture may be=20 applied to support all of a router's functions as defined in=20 [RFC1812]." RFC1812 discusses many important requirements for = IPv4=20 routers from the link layer to the application layer. This = section=20 =20 Yang, et. al. Expires December 2002 [Page = 17] =0C Internet Draft ForCES Framework June 2002 = =20 =20 addresses the relevant requirements for implementing IPv4 = routers=20 based on ForCES architecture and how ForCES satisfies these=20 requirements.=20 =20 6.1. General Router Requirements=20 =20 Routers have at least two or more logical interfaces. When CEs = and=20 FEs are separated by ForCES within a single NE, some additional = interfaces are needed for intra-NE communications. Figure 12 = shows=20 an example to illustrate that. This NE contains one CE and two = FEs.=20 Each FE has four interfaces; two of them are used for receiving = and=20 transmitting packets to the external world, while the other two = are=20 for intra-NE connections. CE has two logical interfaces #9 and = #10,=20 connected to interfaces #3 and #6 from FE1 and FE2, = respectively.=20 Interface #4 and #5 are connected for FE1-FE2 communication. So = this=20 router NE provides four external interfaces (#1, 2, 7 and 8). =20 =20 ---------------------------------=20 | router NE |=20 | ----------- ----------- |=20 | | FE1 | | FE2 | |=20 | ----------- ----------- |=20 | 1| 2| 3| 4| 5| 6| 7| 8| |=20 | | | | | | | | | |=20 | | | | +----+ | | | |=20 | | | | | | | |=20 | | | 9| 10| | | |=20 | | | -------------- | | |=20 | | | | CE | | | |=20 | | | -------------- | | |=20 | | | | | |=20 -----+--+----------------+--+----=20 | | | | =20 | | | | =20 =20 Figure 12. A router NE example with four = interfaces.=20 =20 IPv4 routers must implement IP to support its packet forwarding = function, which is driven by its FIB (Forwarding Information = Base).=20 This Internet layer forwarding (see [RFC1812] Section 5)=20 functionality naturally belongs to FEs in the ForCES = architecture. =20 =20 A router may implement transport layer protocols (like TCP and = UDP)=20 that are required to support application layer protocols (see=20 [RFC1812] Section 6). One important class of application = protocols=20 is routing protocols (see [RFC1812] Section 7). In ForCES=20 architecture, routing protocols are naturally implemented by = CEs.=20 Routing protocols require routers communicate with each other. = This=20 communication between CEs in different routers is supported in=20 ForCES by the FEs' ability to redirect data packets =20 addressed to routers (i.e., NEs) and CEs' ability to originate=20 packets and have them delivered by their FEs. This = communication=20 =20 Yang, et. al. Expires December 2002 [Page = 18] =0C Internet Draft ForCES Framework June 2002 = =20 =20 occurs across Fp reference point inside each router and between = neighboring routers' interfaces, as illustrated in Figure 11. =20 =20 6.2.Link Layer=20 =20 Since FEs own all the external interfaces for the router, FEs = need=20 to conform to all the link layer requirements in RFC1812, = including=20 ARP support. Interface parameters, including MTU, IP address, = etc.,=20 must be configurable by CEs via ForCES. FEs must also inform = CEs the=20 status change of the interfaces (like link up/down) via ForCES. = =20 6.3.Internet Layer Protocols=20 =20 Both FEs and CEs must implement IP protocol and all mandatory=20 options as RFC1812 specified. If an FE receives a packet = containing=20 a completed source route, the packet has reached its final=20 destination. The option as received (the recorded route) MUST = be=20 passed up to the transport layer (or to ICMP message = processing) at=20 CEs. Both FEs and CEs might choose to silently discard packets=20 without sending ICMP errors, and such events should be logged. = FEs=20 can report statistics for such events to CEs via ForCES. =20 =20 When multiple FEs are involved to process packets, the = appearance of=20 single NE must be strictly maintained. For example, = Time-To-Live=20 (TTL) must be decremented only once within a single NE. For = example,=20 it can be always decremented by the last FE with egress = function.=20 Similarly, when source =20 =20 When IP multicast is supported in routers, IGMP is implemented = in=20 CEs. CEs are also required of ICMP support, while it is = optional for=20 FEs to support ICMP. Such an option can be communicated to CEs = as=20 part of the FE model. Therefore, FEs can always rely upon CEs = to=20 send out ICMP error messages, but FEs also have the option to=20 generate ICMP error messages themselves. =20 =20 6.4.Internet Layer Forwarding=20 =20 IP forwarding is implemented by FEs. After routing protocol = update=20 its routing tables at CEs, ForCES is used to send the new = routing=20 table entries from CEs to FEs. Each FE has its own routing = table and=20 uses this table to direct packets to the next hop interface. = Note=20 that the routing table could be different from FE to FE because = each=20 FE has a different set of next hop interfaces. =20 =20 Upon receiving IP packets, FEs verify the IP header and process = most=20 of the IP options. Some options can't be processed until the = routing=20 decision has been made. Routing decision is made after = examining the=20 destination IP address. If the destination address belongs to = the=20 router itself, the packets are forwarded to CEs. Otherwise, FEs = determine the next hop IP address by looking up in its routing=20 table. FEs also determine the network interface it uses to send = the=20 packets. Sometimes an FE may need to forward the packets to = another=20 FE before packets can be forwarded out to the next hop. Right = before=20 =20 Yang, et. al. Expires December 2002 [Page = 19] =0C Internet Draft ForCES Framework June 2002 = =20 =20 packets are forwarded out to the next hop, FEs decrement TTL by = 1=20 and process any IP options that can not be processed before. = FEs=20 perform any IP fragmentation if necessary, determine link layer = address (e.g., by ARP), and encapsulates the IP datagram (or = each of=20 the fragments thereof) in an appropriate link layer frame and = queues=20 it for output on the interface selected.=20 =20 Other options mentioned in RFC1812 for IP forwarding may also = be=20 implemented at FEs, for example, packet filtering.=20 =20 FEs typically forward packets destined locally to CEs. FEs may = also=20 forward exceptional packets (packets that FEs don't know how to = handle) to CEs. CEs are required to handle packets forwarded by = FEs=20 for whatever different reasons. It might be necessary for = ForCES to=20 attach some meta-data with the packets to indicate the reasons = of=20 forwarding from FEs to CEs. Upon receiving packets with = meta-data=20 from FEs, CEs can decide to either process the packets = themselves,=20 or pass the packets to the upper layer protocols including = routing=20 and management protocols. If CEs are to process the packets by=20 themselves, CEs may choose to discard the packets, or modify = and re- send the packets. CEs may also originate new packets and = deliver=20 them to FEs for further forwarding. =20 =20 Any state change during router operation must also be handled=20 correctly according to RFC1812. For example, when an FE ceases=20 forwarding, the entire NE may continue forwarding packets, but = it=20 needs to stop advertising routes that are affected by the = failed FE. =20 =20 6.5.Transport Layer =20 =20 Transport layer is typically implemented at CEs to support = higher=20 layer application protocols like routing protocols. In = practice,=20 this means that most CEs implement both the Transmission = Control=20 Protocol (TCP) and the User Datagram Protocol (UDP).=20 =20 Both CEs and FEs need to implement ForCES protocol. If any = layer-4=20 transport is used to support ForCES, then both CEs and FEs need = to=20 implement the L4 transport and ForCES protocols. It is possible = that=20 all FEs inside an NE implements only one such protocol entity. = =20 6.6. Application Layer -- Routing Protocols=20 =20 Both interior routing protocols and exterior routing protocols = are=20 implemented on CEs. The routing packets originated by CEs are=20 forwarded to FEs for delivery. The results of such protocols = (like=20 routing table update) are communicated to FEs via ForCES.=20 =20 6.7. Application Layer -- Network Management Protocol=20 =20 RFC1812 also dictates "Routers MUST be manageable by SNMP." = (see=20 [RFC1157] Section 8) In general, for post-association phase, = most=20 external management tasks (including SNMP) SHOULD be done = through=20 interaction with the CE in order to support the appearance of a = =20 Yang, et. al. Expires December 2002 [Page = 20] =0C Internet Draft ForCES Framework June 2002 = =20 =20 single functional device. Therefore, it is recommended that = SNMP=20 management agent be implemented by CEs and the SNMP messages = sent to=20 FEs be redirected to their CEs. This also requires that ForCES = In=20 certain conditions (e.g. CE/FE disconnection), it may be useful = to=20 allow SNMP to be used to diagnose and repair problems. However, = care=20 should be taken when exercising such mechanisms and guidelines = are=20 provided in [FORCES-REQ], Section 5, requirement #4.=20 =20 7. Summary=20 =20 This document defines an architectural framework for ForCES. It = identifies the relevant components for an ForCES network = element,=20 including (one or more) FEs, (one or more) CEs, FE manager=20 (optional), and CE manager (optional). It also identifies the=20 interaction among these components and discusses all the major=20 reference points. It is important to point out that, among all = the=20 reference points, only the interface between CEs and FEs is = within=20 the scope of ForCES. ForCES alone may not be enough to support = all=20 different NE configurations. However, we believe ForCES is the = most=20 important element in realizing the physical separation and=20 interoperability of CEs and FEs, and hence the first interface = that=20 ought to be standardized. Simple and useful configurations can = still=20 be implemented with only CE-FE interface standardized, e.g., = single=20 CE with full-meshed FEs and static configuration without the = need=20 for CE/FE managers.=20 =20 8. Security Considerations=20 =20 The security necessary across each reference point except Fp is = discussed throughout the document. In general, the physical=20 separation of two entities usually requires much stricter = security=20 measurement in place. For example, we pointed out in Section = 5.1=20 that authentication becomes necessary between CE manager and FE = manager, between CE and CE manager, between FE and FE manager = in=20 some configuration. The physical separation of CE and FE also=20 imposes serious security requirement for ForCES protocol. The=20 security requirements for reference point Fp (i.e., ForCES = protocol)=20 are discussed in detail in [FORCES-REQ] Section 8.=20 =20 9. Intellectual Property Right=20 =20 The authors are not aware of any intellectual property right = issues=20 pertaining to this document.=20 =20 10. Normative References=20 =20 [RFC2914] S. Floyd, "Congestion Control Principles", RFC2914,=20 September 2000.=20 =20 [RFC1157] J. Case, et. al., "A Simple Network Management = Protocol=20 (SNMP)", RFC1157, May 1990.=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 21] =0C Internet Draft ForCES Framework June 2002 = =20 =20 [RFC3084] K. Chan, et. al., "COPS Usage for Policy Provisioning = (COPS-PR)", RFC3084, March 2001.=20 =20 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers",=20 RFC1812, June 1995.=20 =20 11. Informative References=20 =20 [FORCES-REQ] T. Anderson, et. al., "Requirements for Separation = of=20 IP Control and Forwarding", work in progress, February 2002, = .=20 =20 [FORCES-APP] A. Crouch, et. al., "ForCES Applicability = Statement",=20 work in progress, February 2002, = .=20 =20 12. Acknowledgments=20 =20 Joel M. Halpern gave us many insightful comments and = suggestions and=20 pointed out several major issues. Many of our colleagues and = people=20 in the ForCES mailing list also provided valuable feedback,=20 including Alan Crouch, Patrick Droz, David Putzolu, Hormuzd M.=20 Khosravi, and Ryszard Dyrga.=20 =20 13. Authors' Addresses=20 =20 Lily L. Yang=20 Intel Labs=20 2111 NE 25th Avenue=20 Hillsboro, OR 97124 USA=20 Phone: +1 503 264 8813=20 Email: lily.l.yang@intel.com=20 =20 Ram Dantu=20 Netrake Corporation=20 3000 Technology Drive=20 Plano, Texas 75074=20 Phone: +1 214 291 1111=20 Email: ramd@netrake.com=20 =20 Todd A. Anderson=20 Intel Labs=20 2111 NE 25th Avenue=20 Hillsboro, OR 97124 USA=20 Phone: +1 503 712 1760=20 Email: todd.a.anderson@intel.com=20 =20 =20 =20 =20 1. = Abstract........................................................1=20 2. = Definitions.....................................................1=20 =20 Yang, et. al. Expires December 2002 [Page = 22] =0C Internet Draft ForCES Framework June 2002 = =20 =20 3. Introduction to Forwarding and Control Element Separation=20 = (ForCES)...........................................................3=20 4. = Architecture....................................................6=20 4.1. Control Elements and Fr Reference = Point....................7=20 4.2. Forwarding Elements and Fi reference = point.................8=20 4.3. CE = Managers...............................................10=20 4.4. FE = Managers...............................................11=20 5. Operational = Phases.............................................11=20 5.1. Pre-association = Phase.....................................11=20 5.1.1. Fl Reference = Point...................................11=20 5.1.2. Ff Reference = Point...................................12=20 5.1.3. Fc Reference = Point...................................12=20 5.2. Post-association Phase and Fp reference = point.............13=20 5.2.1. Proximity and Interconnect between CEs and = FEs.......13=20 5.2.2. Association = Establishment............................13=20 5.2.3. Steady-state = Communication...........................14=20 5.2.4. Data Packets across Fp reference = point...............15=20 5.2.5. Proxy = FE.............................................16=20 5.3. Association = Re-establishment..............................16=20 6. Applicability to = RFC1812.......................................17=20 6.1. General Router = Requirements...............................18=20 6.2. Link = Layer................................................19=20 6.3. Internet Layer = Protocols..................................19=20 6.4. Internet Layer = Forwarding.................................19=20 6.5. Transport = Layer...........................................20=20 6.6. Application Layer -- Routing = Protocols....................20=20 6.7. Application Layer -- Network Management = Protocol..........20=20 7. = Summary........................................................21=20 8. Security = Considerations........................................21=20 9. Intellectual Property = Right....................................21=20 10. Normative = References..........................................21=20 11. Informative = References........................................22=20 12. = Acknowledgments...............................................22=20 13. Authors' = Addresses............................................22=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 23] =0C ------_=_NextPart_000_01C21975.18212A90-- 2002 Message-Id: Date: Fri, 21 Jun 2002 15:29:38 -0700 From: "Yang, Lily L" Subject: individual contribution draft on ForCES FE model Comments: To: Internet-Drafts Administrator , "yangliuyang67@yahoo.com" , "Putzolu, David" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C21973.20D923B0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C21973.20D923B0 Content-Type: text/plain; charset="iso-8859-1" <> Here is an individual contribution draft on ForCES FE model. Please review and provide feedback. Thanks, Lily ------_=_NextPart_000_01C21973.20D923B0 Content-Type: text/plain; name="draft-yang-forces-model-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-yang-forces-model-00.txt" Internet Draft L. Yang=20 Expiration: December 2002 Intel Labs=20 File: draft-yang-forces-model-00.txt J. Halpern=20 Working Group: ForCES =20 R. Gopal=20 Nokia=20 R. Dantu=20 Netrake=20 June 2002=20 = =20 =20 =20 ForCES Forwarding Element Functional Model=20 =20 =20 =20 draft-yang-forces-model-00.txt=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance = with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are=20 working documents of the Internet Engineering Task Force = (IETF), its=20 areas, and its working groups. Note that other groups may also = distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other = documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as ``work in=20 progress.''=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed = at =20 http://www.ietf.org/shadow.html.=20 =20 Conventions used in this document =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in=20 this document are to be interpreted as described in [RFC-2119]. = =20 1. Abstract=20 This document defines a functional model for ForCES forwarding=20 elements (FEs). This model is used to describe the state of = ForCES=20 forwarding elements within the context of the ForCES protocol, = so=20 that ForCES control elements (CEs) can control the FEs = accordingly.=20 The model is to specify what logical function instances are = present=20 in the FEs and in what order these functions are performed. The = =20 =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 forwarding element model defined herein is intended to satisfy = the=20 requirements specified in the ForCES requirements draft = [FORCES- REQ]. Using this model, predefined or vendor specific logical=20 functions can be expressed and configured. However, the = definition=20 of these components are not described and defined in this = document.=20 Definitions=20 =20 A set of terminology associated with the ForCES requirements is = defined in [FORCES-REQ] and is not copied here. The following = list=20 of terminology is relevant to the FE model defined in this = document.=20 =20 Datapath -- A conceptual path taken by packets within the = forwarding=20 plane, inside an FE. There might exist more than one datapath = within=20 an FE.=20 =20 Forwarding Element (FE) Block -- An abstraction of the basic = packet=20 processing functions in the datapath. It is the building block = of FE=20 functionality. This concept abstracts away implementation = details=20 from the parameters of interest for configuration, control and=20 management by CE. The general rule of thumb on the granularity = of FE=20 blocks is that FE blocks should be coarse grained, stateful and = focus on a particular domain. For example, RFC1812 compliant = IPv4=20 forwarder, classifiers, meters, etc.. =20 =20 Forwarding Element (FE) Stage -- Representation of a FE block=20 instance in a FE's datapath. As a packet flows through an FE = along a=20 datapath, it flows through one or multiple distinct stages, = with=20 each stage implementing an instance of a certain logical = function.=20 There may be one or more combination of such instances in a = FE's=20 datapath. Using NAT as an example, one NAT function is = typically=20 performed before the forwarding stage (packets arriving = externally=20 have their public addresses replaced with private addresses) = and one=20 NAT function is performed after (for packets exiting the = domain,=20 their private addresses are replaced by public ones). So there = are=20 three stages (NAT, forwarding, and NAT again) in this example = FE,=20 with two NAT instances present in two different stages. =20 =20 2. Motivation and Requirements of FE model=20 =20 The ForCES architecture allows Forwarding Elements (FEs) of = varying=20 functionality to participate in a ForCES network element (NE). = The=20 implication of this varying functionality is that CEs can make = only=20 minimal assumptions about the functionality provided by its = FEs. =20 Before CEs can configure and control the forwarding behavior of = FEs,=20 CEs need to query and discover the capabilities and state of = their=20 FEs. [FORCES-REQ] mandates that this capability and state=20 information be expressed in the form of a FE model, and this = model=20 will be used as the basis for CEs to control FEs' capabilities = and=20 manipulate FEs' state via ForCES protocol. =20 =20 [FORCES-REQ] describes all the requirements placed on the FE = model=20 in detail. We provide a brief summary here to highlight some of = the=20 design issues we face. =20 =20 Yang, et. al. Expires December 2002 [Page = 2] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 . The FE model MUST express what logical functions can be = applied=20 to packets as they pass through a FE.=20 . The FE model MUST be capable of supporting/allowing = variations=20 in the way logical functions are implemented on a FE. =20 . The model MUST be capable of describing the order in which=20 these logical functions are applied in a FE. =20 . The FE model SHOULD be extendable and should have provision = to=20 express new or vendor specific logical functions. . =20 . Should be able to support minimal set of logical functions = that are already identified such as port functions,=20 forwarding functions, QoS functions, filtering functions, = high- touch functions, security functions, and vendor-specific=20 functions. =20 =20 Since the motivation of an FE model is to allow CEs later to = control=20 and configure FEs' behavior via ForCES protocol, it becomes=20 essential to examine and understand what kind of control and=20 configuration CEs might do to FEs. We believe that there are = roughly=20 three levels of control and configuration that CEs can do to = FEs. =20 =20 The first level of control and configuration is the simplest of = all.=20 It assumes that each FE's capability is already given and = remains=20 static in its lifetime, and CEs can only control its behavior = by=20 manipulating its state. We call this "static FE" control and=20 configuration. For example, Figure 2 and 3 each shows an FE=20 configuration example by representing the processing steps in a = directed graph interconnecting all the functional stages that=20 packets can possibly traverse. If such a configuration remains=20 static during FE's lifetime, then all CE can control is the=20 parameters associated with each stage in the graph, for = example, the=20 routing table in the LPM forwarder in Figure 2, or the token = bucket=20 parameters associated with meter1 in Figure 3. But CE cannot=20 reconfigure the graph topology dynamically, such as adding = another=20 meter or queue onto the FE in Figure 3 on the fly. For this = kind of=20 static FE control and configuration purpose, the useful FE = model is=20 consisted of the state information that FEs allow CEs to = manipulate=20 and the statistics and events that FEs can collect and report = back=20 to CEs. Such a state model doesn't need to describe a lot of = other=20 information, like the packet formats supported between meter1 = and=20 counter1 in Figure 3, for example. Because such information is = only=20 useful when the graph is re-configured dynamically on the fly. = =20 =20 The second level of control and configuration builds on top of = the=20 first that is just described. Using Figure 3 as an example, = instead=20 of presenting the static FE graph to CE, FE can convey its=20 capabilities to CE by telling CE that "This FE can support one=20 classifier with up to N filters. This FE can also support M = meters,=20 X queues, etc." We call this dynamic FE control and = configuration.=20 For such control and configuration, a more powerful and = flexible FE=20 capability model is required in addition to the FE state model. = For=20 example, it becomes necessary to model the capability of the=20 building blocks like classifiers, filters, meters etc. it also = needs=20 =20 Yang, et. al. Expires December 2002 [Page = 3] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 to describe the packet formats supported at each input and = output of=20 each block to allow correct reconfiguration of the graph by CE. = =20 =20 The third level of control and configuration is even more = powerful=20 and future looking. In addition to dynamic configuration, CEs = might=20 even be allowed to download a given functionality onto FEs at = run=20 time.=20 The FE model proposed in this document intends to fully support = the=20 static FE control and configuration. It is also our intention = to=20 allow extension later to support dynamic FE control and=20 configuration. However, this FE model currently makes no = attempt to=20 address issues beyond the simple static FE control and=20 configuration.=20 =20 3. Capability and configuration Model versus State Model=20 =20 FE Model describes both the static capabilities and the = configured=20 capabilities. At any time after initial configuration the = logical=20 functions associated with an FE model may exhibit different=20 characteristics and may lead to change in state of FE. The=20 capability describes set of parameters or attributes of one or = more =20 logical functions of a FE, which may be useful for configuring = and=20 managing a FE. The state model describes the instantaneous = values or=20 operational behaviour of a FE.=20 Typical capabilities model describes at the coarsest level = such=20 aspects as=20 - this FE can handle IPv4 and IPv6=20 - this FE can perform 6-tuple classification (or can only do DA = based processing, ...)=20 - this FE can perform metering=20 - this FE can handle multiple queues with multiple priorities=20 - this FE can add and remove encapsulating headers of types: = IPSec,=20 GRE, L2TP=20 =20 Where it gets more complicated is coping with the detailed = limits. =20 Issues such has how many classifiers can the FE handle? =20 How many headers can the FE add and remove? How many queues, = and=20 how many buffer pools can the FE support? How many meters can = the=20 FE provide? How flexibly can these various parts be = interconnected?=20 While one could try to build an object model for representing=20 capabilities in full, other efforts have found this to be a=20 significant undertaking. A middle of the road approach is to = define=20 coarse-grained capabilities and simple capacity measures. = Then, if=20 the CE attempts to instruct the FE to set up some specific = behavior=20 it is not capable of, the FE will return an error indicating = the=20 problem.=20 =20 A state model describes the current state of the FE. It lists=20 - on a given port the packets are classified using a given=20 classification filter=20 - a given classifier results in packets being metered in a = certain=20 way, and then marked in a certain way=20 =20 Yang, et. al. Expires December 2002 [Page = 4] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 - packets coming from specific markers are delivered into a = shared=20 queue for handling, while other packets are delivered to a = different=20 queue=20 - a specific scheduler with specific behavior and parameters = will=20 service these collected queues.=20 =20 While the DiffServ and QDDIM models are not designed with the=20 primary goal of direct machine implementation, we will start = with=20 that model as it is better than no starting point. Alternative = suggestions for a state model which can be implemented more=20 generally without significant transformation are sought from = the=20 community.=20 =20 4. FE Model=20 =20 This section proposes a ForCES FE model to satisfy all the=20 requirements in [FORCES-REQ] for FE control and configuration. = The=20 approach taken is to first define a set of well-known FE = logical=20 functions (FE blocks) as the basic building blocks, so that any = FE=20 can be modeled by describing the kind of FE blocks or variants = of=20 these blocks it contains, and how the instances of these blocks = are=20 interconnected together. This model also allows new logical=20 functions be added to accommodate future innovation in = forwarding=20 plane. We believe this approach strikes a good balance between=20 flexibility and extensibility of the model and ease of use by = the=20 CE. =20 =20 4.1. FE Blocks=20 =20 FE blocks are the very basic building blocks from which FEs = model=20 its overall packet processing behavior. The concept of a FE = block is=20 akin to that of an abstract base class in object-oriented=20 terminology. Different FEs can have different implementation of = the=20 same block, but the packet processing behavior looks the same = to the=20 CE. Sometimes it is difficult to decide the granularity of the = FE=20 blocks. The general rule of thumb is that FE blocks should be = coarse=20 grained, stateful and focus on a particular domain. Basically, = if a=20 logical function doesn=92t have anything to configure, = doesn=92t keep=20 any kind of inter-packet state information (tables, etc), then = it=20 probably is not a FE block. For example, CRC check and IP = checksum=20 are not considered to be FE blocks by themselves, instead = should be=20 part of an FE block (i.e. RFC 1812 IP forwarder).=20 =20 A well-defined block has a well-defined packet processing = behavior,=20 and a well-defined set of state and parameters that CE can=20 potentially configure or control via ForCES. =20 =20 Obviously, a namespace is needed to specify different blocks. = The=20 namespace assigns a unique ID or label to each distinct block = type. =20 =20 For each block, it is necessary to specify the relevant = information=20 and parameters such as:=20 =20 Yang, et. al. Expires December 2002 [Page = 5] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 - how many inputs it takes and what kinds of packets and meta = data=20 it takes for each input;=20 - how many outputs it produces and what kind of packets and = meta=20 data it emits for each output and;=20 - the packet processing (such as modification) behavior;=20 - what information is programmed into it (e.g., LPM list, next = hop=20 list, WRED parameters, etc.) and what parameters among them are = configurable; =20 - what statistics it keeps (e.g., drop count, CRC error count,=20 etc.); =20 - what events it can throw (e.g., table miss, port down, etc.). = =20 CEs later use the information to decide how to configure the=20 parameters, how to modify the relevant data structures (like=20 tables), what kind of statistics it can query from FE, and what = actions to take once a certain event happens.=20 =20 We use the classifier defined in [DS-MODEL] as an example.=20 "Classifiers are 1:N(fan-out) devices: they take a single = traffic=20 stream as input and generate N logically separate traffic = streams as=20 output. Classifiers are parameterized by filters and output = streams.=20 Packets from the input stream are sorted into various output = streams=20 by filters which match the contents of the packet or possibly = match=20 other attributes associated with the packet." To further define = filters: "A filter consists of a set of conditions on the = component=20 values of a packet's classification key (the header values,=20 contents, and attributes relevant for classification)." Figure = 1=20 illustrates an example classifier.=20 =20 =20 Unclassified classified=20 traffic traffic=20 +------------+=20 | |--> match Filter1 --> OutputA=20 ------->| classifier |--> match Filter2 --> OutputB=20 | |--> no match --> OutputC=20 +------------+=20 =20 Figure 1. An Example Classifier=20 =20 4.2.FE Block Library=20 =20 We expect a small set of blocks to be defined initially, e.g.,=20 ingress port, egress port, classifier, forwarder, meter, = marker,=20 shaper, scheduler, queue, encapsulator, decapsulator, = encrypter,=20 decrypter, NAT, mux, demux, header compressor, header = decompressor,=20 etc. Such a set of blocks can be viewed as a FE block library. = The=20 minimum set of FE functions required in [FORCES_REQ] must be = part of=20 this library. It is expected that new FE blocks would be = defined and=20 added into this library over time. It is also expected that the = FE=20 model itself be decoupled from the ForCES protocol so that = extension=20 =20 Yang, et. al. Expires December 2002 [Page = 6] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 to basic blocks or changes to the existing blocks should not=20 impact the protocol itself. =20 =20 This document only intends to describe the conceptual FE model = and=20 illustrate it with some examples. However, it is not the = intention=20 of this document to define any specific block or the library = itself.=20 Separate document(s) would be written to achieve that. =20 =20 4.3. FE Stage=20 =20 As a packet flows through an FE along a datapath, it flows = through=20 one or multiple distinct stages, with each stage instantiating = a=20 certain FE logical function. So an FE stage is simply an = instance of=20 a FE block within an FE's datapath. Each FE allocates a = FE-unique=20 stage ID or label to each of its stages and passes the stage ID = or=20 label along with the corresponding block name as part of the FE = model description. This allows multiple instances of the same = block=20 present in a FE's datapath. =20 =20 For each stage, the following information must be defined:=20 - its FE-unique stage ID or label to identify, configure and = manage=20 the logical block of each by CE.;=20 - the corresponding block name (from the namespace) that this = stage=20 instantiating;=20 - all the information for this stage as described in Section = 5.1;=20 - the number of downstream stages to which this stage can send=20 packets;=20 - for each downstream stage: its stage ID or label.=20 =20 4.4. Directed Graph of FE Blocks=20 =20 Once a library of well-understood FE blocks is defined, and a = stage=20 is represented as described in 5.3, any static FE can be = modeled by=20 a directed graph interconnecting all the stages present in the = FE.=20 The static FEs can be defined by identifying all the input = stage(s)=20 and specifying each stage as described in Section 5.3. Figure 2 = shows one simple example of such an FE with three stages. =20 =20 To model a static FE, the following information needs to be=20 represented:=20 - number of stages in the FE;=20 - for each stage: define the stage using the model in 5.3;=20 - identify the input stages=20 =20 It is frequently necessary to share state between FE functional = stages in the forwarding plane. Since this model uses blocks as = the=20 basic way of modeling forwarding plane packet processing = stages, the=20 state information is exposed as part of connecting stage. For=20 example in Figure 2, stage #2 (IPv4 L3 LPM Forwarder) generates = some=20 meta data at its output to carry information on which port the=20 packets should go to, and #3 (Enet-Egress-port-Manager) uses = this=20 meta data to direct the packets to the right egress port.=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 7] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 =20 +------------+ +------------+ +------------+=20 input | Ethernet | | | | Ethernet = |output=20 ------->| Ingress |-->| IPv4 L3 LPM|-->| Egress = |----->=20 | Port Mgr | | Forwarder | | Port Mgr |=20 +------------+ +------------+ +------------+=20 =20 {stage ID=3D1, {stage ID=3D2, {stage = ID=3D3,=20 function=3D function=3D = function=3D=20 Enet-Ing-port, IPv4-L3-LPM-fwd, = Enet-Eg-port-Mgr,=20 #downstream=3D1, #downstream=3D1, = #downstream=3D1,=20 downstream=3D{2} downstream=3D{3} = downstream=3Dnone=20 } } }=20 =20 Figure 2. A very simple example of a static FE.=20 =20 =20 Queue1=20 +---+ +--+=20 | A|------------------->| |--+=20 +->| | | | |=20 | | B|--+ +--+ +--+ +--+ |=20 | +---+ | | | | | |=20 | Meter1 +->| |-->| | |=20 | | | | | |=20 | +--+ +--+ |=20 | Counter1 Absolute Queue2| +--+=20 +---+ | Dropper1 +--+ +--->|A |=20 | A|---+ | |------>|B |=20 -------->| B|------------------------------>| | +--->|C = |------>=20 | C|---+ +--+ | +->|D |=20 | X|-+ | | | +--+=20 +---+ | | +---+ +---+ Queue3| | = Scheduler=20 Classifier1 | | | A|------------>|A | +--+ | |=20 | +->| | | |->| |--+ |=20 | | B|--+ +--+ +->|B | | | |=20 | +---+ | | | | +---+ +--+ |=20 | Meter2 +->| |-+ Mux1 |=20 | | | |=20 | +--+ Queue4 |=20 | Marker1 +--+ |=20 +---------------------------->| |----+ =20 | |=20 +--+=20 =20 Figure 3. An FE example with multiple datapath.=20 =20 =20 There might be more than one datapath within an FE, typically = due to=20 blocks that are either 1:N or N:1. Figure 3 shows one such FE = block=20 example (based on an example in [MD-MODEL]). This FE implements = QoS=20 functions via combination of one or multiple instances of = logical=20 functions like classifier, meter, marker, queue, scheduler, = etc.=20 =20 Yang, et. al. Expires December 2002 [Page = 8] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 Some of the functions are 1:N (fan-out_ functions. For example, = the=20 stage labeled "Classifier1" is 1:4 function with four = downstream=20 stages, namely, Meter1, Queue2, Meter2, Queue4. A packet = entering=20 this FE can potentially take one of the six distinct datapath. = =20 Note that our stage representation can encode largely arbitrary = topologies of the stages. The only restrictions on topology = relate=20 to the source and sink nature of ingress and egress port = functions=20 respectively. For example, egress port functions must not have = nay=20 downstream stages whereas no other stage may refer to an = ingress=20 port function as one of its downstream stages. =20 =20 An FE block may contain zero, one or more ingress port stages.=20 Similarly, an FE block may contain zero, one or more egress = port=20 stages. In another word, not every FE block has to contain any=20 ingress port or egress port stages. For example, Figure 4 shows = two=20 FE blocks. Block #1 contains one ingress port function but no = egress=20 port function, while block #2 contains one egress port function = but=20 no ingress port function. It is possible to connect these two = FE=20 blocks together to achieve the complete ingress-to-egress = packet=20 processing function. This provides the flexibility to spread = the=20 functions across multiple FEs and interconnect them together = later=20 for certain applications. Figure 4 shows such an example.=20 =20 -------------------------------------------------------=20 | +---------+ +------------+ +---------+ |=20 input| | | | | | output |=20 ---+->| Ingress |-->|Header |-->|IPv4 = |---------+--->--+=20 | | port | |Decompressor| |Forwarder| FE | | = | +---------+ +------------+ +---------+ Block #1| | = ------------------------------------------------------| V = | = +-----------------------<-----------------------------+ = | =20 | |-----------------------------------------=20 V | +------------+ +----------+ |=20 | input | | | | output | = =20 +->--+->|Header |-->| Egress |---------+-->=20 | |Compressor | | port | FE |=20 | +------------+ +----------+ Block #2|=20 -----------------------------------------|=20 =20 =20 Figure 4. An example of two different FE blocks connected = together.=20 =20 5. Model Representation=20 =20 A formal data definition language is needed to represent the FE = model described in this document. The following is a list of = some=20 potential candidates. A suitable candidate needs to be chosen = as the=20 representation of FE model. However, we intend to leave this as = an=20 open issue and much debate is needed in the ForCES WG before a=20 =20 Yang, et. al. Expires December 2002 [Page = 9] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 decision can be made. Therefore, we only provide the candidate = list=20 and some initial discussion here without drawing a conclusion = yet.=20 - XML (Extensible Markup Language) Schema=20 - ASN.1 (Abstract Syntax Notation One)=20 - SMI (Structure of Management Information) [RFC1155]=20 - SPPI (Structure of Policy Provisioning Information) [RFC3159] = - SMIng (Next Generation Structure of Management Information)=20 - UML (Universal Modeling Language)=20 =20 XML has the advantage of being human readable with relatively = little=20 effort. However, it is less efficient and requires XML parsing=20 functions in the CE and FE. Currently XML is not widely = deployed and=20 used in network elements. =20 =20 ASN.1 format is human readable, and widely used in network=20 protocols. SMI is based on a subset of ASN.1 and used to define = Management Information Base (MIB) for SNMP. SPPI is the adapted = subset of SMI used to define Policy Information Base (PIB) for = COPS.=20 SMIng is currently being developed by SMIng working group at = IETF=20 and represents a superset of SMIv2 and SPPI. The objective of = SMIng=20 is to replace both SMIv2 and SPPI with a single, updated = language as=20 the data definition language for the monitoring, configuration, = and=20 provisioning of network devices. =20 =20 =20 6. Security Considerations=20 =20 The FE model just describes the representation and organization = of=20 data sets and attributes in the forwarding plane. There is no=20 communication protocol associated defined as part of the FE = model=20 therefore we do not see any security threats in this model.=20 =20 7. Intellectual Property Right=20 =20 The authors are not aware of any intellectual property right = issues=20 pertaining to this document.=20 =20 8. IANA consideration=20 =20 =20 If we are going to identify and name a new logical components = we may=20 need to standardize those components and the attributes. =20 =20 =20 9. Normative References=20 =20 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers",=20 RFC1812, June 1995.=20 =20 [RFC1155] M. Rose, et. al., "Structure and Identification of=20 Management Informationfor TCP/IP-based Internets", = May=20 1990.=20 =20 Yang, et. al. Expires December 2002 [Page = 10] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 =20 =20 [RFC3159] K. McCloghrie, et. al., "Structure of Policy = Provisioning=20 Information (SPPI)", August 2001.=20 =20 10. Informative References=20 =20 [FORCES-REQ] T. Anderson, et. al., "Requirements for Separation = of=20 IP Control and Forwarding", work in progress, April = 2002,=20 .=20 =20 [GOPAL-MODEL] R. Gopal, "Forwarding Element Model", work in=20 progress, February 2002, = .=20 =20 [ANDERSON-MODEL] T. Anderson, "ForCES Architectural Framework = and FE=20 Functional Model", work in progress, November 2001,=20 .=20 =20 [DS-MODEL] Y. Bernet, et. al., "An Informal Management Model = for=20 Diffserv Routers", work in progress, February 2001,=20 .=20 =20 11. Acknowledgments=20 =20 This document draws heavily from the concepts presented in = [GOPAL- MODEL], [ANDERSON-MODEL] and [DS-MODEL]. In addition to the = authors=20 of these documents, the authors would also like to thank the=20 following individuals for their invaluable technical input: = David=20 Putzolu, Hormuzd Khosravi, Eric Johnson, David Durham, Andrzej=20 Matejko.=20 =20 12. Authors' Addresses=20 =20 Lily L. Yang=20 Intel Labs=20 2111 NE 25th Avenue=20 Hillsboro, OR 97124 USA=20 Phone: +1 503 264 8813=20 Email: lily.l.yang@intel.com=20 =20 Joel Halpern=20 P.O.Box 6049=20 Leesburg, VA 20178=20 Phone: +1 703 371 3043=20 Email: jmh@joelhalpern.com=20 =20 Ram Gopal=20 Nokia Research Center=20 5, Wayside Road,=20 =20 Yang, et. al. Expires December 2002 [Page = 11] =0C Internet Draft ForCES FE Functional Model June = 2002=20 =20 =20 Burlington, MA 01803=20 Phone: +1 781 993 3685=20 Email: ram.gopal@nokia.com=20 =20 Ram Dantu=20 Netrake Corporation =20 3000 Technology Drive =20 Plano, Texas 75074 =20 Phone: +1 214 291 1111 =20 Email: ramd@netrake.com=20 =20 1. = Abstract........................................................1=20 2. Motivation and Requirements of FE = model.........................2=20 3. Capability and configuration Model versus State = Model...........4=20 4. FE = Model........................................................5=20 4.1. FE = Blocks..................................................5=20 4.2. FE Block = Library...........................................6=20 4.3. FE = Stage...................................................7=20 4.4. Directed Graph of FE = Blocks................................7=20 5. Model = Representation............................................9=20 6. Security = Considerations........................................10=20 7. Intellectual Property = Right....................................10=20 8. IANA = consideration.............................................10=20 9. Normative = References...........................................10=20 10. Informative = References........................................11=20 11. = Acknowledgments...............................................11=20 12. Authors' = Addresses............................................11=20 =20 =20 Yang, et. al. Expires December 2002 [Page = 12] =0C ------_=_NextPart_000_01C21973.20D923B0-- 2002 Message-Id: Date: Fri, 21 Jun 2002 07:35:53 -0400 Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-applicability-00.txt Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Applicability Statement Author(s) : A. Crouch, M. Handley Filename : draft-ietf-forces-applicability-00.txt Pages : 9 Date : 20-Jun-02 The ForCES protocol defines a standard framework and mechanism for the interconnection between Control Elements and Forwarding Engines in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-applicability-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-applicability-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-applicability-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020620141419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-applicability-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-applicability-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020620141419.I-D@ietf.org> --OtherAccess-- --NextPart-- 2002 Message-Id: Date: Thu, 20 Jun 2002 11:56:01 -0700 From: "Putzolu, David" Subject: Framework document accepted as WG doc MIME-Version: 1.0 Content-Type: text/plain All, Thank you for the feedback. There is consensus that draft-anderson-forces-arch-01.txt should be accepted as a working group document and be the basis for the following charter deliverable: o An architectural framework defining the entities comprising a ForCES network element and identifying the interactions between them. This document remains an Internet Draft and is subject to change based on the feedback and guidance of the working group. I have asked the authors to submit it as a working group document and it will proceed and evolve with that status. Cheers, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > Sent: Thursday, June 13, 2002 10:45 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Accept Framework individual contrib as WG doc? > Importance: High > > > All, > > There was not sufficient feedback to the prior > request to determine if there is consensus. > > Please indicate whether you feel that the following > draft is ready to become a working group document: > > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > > Thanks, > David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework defining the > > entities comprising a ForCES network element and identifying the > > interactions between them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> > > anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments > on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > > 2002 Message-Id: Date: Wed, 19 Jun 2002 21:10:01 -0400 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Comment on ForCES Requirements draft: FEs and off-loadofsignalingfunctions Comments: To: Robert Haas MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpSb2JlcnQsDQpQbGVhc2UgY29tZSB1cCB3aXRoIHRoZSBhcHByb3ByaWF0ZSB0ZXh0Lg0KDQpj aGVlcnMsDQpqYW1hbA0KDQpPbiBUdWVzZGF5IDE4IEp1bmUgMjAwMiAxMjowNywgUm9iZXJ0IEhh YXMgd3JvdGU6DQo+IEphbWFsLA0KPiBNeSBjb25jZXJuIGlzIHRoZSBsaW1pdGF0aW9uIG9mIHRo ZSBzY29wZSBvZiBGRXMgY2FwYWJpbGl0aWVzIHRvIHdoYXRldmVyDQo+IGNhbiBiZSBkb25lIHRv ICJ0aGUgcGFja2V0IGFzIGl0IHBhc3NlcyB0aHJvdWdoIHRoZSBGRSIsIGFzIHRoZSBkcmFmdA0K PiBtZW50aW9ucyBpdCByZXBlYXRlZGx5Lg0KPiBJZiB0aGVyZSBhcmUgb3RoZXIgY2FwYWJpbGl0 aWVzIHBsYW5uZWQgZm9yIEZvckNFUyBiZXNpZGVzIEZvcndhcmRpbmcrUW9TLA0KPiB0aGVuIHRo ZSByZXF1aXJlbWVudHMgZHJhZnQgc2hvdWxkIGF2b2lkIGJlaW5nIHNvIHJlc3RyaWN0aXZlLCBJ TUhPLiBUaGUNCj4gVENQIHRlcm1pbmF0aW9uIGJlaW5nIGp1c3Qgb25lIGV4YW1wbGUgb3V0IG9m IHRvZGF5J3MgRkVzIGNhcGFiaWxpdGllcyB0aGF0DQo+IGdvIGJleW9uZCB0aGUgY3VycmVudCBz Y29wZSwgYXMgSSB1bmRlcnN0YW5kIG5vdy4NCj4NCj4gSWYgeW91IHRoaW5rIGl0J3MgYWNjZXB0 YWJsZSwgdGhlbiBJJ2xsIHRyeSB0byBjb21lIHVwIHdpdGggYSBjb25jcmV0ZQ0KPiBzdWdnZXN0 aW9uIGhvdyB0byBmb3JtdWxhdGUgdGhpcywgdGhhdCB5b3UgY291bGQgdGhlbiBjb25zaWRlciBp bmNsdWRpbmcgaW4NCj4gdGhlIGRyYWZ0Lg0KPg0KPiBDaGVlcnMsDQo+IC1Sb2JlcnQNCj4NCj4g SmFtYWwgSGFkaSBTYWxpbSB3cm90ZToNCj4gPiBPbiBNb25kYXkgMTAgSnVuZSAyMDAyIDE1OjM0 LCBSb2JlcnQgSGFhcyB3cm90ZToNCj4gPiA+IEphbWFsIEhhZGkgU2FsaW0gd3JvdGU6DQo+ID4g PiA+IE9uIE1vbiwgMTAgSnVuIDIwMDIsIFJvYmVydCBIYWFzIHdyb3RlOg0KPiA+ID4gPiA+IEph bWFsLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBMZXQg bWUgY2xhcmlmeTogdGhlIFJlcXVpcmVtZW50cyBkcmFmdA0KPiA+ID4gPiA+IGxpbWl0cyB0aGUg RkUgbW9kZWwgdG8gZXhwcmVzcyB3aGF0IGxvZ2ljYWwgZnVuY3Rpb25zIGNhbiBiZQ0KPiA+ID4g PiA+IGFwcGxpZWQgdG8gcGFja2V0cyAiYXMgdGhleSBwYXNzIHRocm91Z2ggdGhlIEZFIiAoc2Vl IHNlY3QuIDYuMSkuDQo+ID4gPiA+ID4gIkhpZ2gtVG91Y2giIGlzIGRlZmluZWQgYXMgYSBjYXRl Z29yeSBvZiBzdWNoIGxvZ2ljYWwgZnVuY3Rpb25zLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSW4g bXkgb3BpbmlvbiwgdGhpcyBtb2RlbCBydWxlcyBvdXQgZnVuY3Rpb25zIHN1Y2ggYXMgVENQDQo+ ID4gPiA+ID4gdGVybWluYXRpb24sIHRoYXQgcmVxdWlyZSBwcm9jZXNzaW5nIG5vdCBvbmx5IGFz IGEgcGFja2V0ICJwYXNzZXMNCj4gPiA+ID4gPiB0aHJvdWdoIHRoZSBGRSIgKGZvciBpbnN0YW5j ZSwgaGFuZGxpbmcgdGltZXJzKS4gRnVuY3Rpb25zIHN1Y2ggYXMNCj4gPiA+ID4gPiBUQ1AgdGVy bWluYXRpb24gYXJlIHVzdWFsbHkgcGVyZm9ybWVkIGJ5IHRoZSBDRSBhbmQgY291bGQgYmUNCj4g PiA+ID4gPiAib2ZmLWxvYWRlZCIgaW50byB0aGUgRkVzIGZvciBwZXJmb3JtYW5jZSByZWFzb25z Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlcmVmb3JlLCBpdCBzZWVtcyB0byBtZSB0aGF0IHRo aXMgaXNzdWUgaXMgbm90IGEgbmFtaW5nIGlzc3VlLA0KPiA+ID4gPiA+IGJ1dCByYXRoZXIgYSBk ZXNpZ24gY2hvaWNlIGRlZmluaW5nIHdoYXQgdGhlIEZFIG1vZGVsIG11c3QgaW5jbHVkZQ0KPiA+ ID4gPiA+IG9yIG5vdC4gRG8geW91IGFncmVlID8NCj4gPiA+ID4NCj4gPiA+ID4gSXQgZGVwZW5k cyBvbiBob3cgeW91IGxvb2sgYXQgaXQuIEFuZCBpdCBkb2VzIGJlY29tZSBhIGRlc2lnbiBpc3N1 ZSwNCj4gPiA+ID4gYnV0IHRoZSBtb2RlbCBkb2VzbnQgc3RvcCB5b3U7DQo+ID4gPiA+IGxldHMg dGFrZSBUQ1AgdGVybWluYXRpb24sIGZvciBleGFtcGxlOg0KPiA+ID4gPiBJIHdvdWxkIHRoaW5r IHRoYXQgdGhlIHNldHVwIHBoYXNlIHdoZXJlIHRoZSBzcGxpY2luZyBpcyBiZWluZyBzZXQgdXAN Cj4gPiA+ID4gaXMgYSBjb250cm9sIHBsYW5lIGFjdGl2aXR5LiBTbyBpcyB0aGUgdGVybWluYXRp b24uIFdpdGggdGhlIGN1cnJlbnQNCj4gPiA+ID4gbW9kZWwgeW91IGNvdWxkIHJlZGlyZWN0IHNw ZWNpZmljIHBhY2tldHMgdG8gdGhlIGNvbnRyb2wgcGxhbmUgKGVnIGluDQo+ID4gPiA+IHRoaXMg Y2FzZSwgSWYgaSB1bmRlcnN0b29kIGNvcnJlY3RseSwgd291bGQgYmUgU1lOL0ZJTiBwYWNrZXRz KS4NCj4gPiA+ID4gQWN0aXZpdHkgYWZ0ZXIgdGhlIGNvbm5lY3Rpb24gaXMgIm5haWxlZCIgc2Vl bXMgdG8gbWUgYmVsb25ncyB0byB0aGUNCj4gPiA+ID4gRkUgKHN1Y2ggYXMgbXVuZ2luZyB0aGUg QUNLcyBhbmQgc3BsaWNpbmcpLg0KPiA+ID4gPiBPbiB0aGUgc2FtZSB0b2tlbiwgdGltZXJzIHRv IGdlbmVyYXRlIEZFIGV2ZW50cyBzZWVtIHRvIG1lIGFsc28gdG8gYmUNCj4gPiA+ID4gY29udHJv bCBhY3Rpdml0eS4NCj4gPiA+ID4gRGlkIGkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5Pw0KPiA+ ID4NCj4gPiA+IExldCdzIHNlZToNCj4gPiA+DQo+ID4gPiBUQ1Agc3BsaWNpbmcsIGFmdGVyIHRo ZSBzZXR1cCBwaGFzZSwgYm9pbHMgZG93biB0byBjb252ZXJ0aW5nIHNlcXVlbmNlDQo+ID4gPiBu dW1iZXJzIGJhY2sgYW5kIGZvcnRoLCBhbmQgdGhpcyBpcyBpbmRlZWQgYSBmdW5jdGlvbiB0aGF0 IHRha2VzIHBsYWNlDQo+ID4gPiAiYXMgcGFja2V0cyBwYXNzIHRocm91Z2ggdGhlIEZFIi4gQW4g aWRlYWwgY2FuZGlkYXRlIGZvciBhICJIaWdoLVRvdWNoDQo+ID4gPiBGdW5jdGlvbiIuDQo+ID4g Pg0KPiA+ID4gQnV0IHdoYXQgaWYgSSdkIGxpa2UgdG8gaGF2ZSBzb21lIHNvcnQgb2YgY29udHJv bCBhY3Rpdml0eSB0YWtlIHBsYWNlDQo+ID4gPiBpbiB0aGUgRkUgYXMgd2VsbCwgc3VjaCBhcyBU Q1Agc2V0dXAgb3IgdGltZXJzIGhhbmRsaW5nID8gIFRoZSByZWFzb24NCj4gPiA+IGlzIHRvIGF2 b2lkIG92ZXJsb2FkaW5nIHRoZSBDRSB3aXRoIFRDUCBwcm9jZXNzaW5nLCBpZiB0aGUgRkVzIGFy ZQ0KPiA+ID4gc21hcnQgZW5vdWdoIHRvIGhhbmRsZSB0aGlzIGRpcmVjdGx5LiBUaGlzIGdvZXMg YmV5b25kIHRoZSBjdXJyZW50IEZFDQo+ID4gPiBtb2RlbC4NCj4gPiA+DQo+ID4gPiBEbyB5b3Ug YWxzbyB0aGluayB0aGF0IHNvbWUgc29ydCBvZiBjb250cm9sIGFjdGl2aXR5IHNob3VsZCBiZSBh bGxvd2VkDQo+ID4gPiB0byBiZSAib2ZmLWxvYWRlZCIgaW50byB0aGUgRkVzID8NCj4gPg0KPiA+ IFJvYmVydCwNCj4gPiBJIHRoaW5rIGl0IHdvdWxkIGJlIHdyb25nIHRvIGxpbWl0IHdoYXQgZnVu Y3Rpb25hbGl0eSBnb2VzIG9udG8gdGhlIEZFLiBJDQo+ID4gd29ya2VkIG9uIHRoZSByZXF1aXJl bWVudHMgdGVhbSBhbmQgdHJpZWQgaGFyZCB0byBtYWtlIHN1cmUgdGhpcyBpcw0KPiA+IGNsZWFy Lg0KPiA+DQo+ID4NCj4gPiBJZiB5b3UgZmluZCB0aGF0IHRoaXMgaXMgbm90IHJlZmxlY3RlZCBw cm9wZXJseSwgaSB0aGluayBpdCBzaG91bGQgYmUNCj4gPiBjbGFyaWZpZWQuDQo+ID4NCj4gPiBJ IGNhbnQgcmVtZW1iZXIgd2hvIGNhbWUgdXAgd2l0aCB0aGUgdGVybSAiaGlnaC10b3VjaCIgYW5k IGl0IG1heSBhbHJlYWR5DQo+ID4gYmUgdXNlZCBieSBzb21lIG9yZ2FuaXphdGlvbnMgYXMgbWFy a2V0aW5nIGNsaWNoZSBhbmQgc28gbWF5IGFscmVhZHkgYmUNCj4gPiBwb2xsdXRlZCB0byBtZWFu IHNvbWV0aGluZyBlbHNlIHRoYW4gaW50ZW5kZWQgZm9jdXMuDQo+ID4gVGhlIGNhdmVhdCB0byBu b3RlIGlzIHRoYXQgd2hpbGUgRm9yY2VzIE1VU1Qgbm90IHJlc3RyaWN0IHdoYXQNCj4gPiBmdW5j dGlvbmFsaXR5IGdvZXMgaW50byB0aGUgRkUgdnMgQ0UsIHRoZSBjaGFydGVyIHNheXMgdGhlIGlt bWVkaWF0ZQ0KPiA+IGZvY3VzIChpbiBteSBvcGluaW9uIGl0IGlzIGp1c3QgYW4gZXhhbXBsZSkg aXMgRm9yd2FyZGluZyArIFFvUy4gVGhpcyBtYXkNCj4gPiBiZSBjb25mdXNpbmcgdGhlIG90aGVy IHNpZGUgb2YgdGhlIGNvaW4gd2hlcmUgcGVvcGxlIHNlZW0gdG8gdGhpbmsgdGhlDQo+ID4gcHJv dG9jb2wgaXMgYmFzZWQgb24gRGlmZnNlcnYgY29uZmlndXJhdGlvbi4NCj4gPg0KPiA+IGNoZWVy cywNCj4gPiBqYW1hbA0KPiA+DQo+ID4gPiBUaGFua3MNCj4gPiA+DQo+ID4gPiA+IGNoZWVycywN Cj4gPiA+ID4gamFtYWwNCj4gPiA+ID4NCj4gPiA+ID4gPiBUaGFua3MsDQo+ID4gPiA+ID4gLVJv YmVydA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSmFtYWwgSGFkaSBTYWxpbSB3cm90ZToNCj4gPiA+ ID4gPiA+IFJvYmVydCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBNYXliZSBpIG1pc3VuZGVy c3Rvb2Q6IEhvdyBkb2VzICJIaWdoLXRvdWNoIiBub3QgY292ZXIgd2hhdCB5b3UNCj4gPiA+ID4g PiA+IGFyZSBhZGRyZXNzaW5nPyBJcyBpdCB0aGUgbmFtaW5nIHRoYXQgYm90aGVycyB5b3U/DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gY2hlZXJzLA0KPiA+ID4gPiA+ID4gamFtYWwNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBPbiBXZWRuZXNkYXkgMDUgSnVuZSAyMDAyIDEwOjI3LCBSb2Jl cnQgSGFhcyB3cm90ZToNCj4gPiA+ID4gPiA+ID4gSSdkIGxpa2UgdG8gaGF2ZSB0aGUgb3Bpbmlv biBvZiB0aGUgbGlzdC9kZXNpZ24gdGVhbSByZWdhcmRpbmcNCj4gPiA+ID4gPiA+ID4gdGhlIGlz c3VlIGJlbG93LCB3aGljaCBtaWdodCBpbXBhY3QgdGhlIHJlcXVpcmVtZW50cyBkcmFmdCB0bw0K PiA+ID4gPiA+ID4gPiBzb21lIGV4dGVudCAoc29ycnkgZm9yIHBvcHBpbmcgdXAganVzdCBiZWZv cmUgdGhlIGxhc3QgY2FsbA0KPiA+ID4gPiA+ID4gPiBleHRlbmRlZCBkZWFkbGluZSk6DQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IENlcnRhaW4gRkVzIGJlZ2luIHRvIHByb3ZpZGUgZnVu Y3Rpb25zIHRoYXQgZ28gYmV5b25kDQo+ID4gPiA+ID4gPiA+IHBlci1wYWNrZXQgcHJvY2Vzc2lu Zywgc3VjaCBhcyBUQ1AgdGVybWluYXRpb24sIHdoZXJlIHBhcnQgb2YNCj4gPiA+ID4gPiA+ID4g dGhlIHNpZ25hbGluZyBpcyBvZmYtbG9hZGVkIHRvIHRoZSBGRS4gVGhlIGRlZmluaXRpb24gb2YN Cj4gPiA+ID4gPiA+ID4gIkhpZ2gtVG91Y2ggRnVuY3Rpb25zIiBpbiB0aGUgZHJhZnQgZG9lcyBu b3Qgc2VlbSB0byBpbmNsdWRlDQo+ID4gPiA+ID4gPiA+IHN1Y2ggZnVuY3Rpb25zLg0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBXb3VsZCBpdCBiZSB3aXNlIHRvIGNvbnNpZGVyIGFuIGFk ZGl0aW9uYWwgY2F0ZWdvcnksIHN1Y2ggYXMNCj4gPiA+ID4gPiA+ID4gIk9mZi1sb2FkIEZ1bmN0 aW9ucyIsIHdpdGggYW4gYXBwcm9wcmlhdGUgbW9kZWwgPyBJIGJlbGlldmUNCj4gPiA+ID4gPiA+ ID4gbGVhdmluZyB0aGlzIHVwIHRvIGEgIlZlbmRvci1TcGVjaWZpYyBGdW5jdGlvbiIgd291bGQN Cj4gPiA+ID4gPiA+ID4gY29uc2lkZXJhYmx5IHJlZHVjZSB0aGUNCj4gPiA+ID4gPiA+ID4gYXR0 cmFjdGl2aXR5L2ludGVyb3BlcmFiaWxpdHkgZ3VhcmFudGVlZCBieSBGb3JDRVMuDQo+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFJlZ2FyZHMsDQo+ID4gPiA+ID4gPiA+IC0tDQo+ID4gPiA+ ID4gPiA+IFJvYmVydCBIYWFzDQo+ID4gPiA+ID4gPiA+IElCTSBadXJpY2ggUmVzZWFyY2ggTGFi b3JhdG9yeQ0KPiA+ID4gPiA+ID4gPiBT5HVtZXJzdHJhc3NlIDQNCj4gPiA+ID4gPiA+ID4gQ0gt ODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5kDQo+ID4gPiA+ID4gPiA+IHBob25lICs0MS0xLTcy NC04Njk4ICBmYXggKzQxLTEtNzI0LTg1NzgNCj4gPiA+ID4gPiA+ID4gaHR0cDovL3d3dy56dXJp Y2guaWJtLmNvbS9+cmhhDQo= 2002 Message-Id: Date: Tue, 18 Jun 2002 18:07:10 +0200 From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs and off-loadofsignalingfunctions Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Jamal, My concern is the limitation of the scope of FEs capabilities to whatever= can be done to "the packet as it passes through the FE", as the draft mentions i= t repeatedly. If there are other capabilities planned for ForCES besides Forwarding+QoS= , then the requirements draft should avoid being so restrictive, IMHO. The TCP termination being just one example out of today's FEs capabilities that g= o beyond the current scope, as I understand now. If you think it's acceptable, then I'll try to come up with a concrete su= ggestion how to formulate this, that you could then consider including in the draf= t. Cheers, -Robert Jamal Hadi Salim wrote: > On Monday 10 June 2002 15:34, Robert Haas wrote: > > Jamal Hadi Salim wrote: > > > On Mon, 10 Jun 2002, Robert Haas wrote: > > > > Jamal, > > > > > > > > Thanks for your response. Let me clarify: the Requirements draft = limits > > > > the FE model to express what logical functions can be applied to > > > > packets "as they pass through the FE" (see sect. 6.1). "High-Touc= h" is > > > > defined as a category of such logical functions. > > > > > > > > In my opinion, this model rules out functions such as TCP termina= tion, > > > > that require processing not only as a packet "passes through the = FE" > > > > (for instance, handling timers). Functions such as TCP terminatio= n are > > > > usually performed by the CE and could be "off-loaded" into the FE= s for > > > > performance reasons. > > > > > > > > Therefore, it seems to me that this issue is not a naming issue, = but > > > > rather a design choice defining what the FE model must include or= not. > > > > Do you agree ? > > > > > > It depends on how you look at it. And it does become a design issue= , but > > > the model doesnt stop you; > > > lets take TCP termination, for example: > > > I would think that the setup phase where the splicing is being set = up is > > > a control plane activity. So is the termination. With the current m= odel > > > you could redirect specific packets to the control plane (eg in thi= s > > > case, If i understood correctly, would be SYN/FIN packets). > > > Activity after the connection is "nailed" seems to me belongs to th= e > > > FE (such as munging the ACKs and splicing). > > > On the same token, timers to generate FE events seem to me also to = be > > > control activity. > > > Did i understand you correctly? > > > > Let's see: > > > > TCP splicing, after the setup phase, boils down to converting sequenc= e > > numbers back and forth, and this is indeed a function that takes plac= e "as > > packets pass through the FE". An ideal candidate for a "High-Touch > > Function". > > > > But what if I'd like to have some sort of control activity take place= in > > the FE as well, such as TCP setup or timers handling ? The reason is= to > > avoid overloading the CE with TCP processing, if the FEs are smart en= ough > > to handle this directly. This goes beyond the current FE model. > > > > Do you also think that some sort of control activity should be allowe= d to > > be "off-loaded" into the FEs ? > > > > Robert, > I think it would be wrong to limit what functionality goes onto the FE.= I > worked on the requirements team and tried hard to make sure this is cle= ar. > > If you find that this is not reflected properly, i think it should be > clarified. > I cant remember who came up with the term "high-touch" and it may alrea= dy be > used by some organizations as marketing cliche and so may already be po= lluted > to mean something else than intended focus. > The caveat to note is that while Forces MUST not restrict what function= ality > goes into the FE vs CE, the charter says the immediate focus (in my opi= nion > it is just an example) is Forwarding + QoS. This may be confusing the o= ther > side of the coin where people seem to think the protocol is based on Di= ffserv > configuration. > > cheers, > jamal > > > Thanks > > > > > cheers, > > > jamal > > > > > > > Thanks, > > > > -Robert > > > > > > > > Jamal Hadi Salim wrote: > > > > > Robert, > > > > > > > > > > Maybe i misunderstood: How does "High-touch" not cover what you= are > > > > > addressing? Is it the naming that bothers you? > > > > > > > > > > cheers, > > > > > jamal > > > > > > > > > > On Wednesday 05 June 2002 10:27, Robert Haas wrote: > > > > > > I'd like to have the opinion of the list/design team regardin= g the > > > > > > issue below, which might impact the requirements draft to som= e > > > > > > extent (sorry for popping up just before the last call extend= ed > > > > > > deadline): > > > > > > > > > > > > Certain FEs begin to provide functions that go beyond per-pac= ket > > > > > > processing, such as TCP termination, where part of the signal= ing is > > > > > > off-loaded to the FE. The definition of "High-Touch Functions= " in > > > > > > the draft does not seem to include such functions. > > > > > > > > > > > > Would it be wise to consider an additional category, such as > > > > > > "Off-load Functions", with an appropriate model ? I believe l= eaving > > > > > > this up to a "Vendor-Specific Function" would considerably re= duce > > > > > > the > > > > > > attractivity/interoperability guaranteed by ForCES. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > 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 2002 Message-Id: Date: Mon, 17 Jun 2002 11:32:27 -0700 From: "Putzolu, David" Subject: ForCES Draft Agenda - please send requests Comments: cc: "Patrick Droz (dro@zurich.ibm.com)" MIME-Version: 1.0 Content-Type: text/plain All, ForCES is tentatively scheduled to meet at IETF 54 on Monday, July 15, from 0900-1130. It is time to start coming up with an agenda for the meeting. Please send agenda requests to myself or Patrick. Please include the title of your presentation, URL of any relevant drafts, and an estimate of how much time you feel is necessary. So far I have an agenda request for a model contribution that will be submitted as a draft soon. Thanks, David 2002 Message-Id: Date: Fri, 14 Jun 2002 09:52:13 -0400 From: Vip Sharma Subject: Re: Accept Framework individual contrib as WG doc? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David, This draft should become a work group document... vip -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David Sent: Thursday, June 13, 2002 1:45 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Accept Framework individual contrib as WG doc? Importance: High All, There was not sufficient feedback to the prior request to determine if there is consensus. Please indicate whether you feel that the following draft is ready to become a working group document: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt Thanks, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > Sent: Friday, May 24, 2002 1:41 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > All, > > A new version of the ForCES Framework individual > contribution was submitted last week and the authors > have requested that it be accepted as a working > group document. This document is intended to satisfy > the charter deliverable of "An architectural framework > defining the entities comprising a ForCES network > element and identifying the interactions between > them." > > Patrick and I would like the list to review and > comment whether this draft is ready to be accepted > as a ForCES working group document. Note that > acceptance as a working group document associates > this document with the ForCES WG. It does not grant > formal standards status to the document and the document > will remain open to change or removal. > > Please submit your comments and recommendation to the > mailing list by Friday, May 31, 2002. > > URL: > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > Thanks, > David > > > Lily Yang wrote: > >Patrick, David and all -- > > > >On behalf of my co-authors Ram Dantu, > >Todd Anderson and myself, I would like > >to request the WG review this framework > >draft and consider accepting it as a > >WG document. > > > >Lily > > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > Sent: Wednesday, May 15, 2002 11:13 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > Hi, all -- > > We submitted version 01 of the framework draft last week > after a major > > rewrite: > > * added more description and diagrams to illustrate > different physical > > configuration examples of ForCES CE/FE. > > * added examples of FE topology. > > * restructure the text to focus more on ForCES operation > phases (pre- > > and > > post- association, reestablishment, etc.) > > * added examples to illustrate the handshake between CE and > FE during > > these operational phases. > > > > please let us know what you think -- are these examples/diagrams > > useful? Have we missed anything important? Any comments on the draft > > are welcome! > > > > Thanks, > > Lily > 2002 Message-Id: Date: Fri, 14 Jun 2002 09:30:47 -0400 From: "(Ram Gopal )" Subject: Re: Accept Framework individual contrib as WG doc? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable accept this as working group item. regards ramg > -----Original Message----- > From: ext Putzolu, David [mailto:david.putzolu@intel.com] > Sent: Thursday, June 13, 2002 1:45 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Accept Framework individual contrib as WG doc? > Importance: High >=20 >=20 > All, >=20 > There was not sufficient feedback to the prior > request to determine if there is consensus. >=20 > Please indicate whether you feel that the following > draft is ready to become a working group document: >=20 > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt >=20 > Thanks, > David >=20 > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework > > defining the entities comprising a ForCES network > > element and identifying the interactions between > > them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft->=20 > anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments=20 > on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > >=20 2002 Message-Id: Date: Fri, 14 Jun 2002 08:04:13 +0100 From: Alistair Munro Subject: Re: Accept Framework individual contrib as WG doc? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi David, I supoprt the progression of the draft to WG accepted status. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: 13 June 2002 18:45 > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Accept Framework individual contrib as WG doc? > Importance: High > > > All, > > There was not sufficient feedback to the prior > request to determine if there is consensus. > > Please indicate whether you feel that the following > draft is ready to become a working group document: > > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > > Thanks, > David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework defining the > > entities comprising a ForCES network element and identifying the > > interactions between them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> > > anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments > on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > > 2002 Message-Id: Date: Fri, 14 Jun 2002 08:03:27 +0100 From: Alistair Munro Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, I'm glad that the suggestion of SNMP is not intended to be serious. I have had the dubious pleasure of working on element management using SNMP (vanilla V.2). It failed mainly because the semantics of a MIB is too poorly defined. To allow implementers to build agents that behave consistently from product to product (even from the same vendor) you have to build a model of the FE at a very detailed semantic level, which is seldom done. Also the FE model diverges so widely from the operational situation in which a FE is being used that it is difficult to build an efficient control/configuring client protocol on SNMP. Finally, although it has improved significantly, SNMP is still fundamentally unsuitable as a protocol for a long-lived controlling relationship (i.e. writing lots of data to many FEs). I have the same reservations about using other existing protocols by imposing alternative semantics on the content of their PDUs. A protocol is designed for a specific purpose and should be used only for that purpose. The MIDCOM group appears to be asking a similar question. However, everybody seems to have a different view of what a middlebox is and does (i.e. anything and everything), so (IMO) it's never going to go anywhere until answers this question first. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: 13 June 2002 14:50 > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Requirements Document - Capabilities Model > > > On Thursday 13 June 2002 13:15, avri wrote: > > Jamal Hadi Salim wrote: > > > Which is one of the reasons why COPS is a bad choice. > > > Out of curiosity, why COPS say in a local scope. Think of a very > > > simple setup with a controller and the FEs sitting in the same > > > chasis. Why not SNMP for example? > > > > SNMP? Have you looked at how hard and complicated it is to even > > configure an MPLS label swtich with MIBS? ForCES seems like > it would > > be even more difficult. > > > > I was just being a devils advocate ;-> > > > Plus the info model for a MIB is pretty much the same level of > > difficulty as one for a PIB. As is translation into the Info Base. > > > > snacc compiles both PIBs and MIBS. > The main positive both COPS and SNMP have is that they are > widely used ;-> Some people tend to have emotional > attachments to things that they are comfortable with. I am > not a fan of either COPS or SNMP. I think the protocol > should include good built in event management and reporting, > one-to-many communication, and easy to extend models. > > cheers, > jamal > > > > > a. > > > > > > -- > > Mobile: +46 73 029 8019 > > Office: +46 920 49 3030 > > In US: +1 401 663 5024 > > > > http://homepage.bethepeople.com/mphp/VXEU-2002/avri > 2002 Message-Id: Date: Thu, 13 Jun 2002 19:15:03 +0200 From: avri Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > > > Which is one of the reasons why COPS is a bad choice. > Out of curiosity, why COPS say in a local scope. Think of a very simple setup > with a controller and the FEs sitting in the same chasis. Why not SNMP for > example? SNMP? Have you looked at how hard and complicated it is to even configure an MPLS label swtich with MIBS? ForCES seems like it would be even more difficult. Plus the info model for a MIB is pretty much the same level of difficulty as one for a PIB. As is translation into the Info Base. a. -- Mobile: +46 73 029 8019 Office: +46 920 49 3030 In US: +1 401 663 5024 http://homepage.bethepeople.com/mphp/VXEU-2002/avri 2002 Message-Id: Date: Thu, 13 Jun 2002 18:28:29 -0400 From: Alex Vasquez Subject: Re: Accept Framework individual contrib as WG doc? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The proposed draft is ready to become a working group document. Alex -----Original Message----- From: Putzolu, David [mailto:david.putzolu@intel.com] Sent: Thursday, June 13, 2002 1:45 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Accept Framework individual contrib as WG doc? Importance: High All, There was not sufficient feedback to the prior request to determine if there is consensus. Please indicate whether you feel that the following draft is ready to become a working group document: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt Thanks, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > Sent: Friday, May 24, 2002 1:41 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > All, > > A new version of the ForCES Framework individual > contribution was submitted last week and the authors > have requested that it be accepted as a working > group document. This document is intended to satisfy > the charter deliverable of "An architectural framework > defining the entities comprising a ForCES network > element and identifying the interactions between > them." > > Patrick and I would like the list to review and > comment whether this draft is ready to be accepted > as a ForCES working group document. Note that > acceptance as a working group document associates > this document with the ForCES WG. It does not grant > formal standards status to the document and the document > will remain open to change or removal. > > Please submit your comments and recommendation to the > mailing list by Friday, May 31, 2002. > > URL: > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > Thanks, > David > > > Lily Yang wrote: > >Patrick, David and all -- > > > >On behalf of my co-authors Ram Dantu, > >Todd Anderson and myself, I would like > >to request the WG review this framework > >draft and consider accepting it as a > >WG document. > > > >Lily > > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > Sent: Wednesday, May 15, 2002 11:13 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > Hi, all -- > > We submitted version 01 of the framework draft last week > after a major > > rewrite: > > * added more description and diagrams to illustrate > different physical > > configuration examples of ForCES CE/FE. > > * added examples of FE topology. > > * restructure the text to focus more on ForCES operation > phases (pre- > > and > > post- association, reestablishment, etc.) > > * added examples to illustrate the handshake between CE and > FE during > > these operational phases. > > > > please let us know what you think -- are these examples/diagrams > > useful? Have we missed anything important? Any comments on the draft > > are welcome! > > > > Thanks, > > Lily > 2002 Message-Id: Date: Thu, 13 Jun 2002 15:59:39 -0400 From: "Joel M. Halpern" Subject: Re: Accept Framework individual contrib as WG doc? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I believe it should become a working group document. Yours, Joel M. Halpern At 10:44 AM 6/13/2002 -0700, you wrote: >All, > >There was not sufficient feedback to the prior >request to determine if there is consensus. > >Please indicate whether you feel that the following >draft is ready to become a working group document: > >http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > >Thanks, >David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework > > defining the entities comprising a ForCES network > > element and identifying the interactions between > > them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > 2002 Message-Id: Date: Thu, 13 Jun 2002 14:49:47 -0500 From: Alex Audu Subject: Re: Accept Framework individual contrib as WG doc? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I feel it is ready to be transitioned into a working group document. Alex. "Putzolu, David" wrote: > All, > > There was not sufficient feedback to the prior > request to determine if there is consensus. > > Please indicate whether you feel that the following > draft is ready to become a working group document: > > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt > > Thanks, > David > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > > Sent: Friday, May 24, 2002 1:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > > > > All, > > > > A new version of the ForCES Framework individual > > contribution was submitted last week and the authors > > have requested that it be accepted as a working > > group document. This document is intended to satisfy > > the charter deliverable of "An architectural framework > > defining the entities comprising a ForCES network > > element and identifying the interactions between > > them." > > > > Patrick and I would like the list to review and > > comment whether this draft is ready to be accepted > > as a ForCES working group document. Note that > > acceptance as a working group document associates > > this document with the ForCES WG. It does not grant > > formal standards status to the document and the document > > will remain open to change or removal. > > > > Please submit your comments and recommendation to the > > mailing list by Friday, May 31, 2002. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > > > Thanks, > > David > > > > > > Lily Yang wrote: > > >Patrick, David and all -- > > > > > >On behalf of my co-authors Ram Dantu, > > >Todd Anderson and myself, I would like > > >to request the WG review this framework > > >draft and consider accepting it as a > > >WG document. > > > > > >Lily > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > > Sent: Wednesday, May 15, 2002 11:13 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > > > > Hi, all -- > > > We submitted version 01 of the framework draft last week > > after a major > > > rewrite: > > > * added more description and diagrams to illustrate > > different physical > > > configuration examples of ForCES CE/FE. > > > * added examples of FE topology. > > > * restructure the text to focus more on ForCES operation > > phases (pre- > > > and > > > post- association, reestablishment, etc.) > > > * added examples to illustrate the handshake between CE and > > FE during > > > these operational phases. > > > > > > please let us know what you think -- are these examples/diagrams > > > useful? Have we missed anything important? Any comments on the draft > > > are welcome! > > > > > > Thanks, > > > Lily > > 2002 Message-Id: Date: Thu, 13 Jun 2002 11:53:12 +0200 From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs andoff-loadofsignalingfunctions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Olivier, Olivier Marce wrote: > Hi Robert > > Am I right when I understand that you expect that the FE could offer some > sort of proxy function to the CE (on request of the CE ) ? You're right. > If so, am I right when I say that this is in the scope of item #3 of Lily's > message ? > > "The third kind of control and configuration is even more powerful and future > looking. In addition to dynamic configuration, CEs might be even allowed to > download a given functionality onto FEs. I am not sure how we model that > yet. But we probably can get by without too concerned with this." Not really: in my view, the ability to download new functionalities into an FE is orthogonal to the type of functionality the FE can execute. In other words, you could think of an FE that provides a static proxy-function: that could be the case for an FE that has been built to execute TCP termination in particular, but no other proxy-function. Therefore, by generalization, such proxy-functions (or "Off-load Functions") could be found in any of the 3 "flexibility" classes: #1 (static capabilities), #2 (reconfigurable capabilities), or #3 (downloadable capabilities). Do you agree with this interpretation of the 3 "flexibility" classes suggested by Lily and how proxy-functions can belong to any of them ? Regards, -Robert > > Regards > > Robert Haas wrote: > > > > Let's see: > > > > TCP splicing, after the setup phase, boils down to converting sequence numbers back > > and forth, and this is indeed a function that takes place "as packets pass through > > the FE". An ideal candidate for a "High-Touch Function". > > > > But what if I'd like to have some sort of control activity take place in the FE as > > well, such as TCP setup or timers handling ? The reason is to avoid overloading the > > CE with TCP processing, if the FEs are smart enough to handle this directly. This > > goes beyond the current FE model. > > > > Do you also think that some sort of control activity should be allowed to be > > "off-loaded" into the FEs ? > > > > -- > Olivier Marce (ARX Project/Active Network WP) > Alcatel R&I Dept Tel: +33 (0) 1 69 63 41 67 > Route de Nozay Fax: +33 (0) 1 69 63 13 59 > F-91461 Marcoussis Cedex (France) 2002 Message-Id: Date: Thu, 13 Jun 2002 10:44:43 -0700 From: "Putzolu, David" Subject: Re: Accept Framework individual contrib as WG doc? MIME-Version: 1.0 Content-Type: text/plain All, There was not sufficient feedback to the prior request to determine if there is consensus. Please indicate whether you feel that the following draft is ready to become a working group document: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt Thanks, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@INTEL.COM] > Sent: Friday, May 24, 2002 1:41 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Accept Framework individual contrib as WG doc? > > > All, > > A new version of the ForCES Framework individual > contribution was submitted last week and the authors > have requested that it be accepted as a working > group document. This document is intended to satisfy > the charter deliverable of "An architectural framework > defining the entities comprising a ForCES network > element and identifying the interactions between > them." > > Patrick and I would like the list to review and > comment whether this draft is ready to be accepted > as a ForCES working group document. Note that > acceptance as a working group document associates > this document with the ForCES WG. It does not grant > formal standards status to the document and the document > will remain open to change or removal. > > Please submit your comments and recommendation to the > mailing list by Friday, May 31, 2002. > > URL: > http://www.ietf.org/internet-drafts/draft-> anderson-forces-arch-01.txt > > Thanks, > David > > > Lily Yang wrote: > >Patrick, David and all -- > > > >On behalf of my co-authors Ram Dantu, > >Todd Anderson and myself, I would like > >to request the WG review this framework > >draft and consider accepting it as a > >WG document. > > > >Lily > > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > > Sent: Wednesday, May 15, 2002 11:13 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > > > Hi, all -- > > We submitted version 01 of the framework draft last week > after a major > > rewrite: > > * added more description and diagrams to illustrate > different physical > > configuration examples of ForCES CE/FE. > > * added examples of FE topology. > > * restructure the text to focus more on ForCES operation > phases (pre- > > and > > post- association, reestablishment, etc.) > > * added examples to illustrate the handshake between CE and > FE during > > these operational phases. > > > > please let us know what you think -- are these examples/diagrams > > useful? Have we missed anything important? Any comments on the draft > > are welcome! > > > > Thanks, > > Lily > 2002 Message-Id: Date: Thu, 13 Jun 2002 09:50:21 -0400 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Requirements Document - Capabilities Model Comments: To: avri MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 T24gVGh1cnNkYXkgMTMgSnVuZSAyMDAyIDEzOjE1LCBhdnJpIHdyb3RlOg0KPiBKYW1hbCBIYWRp IFNhbGltIHdyb3RlOg0KPiA+IFdoaWNoIGlzIG9uZSBvZiB0aGUgcmVhc29ucyB3aHkgQ09QUyBp cyBhIGJhZCBjaG9pY2UuDQo+ID4gT3V0IG9mIGN1cmlvc2l0eSwgd2h5IENPUFMgc2F5IGluIGEg bG9jYWwgc2NvcGUuIFRoaW5rIG9mIGEgdmVyeSBzaW1wbGUNCj4gPiBzZXR1cCB3aXRoIGEgY29u dHJvbGxlciBhbmQgdGhlIEZFcyBzaXR0aW5nIGluIHRoZSBzYW1lIGNoYXNpcy4gV2h5IG5vdA0K PiA+IFNOTVAgZm9yIGV4YW1wbGU/DQo+DQo+IFNOTVA/IEhhdmUgeW91IGxvb2tlZCBhdCBob3cg aGFyZCBhbmQgY29tcGxpY2F0ZWQgaXQgaXMgdG8gZXZlbg0KPiBjb25maWd1cmUgYW4gTVBMUyBs YWJlbCBzd3RpY2ggd2l0aCBNSUJTPyBGb3JDRVMgc2VlbXMgbGlrZSBpdA0KPiB3b3VsZCBiZSBl dmVuIG1vcmUgZGlmZmljdWx0Lg0KPg0KDQpJIHdhcyBqdXN0IGJlaW5nIGEgZGV2aWxzIGFkdm9j YXRlIDstPiANCg0KPiBQbHVzIHRoZSBpbmZvIG1vZGVsIGZvciBhIE1JQiBpcyBwcmV0dHkgbXVj aCB0aGUgc2FtZSBsZXZlbCBvZg0KPiBkaWZmaWN1bHR5IGFzIG9uZSBmb3IgYSBQSUIuIEFzIGlz IHRyYW5zbGF0aW9uIGludG8gdGhlIEluZm8gQmFzZS4NCj4NCg0Kc25hY2MgY29tcGlsZXMgYm90 aCBQSUJzIGFuZCBNSUJTLg0KVGhlIG1haW4gcG9zaXRpdmUgYm90aCBDT1BTIGFuZCBTTk1QIGhh dmUgaXMgdGhhdCB0aGV5IGFyZSB3aWRlbHkgdXNlZCA7LT4NClNvbWUgcGVvcGxlIHRlbmQgdG8g aGF2ZSBlbW90aW9uYWwgYXR0YWNobWVudHMgdG8gdGhpbmdzIHRoYXQgdGhleSBhcmUNCmNvbWZv cnRhYmxlIHdpdGguDQpJIGFtIG5vdCBhIGZhbiBvZiBlaXRoZXIgQ09QUyBvciBTTk1QLiAgSSB0 aGluayB0aGUgcHJvdG9jb2wgc2hvdWxkIGluY2x1ZGUNCmdvb2QgYnVpbHQgaW4gZXZlbnQgbWFu YWdlbWVudCBhbmQgcmVwb3J0aW5nLCBvbmUtdG8tbWFueSBjb21tdW5pY2F0aW9uLCBhbmQNCmVh c3kgdG8gZXh0ZW5kIG1vZGVscy4NCg0KY2hlZXJzLA0KamFtYWwgDQoNCg0KDQo+IGEuDQo+DQo+ DQo+IC0tDQo+IE1vYmlsZTogKzQ2IDczIDAyOSA4MDE5DQo+IE9mZmljZTogKzQ2IDkyMCA0OSAz MDMwDQo+IEluIFVTOiAgKzEgNDAxIDY2MyA1MDI0DQo+DQo+IGh0dHA6Ly9ob21lcGFnZS5iZXRo ZXBlb3BsZS5jb20vbXBocC9WWEVVLTIwMDIvYXZyaQ0K 2002 Message-Id: Date: Thu, 13 Jun 2002 06:41:54 -0400 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Requirements Document - Capabilities Model Comments: To: avri MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 T24gV2VkbmVzZGF5IDEyIEp1bmUgMjAwMiAwODozNSwgYXZyaSB3cm90ZToNCj4gT2xpdmllciBN YXJjZSB3cm90ZToNCj4gPiBXaXRoIHRoaXMgaW4gbWluZCwgd2hhdCdzIGFib3V0IGNvbnNpZGVy aW5nIENPUFMgKyBGcmFtZXdvcmsgUElCIGFzIGENCj4gPiBjYW5kaWRhdGUgdG8gRk9SQ0VTID8N Cj4NCj4gaW4gbWFueSByZXNwZWN0cyB0aGlzIGlzIGFuIGV4Y2VsbGVudCBzdWdnZXN0aW9uLiBm cm9tIHRoZQ0KPiBiZWdpbm5pbmcgaSBoYXZlIHRob3VnaHQgdGhhdCBjb3BzIGNvdWxkIHdlbGwg YmUgcGFydCBvZiB0aGUNCj4gc29sdXRpb24uIHRob3VnaCBpdCB3b3VsZCB0YWtlIGNyZWF0aW5n IGEgc3BlY2lmaWMgaW5mbyBtb2RlbC9QSUINCj4gZm9yIEZvckNFUyBpbiBhZGRpdGlvbiB0byB1 c2Ugb2Ygb3RoZXIgZXhpc3RpbmcgUElCcy4NCj4NCj4gd2l0aCB0aGUgcnVtb3JzIHRoYXQgZmx5 LCBob3dldmVyLCBhYm91dCB0aGUgY29udGludWVkIGFjY2VwdGFuY2UNCj4gb2YgQ09QUywgaXMg dGhpcyBjb25zaWRlcmVkIGEgJ3NhZmUnIGNhbmRpZGF0ZT8NCj4gZXZlcnkgdGltZSBpIHN1Z2dl c3QgYSBjb3BzIGJhc2VkIHNvbHV0aW9uIHRvIHNvbWVvbmUsIHRoZXkgdGVsbA0KPiBtZSBpdCBp cyBkZWFkIChhZnRlciBzdXBwcmVzc2luZyBnaWdnbGVzIGF0IG15IG5haXZldOkpLg0KPg0KPiBh cmUgY29tcGFuaWVzIGFjdHVhbGx5IGJ1aWxkaW5nIGFuZCBfc2VsbGluZ18gQ09QUyBlbmdpbmVz Pw0KPg0KPiB0aGUgcmVhc29uIGkgYXNrIGlzIGdldHRpbmcgdGhlIGluZm8gbW9kZWwgYW5kIFBJ QiBkb25lIGlzIGENCj4gc2lnbmlmaWNhbnQgdGFzaywgYW5kIGlmIENPUFMgaXMgbm90IG5vdCBy ZWFsbHkgcmVhbCwgdGhlbiB0aGUNCj4gZWZmb3J0IG1heSBiZSBiZXR0ZXIgc3BlbnQgZWxzZXdo ZXJlLg0KPg0KDQpXaGljaCBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgd2h5IENPUFMgaXMgYSBiYWQg Y2hvaWNlLg0KT3V0IG9mIGN1cmlvc2l0eSwgd2h5IENPUFMgc2F5IGluIGEgbG9jYWwgc2NvcGUu IFRoaW5rIG9mIGEgdmVyeSBzaW1wbGUgc2V0dXAgDQp3aXRoIGEgY29udHJvbGxlciBhbmQgdGhl IEZFcyBzaXR0aW5nIGluIHRoZSBzYW1lIGNoYXNpcy4gV2h5IG5vdCBTTk1QIGZvciANCmV4YW1w bGU/IA0KDQpjaGVlcnMsDQpqYW1hbA0KDQo+IGEuDQo+DQo+IChhIHByb3Bvc2VyIG9mIGNvcHMg YmFzZWQgc29sdXRpb25zIGFuZCBjby1hdXRob3Igb2YgYSBwaWIgd2hvDQo+IGRlc3BhaXJzIG9m IGV2ZXIgc2VlaW5nIHJlYWxseSByZWFsIGltcGxlbWVudGF0aW9ucykNCj4NCj4gPiAtLQ0KPiA+ IE9saXZpZXIgTWFyY2UgKEFSWCBQcm9qZWN0L0FjdGl2ZSBOZXR3b3JrIFdQKQ0KPiA+IEFsY2F0 ZWwgUiZJIERlcHQgICAgICAgICAgICAgICAgICAgICAgICBUZWw6ICszMyAoMCkgMSA2OSA2MyA0 MSA2Nw0KPiA+IFJvdXRlIGRlIE5vemF5ICAgICAgICAgICAgICAgICAgICAgICAgICBGYXg6ICsz MyAoMCkgMSA2OSA2MyAxMyA1OQ0KPiA+IEYtOTE0NjEgTWFyY291c3NpcyBDZWRleCAoRnJhbmNl KQ0K 2002 Message-Id: Date: Thu, 13 Jun 2002 06:39:02 -0400 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Comment on ForCES Requirements draft: FEs and off-load ofsignalingfunctions Comments: To: Robert Haas MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 T24gTW9uZGF5IDEwIEp1bmUgMjAwMiAxNTozNCwgUm9iZXJ0IEhhYXMgd3JvdGU6DQo+IEphbWFs IEhhZGkgU2FsaW0gd3JvdGU6DQo+ID4gT24gTW9uLCAxMCBKdW4gMjAwMiwgUm9iZXJ0IEhhYXMg d3JvdGU6DQo+ID4gPiBKYW1hbCwNCj4gPiA+DQo+ID4gPiBUaGFua3MgZm9yIHlvdXIgcmVzcG9u c2UuIExldCBtZSBjbGFyaWZ5OiB0aGUgUmVxdWlyZW1lbnRzIGRyYWZ0IGxpbWl0cw0KPiA+ID4g dGhlIEZFIG1vZGVsIHRvIGV4cHJlc3Mgd2hhdCBsb2dpY2FsIGZ1bmN0aW9ucyBjYW4gYmUgYXBw bGllZCB0bw0KPiA+ID4gcGFja2V0cyAiYXMgdGhleSBwYXNzIHRocm91Z2ggdGhlIEZFIiAoc2Vl IHNlY3QuIDYuMSkuICJIaWdoLVRvdWNoIiBpcw0KPiA+ID4gZGVmaW5lZCBhcyBhIGNhdGVnb3J5 IG9mIHN1Y2ggbG9naWNhbCBmdW5jdGlvbnMuDQo+ID4gPg0KPiA+ID4gSW4gbXkgb3Bpbmlvbiwg dGhpcyBtb2RlbCBydWxlcyBvdXQgZnVuY3Rpb25zIHN1Y2ggYXMgVENQIHRlcm1pbmF0aW9uLA0K PiA+ID4gdGhhdCByZXF1aXJlIHByb2Nlc3Npbmcgbm90IG9ubHkgYXMgYSBwYWNrZXQgInBhc3Nl cyB0aHJvdWdoIHRoZSBGRSINCj4gPiA+IChmb3IgaW5zdGFuY2UsIGhhbmRsaW5nIHRpbWVycyku IEZ1bmN0aW9ucyBzdWNoIGFzIFRDUCB0ZXJtaW5hdGlvbiBhcmUNCj4gPiA+IHVzdWFsbHkgcGVy Zm9ybWVkIGJ5IHRoZSBDRSBhbmQgY291bGQgYmUgIm9mZi1sb2FkZWQiIGludG8gdGhlIEZFcyBm b3INCj4gPiA+IHBlcmZvcm1hbmNlIHJlYXNvbnMuDQo+ID4gPg0KPiA+ID4gVGhlcmVmb3JlLCBp dCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgaXNzdWUgaXMgbm90IGEgbmFtaW5nIGlzc3VlLCBidXQN Cj4gPiA+IHJhdGhlciBhIGRlc2lnbiBjaG9pY2UgZGVmaW5pbmcgd2hhdCB0aGUgRkUgbW9kZWwg bXVzdCBpbmNsdWRlIG9yIG5vdC4NCj4gPiA+IERvIHlvdSBhZ3JlZSA/DQo+ID4NCj4gPiBJdCBk ZXBlbmRzIG9uIGhvdyB5b3UgbG9vayBhdCBpdC4gQW5kIGl0IGRvZXMgYmVjb21lIGEgZGVzaWdu IGlzc3VlLCBidXQNCj4gPiB0aGUgbW9kZWwgZG9lc250IHN0b3AgeW91Ow0KPiA+IGxldHMgdGFr ZSBUQ1AgdGVybWluYXRpb24sIGZvciBleGFtcGxlOg0KPiA+IEkgd291bGQgdGhpbmsgdGhhdCB0 aGUgc2V0dXAgcGhhc2Ugd2hlcmUgdGhlIHNwbGljaW5nIGlzIGJlaW5nIHNldCB1cCBpcw0KPiA+ IGEgY29udHJvbCBwbGFuZSBhY3Rpdml0eS4gU28gaXMgdGhlIHRlcm1pbmF0aW9uLiBXaXRoIHRo ZSBjdXJyZW50IG1vZGVsDQo+ID4geW91IGNvdWxkIHJlZGlyZWN0IHNwZWNpZmljIHBhY2tldHMg dG8gdGhlIGNvbnRyb2wgcGxhbmUgKGVnIGluIHRoaXMNCj4gPiBjYXNlLCBJZiBpIHVuZGVyc3Rv b2QgY29ycmVjdGx5LCB3b3VsZCBiZSBTWU4vRklOIHBhY2tldHMpLg0KPiA+IEFjdGl2aXR5IGFm dGVyIHRoZSBjb25uZWN0aW9uIGlzICJuYWlsZWQiIHNlZW1zIHRvIG1lIGJlbG9uZ3MgdG8gdGhl DQo+ID4gRkUgKHN1Y2ggYXMgbXVuZ2luZyB0aGUgQUNLcyBhbmQgc3BsaWNpbmcpLg0KPiA+IE9u IHRoZSBzYW1lIHRva2VuLCB0aW1lcnMgdG8gZ2VuZXJhdGUgRkUgZXZlbnRzIHNlZW0gdG8gbWUg YWxzbyB0byBiZQ0KPiA+IGNvbnRyb2wgYWN0aXZpdHkuDQo+ID4gRGlkIGkgdW5kZXJzdGFuZCB5 b3UgY29ycmVjdGx5Pw0KPg0KPiBMZXQncyBzZWU6DQo+DQo+IFRDUCBzcGxpY2luZywgYWZ0ZXIg dGhlIHNldHVwIHBoYXNlLCBib2lscyBkb3duIHRvIGNvbnZlcnRpbmcgc2VxdWVuY2UNCj4gbnVt YmVycyBiYWNrIGFuZCBmb3J0aCwgYW5kIHRoaXMgaXMgaW5kZWVkIGEgZnVuY3Rpb24gdGhhdCB0 YWtlcyBwbGFjZSAiYXMNCj4gcGFja2V0cyBwYXNzIHRocm91Z2ggdGhlIEZFIi4gQW4gaWRlYWwg Y2FuZGlkYXRlIGZvciBhICJIaWdoLVRvdWNoDQo+IEZ1bmN0aW9uIi4NCj4NCj4gQnV0IHdoYXQg aWYgSSdkIGxpa2UgdG8gaGF2ZSBzb21lIHNvcnQgb2YgY29udHJvbCBhY3Rpdml0eSB0YWtlIHBs YWNlIGluDQo+IHRoZSBGRSBhcyB3ZWxsLCBzdWNoIGFzIFRDUCBzZXR1cCBvciB0aW1lcnMgaGFu ZGxpbmcgPyAgVGhlIHJlYXNvbiBpcyB0bw0KPiBhdm9pZCBvdmVybG9hZGluZyB0aGUgQ0Ugd2l0 aCBUQ1AgcHJvY2Vzc2luZywgaWYgdGhlIEZFcyBhcmUgc21hcnQgZW5vdWdoDQo+IHRvIGhhbmRs ZSB0aGlzIGRpcmVjdGx5LiBUaGlzIGdvZXMgYmV5b25kIHRoZSBjdXJyZW50IEZFIG1vZGVsLg0K Pg0KPiBEbyB5b3UgYWxzbyB0aGluayB0aGF0IHNvbWUgc29ydCBvZiBjb250cm9sIGFjdGl2aXR5 IHNob3VsZCBiZSBhbGxvd2VkIHRvDQo+IGJlICJvZmYtbG9hZGVkIiBpbnRvIHRoZSBGRXMgPw0K Pg0KDQpSb2JlcnQsDQpJIHRoaW5rIGl0IHdvdWxkIGJlIHdyb25nIHRvIGxpbWl0IHdoYXQgZnVu Y3Rpb25hbGl0eSBnb2VzIG9udG8gdGhlIEZFLiBJIA0Kd29ya2VkIG9uIHRoZSByZXF1aXJlbWVu dHMgdGVhbSBhbmQgdHJpZWQgaGFyZCB0byBtYWtlIHN1cmUgdGhpcyBpcyBjbGVhcjsNCklmIHlv dSBmaW5kIHRoYXQgdGhpcyBpcyBub3QgcmVmbGVjdGVkIHByb3Blcmx5LCBpIHRoaW5rIGl0IHNo b3VsZCBiZSANCmNsYXJpZmllZC4gDQpJIGNhbnQgcmVtZW1iZXIgd2hvIGNhbWUgdXAgd2l0aCB0 aGUgdGVybSAiaGlnaC10b3VjaCIgYW5kIGl0IG1heSBhbHJlYWR5IGJlIA0KdXNlZCBieSBzb21l IG9yZ2FuaXphdGlvbnMgYXMgbWFya2V0aW5nIGNsaWNoZSBhbmQgc28gbWF5IGFscmVhZHkgYmUg cG9sbHV0ZWQgDQp0byBtZWFuIHNvbWV0aGluZyBlbHNlIHRoYW4gaW50ZW5kZWQgZm9jdXMuDQpU aGUgY2F2ZWF0IHRvIG5vdGUgaXMgdGhhdCB3aGlsZSBGb3JjZXMgTVVTVCBub3QgcmVzdHJpY3Qg d2hhdCBmdW5jdGlvbmFsaXR5IA0KZ29lcyBpbnRvIHRoZSBGRSB2cyBDRSwgdGhlIGNoYXJ0ZXIg c2F5cyB0aGUgaW1tZWRpYXRlIGZvY3VzIChpbiBteSBvcGluaW9uIA0KaXQgaXMganVzdCBhbiBl eGFtcGxlKSBpcyBGb3J3YXJkaW5nICsgUW9TLiBUaGlzIG1heSBiZSBjb25mdXNpbmcgdGhlIG90 aGVyIA0Kc2lkZSBvZiB0aGUgY29pbiB3aGVyZSBwZW9wbGUgc2VlbSB0byB0aGluayB0aGUgcHJv dG9jb2wgaXMgYmFzZWQgb24gRGlmZnNlcnYgDQpjb25maWd1cmF0aW9uLiANCg0KY2hlZXJzLA0K amFtYWwNCg0KDQoNCg0KPiBUaGFua3MNCj4NCj4gPiBjaGVlcnMsDQo+ID4gamFtYWwNCj4gPg0K PiA+ID4gVGhhbmtzLA0KPiA+ID4gLVJvYmVydA0KPiA+ID4NCj4gPiA+IEphbWFsIEhhZGkgU2Fs aW0gd3JvdGU6DQo+ID4gPiA+IFJvYmVydCwNCj4gPiA+ID4NCj4gPiA+ID4gTWF5YmUgaSBtaXN1 bmRlcnN0b29kOiBIb3cgZG9lcyAiSGlnaC10b3VjaCIgbm90IGNvdmVyIHdoYXQgeW91IGFyZQ0K PiA+ID4gPiBhZGRyZXNzaW5nPyBJcyBpdCB0aGUgbmFtaW5nIHRoYXQgYm90aGVycyB5b3U/DQo+ ID4gPiA+DQo+ID4gPiA+IGNoZWVycywNCj4gPiA+ID4gamFtYWwNCj4gPiA+ID4NCj4gPiA+ID4g T24gV2VkbmVzZGF5IDA1IEp1bmUgMjAwMiAxMDoyNywgUm9iZXJ0IEhhYXMgd3JvdGU6DQo+ID4g PiA+ID4gSSdkIGxpa2UgdG8gaGF2ZSB0aGUgb3BpbmlvbiBvZiB0aGUgbGlzdC9kZXNpZ24gdGVh bSByZWdhcmRpbmcgdGhlDQo+ID4gPiA+ID4gaXNzdWUgYmVsb3csIHdoaWNoIG1pZ2h0IGltcGFj dCB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0IHRvIHNvbWUNCj4gPiA+ID4gPiBleHRlbnQgKHNvcnJ5 IGZvciBwb3BwaW5nIHVwIGp1c3QgYmVmb3JlIHRoZSBsYXN0IGNhbGwgZXh0ZW5kZWQNCj4gPiA+ ID4gPiBkZWFkbGluZSk6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBDZXJ0YWluIEZFcyBiZWdpbiB0 byBwcm92aWRlIGZ1bmN0aW9ucyB0aGF0IGdvIGJleW9uZCBwZXItcGFja2V0DQo+ID4gPiA+ID4g cHJvY2Vzc2luZywgc3VjaCBhcyBUQ1AgdGVybWluYXRpb24sIHdoZXJlIHBhcnQgb2YgdGhlIHNp Z25hbGluZyBpcw0KPiA+ID4gPiA+IG9mZi1sb2FkZWQgdG8gdGhlIEZFLiBUaGUgZGVmaW5pdGlv biBvZiAiSGlnaC1Ub3VjaCBGdW5jdGlvbnMiIGluDQo+ID4gPiA+ID4gdGhlIGRyYWZ0IGRvZXMg bm90IHNlZW0gdG8gaW5jbHVkZSBzdWNoIGZ1bmN0aW9ucy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IFdvdWxkIGl0IGJlIHdpc2UgdG8gY29uc2lkZXIgYW4gYWRkaXRpb25hbCBjYXRlZ29yeSwgc3Vj aCBhcw0KPiA+ID4gPiA+ICJPZmYtbG9hZCBGdW5jdGlvbnMiLCB3aXRoIGFuIGFwcHJvcHJpYXRl IG1vZGVsID8gSSBiZWxpZXZlIGxlYXZpbmcNCj4gPiA+ID4gPiB0aGlzIHVwIHRvIGEgIlZlbmRv ci1TcGVjaWZpYyBGdW5jdGlvbiIgd291bGQgY29uc2lkZXJhYmx5IHJlZHVjZQ0KPiA+ID4gPiA+ IHRoZQ0KPiA+ID4gPiA+IGF0dHJhY3Rpdml0eS9pbnRlcm9wZXJhYmlsaXR5IGd1YXJhbnRlZWQg YnkgRm9yQ0VTLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ID4gPiAtLQ0K PiA+ID4gPiA+IFJvYmVydCBIYWFzDQo+ID4gPiA+ID4gSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJv cmF0b3J5DQo+ID4gPiA+ID4gU+R1bWVyc3RyYXNzZSA0DQo+ID4gPiA+ID4gQ0gtODgwMyBS/HNj aGxpa29uL1N3aXR6ZXJsYW5kDQo+ID4gPiA+ID4gcGhvbmUgKzQxLTEtNzI0LTg2OTggIGZheCAr NDEtMS03MjQtODU3OCANCj4gPiA+ID4gPiBodHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGEN Cg== 2002 Message-Id: Date: Wed, 12 Jun 2002 14:35:23 +0200 From: avri Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Olivier Marce wrote: >=20 > With this in mind, what's about considering COPS + Framework PIB as a c= andidate > to FORCES ? >=20 in many respects this is an excellent suggestion. from the beginning i have thought that cops could well be part of the solution. though it would take creating a specific info model/PIB for ForCES in addition to use of other existing PIBs. with the rumors that fly, however, about the continued acceptance of COPS, is this considered a 'safe' candidate? every time i suggest a cops based solution to someone, they tell me it is dead (after suppressing giggles at my naivet=E9). are companies actually building and _selling_ COPS engines? the reason i ask is getting the info model and PIB done is a significant task, and if COPS is not not really real, then the effort may be better spent elsewhere. a. (a proposer of cops based solutions and co-author of a pib who=20 despairs of ever seeing really real implementations) >=20 > -- > Olivier Marce (ARX Project/Active Network WP) > Alcatel R&I Dept Tel: +33 (0) 1 69 63 41 67 > Route de Nozay Fax: +33 (0) 1 69 63 13 59 > F-91461 Marcoussis Cedex (France) >=20 >=20 >=20 --=20 Mobile: +46 73 029 8019 Office: +46 920 49 3030 In US: +1 401 663 5024 http://homepage.bethepeople.com/mphp/VXEU-2002/avri 2002 Message-Id: Date: Wed, 12 Jun 2002 13:34:36 -0700 From: "Durham, David" Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Avri > -----Original Message----- > From: avri [mailto:avri@apocalypse.org] > > are companies actually building and _selling_ COPS engines? > You can find one COPS-PR engine including a universal PIB compiler at: http://www.intel.com/labs/manage/cops The compiler will syntax check any PIB and automatically generate the APIs for that PIB which plug into the COPS-PR stack. Other companies sell these too, though they probably aren't reading this mailing list. 2002 Message-Id: Date: Wed, 12 Jun 2002 10:17:04 +0200 From: Olivier Marce Organization: Alcatel R&I/ARX Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii "Durham, David" wrote: > > I agree with Joel that the DiffServ MIB has no capabilities model, it is > primarily state. Nevertheless, the DiffServ PIB together with the Framework > PIB actually have a very complete capabilities model. They describe > everything from what data structures the device can understand, to what > values it supports, it even lets you specify how to configure the state on > the device itself. > With this in mind, what's about considering COPS + Framework PIB as a candidate to FORCES ? -- Olivier Marce (ARX Project/Active Network WP) Alcatel R&I Dept Tel: +33 (0) 1 69 63 41 67 Route de Nozay Fax: +33 (0) 1 69 63 13 59 F-91461 Marcoussis Cedex (France) 2002 Message-Id: Date: Tue, 11 Jun 2002 13:13:11 +0200 From: Olivier Marce Organization: Alcatel R&I/ARX Subject: Re: Comment on ForCES Requirements draft: FEs and off-loadofsignalingfunctions MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Robert Am I right when I understand that you expect that the FE could offer some sort of proxy function to the CE (on request of the CE ) ? If so, am I right when I say that this is in the scope of item #3 of Lily's message ? "The third kind of control and configuration is even more powerful and future looking. In addition to dynamic configuration, CEs might be even allowed to download a given functionality onto FEs. I am not sure how we model that yet. But we probably can get by without too concerned with this." Regards Robert Haas wrote: > > Let's see: > > TCP splicing, after the setup phase, boils down to converting sequence numbers back > and forth, and this is indeed a function that takes place "as packets pass through > the FE". An ideal candidate for a "High-Touch Function". > > But what if I'd like to have some sort of control activity take place in the FE as > well, such as TCP setup or timers handling ? The reason is to avoid overloading the > CE with TCP processing, if the FEs are smart enough to handle this directly. This > goes beyond the current FE model. > > Do you also think that some sort of control activity should be allowed to be > "off-loaded" into the FEs ? > -- Olivier Marce (ARX Project/Active Network WP) Alcatel R&I Dept Tel: +33 (0) 1 69 63 41 67 Route de Nozay Fax: +33 (0) 1 69 63 13 59 F-91461 Marcoussis Cedex (France) 2002 Message-Id: Date: Tue, 11 Jun 2002 13:09:36 +0200 From: Olivier Marce Organization: Alcatel R&I/ARX Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Joel "Joel M. Halpern" wrote: > The DiffServ conceptual model (and MIB / PIB) which have been mentioned as > starting points for the capabilities model are actually state models, not > capabilities models. There is no way to tell from these models how many > filters a device can handle, or whether it is capable of > metering. However, you can tell at any given time exactly what filters it > has, how they connect to markers, meters, queues, etc. When you want to > configure additional processing elements into the processing path, you > reference the elements of this model. > What's about the section 1.2 of RFC3084 ? " When a device boots, it opens a COPS connection to its Primary PDP. When the connection is established, the PEP sends information about itself to the PDP in the form of a configuration request. This information includes client specific information (e.g., hardware type, software release, configuration information)." Ins't it an sufficient capabilities description step ? -- Olivier Marce (ARX Project/Active Network WP) Alcatel R&I Dept Tel: +33 (0) 1 69 63 41 67 Route de Nozay Fax: +33 (0) 1 69 63 13 59 F-91461 Marcoussis Cedex (France) 2002 Message-Id: Date: Tue, 11 Jun 2002 10:05:00 -0400 From: "Joel M. Halpern" Subject: Re: Requirements Document - Capabilities Model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed When I last reviewed the COPS PIBs, there was some, but only a little, capability information in the various PIBs. In conversation with some of the COPS folks I have been told that more recently both the framework PIB and the DiffServ PIB have had significant capabilities information added to them. I expect to find time before the IETF meeting to review these two documents. If there is a good start on the capabilities model in the PIBs, then we will definitely use that. Yours, Joel M. Halpern PS: For historical context, at one time the DiffServ PIB was closely aligned to the DiffServ MIB, and the MIB definitely did not have much useful capabilities information. Things change. Note that the information described in the section you quote is pretty minimal when one things about capabilities information. But more has been added in other documents. At 01:09 PM 6/11/2002 +0200, Olivier Marce wrote: >Hi Joel > >"Joel M. Halpern" wrote: > > > The DiffServ conceptual model (and MIB / PIB) which have been mentioned as > > starting points for the capabilities model are actually state models, not > > capabilities models. There is no way to tell from these models how many > > filters a device can handle, or whether it is capable of > > metering. However, you can tell at any given time exactly what filters it > > has, how they connect to markers, meters, queues, etc. When you want to > > configure additional processing elements into the processing path, you > > reference the elements of this model. > > > >What's about the section 1.2 of RFC3084 ? >" When a device boots, it opens a COPS connection to its Primary > PDP. When the connection is established, the PEP sends information > about itself to the PDP in the form of a configuration request. > This information includes client specific information (e.g., > hardware type, software release, configuration information)." > >Ins't it an sufficient capabilities description step ? > > >-- >Olivier Marce (ARX Project/Active Network WP) >Alcatel R&I Dept Tel: +33 (0) 1 69 63 41 67 >Route de Nozay Fax: +33 (0) 1 69 63 13 59 >F-91461 Marcoussis Cedex (France) 2002 Message-Id: Date: Tue, 11 Jun 2002 09:06:35 -0700 From: "Durham, David" Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I agree with Joel that the DiffServ MIB has no capabilities model, it is primarily state. Nevertheless, the DiffServ PIB together with the Framework PIB actually have a very complete capabilities model. They describe everything from what data structures the device can understand, to what values it supports, it even lets you specify how to configure the state on the device itself. -Dave > -----Original Message----- > From: Olivier Marce [mailto:Olivier.Marce@alcatel.fr] > Sent: Tuesday, June 11, 2002 4:10 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Requirements Document - Capabilities Model > > > Hi Joel > > "Joel M. Halpern" wrote: > > > The DiffServ conceptual model (and MIB / PIB) which have > been mentioned as > > starting points for the capabilities model are actually > state models, not > > capabilities models. There is no way to tell from these > models how many > > filters a device can handle, or whether it is capable of > > metering. However, you can tell at any given time exactly > what filters it > > has, how they connect to markers, meters, queues, etc. > When you want to > > configure additional processing elements into the > processing path, you > > reference the elements of this model. > > > > What's about the section 1.2 of RFC3084 ? > " When a device boots, it opens a COPS connection to its Primary > PDP. When the connection is established, the PEP sends information > about itself to the PDP in the form of a configuration request. > This information includes client specific information (e.g., > hardware type, software release, configuration information)." > > Ins't it an sufficient capabilities description step ? > > > -- > Olivier Marce (ARX Project/Active Network WP) > Alcatel R&I Dept Tel: +33 (0) 1 69 63 41 67 > Route de Nozay Fax: +33 (0) 1 69 63 13 59 > F-91461 Marcoussis Cedex (France) > 2002 Message-Id: Date: Mon, 10 Jun 2002 21:34:14 +0200 From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs and off-load ofsignalingfunctions Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Jamal Hadi Salim wrote: > On Mon, 10 Jun 2002, Robert Haas wrote: > > > Jamal, > > > > Thanks for your response. Let me clarify: the Requirements draft limi= ts the FE > > model to express what logical functions can be applied to packets "as= they > > pass through the FE" (see sect. 6.1). "High-Touch" is defined as a ca= tegory of > > such logical functions. > > > > In my opinion, this model rules out functions such as TCP termination= , that > > require processing not only as a packet "passes through the FE" (for = instance, > > handling timers). Functions such as TCP termination are usually perfo= rmed by > > the CE and could be "off-loaded" into the FEs for performance reasons. > > > > Therefore, it seems to me that this issue is not a naming issue, but = rather a > > design choice defining what the FE model must include or not. Do you = agree ? > > > > It depends on how you look at it. And it does become a design issue, bu= t > the model doesnt stop you; > lets take TCP termination, for example: > I would think that the setup phase where the splicing is being set up i= s > a control plane activity. So is the termination. With the current model > you could redirect specific packets to the control plane (eg in this > case, If i understood correctly, would be SYN/FIN packets). > Activity after the connection is "nailed" seems to me belongs to the > FE (such as munging the ACKs and splicing). > On the same token, timers to generate FE events seem to me also to be > control activity. > Did i understand you correctly? > Let's see: TCP splicing, after the setup phase, boils down to converting sequence nu= mbers back and forth, and this is indeed a function that takes place "as packets pas= s through the FE". An ideal candidate for a "High-Touch Function". But what if I'd like to have some sort of control activity take place in = the FE as well, such as TCP setup or timers handling ? The reason is to avoid over= loading the CE with TCP processing, if the FEs are smart enough to handle this direct= ly. This goes beyond the current FE model. Do you also think that some sort of control activity should be allowed to= be "off-loaded" into the FEs ? Thanks > > cheers, > jamal > > > > > Thanks, > > -Robert > > > > Jamal Hadi Salim wrote: > > > > > Robert, > > > > > > Maybe i misunderstood: How does "High-touch" not cover what you are > > > addressing? Is it the naming that bothers you? > > > > > > cheers, > > > jamal > > > > > > On Wednesday 05 June 2002 10:27, Robert Haas wrote: > > > > I'd like to have the opinion of the list/design team regarding th= e issue > > > > below, which might impact the requirements draft to some extent (= sorry > > > > for popping up just before the last call extended deadline): > > > > > > > > Certain FEs begin to provide functions that go beyond per-packet > > > > processing, such as TCP termination, where part of the signaling = is > > > > off-loaded to the FE. The definition of "High-Touch Functions" in= the > > > > draft does not seem to include such functions. > > > > > > > > Would it be wise to consider an additional category, such as "Off= -load > > > > Functions", with an appropriate model ? I believe leaving this up= to a > > > > "Vendor-Specific Function" would considerably reduce the > > > > attractivity/interoperability guaranteed by ForCES. > > > > > > > > Regards, > > > > -- > > > > Robert Haas > > > > IBM Zurich Research Laboratory > > > > S=E4umerstrasse 4 > > > > CH-8803 R=FCschlikon/Switzerland > > > > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.c= om/~rha > > 2002 Message-Id: Date: Mon, 10 Jun 2002 11:33:23 +0200 From: Robert Haas Subject: Re: Comment on ForCES Requirements draft: FEs and off-load ofsignaling functions Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Jamal, Thanks for your response. Let me clarify: the Requirements draft limits t= he FE model to express what logical functions can be applied to packets "as the= y pass through the FE" (see sect. 6.1). "High-Touch" is defined as a catego= ry of such logical functions. In my opinion, this model rules out functions such as TCP termination, th= at require processing not only as a packet "passes through the FE" (for inst= ance, handling timers). Functions such as TCP termination are usually performed= by the CE and could be "off-loaded" into the FEs for performance reasons. Therefore, it seems to me that this issue is not a naming issue, but rath= er a design choice defining what the FE model must include or not. Do you agre= e ? Thanks, -Robert Jamal Hadi Salim wrote: > Robert, > > Maybe i misunderstood: How does "High-touch" not cover what you are > addressing? Is it the naming that bothers you? > > cheers, > jamal > > On Wednesday 05 June 2002 10:27, Robert Haas wrote: > > I'd like to have the opinion of the list/design team regarding the is= sue > > below, which might impact the requirements draft to some extent (sorr= y > > for popping up just before the last call extended deadline): > > > > Certain FEs begin to provide functions that go beyond per-packet > > processing, such as TCP termination, where part of the signaling is > > off-loaded to the FE. The definition of "High-Touch Functions" in the > > draft does not seem to include such functions. > > > > Would it be wise to consider an additional category, such as "Off-loa= d > > Functions", with an appropriate model ? I believe leaving this up to = a > > "Vendor-Specific Function" would considerably reduce the > > attractivity/interoperability guaranteed by ForCES. > > > > Regards, > > -- > > Robert Haas > > IBM Zurich Research Laboratory > > S=E4umerstrasse 4 > > CH-8803 R=FCschlikon/Switzerland > > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~= rha 2002 Message-Id: Date: Mon, 10 Jun 2002 07:16:21 -0400 Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-netlink-03.txt Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : Netlink as an IP Services Protocol Author(s) : J. Salim et al. Filename : draft-ietf-forces-netlink-03.txt Pages : 34 Date : 07-Jun-02 This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. This document is intended as informational in the con- text of prior art for the ForCES IETF working group. The focus of this document is to describe Netlink from a perspective of a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. The document ignores the ability of Netlink as a intra-kernel mes- saging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-netlink-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-netlink-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-netlink-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607132502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-netlink-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-netlink-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607132502.I-D@ietf.org> --OtherAccess-- --NextPart-- 2002 Message-Id: Date: Mon, 10 Jun 2002 05:54:47 -0700 From: Jamal Hadi Salim Subject: Re: Comment on ForCES Requirements draft: FEs and off-load ofsignaling functions MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 10 Jun 2002, Robert Haas wrote: > Jamal, >=20 > Thanks for your response. Let me clarify: the Requirements draft limits t= he FE > model to express what logical functions can be applied to packets "as the= y > pass through the FE" (see sect. 6.1). "High-Touch" is defined as a catego= ry of > such logical functions. >=20 > In my opinion, this model rules out functions such as TCP termination, th= at > require processing not only as a packet "passes through the FE" (for inst= ance, > handling timers). Functions such as TCP termination are usually performed= by > the CE and could be "off-loaded" into the FEs for performance reasons. >=20 > Therefore, it seems to me that this issue is not a naming issue, but rath= er a > design choice defining what the FE model must include or not. Do you agre= e ? >=20 It depends on how you look at it. And it does become a design issue, but the model doesnt stop you; lets take TCP termination, for example: I would think that the setup phase where the splicing is being set up is a control plane activity. So is the termination. With the current model you could redirect specific packets to the control plane (eg in this case, If i understood correctly, would be SYN/FIN packets). Activity after the connection is "nailed" seems to me belongs to the FE (such as munging the ACKs and splicing). On the same token, timers to generate FE events seem to me also to be control activity. Did i understand you correctly?=20 cheers, jamal >=20 > Thanks, > -Robert >=20 > Jamal Hadi Salim wrote: >=20 > > Robert, > > > > Maybe i misunderstood: How does "High-touch" not cover what you are > > addressing? Is it the naming that bothers you? > > > > cheers, > > jamal > > > > On Wednesday 05 June 2002 10:27, Robert Haas wrote: > > > I'd like to have the opinion of the list/design team regarding the is= sue > > > below, which might impact the requirements draft to some extent (sorr= y > > > for popping up just before the last call extended deadline): > > > > > > Certain FEs begin to provide functions that go beyond per-packet > > > processing, such as TCP termination, where part of the signaling is > > > off-loaded to the FE. The definition of "High-Touch Functions" in the > > > draft does not seem to include such functions. > > > > > > Would it be wise to consider an additional category, such as "Off-loa= d > > > Functions", with an appropriate model ? I believe leaving this up to = a > > > "Vendor-Specific Function" would considerably reduce the > > > attractivity/interoperability guaranteed by ForCES. > > > > > > Regards, > > > -- > > > Robert Haas > > > IBM Zurich Research Laboratory > > > S=E4umerstrasse 4 > > > CH-8803 R=FCschlikon/Switzerland > > > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~= rha >=20 2002 Message-Id: Date: Fri, 7 Jun 2002 06:47:13 -0400 From: Jamal Hadi Salim Organization: Znyx Networks Subject: new netlink draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpBbiB1cGRhdGVkIGRyYWZ0IHBvc3RlZCBhdDoNCg0KZnRwOi8vb3BlbmFyY2hpdGVjdC56bnl4 LmNvbS9wdWIvamFtYWwvZHJhZnQtZm9yY2VzLW5ldGxpbmstMDMudHh0DQoNClBsZWFzZSBwcm92 aWRlIGNvbW1lbnRzOyB3ZSBhcmUgaG9waW5nIHRvIGxhc3QgY2FsbCB0aGlzLg0KDQpjaGVlcnMs DQpqYW1hbA0K 2002 Message-Id: Date: Fri, 7 Jun 2002 06:40:09 -0400 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Comment on ForCES Requirements draft: FEs and off-load of signaling functions Comments: To: Robert Haas MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpSb2JlcnQsDQoNCk1heWJlIGkgbWlzdW5kZXJzdG9vZDogSG93IGRvZXMgIkhpZ2gtdG91Y2gi IG5vdCBjb3ZlciB3aGF0IHlvdSBhcmUgDQphZGRyZXNzaW5nPyBJcyBpdCB0aGUgbmFtaW5nIHRo YXQgYm90aGVycyB5b3U/DQoNCmNoZWVycywNCmphbWFsDQoNCk9uIFdlZG5lc2RheSAwNSBKdW5l IDIwMDIgMTA6MjcsIFJvYmVydCBIYWFzIHdyb3RlOg0KPiBJJ2QgbGlrZSB0byBoYXZlIHRoZSBv cGluaW9uIG9mIHRoZSBsaXN0L2Rlc2lnbiB0ZWFtIHJlZ2FyZGluZyB0aGUgaXNzdWUNCj4gYmVs b3csIHdoaWNoIG1pZ2h0IGltcGFjdCB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0IHRvIHNvbWUgZXh0 ZW50IChzb3JyeQ0KPiBmb3IgcG9wcGluZyB1cCBqdXN0IGJlZm9yZSB0aGUgbGFzdCBjYWxsIGV4 dGVuZGVkIGRlYWRsaW5lKToNCj4NCj4gQ2VydGFpbiBGRXMgYmVnaW4gdG8gcHJvdmlkZSBmdW5j dGlvbnMgdGhhdCBnbyBiZXlvbmQgcGVyLXBhY2tldA0KPiBwcm9jZXNzaW5nLCBzdWNoIGFzIFRD UCB0ZXJtaW5hdGlvbiwgd2hlcmUgcGFydCBvZiB0aGUgc2lnbmFsaW5nIGlzDQo+IG9mZi1sb2Fk ZWQgdG8gdGhlIEZFLiBUaGUgZGVmaW5pdGlvbiBvZiAiSGlnaC1Ub3VjaCBGdW5jdGlvbnMiIGlu IHRoZQ0KPiBkcmFmdCBkb2VzIG5vdCBzZWVtIHRvIGluY2x1ZGUgc3VjaCBmdW5jdGlvbnMuDQo+ DQo+IFdvdWxkIGl0IGJlIHdpc2UgdG8gY29uc2lkZXIgYW4gYWRkaXRpb25hbCBjYXRlZ29yeSwg c3VjaCBhcyAiT2ZmLWxvYWQNCj4gRnVuY3Rpb25zIiwgd2l0aCBhbiBhcHByb3ByaWF0ZSBtb2Rl bCA/IEkgYmVsaWV2ZSBsZWF2aW5nIHRoaXMgdXAgdG8gYQ0KPiAiVmVuZG9yLVNwZWNpZmljIEZ1 bmN0aW9uIiB3b3VsZCBjb25zaWRlcmFibHkgcmVkdWNlIHRoZQ0KPiBhdHRyYWN0aXZpdHkvaW50 ZXJvcGVyYWJpbGl0eSBndWFyYW50ZWVkIGJ5IEZvckNFUy4NCj4NCj4gUmVnYXJkcywNCj4gLS0N Cj4gUm9iZXJ0IEhhYXMNCj4gSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQo+IFPkdW1l cnN0cmFzc2UgNA0KPiBDSC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCj4gcGhvbmUgKzQx LTEtNzI0LTg2OTggIGZheCArNDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNv bS9+cmhhDQo= 2002 Message-Id: Date: Wed, 5 Jun 2002 16:27:56 +0200 From: Robert Haas Subject: Comment on ForCES Requirements draft: FEs and off-load of signaling functions Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to have the opinion of the list/design team regarding the issue below, which might impact the requirements draft to some extent (sorry for popping up just before the last call extended deadline): Certain FEs begin to provide functions that go beyond per-packet processing, such as TCP termination, where part of the signaling is off-loaded to the FE. The definition of "High-Touch Functions" in the draft does not seem to include such functions. Would it be wise to consider an additional category, such as "Off-load Functions", with an appropriate model ? I believe leaving this up to a "Vendor-Specific Function" would considerably reduce the attractivity/interoperability guaranteed by ForCES. Regards, -- Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha