From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 1 19:28:49 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10151 for ; Fri, 1 Nov 2002 19:28:44 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007A4228@cherry.ease.lsoft.com>; Fri, 1 Nov 2002 19:31:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30655974 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 1 Nov 2002 19:31:06 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 1 Nov 2002 19:31:04 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gA20SLr26026 for ; Sat, 2 Nov 2002 00:28:21 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gA20JEC04502 for ; Sat, 2 Nov 2002 00:19:15 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110116345423849 for ; Fri, 01 Nov 2002 16:34:54 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 16:31:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C28207.1F79E7A0" Approved-By: "Yang, Lily L" Message-ID: Date: Fri, 1 Nov 2002 16:31:02 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: ietf-yang-forces-model-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C28207.1F79E7A0 Content-Type: text/plain; charset="iso-8859-1" Hi, all Here is an individual contribution on ForCES model v01 that we submitted today. The basic concepts remain the same as in v00, including FE block, stage, directed graph, FE block library, etc. But we did rewrite a lot of the texts and hopefully it results in improved clarity. We also added new contents. A summary of changes: -- Section 3 "capability versus state model": substantial rewrite to clarify the concepts -- Section 4 "FE model" also went thru major rewrite. -- 4.1 "FE block" -- define FE block as the base class and what attributes it contain. -- 4.2 "FE block libraray" -- we added new subsection 4.2.1-8 to discuss the 8 categories of FE functions that are mandated by the requirement draft. Each sub-section either provides some survy into the exisiting work (like DiffServ model and QDDIM model for QoS) or initial definition effort (like Forwarding). These sub-sections are not complete yet but can be used as starting point for discussion. -- 4.3 "FE stage and directed graph" combines the 4.3&4.4 in v00. It is broken down into 4.3.1 "basic concepts" with more clear definition of each node; 4.3.2 "topological versus encoded state" discusses two different appraoches in describing the graph topology. This is new content. 4.3.3 "cascading FE blocks" is old content from v00. -- Section 5 "Data modeling" largely the same. It still mainly just provides a candidate list of 5 entries (instead of 6 in v01 -- we took out SMIng since it is still early in the development phase, probably won't be ready when we need it). It is still a relatively short and easy to read draft --19 pages. So please check it out and provide feedback!!! Thanks, Lily <> ------_=_NextPart_000_01C28207.1F79E7A0 Content-Type: text/plain; name="ietf-yang-forces-model-01.txt" Content-Disposition: attachment; filename="ietf-yang-forces-model-01.txt" Content-Transfer-Encoding: quoted-printable Internet Draft L. Yang=20 Expiration: May 2003 Intel Labs=20 File: draft-yang-forces-model-01.txt J. Halpern=20 Working Group: ForCES =20 R. Gopal=20 Nokia=20 R. Dantu=20 Univ. of = Texas=20 Nov 2002=20 = =20 =20 =20 ForCES Forwarding Element Functional Model=20 =20 =20 =20 draft-yang-forces-model-01.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 Abstract=20 =20 This document defines a functional model for forwarding = elements=20 (FEs) used in the Forwarding and Control Plane Separation = (ForCES)=20 protocol. This model is used to describe the capabilities and = state=20 of ForCES forwarding elements within the context of the ForCES=20 protocol, so that ForCES control elements (CEs) can control the = FEs=20 accordingly. The model is to specify what logical functions are = present in the FEs, what capabilities these functions support, = and=20 in what order these functions are or can be performed. The=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 =20 =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 functions can be expressed and configured. However, the = definition=20 of these individual functions are not described and defined in = this=20 document. =20 =20 Table of Contents =20 =20 = Abstract...........................................................1=20 1. = Definitions.....................................................2=20 2. Motivation and Requirements of FE = model.........................3=20 3. Capability Model versus State = Model.............................3=20 4. FE = Model........................................................6=20 4.1. FE = Blocks..................................................7=20 4.2. FE Block = Library...........................................7=20 4.2.1. QoS = Functions.........................................8=20 4.2.2. Generic Filtering = Functions..........................10=20 4.2.3. Vendor Specific = Functions............................10=20 4.2.4. Port = Functions.......................................10=20 4.2.5. Forwarding = Functions.................................11=20 4.2.6. High-Touch Functions...............................= ..12=20 4.2.7. Security = Functions...................................12=20 4.2.8. Off-loaded = Functions.................................12=20 4.3. FE Stage and Directed Graph of = FE.........................13=20 4.3.1. Basic = Concepts.......................................13=20 4.3.2. Topological versus Encoded State = Approaches..........13=20 4.3.3. Cascading FE = Blocks..................................16=20 5. Data Modeling and = Representation...............................16=20 6. Security = Considerations........................................17=20 7. Intellectual Property = Right....................................17=20 8. IANA = consideration.............................................18=20 9. Normative = References...........................................18=20 10. Informative = References........................................18=20 11. = Acknowledgments...............................................18=20 12. Authors' = Addresses............................................19=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 =20 1. 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 logical functions in the datapath. It is the = building=20 =20 Yang, et. al. Expires May 2003 [Page 2] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 block of FE functionality. This concept abstracts away=20 implementation details from the parameters of interest for=20 configuration, control and management by CE. =20 =20 Forwarding Element (FE) Stage -- Representation of an 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 block. There may be multiple instances of the same functional = block=20 in a FE's datapath. =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 states of = their=20 FEs. [FORCES-REQ] mandates that this capabilities and states=20 information be expressed in the form of an FE model, and this = model=20 will be used as the basis for CEs to control and manipulate = FEs'=20 behavior 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 . The FE model MUST express what logical functions can be = applied=20 to packets as they pass through an FE.=20 . The FE model MUST be capable of supporting/allowing = variations=20 in the way logical functions are implemented on an 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 . The FE model SHOULD be able to support minimal set of = logical=20 functions that are already identified, such as port = functions,=20 forwarding functions, QoS functions, filtering functions, = high- touch functions, security functions, vendor-specific = functions=20 and off-loaded functions. =20 =20 3. Capability Model versus State Model=20 =20 Since the motivation of an FE model is to allow the CEs later = to=20 control and configure the FEs' behavior via ForCES protocol, it = becomes essential to examine and understand what kind of = control and=20 configuration the CEs might do to the FEs. It is also equally=20 essential to understand how configurable or programmable FEs = are=20 today and will be in the near future. To understand the issue=20 better, it is helpful to make a distinction between two = different=20 kinds of FE models =96 the FE state model and FE capability = model. =20 =20 =20 Yang, et. al. Expires May 2003 [Page 3] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 The FE state model describes the current state of the FE, that = is,=20 the instantaneous values or operational behavior of the FE. The = FE=20 state model presents the snapshot view of the FE to the CE. On = the=20 other hand, the FE capability model describes the configurable=20 capabilities of an FE in terms of variations of functions = supported=20 or limitations contained. Conceptually FE capability model = presents=20 the many possible states allowed on an FE. The information on = the=20 capabilities of the FE helps the CE to make more intelligent=20 decision on the configuration it wants to send to the FE. So = the=20 configuration is the desirable state that the FE should be in.=20 Figure 1 shows the concepts of FE state, capabilities and=20 configuration in the context of CE-FE communication via ForCES=20 protocol.=20 =20 +---------+ = +---------+=20 | | FE state: what it is now. | = |=20 | |<------------------------------------| = |=20 | | | = |=20 | CE | FE capabilities: what it can be. | FE = |=20 | |<------------------------------------| = |=20 | | | = |=20 | | FE configuration: what it should be.| = |=20 | |------------------------------------>| = |=20 +---------+ = +---------+=20 =20 Figure 1. Illustration of FE state, capabilities and = configuration=20 in the context of CE-FE communication via ForCES.=20 =20 For example, using the FE state model, an FE may be described = to its=20 CE as the following: =20 - on a given port the packets are classified using a given=20 classification filter;=20 - the given classifier results in packets being metered in a = certain=20 way, and then marked in a certain way;=20 - the packets coming from specific markers are delivered into a = shared queue for handling, while other packets are delivered to = a=20 different queue;=20 - a specific scheduler with specific behavior and parameters = will=20 service these collected queues. =20 On the other hand, the capability model may describe the FE at = the=20 coarsest level such as:=20 - this FE can handle IPv4 and IPv6 forwarding;=20 - this FE can perform classification on the following fields: = source=20 IP address, destination IP address, source port number, = destination=20 port number, etc;=20 - this FE can perform metering;=20 - this FE can handle up to N queues;=20 - this FE can add and remove encapsulating headers of types=20 including IPSec, GRE, L2TP.=20 =20 Where it gets more complicated is for the capability model to = cope=20 with the detailed limits, issues such as how many classifiers = the FE=20 =20 Yang, et. al. Expires May 2003 [Page 4] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 can handle, how many queues, and how many buffer pools the FE = can=20 support, how many meters the FE can provide. There is also the = issue=20 as how flexibly these various functions can be interconnected = within=20 the FE, in another word, how programmable the FE really can be = and=20 how the FE capability model can reflect that.=20 =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 It is clear that in the context of ForCES, a state model is=20 definitely necessary. The question is how much of the = capability=20 model is needed in addition to the state model. A simple state = model=20 without any capability flavor will severely limit ForCES=92s = ability=20 to take advantage of the flexibility offered by programmable = FEs. On=20 the other hand, an all too powerful capability model is = difficult to=20 develop and may impose unnecessary overhead for most of the FEs = that=20 only offer static functionalities. =20 =20 In order to strike a good balance, it is necessary to examine = the=20 kinds of control and configuration that the CEs may do to the = FEs. =20 =20 The first kind of control and configuration is the simplest of = all.=20 It assumes that the logical functions that an FE supports are=20 already given and the interconnection of these functions = remains=20 static in its lifetime. Therefore, the CE can only control = FE=92s=20 behavior by manipulating the parameters for each individual=20 function, but it cannot change either the datapath or the = functions=20 along each datapath. We call this "static FE" control and=20 configuration. For example, Figure 4 and 6 each show 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 4, or the token = bucket=20 parameters associated with meter1 in Figure 6. However, the CE=20 cannot reconfigure the graph topology dynamically, such as = adding=20 another meter or queue onto the FE in Figure 6 on the fly. For = this=20 kind of static control and configuration purpose, the useful FE = model should describe how the graph is connected and what are = the=20 =93dials and knobs=94 (i.e., the parameters or attributes) each = function=20 allows CE to manipulate. It should also include the statistics = and=20 events that FEs can collect and report to CEs. Even for such a=20 =93static FE=94, some capability model at the individual = functions level=20 may be desirable to convey the flexibility of each function.=20 However, a lot of other information may not be necessary, like = the=20 packet formats supported between meter1 and counter1 in Figure = 6 as=20 =20 Yang, et. al. Expires May 2003 [Page 5] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 an example, because such information is only useful when the = graph=20 can be re-configured dynamically on the fly. =20 =20 The second kind of control and configuration builds on top of = the=20 first kind. Using Figure 6 as an example, instead of presenting = the=20 static FE graph to the CE, the FE can convey its capabilities = to the=20 CE by telling "this FE can support one classifier with up to N=20 filters. This FE can also support up to M meters, X queues, = etc." We=20 call this dynamic FE control and configuration. For such = dynamic=20 control and configuration, a more powerful and flexible FE=20 capability model is required. For example, it becomes necessary = to=20 model not only the capability of the building blocks like=20 classifiers, filters, meters etc., but also the linkage = flexibility=20 and constraints between the blocks, so that CE can have the=20 intelligence to build a dynamic FE graph that makes sense.=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. This is similar to the active network concept and so we = call=20 it active FE control and configuration. Like active network, = this is=20 still considered a research area and is not being considered = here. =20 =20 The FE model proposed in this document intends to fully support = the=20 static FE control and configuration at the minimum. It is also = our=20 intention to allow dynamic FE control and configuration to a = certain=20 degree when it makes sense. This FE model currently makes no = attempt=20 to address issues beyond the first two kinds of control and=20 configuration scenarios. =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 model the FE datapath(s) and its packet=20 treatment behavior via a directional graph where each node in = the=20 graph is an instance of a well-defined logical function block. = =20 The FE model defines a generic FE block akin to an abstract = base=20 class in object-oriented terminology. The generic FE block = contains=20 basic information like block type and textual description of = the=20 block function. Based on this generic FE block, a set of = well-known=20 FE logical functions are defined with additional state and=20 capability information pertinent to each specific function. A = name=20 space is used to associate a unique name or ID with each type = of FE=20 block. New logical functions can also be added later to = accommodate=20 future innovation in the forwarding plane, as long as the new=20 functions are modeled as an FE block. With such a set of basic = building blocks defined, any FE can be modeled by a directional = graph where each node is an instance of an FE block, = representing a=20 processing stage in the packet datapath. Each node contains=20 information like block name or ID (indicating the block type), = stage=20 =20 Yang, et. al. Expires May 2003 [Page 6] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 ID (local to FE), number of downstream blocks and a list of the = stage IDs of those downstream blocks. =20 =20 The rest of this section is devoted to describe the informal = data=20 model of FE. The description here is intended to be abstract = and=20 conceptual, and examples are used for illustration purpose = only.=20 Separate document(s) will serve as specifications by using a = formal=20 data modeling language and those specifications should be = consistent=20 with the conceptual model described here. =20 =20 4.1. FE Blocks=20 =20 The generic FE block is the basic building block of the FE = model,=20 like an abstract base class in object-oriented terminology. = Actual=20 FE logical functions like classifiers, IPv4 forwarders and = meters=20 are examples of real FE blocks derived from the generic FE = block=20 concept. =20 =20 A well-defined block has a well-defined packet processing = behavior=20 and a well-defined set of state and capabilities that CE can=20 potentially configure or control via ForCES. A namespace is = needed=20 to specify different types of blocks. The namespace assigns = either a=20 unique ID or label to each distinct block type. Such a = namespace=20 must be extensible so that new functions can be easily added = later. =20 =20 Therefore, the following defines a generic FE Block:=20 - block ID or label which uniquely identifies the block type;=20 - textual description of block function. =20 =20 4.2. FE Block Library=20 =20 We expect a small set of well-understood FE functional blocks = to be=20 defined initially. Such a set of blocks can be viewed as a FE = block=20 library. The minimum set of FE functions required in = [FORCES-REQ]=20 must be part of this library. It is expected that new FE blocks = would be defined and added into this library over time.=20 =20 The actual model for each functional block may differ and = contains=20 information pertinent to the semantics of the function itself.=20 However, some general guideline is still useful. For example,=20 typically it is important to specify information such as:=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;=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 =20 Yang, et. al. Expires May 2003 [Page 7] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =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 do that. The minimum = set of=20 FE functions required in [FORCES-REQ] is listed and discussed=20 briefly in the following subsections. The IETF DiffServ=20 (Differentiated Services) and RAP (Resource Allocation = Protocols)=20 working groups have done some relevant work in modeling the=20 provisioning policy data for QoS functions and filtering = functions.=20 Therefore, we will start our discussion from these related = models.=20 =20 4.2.1. QoS Functions=20 =20 The IETF community has already done some work in modeling the = QoS=20 functions in the datapath. The IETF DiffServ working group has=20 defined an informal data model [RFC3290] for QoS-related = functions=20 like classification, metering, marking, actions of marking,=20 dropping, counting and multiplexing, queueing, etc. The latest = work=20 on DiffServ PIB (Policy Information Base) [DS-PIB] defines a = set of=20 provisioning classes to provide policy control of resources=20 implementing the Diferentiated Services Architecture. DiffServ = PIB=20 also has an element of capability flavor in it that can = potentially=20 enable more dynamic and intelligent configuration of individual = functions and the interconnection of the functions. The IETF = Policy=20 Framework working group is also defining an informational model = [QDDIM] to describe the QoS mechanisms inherent in different = network=20 devices, including hosts. This model is intended to be used = with the=20 QoS Policy Information Model [QPIM] to model how policies can = be=20 defined to manage and configure the QoS mechanisms present in = the=20 datapath of devices.=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 2. An Example Classifier Using DiffServ Model=20 =20 We use the classifier defined in [RFC3290] as an example to=20 illustrate the DiffServ model. "Classifiers are 1:N (fan-out)=20 devices: they take a single traffic stream as input and = generate N=20 logically separate traffic streams as output. Classifiers are=20 parameterized by filters and output streams. Packets from the = input=20 stream are sorted into various output streams by filters which = match=20 the contents of the packet or possibly match other attributes=20 associated with the packet." To further define filters: "A = filter=20 consists of a set of conditions on the component values of a=20 packet's classification key (the header values, contents, and=20 =20 Yang, et. al. Expires May 2003 [Page 8] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 attributes relevant for classification)." Figure 2 illustrates = an=20 example classifier. =20 =20 Based on this conceptual model, [DS-PIB] specifies a classifier = of=20 1:N by N classifier elements. Each classifier element specifies = the=20 following:=20 - element ID which identifies the particular output out of N;=20 - classifier instance ID which identifies the classifier = instance=20 (all the N classifier elements belong to the same classifier = have=20 the same classifier instance ID);=20 - precedence which is an unsigned integer value to represent = the=20 relative order in which classifier elements are applied (the=20 classifier element with the highest precedence will be matched=20 first);=20 - next datapath element which provides a pointer to the next=20 function along this branch out of N fan-out;=20 - filter ID which points to the filter used for this branch = (Note=20 that filter is defined independent of the classifier and used = here=20 as a parameter to the classifier).=20 =20 It is clear from the example above that DiffServ model uses a=20 topological approach to capture the multiple datapath a packet = can=20 potentially take. Graphically, a classifier of 1:N has N output = branches leading to the next N datapath elements. This has=20 significant implication when we consider the interconnected = graph of=20 the functions on FE (see Section 4.3). The alternative is to = use an=20 encoded state approach where each packet gets some state = information=20 associated with it that indicates the datapath it takes next. = For=20 example, using the encoded state approach, a classifier of 1:N = may=20 be represented by just one output branch, if all N of the next=20 datapath elements are of the same block function, say, shaper. = =20 +----------------+=20 | Meter-A |=20 | |=20 ----->| In -|-----PM-1--->=20 | |=20 | Out -|-----PM-2--->=20 +----------------+=20 =20 Figure 3: Meter Followed by Two Preamble Markers=20 =20 The QDDIM model uses the alternative encoded state approach so = that=20 information about the treatment that a packet received on an = ingress=20 interface is allowed to be communicated along with the packet = to the=20 egress interface (see [QDDIM] Section 3.8.3). QDDIM model = represents=20 this information transfer in terms of a packet preamble. Figure = 3=20 shows the same example used in [QDDIM] (section 3.8.3) in which = meter results are captured in a packet preamble. = =93PreamberMarker PM- =20 Yang, et. al. Expires May 2003 [Page 9] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 1 adds to the packet preamble an indication that the packet = exited=20 Meter A as conforming traffic. Similarly, PreambleMarker PM-2 = adds=20 to the preambles of packets that come through it indications = that=20 they exited Meter A as nonconforming traffic. A PreambleMarker=20 appends its information to whatever is already present in a = packet=20 preamble, as opposed to overwriting what is already there.=94 = =93To=20 foster interoperability, the basic format of the information=20 captured by a PreambleMarker is specified.=94 =93Once a meter = result has=20 been stored in a packet preamble, it is available for any = subsequent=20 Classifier to use.=94 =20 =20 Section 4.3 has more discussion on the difference between the=20 topological approach (as used by DiffServ model) and the = encoded=20 state approach (as used by QDDIM). =20 =20 [DS-PIB] also defines a capability model for classifiers by=20 specifying a bit set to indicate the ability to classify based = on IP=20 source address, IP destination address, IP protocol numbers, IP = DSCP=20 field, layer 4 port number for UDP and TCP, and Ipv6 flow ID. = The=20 capability is thus made known by simply setting the bits=20 accordingly. Similar technique is also used to indicate = capabilities=20 of other functions like meters, droppers, etc. =20 =20 While the DiffServ and QDDIM models are not designed with the=20 primary goal of direct machine implementation, we can still use = them=20 as our starting point. =20 =20 4.2.2. Generic Filtering Functions=20 =20 The framework PIB ([FRMWK-PIB]) from the IETF RAP (Resource=20 Allocation Protocol) working group defines four groups of PRCs=20 (Provisioning Classes) that are expected to be common to all = clients=20 that provision policy using COPS-PR ([RFC3084]). One of the = four PRC=20 groups is classifier group, which contains the Base Filter = Class and=20 the other extended filters including the IP Filter, the IEEE = 802=20 Filter and the Internal Label Filter. Even if SPPI ([RFC3159]) = is=20 not the final chosen data model for our FE model, it may still = be=20 valuable to use the work done here as a starting point for the=20 generic filter functions modeling.=20 =20 4.2.3. Vendor Specific Functions=20 =20 New and currently unknown FE functionality can be derived = (i.e.,=20 extended) based on the generic FE Block. The name space used to = identify the FE block type must be extensible such that new = logical=20 functions can be defined and added later to accommodate future=20 innovation in forwarding plane, as long as the new functions = are=20 modeled as an FE block. =20 =20 4.2.4. Port Functions=20 =20 Yang, et. al. Expires May 2003 [Page 10] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 =20 Every FE contains a certain number of interfaces (ports), = including=20 both the inter-NE interfaces and intra-NE interfaces. The = inter-NE=20 interfaces are the external interfaces for the NE to = receive/forward=20 packets from/to the external world. The intra-NE interfaces are = used=20 for FE-FE or FE-CE communications. =20 =20 Certain types of physical ports have sub-interfaces (frame = relay=20 DLCIs, ATM VCs, Ethernet VLans, etc.) as virtual or logical=20 interfaces. Some implementations treat tunnels (e.g., GRE, = L2TP,=20 IPSec, MPLS, etc.) as interfaces, while others do not. = [FORCES-REQ]=20 treats tunneling as high-touch functions and so FE model does = not=20 model tunneling as part of the port functions. Instead, = tunneling is=20 covered in Section 4.2.6. =20 =20 Port function expresses:=20 - the number of ports on the FE;=20 - the sub-interfaces if any;=20 - the static attributes of each port (e.g., port type, = direction,=20 link speed);=20 - the configurable attributes of each port (e.g., IP address,=20 administrative status);=20 - the statistics collected on each port (e.g., number of = packets=20 received); =20 - the current status (up or down).=20 =20 =20 4.2.5. Forwarding Functions=20 =20 Support for IPv4 and IPv6 unicast and multicast forwarding = functions=20 must be provided by the model. =20 =20 Typically, the control plane maintains the Routing Information = Base=20 (RIB), which contains all the routes discovered by all the = routing=20 protocols with all kinds of attributes relevant to the routes. = The=20 forwarding plane uses a different database, the Forwarding=20 Information Base (FIB), which contains only the active subset = of=20 those routes (only the best routes chosen for forwarding) with=20 attributes that are only relevant for forwarding. A component = in the=20 control plane, termed Route Table Manager (RTM), is responsible = to=20 manage the RIB in the CE and maintain the FIB used by the FEs.=20 Therefore, the most important aspect in modeling the forwarding = functions is the data model for the FIB. The model also needs = to=20 support the possibility of multiple paths. =20 =20 At the very minimum, each route in the FIB needs to contain the = following layer-3 information:=20 - the prefix of the destination IP address;=20 - the length of the prefix;=20 - the number of equal-cost multi-path;=20 - the next hop IP address and the egress interface for each = path.=20 =20 =20 Yang, et. al. Expires May 2003 [Page 11] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 Another aspect of the forwarding functions is the method to = resolve=20 a next hop destination IP address into the associated media = address.=20 There are many ways to resolve Layer 3 to Layer 2 address = mapping=20 depending upon link layer. For example, in case of Ethernet = links,=20 the Address Resolution Protocol (ARP, defined in RFC 826) is = used=20 for IPv4 address resolution.=20 =20 Assuming a separate table is maintained in the FEs for address=20 resolution, the following information is necessary for each = address=20 resolution entry:=20 - the next hop IP address;=20 - the media address.=20 =20 Different implementation may have different ways to maintain = the FIB=20 and the resolution table. For example, a FIB may consist of two = separate tables, one to match the prefix to the next hop and = the=20 other to match the next hop to the egress interface. Another=20 implementation may use one table instead. Our model of the=20 forwarding functions should allow such flexibility. =20 =20 4.2.6. High-Touch Functions=20 =20 High-touch functions are those that take action on the contents = or=20 headers of a packet based on content other than what is found = in the=20 IP header. Examples of such functions include NAT, ALG, = firewall,=20 tunneling and L7 content recognition. =20 =20 The ForCES working group first needs to agree upon a small set = of=20 common high-touch functions with well-defined behavior to be=20 included in the initial FE block library. =20 =20 4.2.7. Security Functions=20 =20 The FE model must be able to describe the types of encryption = and/or=20 decryption functions that an FE supports and the associated=20 attributes for such functions.=20 =20 4.2.8. Off-loaded Functions=20 =20 In addition to the packet processing functions that are typical = to=20 find on the FEs, some logical functions may also be executed=20 asynchronously by some FEs, according to a certain finite-state = machine, triggered not only by packet events, but by timer = events as=20 well. Examples of such functions include finite-state machine=20 execution required by TCP termination or OSPF Hello processing = off- loaded from the CE. The FE model must be capable of expressing = these=20 asynchronous functions, so that the CE may take advantage of = such=20 off-loaded functions on the FEs.=20 =20 The ForCES working group first needs to agree upon a small set = of=20 such off-loaded functions with well-understood behavior and=20 interactions with the control plane. =20 =20 =20 Yang, et. al. Expires May 2003 [Page 12] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 4.3. FE Stage and Directed Graph of FE =20 =20 With a set of basic FE functions defined in the block library, = we=20 are ready to model any FE=92s packet processing behavior by a=20 directional graph where each node is an instance of an FE = block,=20 representing a processing stage in the packet datapath. This = section=20 describes the details behind such a =93directed graph=94 FE = model.=20 =20 4.3.1. Basic Concepts=20 =20 An FE stage is simply an instance of an FE block within an FE's = datapath. As a packet flows through an FE along a datapath, it = flows=20 through one or multiple distinct stages, with each stage=20 instantiating a certain FE logical function. Each FE allocates = an=20 FE-unique stage ID to each of its stages and passes the stage = ID=20 along with the corresponding block type as part of the FE stage = information. This allows multiple instances of the same block=20 present in a FE's datapath. Using NAT as an example, one NAT=20 function is typically performed before the forwarding stage = (packets=20 arriving externally have their public addresses replaced with=20 private addresses) and one NAT function is performed after (for = packets exiting the domain, their private addresses are = replaced by=20 public ones). So there are three stages (NAT, forwarding, and = NAT=20 again) in this example datapath, with two NAT instances present = in=20 two different stages. =20 =20 A static FE can be modeled by a directed graph interconnecting = all=20 the stages present in the FE. Each node in the graph = corresponds to=20 a stage. In order to represent the directed interconnection = between=20 two consecutive stages along a datapath, each stage contains a = =93next=20 stage=94 pointer that is simply the stage ID of its next stage = in the=20 graph. Therefore, the following defines an FE stage (i.e., a = node in=20 the FE gragh):=20 - stage identifier which uniquely identifies the node within = this FE=20 graph;=20 - block type which identifies the block function that this = stage is=20 an instance of;=20 - number of downstream stages which corresponds to the number = of=20 downstream nodes connected to this stage;=20 - downstream stage identifiers which corresponds to the set of=20 downstream nodes connected to this stage.=20 =20 With such information defined for each FE stage, it is now = possible=20 for CE to query the state of the static FE graph by querying = for the=20 initial (ingress) stages of the graph and then traversing the = whole=20 graph in a node-by-node fashion. =20 =20 4.3.2. Topological versus Encoded State Approaches=20 =20 As pointed out in Section 4.2.1, there are potentially two = different=20 approaches to model the nodes and the connections between the = nodes=20 in the FE graph, namely, the topological approach and the = encoded=20 state approach. =20 =20 Yang, et. al. Expires May 2003 [Page 13] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =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 type=3D type=3D type=3D=20 Enet-IngP-Mgr, IPv4-L3-LPM-fwd, = Enet-EgP-Mgr,=20 #downstream=3D1, #downstream=3D1, = #downstream=3D1,=20 downstream=3D{2} downstream=3D{3} = downstream=3Dnone=20 } } }=20 =20 Figure 4. A simple example of an FE graph using encoded = state=20 approach.=20 =20 =20 Input +------------+ +------------+ = output=20 ------->|Ingr-Port #1|-->| |=20 +------------+ | | +------------+=20 ------->|Ingr-Port #2|-->| = |-->|EgressPort#1|----->=20 +------------+ | | +------------+=20 ------->|Ingr-Port #3|-->|IPv4 L3 LPM = |-->|EgressPort#2|----->=20 +------------+ |Forwarder | +------------+=20 ------->|Ingr-Port #4|-->| = |-->|EgressPort#3|----->=20 +------------+ | | +------------+=20 ------->|Ingr-Port #5|-->| = |-->|EgressPort#4|----->=20 +------------+ | | +------------+=20 ------->|Ingr-Port #6|-->| |=20 +------------+ +------------+ =20 =20 {stage ID=3D1 {stage ID=3D7, {stage = ID=3D8,=20 type=3D type=3D type=3D=20 Enet-Ing-port, IPv4-L3-LPM-fwd, = Enet-Eg-port,=20 #downstream=3D1, #downstream=3D4, = #downstream=3D1,=20 downstream=3D{7} downstream=3D = downstream=3Dnone=20 } {8,9,10,11} }=20 . . . } . . .=20 {stage ID=3D6 {stage = ID=3D11,=20 type=3D type=3D=20 Enet-Ing-port, = Enet-Eg-port-Mgr,=20 #downstream=3D1, = #downstream=3D1,=20 downstream=3D{7} = downstream=3Dnone=20 } }=20 =20 Figure 5. The same example as in Figure 4 using = topological=20 approach.=20 =20 Using the topological approach as exemplified by DiffServ = model,=20 there are N connections between a fan-out node of 1:N (e.g., a=20 classifier) and its next stages. Using the encoded state = approach,=20 =20 Yang, et. al. Expires May 2003 [Page 14] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 fewer connections are typically needed between the same fan-out = node=20 and its next stages, because each packet carries some state=20 information as metadata that the next stage nodes can interpret = and=20 invoke different packet treatment. Pure topological approaches = can=20 be overly complex to represent because they force on to build=20 elaborate topologies with a lot more connections. An encoded = state=20 approach is nicer in that it allows one to simplify the graph = and=20 represent the functional blocks with more clarity. But it does=20 require extra metadata to be carried along with the packet, = like the=20 preamble in the QDDIM model.=20 =20 For example in Figure 4, stage #2 (IPv4 L3 LPM Forwarder) = generates=20 some metadata 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. = Figure 5=20 shows how the FE graph looks like when using the pure = topological=20 approach instead, assuming 6 ingress and 4 egress ports. It is = clear=20 that Figure 5 is unwieldy compared to Figure 4.=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 6. An FE example with multiple datapath.=20 =20 Note that the FE graph can represent largely arbitrary = topologies of=20 the stages, regardless which approach (topological or encoded = state)=20 is taken. For example, Figure 6 shows an FE implementing QoS=20 functions via a combination of logical functions like = classifier,=20 =20 Yang, et. al. Expires May 2003 [Page 15] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 meter, marker, queue, scheduler, etc. Both approaches are able = to=20 represent such an FE graph. 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 = any=20 downstream stages whereas no other stage may refer to an = ingress=20 port function as one of its downstream stages. =20 =20 4.3.3. Cascading FE Blocks=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 7 shows = two=20 cascading FE blocks. Block #1 contains one ingress port = function but=20 no egress port function, while block #2 contains one egress = port=20 function but no ingress port function. It is possible to = connect=20 these two FE blocks together to achieve the complete = ingress-to- egress packet processing function. This provides the = flexibility to=20 spread the functions across multiple FEs and interconnect them=20 together later for certain applications. =20 =20 -------------------------------------------------------=20 | +---------+ +------------+ +---------+ |=20 input| | | | | | output |=20 ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ = | | 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 7. An example of two different FE blocks connected = together.=20 =20 5. Data Modeling and Representation=20 =20 A formal data modeling language is needed to represent the=20 conceptual FE model described in this document and a full=20 specification will be written using such a data modeling = language.=20 It is also necessary to identify a data representation method = for=20 over-the-wire transport of the FE model data. =20 =20 The following is a list of some potential candidates for=20 consideration. For the moment, we intend to leave this as an = open=20 issue and much debate is needed in the ForCES WG before a = decision=20 =20 Yang, et. al. Expires May 2003 [Page 16] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 can be made. Therefore, we only provide the candidate list and = some=20 initial discussion here without drawing a conclusion yet. =20 =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] = - UML (Universal Modeling Language)=20 =20 Most of the candidates here, with the notable exception of UML, = are=20 capable of representing the model in the document and = over-the-wire.=20 Of course, it is also possible to choose one data model = language for=20 specification in the document and later allow several = over-the-wire=20 representations to map the model into different = implementations. =20 =20 XML has the advantage of being human and machine readable with=20 widely available tools support. However, it is very verbose and = hence less efficient for over-the-wire transport. It also = requires=20 XML parsing functions in both the CE and FE and hence may = impose=20 large footprint esp. for FEs. Currently XML is not yet widely=20 deployed and used in network elements. XML for network = configuration=20 in general remains an open area that still requires substantial = investigation and experiment in IETF. =20 =20 ASN.1 format is human readable and widely used in network = protocols.=20 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=20 used to define Policy Information Base (PIB) for COPS. = Substantial=20 investment has been made in SMI/MIBs/SNMP by IETF and the = Internet=20 community collectively has had many years of design and = operation=20 experience with SMI/MIBs/SNMP. However, it is also well = recognized=20 that SMI/MIBs/SNMP is not well suited for configuration and so=20 SPPI/PIBs/COPS-PR attempts to optimize for network provisioning = and=20 configuration. =20 =20 UML is the software industry=92s standard language for = specifying,=20 visualizing, constructing and documenting the artifacts of = software=20 systems. It is a powerful tool for data modeling. However, it = does=20 not provide a data representation format for over-the-wire=20 transport. =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. The = associated=20 communication protocol (i.e., ForCES protocol) will be defined = in=20 separate documents and so the security issues will be addressed = there.=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 Yang, et. al. Expires May 2003 [Page 17] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 =20 8. IANA consideration=20 =20 A namespace is needed to uniquely identify the FE block type = for=20 each FE logical function. =20 =20 9. Normative References=20 =20 [RFC1812] F. Baker, =93Requirements for IP Version 4 Routers", = June=20 1995.=20 =20 [RFC1155] M. Rose, et. al., =93Structure and Identification of=20 Management Informationfor TCP/IP-based Internets", = May=20 1990.=20 =20 [RFC3084] K. Chan, et. al., =93COPS Usage for Policy = Provisioning,=94=20 March 2001.=20 =20 [RFC3159] K. McCloghrie, et. al., =93Structure of Policy = Provisioning=20 Information (SPPI)", August 2001.=20 =20 [RFC3290] Y. Bernet, et. al., =93An Informal Management Model = for=20 Diffserv Routers=94, May 2002.=20 =20 10. Informative References=20 =20 [FORCES-REQ] H. Khosravi, et. al., =93Requirements for = Separation of=20 IP Control and Forwarding", work in progress, Oct = 2002,=20 .=20 =20 [DS-PIB] M. Fine, et. al., =93Differentiated Services Quality = of=20 Service Policy Information Base=94, work in = progress, June=20 2002, .=20 =20 [FRMWK-PIB] M. Fine, et. al., =93Framework Policy Information = Base=94,=20 work in progress, June 2002, .=20 =20 [QDDIM] B. Moore, et. al., =93Information Model for Describing = Network=20 Device QoS Datapath Mechanisms=94, work in progress, = May=20 2002, = .=20 =20 [QPIM] Y. Snir, et. al., =93Policy Framework QoS Information = Model=94,=20 work in progress, Nov 2001, = ; Tue, 5 Nov 2002 09:49:46 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.007AC7C9@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 9:52:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30859604 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 5 Nov 2002 09:52:13 -0500 Received: from 143.183.152.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 09:52:13 -0500 Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id gA5Eplx04705 for ; Tue, 5 Nov 2002 14:51:57 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110506520627637 for ; Tue, 05 Nov 2002 06:52:06 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 06:51:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Tue, 5 Nov 2002 06:51:42 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Framework Last Call - ends Monday, November 18, 2 002 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, The authors of the ForCES framework have requested working group last call and the document appears to have stabilized and reached a completed state. URL: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-03.txt This email begins a last call period for the ForCES framework document. This last call period is approximately two weeks in length and ends on Monday, November 18th at the ForCES meeting in IETF 55. Please send to the list any suggested changes and/or comments on this document. Thanks, David & Patrick From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 6 09:42:23 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22931 for ; Wed, 6 Nov 2002 09:42:22 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007B2058@cherry.ease.lsoft.com>; Wed, 6 Nov 2002 9:44:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30953438 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 6 Nov 2002 09:43:04 -0500 Received: from 194.196.100.234 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 6 Nov 2002 09:43:03 -0500 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA6EgqZ1080022 for ; Wed, 6 Nov 2002 15:42:57 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gA6Eglo9066860 for ; Wed, 6 Nov 2002 15:42:47 +0100 Received: from dhcp70-217.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46960 from ; Wed, 6 Nov 2002 15:42:46 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Patrick Droz Message-ID: <3DC92A66.10204@zurich.ibm.com> Date: Wed, 6 Nov 2002 15:42:46 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: upcoming ForCES agenda To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit please either contact David or me if you want to get a slot at the ForCES meeting. So far I have gotten only one request. There is one more week to go before the agenda deadline. Thanks, Patrick -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 7 11:31:01 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01106 for ; Thu, 7 Nov 2002 11:31:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.007B7B95@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 11:33:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31018395 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 7 Nov 2002 11:33:28 -0500 Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 11:33:27 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gA7GVjn08323 for ; Thu, 7 Nov 2002 16:31:46 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gA7GTNY06637 for ; Thu, 7 Nov 2002 16:29:23 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110708315814817 for ; Thu, 07 Nov 2002 08:31:58 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 08:33:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Thu, 7 Nov 2002 08:33:16 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: FW: HPCA9: Network Processor Workshop CFP *Deadline Extension* To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Forwarded as relevant. Cheers, David -----Original Message----- From: Patrick Crowley [mailto:pcrowley@cs.washington.edu] Sent: Wednesday, November 06, 2002 5:04 PM To: end2end-interest@postel.org; ixp1200@CS.Princeton.EDU; opensig-announce@comet.columbia.edu; ActiveNets_Wire@ittc.ukans.edu; FORCES@PEACH.EASE.LSOFT.COM; itc@comsoc.org Subject: FW: HPCA9: Network Processor Workshop CFP *Deadline Extension* Due to the number of requests received, the submission deadline has been extended to November 15. ********************************************************************* CALL FOR PAPERS ********************************************************************* Workshop on Network Processors http://www.cs.washington.edu/NP2/ Anaheim, California February 9, 2003 Held in conjunction with HPCA 9 - The 9th International Symposium on High-Performance Computer Architecture http://www.cs.arizona.edu/hpca9/ February 8-12, 2003 OVERVIEW As the performance and importance of digital communication networks have increased, so have the challenges in network component design. To meet ever-escalating performance, flexibility and economy requirements, the networking industry has opted to build products around network processors. These processors are programmable yet application-specific; their designs are tailored to efficiently implement communications applications such as: routing, protocol analysis, voice and data convergence, firewalls, VPNs, and QoS. The term network processor is used here in the most generic sense -- from task-specific processors, such as classification and encryption engines, to more general-purpose packet or communications processors. Network processor design is an emerging field with numerous challenges and opportunities. The goal of this workshop is to provide a forum for engineers and scientists from academia and industry to discuss their latest research in the architecture, design, programming, and use of these devices. We are especially interested in attracting new or experimental techniques and approaches. IMPORTANT DATES Papers due : **November 15, 2002** Notification to authors : January 6, 2003 Final papers due: January 24, 2003 TOPICS Topics of particular interest include, but are not limited to: * Architectures for network, communications, or packet processors * Network Processor theory of design * Novel commercial product designs * Search engines * Benchmarking and performance analysis * Coprocessors such as CAMs and other support devices * Interfaces to high-speed packet buses and switch fabrics * Techniques for accelerating network services * Voice processing and packet telephony * Software aspects of programming processors for networking * Applications, including packet forwarding, packet classification, QoS, encryption and security, compression, etc. The workshop will consist of a keynote address, paper presentations and a panel session. In addition to academic and research contributions, product descriptions that focus on architecture (hardware or software) or performance analysis will also be considered. Attendees will receive a copy of workshop papers. After the workshop, selected papers will be published in a book entitled Network Processor Design: Issues and Practices Volume II (Morgan Kaufmann Publishers). SUBMISSIONS Please submit full papers (single spaced, font size 11, 1 inch margins, not exceeding 15 pages) in Adobe PDF format for review to pcrowley@cs.washington.edu. PROGRAM COMMITTEE Anant Agarwal, MIT Andrew Campbell, Columbia University Patrick Crowley, University of Washington Mark Franklin, Washington University in St. Louis Haldun Hadimioglu, Polytechnic University Kenneth Mackenzie, Georgia Tech Bill Mangione-Smith, UCLA John Marshall, Cisco Systems Danial Mylnek, EPFL (Switzerland) Mohammad Peyravian, IBM Corporation Dimitrios Stiliadis, Bell Labs Jonathan Turner, Washington University in St. Louis Mateo Valero, UPC (Spain) Tilman Wolf, University of Massachusetts Peter Z. Onufryk, IDT Raj Yavatkar, Intel Corporation ORGANIZERS Patrick Crowley, University of Washington (pcrowley@cs.washington.edu) Mark Franklin, Washington University in St. Louis (jbf@ccrc.wustl.edu) Haldun Hadimioglu, Polytechnic University (haldun@photon.poly.edu) Peter Z. Onufryk, IDT (peter.onufryk@idt.com) NOTES FROM NP1 (2002): Selected papers from NP1 and additional industry contributions will appear in Network Processor Design : Issues and Practices Volume I (Morgan Kaufmann Publishers, September 2002). From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 8 03:28:04 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10379 for ; Fri, 8 Nov 2002 03:28:03 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007BA489@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 3:30:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31131862 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 8 Nov 2002 03:30:33 -0500 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 03:30:33 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gA88QGb21190 for ; Fri, 8 Nov 2002 08:26:16 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gA88QT720072 for ; Fri, 8 Nov 2002 08:26:29 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110800290527210 for ; Fri, 08 Nov 2002 00:29:05 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 00:30:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Khosravi, Hormuzd M" Message-ID: Date: Fri, 8 Nov 2002 00:30:31 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Framework Last Call - ends Monday, November 1 8, 2 002 Comments: cc: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Hi Lily, All I had the following comments/suggestions on the Framework draft (I wish I could have done this earlier, sorry about the delay) In Figure 3, you might want to show "OSPF Offload" as an example FE function. In Section 3.2, you have mentioned "Upon detection of CE1 failure, perhaps across Fr reference"...add.."or Fp reference" since loss of association, which could be caused by CE failure, is part of Fp Requirements. In Section 3.2, you might want to mention that "Fi reference point could be used by FEs to discovery their (inter-FE) topology, perhaps during pre-association phase." In Section 4.1.2, you should mention that "the FE Managers could also assign unique FE identifiers to FEs using this reference point, which could be used in post association phase to express FE topology". Editorial- section 4.3,2nd para - should be "Section 3.2 already explains..." section 9.2 - new version of Requirements 0.7 is out Thanks Hormuzd -----Original Message----- From: Putzolu, David [mailto:david.putzolu@INTEL.COM] Sent: Tuesday, November 05, 2002 6:52 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] ForCES Framework Last Call - ends Monday, November 18, 2 002 All, The authors of the ForCES framework have requested working group last call and the document appears to have stabilized and reached a completed state. URL: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-03.txt This email begins a last call period for the ForCES framework document. This last call period is approximately two weeks in length and ends on Monday, November 18th at the ForCES meeting in IETF 55. Please send to the list any suggested changes and/or comments on this document. Thanks, David & Patrick From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 12 17:26:07 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18420 for ; Tue, 12 Nov 2002 17:26:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.007C6D5B@cherry.ease.lsoft.com>; Tue, 12 Nov 2002 17:28:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31426375 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Nov 2002 17:28:39 -0500 Received: from 143.183.152.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 12 Nov 2002 17:28:39 -0500 Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id gACMSDe07712 for ; Tue, 12 Nov 2002 22:28:23 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002111214282402014 for ; Tue, 12 Nov 2002 14:28:24 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 14:27:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Tue, 12 Nov 2002 14:27:55 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Last call complete on updated requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, The requirements document, which had some small updates made in response to AD feedback, has completed a second last call. This document is now being forwarded to the ADs and IESG for consideration as an RFC. URL: http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-07.txt Cheers, David From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 13 04:44:03 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26095 for ; Wed, 13 Nov 2002 04:44:02 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.007C813B@cherry.ease.lsoft.com>; Wed, 13 Nov 2002 4:46:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31459426 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Nov 2002 04:46:35 -0500 Received: from 194.196.100.235 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 13 Nov 2002 04:46:34 -0500 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAD9kVQk062280 for ; Wed, 13 Nov 2002 10:46:32 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAD9kUlO135336 for ; Wed, 13 Nov 2002 10:46:30 +0100 Received: from dhcp71-86.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA37512 from ; Wed, 13 Nov 2002 10:46:29 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Patrick Droz Message-ID: <3DD21F74.9060703@zurich.ibm.com> Date: Wed, 13 Nov 2002 10:46:28 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Current Agenda To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit attached is the current agenda. The activity on Netlink2 will not be presented due to some emergency. Regards, Patrick Agenda ForCES WG, IETF 55 ------------------------- Monday, November 18th, 9:00 - 11:30 Agenda bashing Drafts: ForCES Forwarding Element Functional Model http://www.ietf.org/internet-drafts/draft-yang-forces-model-01.txt 30 min -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 19 14:08:03 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13480 for ; Tue, 19 Nov 2002 14:08:03 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007E8BF9@cherry.ease.lsoft.com>; Tue, 19 Nov 2002 14:10:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31952770 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 19 Nov 2002 14:10:38 -0500 Received: from 194.196.100.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 19 Nov 2002 14:10:38 -0500 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAJJAaeW005068 for ; Tue, 19 Nov 2002 20:10:36 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAJJAanb060166 for ; Tue, 19 Nov 2002 20:10:36 +0100 Received: from dhcp70-16.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40126 from ; Tue, 19 Nov 2002 20:10:35 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate-4.de.ibm.com id gAJJAaeW005068 Approved-By: Robert Haas Message-ID: <3DDA8CAA.6030708@zurich.ibm.com> Date: Tue, 19 Nov 2002 20:10:34 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: clarifications needed on FACT To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA13480 Hi, In my attempt to understand the FACT proposal, I would appreciate a few clarifications from the authors: 1) how are CE-sets meant to be used, and why is there no FE-set equivalent ? 2) why rely on the message type to infer in which direction the message is going (FE-to-CE or CE-to-FE) ? 3) why is the association SETUP message not described in the draft ? 4) are FE-CE associations (or logical connections) always made of one FE and one CE only ? With many thanks, -- Robert Haas IBM Zurich Research Laboratory Säumerstrasse 4 CH-8803 Rüschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 22 16:37:23 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04771 for ; Fri, 22 Nov 2002 16:37:08 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007F40AB@cherry.ease.lsoft.com>; Fri, 22 Nov 2002 16:39:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32239931 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 22 Nov 2002 16:39:46 -0500 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 22 Nov 2002 16:39:46 -0500 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAMLdkj01514 for ; Fri, 22 Nov 2002 15:39:46 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 22 Nov 2002 15:39:45 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Nov 2002 13:39:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: clarifications needed on FACT Thread-Index: AcKP/2jdxAmHECS1Sv+OVTzXSviKXACbqIPA X-OriginalArrivalTime: 22 Nov 2002 21:39:45.0244 (UTC) FILETIME=[AC7921C0:01C2926F] Approved-By: ram.gopal@NOKIA.COM Message-ID: Date: Fri, 22 Nov 2002 16:39:43 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "(Ram Gopal )" Subject: Re: clarifications needed on FACT To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA04771 Hello Roberts, I want to add to Alex comments for first question. Comments are inline. > > Hi, > In my attempt to understand the FACT proposal, I would > appreciate a few > clarifications from the authors: > > 1) how are CE-sets meant to be used, and why is there no > FE-set equivalent ? CE-set is a logical grouping. One or more CE's can control a FE. CE-Set is a major number and CE-Id is a minor number. CE-Tag represents CE-set and CE-ID. One or more CE belonging to a CE-set controls a FE. FE's will not respond to a CE's request if that CE is not belonging to a CE-set. There is no need for FE-set. What CE-set can control FE is part of pre-configuration for this protocol. Regards Ramg