idnits 2.17.1 draft-ietf-forces-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 107 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 52 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7498 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-2119' on line 133 -- Looks like a reference, but probably isn't: 'DiffServ' on line 1726 == Unused Reference: '3' is defined on line 2288, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft L. Yang 3 Expiration: April 2004 Intel Labs 4 File: draft-ietf-forces-model-01.txt J. Halpern 5 Working Group: ForCES Megisto Systems 6 R. Gopal 7 Nokia 8 A. DeKok 9 IDT Inc. 10 Z. Haraszti 11 S. Blake 12 Ericsson 13 October 2003 15 ForCES Forwarding Element Model 17 draft-ietf-forces-model-01.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are 23 working documents of the Internet Engineering Task Force (IETF), 24 its areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as ``work in 31 progress.'' 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document defines the forwarding element (FE) model used in the 42 Forwarding and Control Plane Separation (ForCES) protocol. The 43 model represents the capabilities, state and configuration of 44 forwarding elements within the context of the ForCES protocol, so 45 that control elements (CEs) can control the FEs accordingly. More 46 specifically, the model describes the logical functions that are 47 present in an FE, what capabilities these functions support, and 48 how these functions are or can be interconnected. This FE model is 49 intended to satisfy the model requirements specified in the ForCES 50 requirements draft [1]. A list of the basic logical functional 51 blocks (LFBs) is also defined in the LFB class library to aid the 52 effort in defining individual LFBs. 54 Table of Contents 56 Abstract.........................................................1 57 1. Definitions...................................................3 58 2. Introduction..................................................5 59 2.1. Requirements on the FE model.............................6 60 2.2. The FE Model in Relation to FE Implementations...........6 61 2.3. The FE Model in Relation to the ForCES Protocol..........6 62 2.4. Modeling Language for FE Model...........................7 63 2.5. Document Structure.......................................8 64 3. FE Model Concepts.............................................8 65 3.1. State Model and Capability Model.........................8 66 3.2. LFB Modeling............................................11 67 3.2.1. LFB Input and Input Group..........................13 68 3.2.2. LFB Output and Output Group........................15 69 3.2.3. Packet Type........................................16 70 3.2.4. Metadata...........................................16 71 3.2.5. LFB Versioning.....................................18 72 3.2.6. LFB Inheritance....................................18 73 3.3. FE Datapath Modeling....................................19 74 3.3.1. Alternative Approaches for Modeling FE Datapaths...19 75 3.3.2. Configuring the LFB Topology.......................23 76 4. LFB Model -- LFB and Associated Data Definitions.............27 77 4.1. General Data Type Definitions...........................28 78 4.1.1. Arrays.............................................29 79 4.1.2. Structures.........................................29 80 4.1.3. Augmentations......................................30 81 4.2. Metadata Definitions....................................30 82 4.3. Frame Format Definitions................................30 83 4.4. LFB Class Definitions...................................31 84 4.4.1. LFB Inheritance....................................31 85 4.4.2. LFB Inputs.........................................31 86 4.4.3. LFB Outputs........................................32 87 4.4.4. LFB Attributes.....................................33 88 4.4.5. LFB Operational Specification......................34 89 5. LFB Topology Model (To be written)...........................34 90 6. FE Level Attributes (To be written)..........................35 91 7. LFB Class Library............................................35 92 7.1. Port LFB................................................35 93 7.2. Dropper LFB.............................................36 94 7.3. Redirector (de-MUX) LFB.................................36 95 7.4. Scheduler LFB...........................................36 96 7.5. Queue LFB...............................................36 97 7.6. Counter LFB.............................................37 98 7.7. Meter LFB and Policer LFB...............................37 99 7.8. Classifier LFB..........................................37 100 7.9. Modifier LFB............................................38 101 7.10. Packet Header Rewriter LFB.............................38 102 8. Satisfying the Requirements on FE Model......................39 103 8.1. Port Functions..........................................39 104 8.2. Forwarding Functions....................................40 105 8.3. QoS Functions...........................................41 106 8.4. Generic Filtering Functions.............................41 107 8.5. Vendor Specific Functions...............................42 108 8.6. High-Touch Functions....................................42 109 8.7. Security Functions......................................42 110 8.8. Off-loaded Functions....................................43 111 8.9. IPFLOW/PSAMP Functions..................................43 112 9. Using the FE model in the ForCES Protocol....................43 113 9.1. FE Topology Query.......................................45 114 9.2. FE Capability Declarations..............................46 115 9.3. LFB Topology and Topology Configurability Query.........47 116 9.4. LFB Capability Declarations.............................47 117 9.5. State Query of LFB Attributes...........................48 118 9.6. LFB Attribute Manipulation..............................48 119 9.7. LFB Topology Re-configuration...........................49 120 10. Acknowledgments.............................................49 121 11. Security Considerations.....................................49 122 12. Normative References........................................49 123 13. Informative References......................................50 124 14. Authors' Addresses..........................................50 125 15. Intellectual Property Right.................................51 126 16. IANA consideration..........................................51 128 Conventions used in this document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 132 this document are to be interpreted as described in [RFC-2119]. 134 1. Definitions 136 A set of terminology associated with the ForCES requirements is 137 defined in [1] and is not copied here. The following list of 138 terminology is relevant to the FE model defined in this document. 140 FE Model -- The FE model is designed to model the logical 141 processing functions of an FE. The FE model proposed in this 142 document includes three components: the modeling of individual 143 logical functional blocks (LFB model), the logical interconnection 144 between LFBs (LFB topology) and the FE level attributes including 145 FE capabilities. The FE model provides the basis to define the 146 information elements exchanged between the CE and the FE in the 147 ForCES protocol. 149 Datapath -- A conceptual path taken by packets within the 150 forwarding plane, inside an FE. There might exist more than one 151 datapath within an FE. 153 LFB (Logical Function Block) class (or type) -- A template 154 representing a fine-grained, logically separable and well-defined 155 packet processing operation in the datapath. LFB classes are the 156 basic building blocks of the FE model. 158 LFB (Logical Function Block) Instance -- As a packet flows through 159 an FE along a datapath, it flows through one or multiple LFB 160 instances, with each implementing an instance of a certain LFB 161 class. There may be multiple instances of the same LFB in an FE's 162 datapath. Note that we often refer to LFBs without distinguishing 163 between LFB class and LFB instance when we believe the implied 164 reference is obvious for the given context. 166 LFB Model -- The LFB model describes the content and structures in 167 LFB and associated data definition. There are four types of 168 information defined in the LFB model. The core part of the LFB 169 model is LFB class definitions while the other three are to define 170 the associated data including common data types, supported frame 171 formats and metadata. 173 LFB Metadata -- Metadata is used to communicate per-packet state 174 from one LFB to another, but is not sent across the network. The 175 FE model defines how such metadata is identified, produced and 176 consumed by the LFBs, but not how metadata is encoded within an 177 implementation. 179 LFB Attribute -- Operational parameters of the LFBs that must be 180 visible to the CEs are conceptualized in the FE model as the LFB 181 attributes. The LFB attributes include, for example, flags, single 182 parameter arguments, complex arguments, and tables that the CE can 183 read or/and write via the ForCES protocol. 185 LFB Topology -- Representation of how the LFB instances are 186 logically interconnected and placed along the datapath within one 187 FE. Sometimes it is also called intra-FE topology, to be 188 distinguished from inter-FE topology. LFB topology is outside of 189 the LFB model, but part of the FE model. 191 FE Topology -- Representation of how the multiple FEs in a single 192 NE are interconnected. Sometimes it is called inter-FE topology, 193 to be distinguished from intra-FE topology (i.e., LFB topology). 194 Individual FE may not have the global knowledge of full FE 195 topology, but the local view of its connectivity with other FEs are 196 considered part of the FE model. FE topology is discovered by the 197 ForCES base protocol or some other means. 199 Inter-FE Topology -- See FE Topology. 201 Intra-FE Topology -- See LFB Topology. 203 LFB class library -- A set of LFB classes that are identified as 204 the most common functions found in most FEs and hence should be 205 defined first by the ForCES Working Group. 207 2. Introduction 209 [2] specifies a framework by which control elements (CEs) can 210 configure and manage one or more separate forwarding elements (FEs) 211 within a networking element (NE) using the ForCES protocol. The 212 ForCES architecture allows Forwarding Elements of varying 213 functionality to participate in a ForCES network element. The 214 implication of this varying functionality is that CEs can make only 215 minimal assumptions about the functionality provided by FEs in a 216 NE. Before CEs can configure and control the forwarding behavior 217 of FEs, CEs need to query and discover the capabilities and states 218 of their FEs. [1] mandates that the capabilities, states and 219 configuration information be expressed in the form of an FE model. 221 RFC 3444 [11] made the observation that information models (IMs) 222 and data models (DMs) are different because they serve different 223 purposes. "The main purpose of an IM is to model managed objects 224 at a conceptual level, independent of any specific implementations 225 or protocols used". "DMs, conversely, are defined at a lower level 226 of abstraction and include many details. They are intended for 227 implementors and include protocol-specific constructs." Sometimes 228 it is difficult to draw a clear line between the two. The FE model 229 described in this document is first and foremost an information 230 model, but it also has a flavor of a data model as it contains 231 explicit definition of the LFB class schema and other data 232 structures. It is expected that this FE model will be used as the 233 basis to define the payload for information exchange between the CE 234 and FE in the ForCES protocol. 236 2.1. Requirements on the FE model 238 [1] defines requirements which must be satisfied by a ForCES FE 239 model. To summarize, an FE model must define: 240 . Logically separable and distinct packet forwarding operations 241 in an FE datapath (logical functional blocks or LFBs); 242 . The possible topological relationships (and hence the sequence 243 of packet forwarding operations) between the various LFBs; 244 . The possible operational capabilities (e.g., capacity limits, 245 constraints, optional features, granularity of configuration) 246 of each type of LFB; 247 . The possible configurable parameters (i.e., attributes) of 248 each type of LFB; 249 . Metadata that may be exchanged between LFBs. 251 2.2. The FE Model in Relation to FE Implementations 253 The FE model proposed here is based on an abstraction of distinct 254 logical functional blocks (LFBs), interconnected in a directed 255 graph, and receiving, processing, modifying, and transmitting 256 packets along with metadata. Note that a real forwarding datapath 257 implementation should not be constrained by the model. On the 258 contrary, the FE model should be designed such that different 259 implementations of the forwarding datapath can all be logically 260 mapped onto the model with the functionality and sequence of 261 operations correctly captured. However, the model itself does not 262 directly address the issue of how a particular implementation maps 263 to an LFB topology. This is left to the forwarding plane vendors 264 as to how the FE functionality is represented using the FE model. 265 Nevertheless, we do strive to design the FE model such that it is 266 flexible enough to accommodate most common implementations. 268 The LFB topology model for a particular datapath implementation 269 MUST correctly capture the sequence of operations on the packet. 270 Metadata generation (by certain LFBs) must always precede any use 271 of that metadata (by subsequent LFBs in the topology graph); this 272 is required for logically consistent operation. Further, 273 modifications of packet fields that are subsequently used as inputs 274 for further processing must occur in the order specified in the 275 model for that particular implementation to ensure correctness. 277 2.3. The FE Model in Relation to the ForCES Protocol 279 The ForCES base protocol is used by the CEs and FEs to maintain the 280 communication channel between the CEs and FEs. The ForCES protocol 281 may be used to query and discover the inter-FE topology. The 282 details of a particular datapath implementation inside an FE 283 including the LFB topology, along with the operational capabilities 284 and attributes of each individual LFB, are conveyed to the CE 285 within information elements in the ForCES protocol. The model of 286 an LFB class should define all of the information that would need 287 to be exchanged between an FE and a CE for the proper configuration 288 and management of that LFB. 290 Definition of the various payloads of ForCES messages (irrespective 291 of the transport protocol ultimately selected) cannot proceed in a 292 systematic fashion until a formal definition of the objects being 293 configured and managed (the FE and the LFBs within) is undertaken. 294 The FE Model document defines a set of classes and attributes for 295 describing and manipulating the state of the LFBs of an FE. These 296 class definitions themselves will generally not appear in the 297 Forces protocol. Rather, Forces protocol operations will 298 references classes defined in this model, including relevant 299 attributes (and operations if such are defined). 301 Section 9 provides more detailed discussion on how the FE model 302 should be used by the ForCES protocol. 304 2.4. Modeling Language for FE Model 306 Even though not absolutely required, it is beneficial to use a 307 formal data modeling language to represent the conceptual FE model 308 described in this document and a full specification will be written 309 using such a data modeling language. Using a formal language can 310 help in enforcing consistency and logical compatibility among LFBs. 311 In addition, formal definition of the LFB classes has the potential 312 to facilitate the eventual automation of some part of the code 313 generation process and the functional validation of arbitrary LFB 314 topologies. 316 The modeling language is used for writing the specification but not 317 necessarily for encoding the data over-the-wire between FEs and 318 CEs. When selecting the specification language, human readability 319 is very important, while there are no performance requirements on 320 the language for encoding, decoding, and transmission on the 321 language. XML is used as the specification language in this 322 document, because XML has the advantage of being human and machine 323 readable with widely available tools support. 325 The encoding method for over the wire transport is an issue 326 independent of the specification language chosen here. It is 327 outside the scope of this document and up to the ForCES protocol to 328 define. 330 2.5. Document Structure 332 Section 3 provides conceptual overview of the FE model, laying the 333 foundation for the more detailed discussion and specifications in 334 the sections that follow. Section 4, 5, and 6 together constitute 335 the core of the FE model, detailing the three major components in 336 the FE model: LFB model, LFB topology, and FE level attributes 337 including capability. Section 7 presents a list of LFB classes in 338 the LFB class library that will be further specified according to 339 the FE model presented in earlier Sections (4, 5 and 6). Section 8 340 directly addresses the model requirements imposed by the ForCES 341 requirement draft [1] while Section 9 explains how the FE model 342 should be used in the ForCES protocol. 344 3. FE Model Concepts 346 Some of the most important concepts used throughout this document 347 are introduced in this section. Section 3.1 explains the 348 difference between a state model and a capability model, and how 349 the two can be combined in the FE model. Section 3.2 introduces 350 the concept of LFBs (Logical Functional Blocks) as the basic 351 functional building blocks in the FE model. Section 3.3 discusses 352 the logical inter-connection and ordering between LFB instances 353 within an FE, that is, the LFB topology. 355 The FE model proposed in this document is comprised of these three 356 components: LFB model, LFB topology and FE attributes including FE 357 capabilities. The LFB model provides the content and data 358 structures to define each individual LFB class; LFB topology 359 provides a mean to express the logical inter-connection between the 360 LFB instances along the datapath(s) within the FE; and FE 361 attributes provide information at the FE level and the capabilities 362 about what the FE can or cannot do at a coarse level. Details on 363 each of the three components are described in Section 4, 5 and 6, 364 respectively. The intention of this section is to discuss these 365 concepts at the high level and lay the foundation for the detailed 366 description in the following sections. 368 3.1. State Model and Capability Model 370 The FE capability model describes the capabilities and capacities 371 of an FE in terms of variations of functions supported or 372 limitations contained. Conceptually, the FE capability model 373 presents the many possible states allowed on an FE with capacity 374 information indicating certain quantitative limits or constraints. 376 For example, an FE capability model may describe the FE at a coarse 377 level such as: 378 . this FE can handle IPv4 and IPv6 forwarding; 379 . this FE can perform classification on the following fields: 380 source IP address, destination IP address, source port number, 381 destination port number, etc; 382 . this FE can perform metering; 383 . this FE can handle up to N queues (capacity); 384 . this FE can add and remove encapsulating headers of types 385 including IPSec, GRE, L2TP. 387 On the other hand, an FE state model describes the current state of 388 the FE, that is, the instantaneous values or operational behavior 389 of the FE. The FE state model presents the snapshot view of the FE 390 to the CE. For example, using an FE state model, an FE may be 391 described to its CE as the following: 392 . on a given port the packets are classified using a given 393 classification filter; 394 . the given classifier results in packets being metered in a 395 certain way, and then marked in a certain way; 396 . the packets coming from specific markers are delivered into a 397 shared queue for handling, while other packets are delivered 398 to a different queue; 399 . a specific scheduler with specific behavior and parameters 400 will service these collected queues. 402 The information on the capabilities and capacities of the FE helps 403 the CE understand the flexibility and limitations of the FE 404 functions, so that the CE knows at a coarse level what 405 configurations are applicable to the FEs and what are not. Where 406 it gets more complicated is for the capability model to cope with 407 the detailed limits, issues such as how many classifiers the FE can 408 handle, how many queues, and how many buffer pools the FE can 409 support, how many meters the FE can provide. 411 While one could try to build an object model for representing 412 capabilities in full, other efforts have found this to be a 413 significant undertaking. A middle of the road approach is to define 414 coarse-grained capabilities and simple capacity measures. Then, if 415 the CE attempts to instruct the FE to set up some specific behavior 416 it is not capable of, the FE will return an error indicating the 417 problem. Examples of such approach include Framework Policy 418 Information Base (PIB) [RFC3318) and Differentiated Services QoS 419 Policy Information Base [4]. The capability reporting classes in 420 the DiffServ and Framework PIBs are all meant to allow the device 421 to indicate some general guidelines about what it can or cannot do, 422 but do not necessarily allow it to indicate every possible 423 configuration that it can or cannot support. If a device receives 424 a configuration that it cannot implement, it can reject such 425 configuration by replying with a failure report. 427 Figure 1 shows the concepts of FE state, capabilities and 428 configuration in the context of CE-FE communication via ForCES 429 protocol. 431 +-------+ +-------+ 432 | | FE capabilities: what it can/cannot do. | | 433 | |<-----------------------------------------| | 434 | | | | 435 | CE | FE state: what it is now. | FE | 436 | |<-----------------------------------------| | 437 | | | | 438 | | FE configuration: what it should be. | | 439 | |----------------------------------------->| | 440 +-------+ +-------+ 442 Figure 1. Illustration of FE state, capabilities and configuration 443 exchange in the context of CE-FE communication via ForCES. 445 The ForCES FE model must include both a state model and some flavor 446 of a capability model. We believe that a good balance between 447 simplicity and flexibility can be achieved for the FE model by 448 combining the coarse level capability reporting with the error 449 reporting mechanism. Examples of similar approach include DiffServ 450 PIB [4] and Framework PIB [5]. 452 The concepts of LFB and LFB topology will be discussed in the rest 453 of this section. It will become clear that some flavor of 454 capability model is needed at both the FE level and LFB level. 456 Capability information at the LFB level is an integral part of the 457 LFB model, and is modeled the same way as the other operational 458 parameters inside an LFB. For example, certain features of an LFB 459 class may be optional, in which case it must be possible for the CE 460 to determine if an optional feature is supported by a given LFB 461 instance or not. Such capability information can be modeled as a 462 read-only attribute in the LFB instance. See Section 4.4.4 for 463 more details on LFB attributes. 465 Capability information at the FE level may describe what LFB 466 classes the FE can instantiate; how many instances of each can be 467 created; the topological (i.e., linkage) limitations between these 468 LFB instances, etc. Section 6 defines the FE level attributes 469 including capability information. 471 Once the FE capability is described to the CE, the FE state 472 information can be represented by two levels. The first level is 473 the logically separable and distinctive packet processing 474 functions, and we call these individual functions Logical 475 Functional Blocks (LFBs). The second level of information is about 476 how these individual LFBs are ordered and placed along the datapath 477 to deliver a complete forwarding plane service. The 478 interconnection and ordering of the LFBs is called LFB Topology. 479 Section 3.2 discuss high level concepts around LFBs while Section 480 3.3 discuss issues around LFB topology. 482 3.2. LFB Modeling 484 Each LFB (Logical Functional Block) performs a well-defined action 485 or computation on the packets passing through it. Upon completion 486 of such function, either the packets are modified in certain ways 487 (like decapsulator, marker), or some results are generated and 488 stored, probably in the form of metadata (like classifier). Each 489 LFB typically does one thing and one thing only. Classifiers, 490 shapers, meters are all examples of LFB. Modeling LFB at such fine 491 granularity allows us to use a small number of LFBs to create the 492 higher-order FE functions (like IPv4 forwarder) precisely, which in 493 turn can describe more complex networking functions and vendor 494 implementations of software and hardware. 496 (Editor's note: We need to revisit the granularity issue around LFB 497 later and provide a practical design guideline as how to partition 498 the FE functions into LFB classes. We will gain more insight on 499 the subject once we debate and settle on the LFB list in the LFB 500 class library, described in Section 7. So the text around 501 granularity here might be revised to reflect the lessons we learn.) 503 An LFB has one or more inputs, each of which takes a packet P, and 504 optionally metadata M; and produces one or more outputs, each of 505 which carries a packet P', and optionally metadata M'. Metadata is 506 data associated with the packet in the network processing device 507 (router, switch, etc.) and passed between one LFB to the next, but 508 not sent across the network. It is most likely that there are 509 multiple LFBs within one FE, as shown in Figure 2, and all the LFBs 510 share the same ForCES protocol termination point that implements 511 the ForCES protocol logic and maintains the communication channel 512 to and from the CE. 514 An LFB, as shown in Figure 2, has inputs, outputs and attributes 515 that can be queried and manipulated by the CE indirectly via Fp 516 reference point (defined in [2]) and the ForCES protocol 517 termination point. The horizontal axis is in the forwarding plane 518 for connecting the inputs and outputs of LFBs within the same FE. 519 The vertical axis between the CE and the FE denotes the Fp 520 reference point where bidirectional communication between the CE 521 and FE happens: the CE to FE communication is for configuration, 522 control and packet injection while the FE to CE is for packet re- 523 direction to the control plane, monitoring and accounting 524 information, errors, etc. Note that the interaction between the CE 525 and the LFB is only abstract and indirect. The result of such 526 interaction is for the CE to indirectly manipulate the attributes 527 of the LFB instances. 529 +-----------+ 530 | CE | 531 +-----------+ 532 ^ 533 | Fp reference point 534 | 535 +--------------------------|-----------------------------------+ 536 | FE | | 537 | v | 538 | +----------------------------------------------------------+ | 539 | | ForCES protocol | | 540 | | termination point | | 541 | +----------------------------------------------------------+ | 542 | ^ ^ | 543 | : : Internal control | 544 | : : | 545 | +---:----------+ +---:----------+ | 546 | | :LFB1 | | : LFB2 | | 547 | =====>| v |============>| v |======>...| 548 | Inputs| +----------+ |Outputs | +----------+ | | 549 | (P,M) | |Attributes| |(P',M') | |Attributes| |(P",M") | 550 | | +----------+ | | +----------+ | | 551 | +--------------+ +--------------+ | 552 | | 553 +--------------------------------------------------------------+ 555 Figure 2. Generic LFB Diagram 557 A namespace is used to associate a unique name or ID with each LFB 558 class. The namespace must be extensible so that new LFB class can 559 also be added later to accommodate future innovation in the 560 forwarding plane. 562 LFB operation must be specified in the model to allow the CE to 563 understand the behavior of the forwarding datapath. For instance, 564 the CE must understand at what point in the datapath the IPv4 565 header TTL is decremented (i.e., it needs to know if a control 566 packet could be delivered to the CE either before or after this 567 point in the datapath). In addition, the CE must understand where 568 and what type of header modifications (e.g., tunnel header append 569 or strip) are performed by the FEs. Further, the CE must verify 570 that various LFB along a datapath within an FE are compatible to 571 link together. 573 There is value to vendors if the operation of LFB classes can be 574 expressed in sufficient detail so that physical devices 575 implementing different LFB functions can be integrated easily into 576 a FE design. Therefore, semi-formal specification is needed; that 577 is, a text description of the LFB operation (human readable), but 578 sufficiently specific and unambiguous to allow conformance testing 579 and efficient design (i.e., eliminate guess-work), so that 580 interoperability between different CEs and FEs can be achieved. 582 The LFB class model specifies information like: 583 . number of inputs and outputs (and whether they are 584 configurable) 585 . metadata read/consumed from inputs; 586 . metadata produced at the outputs; 587 . packet type(s) accepted at the inputs and emitted at the 588 outputs; 589 . packet content modifications (including encapsulation or 590 decapsulation); 591 . packet routing criteria (when multiple outputs on an LFB are 592 present); 593 . packet timing modifications; 594 . packet flow ordering modifications; 595 . LFB capability information; 596 . LFB operational attributes, etc. 598 Section 5 of this document provides detailed discussion on the LFB 599 model with a formal specification of LFB class schema. The rest of 600 Section 3.2 here only intends to provide conceptual overview of 601 some important issues in LFB modeling, without covering all the 602 specific details. 604 3.2.1. LFB Input and Input Group 606 An LFB input is a conceptual port of the LFB where the LFB can 607 receive information from other LFBs. The information is typically a 608 packet (or frame in general) and associated metadata, although in 609 some cases it might consist of only metadata, i.e., with a Null- 610 packet. 612 It is inevitable that there will be LFB instances that will receive 613 packets from more than one other LFB instances (fan-in). If these 614 fan-in links all carry the same type of information (packet type 615 and set of metadata) and require the same processing within the 616 LFB, then one input should be sufficient. If, however, the LFB 617 class can receive two or more very different types of input, and 618 the processing of these inputs are also very distinct, then that 619 may justify the definition of multiple inputs. But in these cases 620 splitting the LFB class into two LFB classes should always be 621 considered as an alternative. In intermediate cases, e.g., where 622 the inputs are somewhat different but they require very similar 623 processing, the shared input solution should be preferred. For 624 example, if an Ethernet framer LFB is capable of receiving IPv4 and 625 IPv6 packets, these can be served by the same LFB input. 627 Note that we assume the model allows for connecting more than one 628 LFB output to a single LFB input directly. There is no restriction 629 on the number of up-stream LFBs connecting their outputs to the 630 same input of a single LFB instance. Note that the behavior of the 631 system when multiple packets arrive at such an input simultaneously 632 is not defined by the model. If such behavior needs to be 633 described, it can be done either by separating the single input to 634 become multiple inputs (one per output), or by inserting other 635 appropriate LFBs (such as Queues and possibly Schedulers) between 636 the multiple outputs and the single input. 638 If there are multiple inputs with the same input type, we model 639 them as an input group, that is, multiple instances of the same 640 input type. In general, an input group is useful to allow an LFB 641 to differentiate packet treatment based on where the packet came 642 from. 644 +----+ +----+ 645 |LFB1+---+ |LFB1+---+ 646 +----+ | +---------+ +----+ | +-----------+ 647 +--->|in LFB3 | input / +--->|in:1 LFB3 | 648 +----+ | +---------+ group \ +--->|in:2 | 649 |LFB2+---+ +----+ | +-----------+ 650 +----+ |LFB2+---+ 651 +----+ 653 (a) without input group (b) with input group 655 Figure 3. An example of using input group. 657 Consider the following two cases in Figure 3(a) and (b). In Figure 658 3(a), the output from two LFBs are directly connected into one 659 input of LFB3, assuming that it can be guaranteed no two packets 660 arrive at the same time instance. If LFB3 must do something 661 different based on the source of the packet (LFB1 or LFB2), the 662 only way to model that is to make LFB1 and LFB2 to pass some 663 metadata with different values so that LFB3 can make the 664 differentiation based on the metadata. In Figure 3(b), that 665 differentiation can be elegantly expressed within LFB3 using the 666 input group concept where the instance id can server as the 667 differentiating key. For example, a scheduler LFB can potentially 668 use an input group consisting of a variable number of inputs to 669 differentiate the queues from which the packets are coming. 671 3.2.2. LFB Output and Output Group 673 An LFB output is a conceptual port of the LFB where it can send 674 information to some other LFBs. The information is typically a 675 packet (or frame in general) and associated metadata, although in 676 some cases it might emit only metadata,, i.e., with a Null-packet. 678 We assume that a single LFB output can be connected to only one LFB 679 input (this is required to make the packet flow through the LFB 680 topology unambiguous). Therefore, to allow any non-trivial 681 topology, multiple outputs must be allowed for an LFB class. If 682 there are multiple outputs with the same output type, we model them 683 as output group, that is, multiple instances of the same output 684 type. For illustration of output group, consider the hypothetical 685 LFB in Figure 4. The LFB has two types of outputs, one of which 686 can be instantiated to form an output group. 688 +------------------+ 689 | UNPROC +--> 690 | | 691 | PKTOUT:1 +--> \ 692 --> PKTIN PKTOUT:2 +--> | 693 | . + . | Output group 694 | . + . | 695 | PKTOUT:N +--> / 696 +------------------+ 698 Figure 4. An example of an LFB with output group. 700 Multiple outputs should mainly be used for functional separation 701 where the outputs are connected to very different types of LFBs. 702 For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one 703 default output to send those packets for which look-up was 704 successful (passing a META_ROUTEID as metadata); and have another 705 output for sending packets for which the look-up failed. The 706 former output may be connected to a route handler LFB, while the 707 latter can be connected to an ICMP response generator LFB or to a 708 packet handler LFB that passes the packet up to the CE. 710 3.2.3. Packet Type 712 When LFB classes are defined, the input and output packet formats 713 (e.g., IPv4, IPv6, Ethernet, etc.) must be specified: these are the 714 types of packets a given LFB input is capable of receiving and 715 processing, or a given LFB output is capable of producing. This 716 requires that distinct frame types be uniquely labeled with a 717 symbolic name and/or ID. 719 Note that each LFB has a set of packet types that it operates on, 720 but it does not care about whether the underlying implementation is 721 passing a greater portion of the packets. For example, an IPv4 LFB 722 might only operate on IPv4 packets, but the underlying 723 implementation may or may not be stripping the L2 header before 724 handing it over -- whether that is happening or not is opaque to 725 the CE. 727 3.2.4. Metadata 729 Metadata is used to communicate per-packet state from one LFB to 730 another. To ensure inter-operability among LFBs, the LFB class 731 specification must define what metadata the LFB class "reads" or 732 "consumes" on its input(s) and what metadata it "produces" on its 733 output(s). For that purpose, metadata types must be identified. 734 For example, an META_IFID, passed from a port LFB to an IPv4 735 processing LFB (with the IP packet) can be one of the defined 736 metadata types. 738 Symbolic names can be assigned for common metadata types. In 739 addition, additional information such as numeric data type, maximum 740 and minimum accepted values, and special values should be defined 741 for each metadata value. Some of these constraints will be defined 742 in the LFB class model, and some of them may be specific 743 capabilities of a particular LFB instance. 745 While it is important to define the metadata passing between LFB in 746 terms of its name, value and interpretation, it is not necessary to 747 define the exact encoding mechanism used by LFBs for metadata. 748 Different implementations are allowed to use different encoding 749 mechanisms for metadata. For example, one implementation may store 750 metadata in registers or shared memory, while another 751 implementation may encode metadata in-band as preamble in the 752 packets. 754 A given LFB may require a certain metadata at its inputs for its 755 internal processing. What should happen with the metadata after it 756 is read by the LFB? In particular, should the metadata be 757 propagated along with the packet when the packet is forwarded from 758 the LFB to the next LFB, or should it be removed (consumed) by the 759 LFB? 761 In certain cases, passing the metadata along is desirable. For 762 example, a META_CLASSID metadata may denote the result of a 763 classification LFB and used in more than one downstream LFBs to 764 trigger the proper operation on the packet. In this case the first 765 LFB that uses the META_CLASSID should also allow the META_CLASSID 766 to be passed with the packet to the next LFB, and so on. On the 767 other hand, it is easy to see that if metadata is never consumed by 768 LFBs, then as the packet trickles through the datapath, a large 769 number of metadata will potentially be accumulated by the packet. 771 We believe that one way to accommodate both scenarios is to specify 772 the propagation mode for each element of metadata utilized by an 773 LFB class. Metadata elements which are not propagated are 774 specified with the CONSUME mode, while elements which are 775 propagated are specified with the PROPAGATE mode. 777 However, whether a metadata is useful beyond an LFB may depend on 778 the actual LFB topology, i.e., what other LFBs are placed 779 downstream. So the propagation mode of metadata should be 780 configurable. 782 A packet may arrive to an LFB with metadata that is not meaningful 783 to that LFB, but may be important to some other downstream LFBs. 784 To cater to such cases it should be the assumed (default) behavior 785 of all LFB classes that they transparently propagate any metadata 786 elements that they do not utilize internally. 788 Actual implementations of LFBs in hardware may have limitations on 789 how much metadata they can pass through. The limitation may be 790 expressed in terms of total framesize (packet + metadata), metadata 791 total size, number of metadata elements, or a combination of these. 792 The limitation may be on the FE level or may be specific to LFBs 793 within an FE. The pass-through capabilities of LFB instances and 794 FEs can be queried as part of the capability discovery process. 796 (Editor's note: The definition of metadata here is only preliminary 797 and the authors intend to work on the subject in more detail. 798 Input is most welcome.) 800 3.2.5. LFB Versioning 802 LFB class versioning is a method to enable incremental evolution of 803 LFB classes. Unlike inheritance (discussed next in Section 3.2.6), 804 where it assumed that an FE datapath model containing an LFB 805 instance of a particular class C could also simultaneously contain 806 an LFB instance of a class C' inherited from class C; with 807 versioning, an FE would not be allowed to contain an LFB instance 808 for more than one version of a particular class. 810 LFB class versioning is supported by requiring a version string in 811 the class definition. CEs may support backwards compatibility 812 between multiple versions of a particular LFB class, but FEs are 813 not allowed to support more than one single version of a particular 814 class. 816 3.2.6. LFB Inheritance 818 LFB class inheritance is supported in the FE model as a means of 819 defining new LFB classes. This also allows FE vendors to add 820 vendor-specific extensions to standardized LFBs. An LFB class 821 specification MUST specify the base class (with version number) it 822 inherits from (with the default being the base LFB class). 823 Multiple-inheritance is not allowed, though, to avoid the 824 unnecessary complexity. 826 Inheritance should be used only when there is significant reuse of 827 the base LFB class definition. A separate LFB class should be 828 defined if there is not enough reuse between the derived and the 829 base LFB class. 831 An interesting issue related to class inheritance is backward 832 compatibility (between a descendant and an ancestor class). 833 Consider the following hypothetical scenario where there exists a 834 standardized LFB class "L1". Vendor A builds an FE that implements 835 LFB "L1" and vendors B builds a CE that can recognize and operate 836 on LFB "L1". Suppose that a new LFB class, "L2", is defined based 837 on the existing "L1" class (for example, by extending its 838 capabilities in some incremental way). Lets first examine the FE 839 backward compatibility issue by considering what would happen if 840 vendor B upgrades its FE from "L1" to "L2" while vendor C's CE is 841 not changed. The old L1-based CE can interoperate with the new L2- 842 based FE if the derived LFB class "L2" is indeed backward 843 compatible with the base class "L1". 845 The reverse scenario is a much less problematic case, i.e., when CE 846 vendor B upgrades to the new LFB class "L2", but the FE is not 847 upgraded. Note that as long as the CE is capable of working with 848 older LFB classes, this problem does not affect the model; hence we 849 will use the term "backward compatibility" to refer to the first 850 scenario concerning FE backward compatibility. 852 Inheritance can be designed into the model with backward 853 compatibility support by constraining the LFB inheritance such that 854 the derived class is always a functional superset of the base 855 class, i.e., the derived class can only grow on top of the base 856 class, but not shrink from it. Additionally, the following 857 mechanisms are required to support FE backward compatibility: 858 1) When detecting an LFB instance of an LFB type that is 859 unknown to the CE, the CE MUST be able to query the base 860 class of such an LFB from the FE. 861 2) The LFB instance on the FE SHOULD support a backward 862 compatibility mode (meaning the LFB instance reverts itself 863 back to the base class instance), and the CE SHOULD be able 864 to configure the LFB to run in such mode. 866 3.3. FE Datapath Modeling 868 Packets coming into the FE from ingress ports generally flow 869 through multiple LFBs before leaving out of the egress ports. How 870 an FE treats a packet depends on many factors, such as type of the 871 packet (e.g., IPv4, IPv6 or MPLS), actual header values, time of 872 arrival, etc. The result of the operation of an LFB may have an 873 impact on how the packet is to be treated in further (downstream) 874 LFBs and this differentiation of packet treatment downstream can be 875 conceptualized as having alternative datapaths in the FE. For 876 example, the result of a 6-tuple classification (performed by a 877 classifier LFB) controls what rate meter is applied to the packet 878 (by a rate meter LFB) in a later stage in the datapath. 880 LFB topology is a directed graph representation of the logical 881 datapaths within an FE, with the nodes representing the LFB 882 instances and the directed link the packet flow direction from one 883 LFB to the next. Section 3.3.1 discusses how the FE datapaths can 884 be modeled as LFB topology; while Section 3.3.2 focuses on issues 885 around LFB topology reconfiguration. 887 3.3.1. Alternative Approaches for Modeling FE Datapaths 888 There are two basic ways to express the differentiation in packet 889 treatment within an FE, one representing the datapath directly and 890 graphically (topological approach) and the other utilizing metadata 891 (the encoded state approach). 893 . Topological Approach 895 Using this approach, differential packet treatment is expressed 896 via actually splitting the LFB topology into alternative paths. 897 In other words, if the result of an LFB must control how the 898 packet is further processed, then such an LFB will have separate 899 output ports (one for each alternative treatment) connected to 900 separate sub-graphs (each expressing the respective treatment 901 downstream). 903 . Encoded State Approach 905 An alternative way of expressing differential treatment is using 906 metadata. The result of the operation of an LFB can be encoded 907 in a metadata which is passed along with the packet to 908 downstream LFBs. A downstream LFB, in turn, can use the 909 metadata (and its value, e.g., as an index into some table) to 910 decide how to treat the packet. 912 Theoretically, the two approaches can substitute for each other, so 913 one may consider using purely one (or the other) approach to 914 describe all datapaths in an FE. However, neither model by itself 915 is very useful for practically relevant cases. For a given FE with 916 certain logical datapaths, applying the two different modeling 917 approaches would result in very different looking LFB topology 918 graphs. A model using purely the topological approach may require 919 a very large graph with many links (i.e., paths) and nodes (i.e., 920 LFB instances) to express all alternative datapaths. On the other 921 hand, a model using purely the encoded state model would be 922 restricted to a string of LFBs, which would make it very 923 unintuitive to describe very different datapaths (such as MPLS and 924 IPv4). Therefore, a mix of these two approaches will likely be 925 used for a practical model. In fact, as we illustrate it below, 926 the two approaches can be mixed even within the same LFB. 928 Using a simple example of a classifier with N classification 929 outputs followed by some other LFBs, Figure 5(a) shows what the LFB 930 topology looks like by using the purely topological approach. Each 931 output from the classifier goes to one of the N LFBs followed and 932 no metadata is needed here. The topological approach is simple, 933 straightforward and graphically intuitive. However, if N is large 934 and the N nodes followed the classifier (LFB#1, LFB#2, ..., LFB#N) 935 all belong to the same LFB type (for example, meter) but each with 936 its own independent attributes, the encoded state approach gives a 937 much simpler topology representation, as shown in Figure 5(b). The 938 encoded state approach requires that a table of N rows of meter 939 attributes is provided in the Meter node itself, with each row 940 representing the attributes for one meter instance. A metadata M 941 is also needed to pass along with the packet P from the classifier 942 to the meter, so that the meter can use M as a look-up key (index) 943 to find the corresponding row of the attributes that should be used 944 for any particular packet P. 946 Now what if all the N nodes (LFB#1, LFB#2, ..., LFB#N) are not of 947 the same type? For example, if LFB#1 is a queue while the rest are 948 all meters, what is the best way to represent such datapaths? 949 While it is still possible to use either the pure topological 950 approach or the pure encoded state approach, the natural 951 combination of the two seems the best by representing the two 952 different functional datapaths using topological approach while 953 leaving the N-1 meter instances distinguished by metadata only, as 954 shown in Figure 5(c). 955 +----------+ 956 P | LFB#1 | 957 +--------->|(Attrib-1)| 958 +-------------+ | +----------+ 959 | 1|------+ P +----------+ 960 | 2|---------------->| LFB#2 | 961 | classifier 3| |(Attrib-2)| 962 | ...|... +----------+ 963 | N|------+ ... 964 +-------------+ | P +----------+ 965 +--------->| LFB#N | 966 |(Attrib-N)| 967 +----------+ 969 5(a) Using pure topological approach 971 +-------------+ +-------------+ 972 | 1| | Meter | 973 | 2| (P, M) | (Attrib-1) | 974 | 3|---------------->| (Attrib-2) | 975 | ...| | ... | 976 | N| | (Attrib-N) | 977 +-------------+ +-------------+ 979 5(b) Using pure encoded state approach to represent the LFB 980 topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the 981 same type (e.g., meter). 983 +-------------+ 984 +-------------+ (P, M) | queue | 985 | 1|------------->| (Attrib-1) | 986 | 2| +-------------+ 987 | 3| (P, M) +-------------+ 988 | ...|------------->| Meter | 989 | N| | (Attrib-2) | 990 +-------------+ | ... | 991 | (Attrib-N) | 992 +-------------+ 994 5(c) Using a combination of the two, if LFB#1, LFB#2, ..., and 995 LFB#N are of different types (e.g., queue and meter). 997 Figure 5. An example of how to model FE datapaths 999 From this example, we demonstrate that each approach has distinct 1000 advantage for different situations. Using the encoded state 1001 approach, fewer connections are typically needed between a fan-out 1002 node and its next LFB instances of the same type, because each 1003 packet carries metadata with it so that the following nodes can 1004 interpret and hence invoke a different packet treatment. For those 1005 cases, a pure topological approach forces one to build elaborate 1006 graphs with a lot more connections and often results in an unwieldy 1007 graph. On the other hand, a topological approach is intuitive and 1008 most useful for representing functionally very different datapaths. 1010 For complex topologies, a combination of the two is the most useful 1011 and flexible. Here we provide a general design guideline as to 1012 what approach is best used for what situation. The topological 1013 approach should primarily be used when the packet datapath forks 1014 into areas with distinct LFB classes (not just distinct 1015 parameterizations of the same LFB classes), and when the fan-outs 1016 do not require changes (adding/removing LFB outputs) at all or 1017 require only very infrequent changes. Configuration information 1018 that needs to change frequently should preferably be expressed by 1019 the internal attributes of one or more LFBs (and hence using the 1020 encoded state approach). 1021 +---------------------------------------------+ 1022 | | 1023 +----------+ V +----------+ +------+ | 1024 | | | | |if IP-in-IP| | | 1025 ---->| ingress |->+----->|classifier|---------->|Decap.|---->---+ 1026 | ports | | |----+ | | 1027 +----------+ +----------+ |others+------+ 1028 | 1029 V 1030 (a) The LFB topology with a logical loop 1032 +-------+ +-----------+ +------+ +-----------+ 1033 | | | |if IP-in-IP | | | | 1034 --->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|-> 1035 | ports | | |----+ | | | | 1036 +-------+ +-----------+ |others +------+ +-----------+ 1037 | 1038 V 1039 (b) The LFB topology without the loop utilizing two 1040 independent classifier instances. 1042 Figure 6. An LFB topology example. 1044 It is important to point out that the LFB topology here is the 1045 logical topology that the packets flow through, not the physical 1046 topology as determined by how the FE hardware is laid out. 1047 Nevertheless, the actual implementation may still influence how the 1048 functionality should be mapped into the LFB topology. Figure 6 1049 shows one simple FE example. In this example, an IP-in-IP packet 1050 from an IPSec application like VPN may go to the classifier first 1051 and have the classification done based on the outer IP header; upon 1052 being classified as an IP-in-IP packet, the packet is then sent to 1053 a decapsulator to strip off the outer IP header, followed by a 1054 classifier again to perform classification on the inner IP header. 1055 If the same classifier hardware or software is used for both outer 1056 and inner IP header classification with the same set of filtering 1057 rules, a logical loop is naturally present in the LFB topology, as 1058 shown in Figure 6(a). However, if the classification is 1059 implemented by two different pieces of hardware or software with 1060 different filters (i.e., one set of filters for outer IP header 1061 while another set for inner IP header), then it is more natural to 1062 model them as two different instances of classifier LFB, as shown 1063 in Figure 6(b). 1065 To distinguish multiple instances of the same LFB class, each LFB 1066 instance has its own LFB instance ID. One way to encode the LFB 1067 instance ID is to encode it as x.y where x is the LFB class ID 1068 while y is the instance ID within each LFB class. 1070 3.3.2. Configuring the LFB Topology 1071 While there is little doubt that the individual LFB must be 1072 configurable, the configurability question is more complicated for 1073 LFB topology. Since LFB topology is really the graphic 1074 representation of the datapaths within FE, configuring the LFB 1075 topology means dynamically changing the datapaths including changes 1076 to the LFBs along the datapaths on an FE, e.g., creating (i.e., 1077 instantiating) or deleting LFBs, setting up or deleting 1078 interconnections between outputs of upstream LFBs to inputs of 1079 downstream LFBs. 1081 Why would the datapaths on an FE ever change dynamically? The 1082 datapaths on an FE is set up by the CE to provide certain data 1083 plane services (e.g., DiffServ, VPN, etc.) to the NE's customers. 1084 The purpose of reconfiguring the datapaths is to enable the CE to 1085 customize the services the NE is delivering at run time. The CE 1086 needs to change the datapaths when the service requirements change, 1087 e.g., when adding a new customer, or when an existing customer 1088 changes their service. However, note that not all datapath changes 1089 result in changes in the LFB topology graph, and that is determined 1090 by the approach we use to map the datapaths into LFB topology. As 1091 discussed in 3.3.1, the topological approach and encoded state 1092 approach can result in very different looking LFB topologies for 1093 the same datapaths. In general, an LFB topology based on a pure 1094 topological approach is likely to experience more frequent topology 1095 reconfiguration than one based on an encoded state approach. 1096 However, even an LFB topology based entirely on an encoded state 1097 approach may have to change the topology at times, for example, to 1098 totally bypass some LFBs or insert new LFBs. Since a mix of these 1099 two approaches is used to model the datapaths, LFB topology 1100 reconfiguration is considered an important aspect of the FE model. 1102 We want to point out that allowing a configurable LFB topology in 1103 the FE model does not mandate that all FEs must have such 1104 capability. Even if an FE supports configurable LFB topology, it 1105 is expected that there will be FE-specific limitations on what can 1106 actually be configured. Performance-optimized hardware 1107 implementation may have zero or very limited configurability, while 1108 FE implementations running on network processors may provide more 1109 flexibility and configurability. It is entirely up to the FE 1110 designers to decide whether or not the FE actually implements such 1111 reconfiguration and how much. Whether it is a simple runtime 1112 switch to enable or disable (i.e., bypass) certain LFBs, or more 1113 flexible software reconfiguration is all implementation detail 1114 internal to the FE but outside of the scope of FE model. In either 1115 case, the CE(s) must be able to learn the FE's configuration 1116 capabilities. Therefore, the FE model must provide a mechanism for 1117 describing the LFB topology configuration capabilities of an FE. 1118 These capabilities may include (see Section 6 for details): 1119 . What LFB classes can the FE instantiate? 1120 . How many instances of the same LFB class can be created? 1121 . What are the topological limitations? For example: 1122 o How many instances of the same class or any class can be 1123 created on any given branch of the graph? 1124 o Ordering restrictions on LFBs (e.g., any instance of LFB 1125 class A must be always downstream of any instance of LFB 1126 class B). 1128 Even if the CE is allowed to configure LFB topology for an FE, how 1129 can the CE interpret an arbitrary LFB topology (presented to the CE 1130 by the FE) and know what to do with it? In another word, how does 1131 the CE know the mapping between an LFB topology and a particular NE 1132 service or application (e.g., VPN, DiffServ, etc.)? We argue that 1133 first of all, it is unlikely that an FE can support any arbitrary 1134 LFB topology; secondly, once the CE understands the coarse 1135 capability of an FE, it is up to the CE to configure the LFB 1136 topology according to the network service the NE is supposed to 1137 provide. So the more important mapping that the CE has to 1138 understand is from the high level NE service to a specific LFB 1139 topology, not the other way around. Do we expect the CE has the 1140 ultimate intelligence to translate any high level service policy 1141 into the configuration data for the FEs? No, but it is conceivable 1142 that within a given network service domain (like DiffServ), a 1143 certain amount of intelligence can be programmed into the CE such 1144 that the CE has a general understanding of the LFBs involved and so 1145 the translation from a high level service policy to the low level 1146 FE configuration can be done automatically. In any event, this is 1147 considered an implementation issue internal to the control plane 1148 and outside the scope of the FE model. Therefore, it is not 1149 discussed any further in this draft. 1151 +----------+ +-----------+ 1152 ---->| Ingress |---->|classifier |--------------+ 1153 | | |chip | | 1154 +----------+ +-----------+ | 1155 v 1156 +-------------------------------------------+ 1157 +--------+ | Network Processor | 1158 <----| Egress | | +------+ +------+ +-------+ | 1159 +--------+ | |Meter | |Marker| |Dropper| | 1160 ^ | +------+ +------+ +-------+ | 1161 | | | 1162 +----------+-------+ | 1163 | | | 1164 | +---------+ +---------+ +------+ +---------+ | 1165 | |Forwarder|<------|Scheduler|<--|Queue | |Counter | | 1166 | +---------+ +---------+ +------+ +---------+ | 1167 |--------------------------------------------------------------+ 1169 (a) The Capability of the FE, reported to the CE 1171 +-----+ +-------+ +---+ 1172 | A|--->|Queue1 |--------------------->| | 1173 ------>| | +-------+ | | +---+ 1174 | | | | | | 1175 | | +-------+ +-------+ | | | | 1176 | B|--->|Meter1 |----->|Queue2 |------>| |->| | 1177 | | | | +-------+ | | | | 1178 | | | |--+ | | | | 1179 +-----+ +-------+ | +-------+ | | +---+ 1180 classifier +-->|Dropper| | | IPv4 1181 +-------+ +---+ Fwd. 1182 Scheduler 1183 (b) One LFB topology as configured by the CE and 1184 accepted by the FE 1186 Queue1 1187 +---+ +--+ 1188 | A|------------------->| |--+ 1189 +->| | | | | 1190 | | B|--+ +--+ +--+ +--+ | 1191 | +---+ | | | | | | 1192 | Meter1 +->| |-->| | | 1193 | | | | | | 1194 | +--+ +--+ | Ipv4 1195 | Counter1 Dropper1 Queue2| +--+ Fwd. 1196 +---+ | +--+ +--->|A | +-+ 1197 | A|---+ | |------>|B | | | 1198 ------>| B|------------------------------>| | +--->|C |->| |-> 1199 | C|---+ +--+ | +->|D | | | 1200 | D|-+ | | | +--+ +-+ 1201 +---+ | | +---+ Queue3| | Scheduler 1202 Classifier1 | | | A|------------> +--+ | | 1203 | +->| | | |--+ | 1204 | | B|--+ +--+ +-------->| | | 1205 | +---+ | | | | +--+ | 1206 | Meter2 +->| |-+ | 1207 | | | | 1208 | +--+ Queue4 | 1209 | Marker1 +--+ | 1210 +---------------------------->| |----+ 1211 | | 1212 +--+ 1213 (c) Another LFB topology as configured by the CE and 1214 accepted by the FE 1216 Figure 7. An example of configuring LFB topology. 1218 Figure 7 shows an example where a QoS-enabled router has several 1219 line cards that have a few ingress ports and egress ports, a 1220 specialized classification chip, a network processor containing 1221 codes for FE blocks like meter, marker, dropper, counter, queue, 1222 scheduler and Ipv4 forwarder. Some of the LFB topology is already 1223 fixed and has to remain static due to the physical layout of the 1224 line cards. For example, all the ingress ports might be already 1225 hard wired into the classification chip and so all packets must 1226 follow from the ingress port into the classification engine. On 1227 the other hand, the LFBs on the network processor and their 1228 execution order are programmable, even though there might exist 1229 certain capacity limits and linkage constraints between these LFBs. 1230 Examples of the capacity limits might be: there can be no more than 1231 8 meters; there can be no more than 16 queues in one FE; the 1232 scheduler can handle at most up to 16 queues; etc. The linkage 1233 constraints might dictate that classification engine may be 1234 followed by a meter, marker, dropper, counter, queue or IPv4 1235 forwarder, but not scheduler; queues can only be followed by a 1236 scheduler; a scheduler must be followed by the IPv4 forwarder; the 1237 last LFB in the datapath before going into the egress ports must be 1238 the IPv4 forwarder, etc. 1240 Once the FE reports such capability and capacity to the CE, it is 1241 now up to the CE to translate the QoS policy into the desirable 1242 configuration for the FE. Figure 7(a) depicts the FE capability 1243 while 7(b) and 7(c) depict two different topologies that the FE 1244 might be asked to configure to. Note that both the ingress and 1245 egress are omitted in (b) and (c) for simple representation. The 1246 topology in 7(c) is considerably more complex than 7(b) but both 1247 are feasible within the FE capabilities, and so the FE should 1248 accept either configuration request from the CE. 1250 4. LFB Model -- LFB and Associated Data Definitions 1252 The main goal of the FE model is to provide an abstract, generic, 1253 modular, implementation independent representation of the FEs. This 1254 is facilitated using the concept of LFBs which are instantiated 1255 from LFB classes. The LFB model is defined in this section to 1256 describe the content and structures in LFB and associated data type 1257 definition. 1259 The core part of the model is the definition of LFB classes. 1260 Section 4.4 provides more discussion on what will be part of an LFB 1261 class definition. 1263 Operational parameters of the LFBs that must be visible to the CEs 1264 are conceptualized in the model as the LFB attributes. These 1265 include, for example, flags, single parameter arguments, complex 1266 arguments, and tables. The definition of the attributes of an LFB 1267 MUST be part of the LFB class definition. To promote consistent and 1268 terse definitions of the attributes of LFB classes, commonly used 1269 attribute types SHOULD be defined in the model outside of the LFB 1270 class definitions, so that LFB class definitions can "share" these 1271 type definitions by simply referring to the types. What will 1272 comprise a data type definition is further discussed in Section 1273 4.1. 1275 LFBs form a directed graph with each other by sending and receiving 1276 packets and associated metadata. To provide consistency and logical 1277 inter-operability among LFB classes, packet types (generic frame 1278 types) and metadata types MUST BE specified outside of the LFB 1279 class definitions (but part of the LFB model), so that the LFB 1280 class definitions can simply refer to these types. These blocks are 1281 further discussed in Section 4.3 and Section 4.2, respectively. 1282 In summary, the LFB model will consist of the following four 1283 categories of definitions: 1284 1) Common data type definitions (Section 4.1) 1285 2) Metadata definitions (Section 4.2); 1286 3) Frame format definitions (Section 4.3); 1287 4) LFB class definitions (Section 4.4). 1289 It is not expected that the above information is exchanged between 1290 FEs and CEs "over-the-wire". But the model will serve as an 1291 important reference for the design and development of the CEs 1292 (software) and FEs (mostly the software part). 1294 4.1. General Data Type Definitions 1296 Data types will be used to describe the LFB attributes (see Section 1297 4.4.4). This is similar to the concept of having a common header 1298 file for shared data types. Data types will include atomic data 1299 types (e.g. integer, ASCII string), as well as compound or derived 1300 data types (such as arrays and structures). Given that the FORCES 1301 protocol will be getting and setting attribute values, all atomic 1302 data types used here must be able to be conveyed in the FORCES 1303 protocol. Further, the FORCES protocol will need a mechanism to 1304 convey compound data types. Details of such representation are for 1305 the protocol document, not the model documents. 1307 Compound data types can build on atomic data types and other 1308 compound data types. There are three ways that compound data types 1309 can be defined. They may be defined as an array of elements of 1310 some compound or atomic data type. They may be a structure of 1311 named elements of compound or atomic data types (ala C structures). 1312 They may also be defined as augmentations (explained below in 1313 4.1.3) of existing compound data types. 1315 In addition, any data type may be used to define a new type by 1316 restricting the range of values that an instance of the data type 1317 can take on, and specifying specific semantics that go with that. 1318 This is similar to the SNMP notion of a textual convention. 1320 For each data type the following information MUST be provided: 1321 . Symbolic name of data type. Example: "T_IPV4ADDRESS". 1322 . Actual type declaration. 1324 In addition, a data type definition MAY include the following: 1325 . Range restrictions. 1326 . A set of symbolic names for special values. Example: 1327 "IPV4ADDR_LOOPBACK". 1329 Note that not all attributes will exist at all times in all 1330 implementations. While the capabilities will frequently indicate 1331 this non-existence, CEs may attempt to reference non-existent or 1332 non-permitted attributes anyway. The FORCES protocol mechanisms 1333 should include appropriate error indicators for this case. 1335 4.1.1. Arrays 1337 Compound data types can be defined as arrays of compound or atomic 1338 data types. Arrays can only be subscripted by integers, and will 1339 be presumed to start with subscript 0. The mechanism defined above 1340 for non-supported attributes can also apply to attempts to 1341 reference non-existent array elements or to set non-permitted 1342 elements. The valid range of the subscripts of the array must be 1343 defined either in the definition of the array or in the LFB class 1344 which uses the compound type definition. 1346 4.1.2. Structures 1348 A structure is comprised of a collection of data elements. Each 1349 data element has a data type (either an atomic type or an existing 1350 compound type.) and is assigned a name unique within the scope of 1351 the compound data type being defined. These serve the same 1352 function as "struct" in C, etc. 1354 4.1.3. Augmentations 1356 Compound types can also be defined as augmentations of existing 1357 compound types. If the existing compound type is a structure, 1358 augmentation may add new elements to the type. They may replace 1359 the type of an existing element with an augmentation derived from 1360 the current type. They may not delete an existing element, nor may 1361 they replace the type of an existing element with one that is not 1362 an augmentation of the type that the element has in the basis for 1363 the augmentation. If the existing compound type is an array, 1364 augmentation means augmentation of the array element type. 1366 One consequence of this is that augmentations are compatible with 1367 the compound type from which they are derived. As such, 1368 augmentations are useful in defining attributes for LFB subclasses 1369 with backward compatibility. In addition to adding new attributes 1370 to a class, the data type of an existing attribute may be replaced 1371 by an augmentation of that attribute, and still meet the 1372 compatibility rules for subclasses. 1374 For example, consider a simple base LFB class A that has only one 1375 attribute (attr1) of type X. One way to derive class A1 from A can 1376 be simply adding a second attribute (of any type). Another way to 1377 derive a class A2 from A can be replacing the original attribute 1378 (attr1) in A of type X with one of type Y, where Y is an 1379 augmentation of X. Both classes A1 and A2 are backward compatible 1380 with class A. 1382 4.2. Metadata Definitions 1384 For each metadata type, the following MUST be specified: 1385 . Metadata symbolic name. Used to refer to the metadata type in 1386 LFB type specifications. Example: META_CLASSID. 1387 . Brief synopsis of the metadata. Example: "Result of 1388 classification (0 means no match)". 1389 . Data type and valid range. 1391 In addition, the following information MAY BE part of the metadata 1392 definition: 1393 . Symbolic definitions for frequently used or special values of 1394 the metadata. 1396 4.3. Frame Format Definitions 1397 This part of the LFB model will list packet types (frame types in 1398 general) that LFB classes can receive at their inputs and/or emit 1399 at their outputs. 1401 For each distinct frame type, the following MUST be provided: 1402 . Symbolic name of frame type. Example: FRAME_IPV4. 1403 . Brief synopsis of the frame type. Example: "IPv4 packet". 1405 4.4. LFB Class Definitions 1407 Each LFB Class definition must provide the following information: 1408 . Symbolic name of LFB class. Example: "LFB_IPV4_LPM" 1409 . Short synopsis of LFB class. Example: "IPv4 LPM Lookup LFB" 1410 . Version indicator 1411 . Inheritance indicator (see discussion in Section 4.4.1) 1412 . Inputs (see discussion in Section 4.4.2) 1413 . Outputs (see discussion in Section 4.4.3) 1414 . Attributes (see discussion in Section 4.4.4) 1415 . Operational specification (see discussion in Section 4.4.5) 1417 4.4.1. LFB Inheritance 1419 To support LFB class inheritance, the LFB specification must have a 1420 place holder for indicating the base class and its version. It is 1421 assumed that the derived class is backward compatible with the base 1422 class. 1424 4.4.2. LFB Inputs 1426 An LFB class may have zero, one, or more inputs. We assume that 1427 most LFBs will have exactly one input. Multiple inputs with the 1428 same input type are modeled as one input group. The input group 1429 should count as one entry in the input specification. The number 1430 of inputs (including input groups) is fixed. 1432 Multiple inputs with different input type should be avoided if 1433 possible (see discussion in Section 3.2.1). Some special LFBs will 1434 have no inputs at all. For example, a packet generator LFB does 1435 not need an input. 1437 The LFB class definition MUST specify whether or not the number of 1438 inputs of the LFB is fixed, and the exact number if fixed. For each 1439 LFB input (group), the following MUST be specified: 1441 . Symbolic name of input. Example: "PKT_IN". Note that this 1442 symbolic name must be unique only within the scope of the LFB 1443 class. 1444 . Brief synopsis of the input. Example: "Normal packet input". 1445 . Indication of whether this input is an input group (i.e., if 1446 it is allowed to be instantiated). 1447 . List of allowed frame formats. Example: "{FRAME_IPV4, 1448 FRAME_IPV6}". Note that this list should refer to symbols 1449 specified in the frame definition of the LFB model (see 1450 Section 4.3). 1451 . List of required metadata. Example: {META_CLASSID, META_IFID}. 1452 This list should refer to symbols specified in the metadata 1453 definition of the LFB model (see Section 4.2). For each 1454 metadata it should be specified whether the metadata is 1455 required or optional. For each optional metadata a default 1456 value MAY BE specified, which is used by the LFB if the 1457 metadata is not provided at the input. 1459 4.4.3. LFB Outputs 1461 An LFB class may have zero, one, or more outputs. If there are 1462 multiple outputs with the same output type, we model them as output 1463 group. Some special LFBs may have no outputs at all (e.g., 1464 Dropper). 1466 The number of outputs may be fixed for some LFB types and may be 1467 configurable for others. The LFB Class definition MUST specify the 1468 number of outputs (or output types) of the LFB. The output group 1469 should count as one entry in the output specification, but the 1470 entry should indicate that instantiation of the output is 1471 allowed. 1473 For each LFB output (group) the following MUST be specified: 1474 . Symbolic name of the output. Example: "UNPROC". In case of an 1475 output group, the symbolic name is the prefix used to 1476 construct unique symbols for each output instance. Example: 1477 "PKTOUT". Note that the symbolic name must be unique only 1478 within the scope of the LFB class. 1479 . Brief synopsis of the output. Example: "Normal packet output". 1480 . Indication of whether this output is an output group (i.e., if 1481 it is allowed to be instantiated). 1482 . List of allowed frame formats. Example: "{FRAME_IPV4, 1483 FRAME_IPV6}". Note that this list should refer to symbols 1484 specified in the frame definition of the LFB model (see 1485 Section 4.3). 1486 . List of emitted (generated) metadata. Example: {META_CLASSID, 1487 META_IFID}. This list should refer to symbols specified in the 1488 metadata definition of the LFB model (see Section 4.2). For 1489 each generated metadata, it should be specified whether the 1490 metadata is always generated or generated only in certain 1491 conditions. This information is important when assessing 1492 compatibility between LFBs. 1494 4.4.4. LFB Attributes 1496 The operational state of the LFB is modeled by the variables of the 1497 LFB, collectively called attributes. Note that the attributes here 1498 refer to the operational parameters of the LFBs that must be 1499 visible to the CEs. The other variables that are internal to LFB 1500 implementation are not included here in the LFB attributes and are 1501 not modeled here. 1503 Attribute types will include the following three categories: 1504 . Capability attributes (see Section 9.4 for more on LFB 1505 capabilities). Examples: 1506 * Supported optional features of the LFB class; 1507 * Maximum number of configurable outputs for an output group; 1508 * Metadata pass-through limitations of the LFB; 1509 * Maximum size of configurable attribute tables; 1510 * Supported access modes of certain attributes (see below). 1511 . Operational attributes, some of them are configurable by the 1512 CE, while others might be internally maintained state which 1513 are read-only for the CE and necessary for the CE to operate 1514 properly. Examples: 1515 * Configurable flags and switches selecting between 1516 operational modes of the LFB; 1517 * ARP tables; 1518 * Number of outputs in an output group; 1519 * Metadata CONSUME vs. PROPAGATE mode selector. 1520 . Statistical attributes (collected by the FE and provided for 1521 reading to the CE). Examples: 1522 * Packet and byte counters; 1523 * Other event counters. 1525 Some of the attributes will be generically available in all LFBs 1526 while others will be specific to the LFB class. Examples of 1527 generic LFB attributes are: 1528 . LFB class inheritance information (see Section 4.4.1) 1529 . Number and type of inputs (in case the LFB is self- 1530 descriptive) 1531 . Number and type of outputs (in case the LFB is self- 1532 descriptive) 1533 . Number of current outputs for each output group 1534 . Metadata CONSUME/PROPAGATE mode selector 1536 There may be various access permission restrictions on what the CE 1537 can do with an LFB attribute. The following categories may be 1538 supported: 1539 . No-access attributes. This is useful when multiple access 1540 modes maybe defined for a given attribute to allow some 1541 flexibility for different implementations. 1542 . Read-only attributes. 1543 . Read-write attributes. 1544 . Write-only attributes. This could be any configurable data 1545 for which read capability is not provided to the CEs. (??? Do 1546 we have good example???) 1547 . Read-reset attributes. The CE can read and reset this 1548 resource, but cannot set it to an arbitrary value. Example: 1549 Counters. 1550 . Firing-only attributes. A write attempt to this resource will 1551 trigger some specific actions in the LFB, but the actual value 1552 written is ignored. (??? Example???) 1554 The LFB class may define more than one possible access mode for a 1555 given attribute (for example, write-only and read-write), in which 1556 case it is left to the actual implementation to pick one of the 1557 modes. In such cases a corresponding capability parameter must 1558 inform the CE of which mode the actual LFB instance supports. 1559 The attributes of the LFB class must be defined as a list. For each 1560 attribute the following information MUST be provided: 1561 . Reference to the data type (e.g., specified in the generic 1562 data type block of the LFB model or in an LFB specific data 1563 type block). 1564 . Access permission(s). 1565 . Additional range restrictions (i.e., beyond what is specified 1566 by the data type definition). 1567 . Default value. Applied when the LFB is initialized or reset. 1569 The actual structuring of LFB attributes requires further study. 1571 4.4.5. LFB Operational Specification 1573 This section of the model should verbally describe what the LFB 1574 does. This will most likely be embedded in an unstructured text 1575 field in the model. 1577 5. LFB Topology Model (To be written) 1579 (Editor's note: This is a place holder to describe the details on 1580 how to model LFB topology.) 1582 6. FE Level Attributes (To be written) 1584 (Editor's note: This is a place holder to describe the FE level 1585 attributes including FE capabilities, for examples: 1586 . How this FE is connected with other FEs (if known by the FE)? 1587 . What LFB classes can the FE instantiate? 1588 . How many instances of the same LFB class can be created? 1589 . What are the topological limitations? For example: 1590 o How many instances of the same class or any class can be 1591 created on any given branch of the graph? 1592 o Ordering restrictions on LFBs (e.g., any instance of LFB 1593 class A must be always downstream of any instance of LFB 1594 class B). 1595 ) 1597 7. LFB Class Library 1599 A set of LFB classes are identified here in the LFB class library 1600 as necessary to build common FE functions. 1602 Several working groups in the IETF have already done some relevant 1603 work in modeling the provisioning policy data for some of the 1604 functions we are interested in, for example, DiffServ 1605 (Differentiated Services) PIB [4], IPSec PIB [8]. Whenever 1606 possible, we should try to reuse the work done elsewhere instead of 1607 reinventing the wheel. 1609 7.1. Port LFB 1611 A Port LFB is used to map a physical port into the LFB model. 1613 The Port LFB maps sources and sinks of packets from outside the LFB 1614 model onto one logical block which defines and models a physical 1615 port implementing those functions. 1617 The Port LFB contains a number of configurable parameters, which 1618 may include, but are not limited to, the following items: 1619 . the number of ports on this LFB; 1620 . the sub-interfaces if any; 1621 . the static attributes of each port (e.g., port type, 1622 direction, link speed); 1623 . the configurable attributes of each port (e.g., IP address, 1624 administrative status); 1625 . the statistics collected on each port (e.g., number of packets 1626 received); 1628 . the current status (up or down). 1630 The Port LFB can have three modes of operation: 1631 . ingress only 1632 . egress only 1633 . hybrid (contains ingress and egress functions) 1635 7.2. Dropper LFB 1637 A dropper LFB has one input, and no outputs. It discards all 1638 packets that it receives without any modification or examination of 1639 those packets. 1641 The purpose of a dropper LFB is to allow the description of "sinks" 1642 within the model, where those sinks do not result in the packet 1643 being sent into any object external to the model. 1645 7.3. Redirector (de-MUX) LFB 1647 A redirector LFB has one input, and N outputs. 1649 The purpose of the redirector LFB is to explicitly represent a 1650 place in the LFB Topology where the redirection process occurs, and 1651 where it may be configured. 1653 The redirector LFB takes an input packet P, and uses the metadata M 1654 to redirect that packet to one or more of N outputs, e.g. unicast 1655 forwarding, multicast, or broadcast. 1657 Note that other LFBs may also have redirecting functionality, if 1658 they have multiple outputs. 1660 7.4. Scheduler LFB 1662 A Scheduler LFB has multiple inputs and one output. The purpose of 1663 the Scheduler LFB is to perform time-dependent packet forwarding. 1664 The Scheduler LFB multiplexes from its inputs onto its output(s), 1665 based on internal configuration such as packet priority, etc. The 1666 packet is not modified during this process. 1668 7.5. Queue LFB 1670 The Queue LFB has one input and one output. It takes input packets 1671 and places them onto queues. These packets are later forwarded to 1672 the output(s) of the LFB, based on back-pressure from the next LFB 1673 which typically is a scheduler LFB. 1675 7.6. Counter LFB 1677 A counter LFB updates its statistical attributes, by counting 1678 packets, or metadata. The packet is not modified, and the metadata 1679 may, or may not, be modified. 1681 The purpose of a Counter LFB is to record simple accounting of 1682 events on the FE. 1684 A counter LFB is independent of time 't', in that it does not 1685 perform any time-dependent counting. The time at which a count is 1686 made may, however, be associated with that count. 1688 7.7. Meter LFB and Policer LFB 1690 A Meter LFB is a counter LFB that is time dependent. That is, it 1691 meters the rate over time at which packets or metadata flow through 1692 the LFB. The purpose of the Meter LFB is to record time-dependent 1693 accounting of events on the FE. 1695 When a Meter LFB has multiple outputs, with one output being a 1696 marker, or dropping the packet, then the Meter LFB becomes a 1697 Policer LFB, performing a policing function. 1699 7.8. Classifier LFB 1701 A Classifier LFB uses its attributes to classify the packet into 1702 one of N different logical classes. 1704 The purpose of a Classifier LFB is to logically partition packets 1705 into one or more classes. The result of this partitioning is that 1706 the Classifier LFB produces metadata that describes the classes 1707 into which the packet has been partitioned. The packet is not 1708 modified during this process. 1710 A Classifier LFB takes an input packet and metadata, and produces 1711 the same packet with new or more metadata. A classifier is 1712 parameterized by filters. Classification is done by matching the 1713 contents of the incoming packets according to the filters, and the 1714 result of classification is produced in the form of metadata. Note 1715 that this classifier is modeled solely based on its internal 1716 processing, and not on its inputs and outputs. The block is a 1717 single-exit classifier that does NOT physically redirect the 1718 packet. In contrast, a DiffServ-like classifier is a 1:N (fan-out) 1719 device: It takes a single traffic stream as input and generate N 1720 logically separate traffic streams as output. That kind of multi- 1721 exit classifier can be modeled by combining this classifier with a 1722 redirector (see Section 6.1.6). 1724 A filter decides if input packets match particular criteria. That 1725 is, it "marks" a packet as either matching, or non-matching to the 1726 filter criteria. According to [DiffServ], "a filter consists of a 1727 set of conditions on the component values of a packet's 1728 classification key (the header values, contents, and attributes 1729 relevant for classification)". 1731 Note that other FE LFBs MAY perform simple classification on the 1732 packet or metadata. The purpose of the FE Classifier LFB is to 1733 model an LFB that "digests" large amounts of input data (packet, 1734 metadata), to produce a "summary" of the classification results, in 1735 the form of additional metadata. Other FE LFBs can then use this 1736 summary information to quickly and simply perform trivial 1737 "classifications". 1739 The requirement for a unique and separate FE Classifier LFB comes 1740 about because it would not make sense to model a classifier LFB 1741 inside each of every other LFB. Such a model would be highly 1742 redundant. We therefore specifically model a complex 1743 classification LFB, and explicitly state that other blocks may make 1744 decisions based on the parameters S, t, and M, but not on P. 1746 Note that a classifier LFB may have multiple outputs. In that 1747 case, it may redirect input packets to one (or more) of the 1748 outputs, and may not associate any metadata with those output 1749 packets. 1751 7.9. Modifier LFB 1753 A modifier LFB modifies incoming packets and sends them out. 1754 Usually the metadata is used to determine how to modify the packet. 1756 This LFB is defined in a generic manner, and we expect that 1757 specific examples of packet and/or metadata modification will be 1758 described as a subclass of the modifier LFB. 1760 For example, we may have an explicit LFB for packet compression and 1761 decompression, or for encryption and decryption, or for packet 1762 encapsulation. The decision as to how best to model these 1763 functions will be made based on further investigation of the LFB 1764 model, and with practical experience using it. 1766 7.10. Packet Header Rewriter LFB 1767 This LFB is used to re-write fields on the packet header, such as 1768 IPv4 TTL decrementing, checksum calculation, or TCP/IP NAT. 1770 We may want to have multiple LFBs for different kinds of header re- 1771 writing. 1773 8. Satisfying the Requirements on FE Model 1775 (Editor's Note: The text in this section is very preliminary but 1776 we decide to leave it as is because it is too early to understand 1777 how to model all the functions as dictated in [1] when Section 7 1778 is still very much work in progress. This section should be 1779 revised once Section 7 is more settled.) 1781 A minimum set of FE functions is defined in [1] that must be 1782 supported by any proposed FE model. In this section, we 1783 demonstrate how the three components in FE model as described in 1784 Section 4, 5, 6 along with the LFB class library defined in Section 1785 7 can be used to express all the logical functions required in [1]. 1787 8.1. Port Functions 1789 Every FE contains a certain number of interfaces (ports), including 1790 both the inter-NE interfaces and intra-NE interfaces. The inter-NE 1791 interfaces are the external interfaces for the NE to 1792 receive/forward packets from/to the external world. The intra-NE 1793 interfaces are used for FE-FE or FE-CE communications. Same model 1794 should be used for both the inter-FE and intra-FE interfaces, but 1795 it is necessary to make the distinction between the two known to 1796 the CE so that the CE can do different configuration. 1798 The port LFB class is designed to model the specific physical ports 1799 while the source/sink LFB can be used to model the logical 1800 interface. 1802 The intra-NE interfaces that are used for FE-FE communications 1803 should be modeled just like the inter-NE interfaces. The ForCES 1804 base protocol will include FE topology query so that the CE can 1805 learn of how the multiple FEs are interconnected via such 1806 interfaces. But the intra-NE interfaces that are used for FE-CE 1807 communications are part of the ForCES protocol entity on the FE and 1808 so it is not necessary to model them explicitly. It is assumed 1809 that every FE will have at least one internal interface to 1810 communicate to the CE and such interface do not have to be visible 1811 in the FE model. 1813 8.2. Forwarding Functions 1815 Support for IPv4 and IPv6 unicast and multicast forwarding 1816 functions must be provided by the model. 1818 Typically, the control plane maintains the Routing Information Base 1819 (RIB), which contains all the routes discovered by all the routing 1820 protocols with all kinds of attributes relevant to the routes. The 1821 forwarding plane uses a different database, the Forwarding 1822 Information Base (FIB), which contains only the active subset of 1823 those routes (only the best routes chosen for forwarding) with 1824 attributes that are only relevant for forwarding. A component in 1825 the control plane, termed Route Table Manager (RTM), is responsible 1826 to manage the RIB in the CE and maintain the FIB used by the FEs. 1827 Therefore, the most important aspect in modeling the forwarding 1828 functions is the data model for the FIB. The model also needs to 1829 support the possibility of multiple paths. 1831 At the very minimum, each route in the FIB needs to contain the 1832 following layer-3 information: 1833 . the prefix of the destination IP address; 1834 . the length of the prefix; 1835 . the number of equal-cost multi-path; 1836 . the next hop IP address and the egress interface for each 1837 path. 1839 Another aspect of the forwarding functions is the method to resolve 1840 a next hop destination IP address into the associated media 1841 address. There are many ways to resolve Layer 3 to Layer 2 address 1842 mapping depending upon link layer. For example, in case of Ethernet 1843 links, the Address Resolution Protocol (ARP, defined in RFC 826) is 1844 used for IPv4 address resolution. 1846 Assuming a separate table is maintained in the FEs for address 1847 resolution, the following information is necessary for each address 1848 resolution entry: 1849 . the next hop IP address; 1850 . the media address. 1852 Different implementation may have different ways to maintain the 1853 FIB and the resolution table. For example, a FIB may consist of two 1854 separate tables, one to match the prefix to the next hop and the 1855 other to match the next hop to the egress interface. Another 1856 implementation may use one table instead. Our approach of using 1857 the fine-grained FE blocks to model the forwarding functions allow 1858 such flexibility. 1860 For example, a combination of a classifier, followed by a modifier 1861 and a redirector can model the forwarding function. 1863 8.3. QoS Functions 1865 The IETF community has already done lots work in modeling the QoS 1866 functions in the datapath. The IETF DiffServ working group has 1867 defined an informal data model [3]for QoS-related functions like 1868 classification, metering, marking, actions of marking, dropping, 1869 counting and multiplexing, queueing, etc. The latest work on 1870 DiffServ PIB (Policy Information Base) [4] defines a set of 1871 provisioning classes to provide policy control of resources 1872 implementing the Diferentiated Services Architecture. DiffServ PIB 1873 also has an element of capability flavor to it. The IETF Policy 1874 Framework working group is also defining an informational model [6] 1875 to describe the QoS mechanisms inherent in different network 1876 devices, including hosts. This model is intended to be used with 1877 the QoS Policy Information Model [7] to model how policies can be 1878 defined to manage and configure the QoS mechanisms present in the 1879 datapath of devices. 1881 Here is a list of QoS functions that should be supported by the FE 1882 model: 1883 . Classifier 1884 . Meter 1885 . Marker 1886 . Dropper 1887 . Counter 1888 . Queue and Scheduler 1889 . Shaper 1891 LFB class library as described in Section 7 already supports most 1892 of these functions directly. 1894 Note that A shaper should be modeled as a queue feeding a scheduler 1895 input that is serviced using a non-work-conserving policy. The 1896 queue LFB would include multiple FIFO queue resources (selected by 1897 META_QUEUE_ID) and AQManagers assigned to queues. The scheduler 1898 LFB would include multiple input resources with associated service 1899 policies. Queue outputs would be bound to scheduler inputs via 1900 passing META_SCHED_ID with the packet at the output of the queue. 1901 The metadata is only there to allow correlation in configuration 1902 parameters between the queueing LFB and the scheduler LFB (assign 1903 queue X to scheduler input Y by configuring queue X to emit 1904 META_SCHED_ID Y). 1906 8.4. Generic Filtering Functions 1907 A combination of classifier, redirector, modifier etc. can model 1908 complex set of filtering functions. For example, Figure 8 1909 represents a filtering function that classifies packets into one of 1910 two logical classes: forward, and drop. These logical classes are 1911 represented as meta data M1, and M2. The re-director uses this 1912 meta data to re-direct the packet to one of two outputs. The first 1913 sinks the packet back into the network. The second silently drops 1914 the packets. 1916 classifier -> redirector ---M1--- sink 1917 \ 1918 \-M2--- dropper 1920 Figure 8. A filtering function example. 1922 8.5. Vendor Specific Functions 1924 New LFB class can always be defined according to the LFB model as 1925 described in Section 7 to support vendor specific functions. New 1926 LFB class can also be derived from an existing LFB class by 1927 inheritance. 1929 8.6.High-Touch Functions 1931 High-touch functions are those that take action on the contents or 1932 headers of a packet based on content other than what is found in 1933 the IP header. Examples of such functions include NAT, ALG, 1934 firewall, tunneling and L7 content recognition. 1936 The ForCES working group first needs to agree upon a small set of 1937 common high-touch functions with well-defined behavior to be 1938 included in the LFB class library. Here is a list of candidate 1939 blocks: 1940 . NAT 1941 . Firewall 1942 . Encapsulator 1943 . Decapsulator 1945 8.7. Security Functions 1947 The FE model must be able to describe the types of encryption 1948 and/or decryption functions that an FE supports and the associated 1949 attributes for such functions. 1951 The IP Security Policy (IPSP) Working Group in the IETF has started 1952 work in defining the IPSec Policy Information Base [8]. Further 1953 study on this is needed to determine whether it can be reused here 1954 and any other additional work is needed. 1956 8.8. Off-loaded Functions 1958 In addition to the packet processing functions that are typical to 1959 find on the FEs, some logical functions may also be executed 1960 asynchronously by some FEs, according to a certain finite-state 1961 machine, triggered not only by packet events, but by timer events 1962 as well. Examples of such functions include finite-state machine 1963 execution required by TCP termination or OSPF Hello processing off- 1964 loaded from the CE. The FE model must be capable of expressing 1965 these asynchronous functions, so that the CE may take advantage of 1966 such off-loaded functions on the FEs. 1968 The ForCES working group first needs to agree upon a small set of 1969 such off-loaded functions with well-understood behavior and 1970 interactions with the control plane. 1972 8.9. IPFLOW/PSAMP Functions 1974 [9] defines architecture for IP traffic flow monitoring, measuring 1975 and exporting. The LFB model supports statistics collection on the 1976 LFB by including statistical attributes (Section 4.4.4) for all the 1977 LFB class definitions, and meter LFB (Section 7.2.2) and counter 1978 LFB (Section 7.2.1) can also be used to support accounting 1979 functions in the FE. 1981 [10] describes a framework to define a standard set of capabilities 1982 for network elements to sample subsets of packets by statistical 1983 and other methods. Time event generation, filter LFB, and 1984 counter/meter LFB are the elements needed to support packet 1985 filtering and sampling functions -- these elements are all included 1986 in the FE model. 1988 9. Using the FE model in the ForCES Protocol 1990 The actual model of the forwarding plane in a given NE is 1991 something the CE must learn and control via communicating with the 1992 FEs (or by other means). Most of this communication will happen in 1993 the post-association phase using the ForCES protocol. The 1994 following types of information must be exchanged between CEs and 1995 FEs via the ForCES protocol: 1996 1) FE topology query; 1997 2) FE capability declaration; 1998 3) LFB topology (per FE) and configuration capabilities query; 1999 4) LFB capability declaration; 2000 5) State query of LFB attributes; 2001 6) Manipulation of LFB attributes; 2002 7) LFB topology reconfiguration. 2004 Items 1) through 5) are query exchanges, the main flow of 2005 information being from the FEs to the CEs. Items 1) through 4) are 2006 typically queried by the CE(s) in the beginning of the post- 2007 association (PA) phase, though they may be repeatedly queried at 2008 any time in the PA phase. Item 5) (state query) will be used at 2009 the beginning of the PA phase, and often frequently during the PA 2010 phase (especially for the query of statistical counters). 2012 Items 6) and 7) are "command" type of exchanges, the main flow of 2013 information being from the CEs to the FEs. Messages in Item 6) 2014 (the LFB re-configuration commands) are expected to be used 2015 frequently. Item 7) (LFB topology re-configuration) is needed 2016 only if dynamic LFB topologies are supported by the FEs and it is 2017 expected to be used infrequently. 2019 Among the seven types of payload information the ForCES protocol 2020 carries between CEs and FEs, the FE model covers all of them 2021 except item 1), which concerns the inter-FE topology. The FE 2022 model focuses on the LFB and LFB topology within a single FE. 2023 Since the information of item 1) requires global knowledge about 2024 all the FEs and their inter-connection with each other, this 2025 exchange is made part of the ForCES base protocol instead of the 2026 FE model. 2028 The relationship between the FE model and the seven post- 2029 association messages are visualized in Figure 9: 2031 +--------+ 2032 ..........-->| CE | 2033 /----\ . +--------+ 2034 \____/ FE Model . ^ | 2035 | |................ (1),2 | | 6, 7 2036 | | (off-line) . 3, 4, 5 | | 2037 \____/ . | v 2038 . +--------+ 2039 e.g. RFCs ..........-->| FE | 2040 +--------+ 2042 Figure 9. Relationship between FE model and the ForCES protocol 2043 messages, where (1) is part of the ForCES base protocol, and the 2044 rest are defined by the FE model. 2046 The actual encoding of these messages is defined by the ForCES 2047 protocol and beyond the scope of the FE model. Their discussion is 2048 nevertheless important here for the following reasons: 2049 . These PA model components have considerable impact on the FE 2050 model. For example, some of the above information can be 2051 represented as attributes of the LFBs, in which case such 2052 attributes must be defined in the LFB classes. 2053 . The understanding of the type of information that must be 2054 exchanged between the FEs and CEs can help to select the 2055 appropriate protocol format and the actual encoding method 2056 (such as XML, TLVs). 2057 . Understanding the frequency of these types of messages should 2058 influence the selection of the protocol format (efficiency 2059 considerations). 2061 The remaining sub-sections of this section address each of the 2062 seven message types. 2064 9.1. FE Topology Query 2066 (Editor's Note: It is still an open issue where the FE topology 2067 information query belongs -- it can be either supported as part of 2068 FE attributes in the FE model, or it can be supported by the ForCES 2069 protocol explicitly. Hence the text here is tentative and subject 2070 to change per WG discussion.) 2072 An FE may contain zero, one or more external ingress ports. 2073 Similarly, an FE may contain zero, one or more external egress 2074 ports. In another word, not every FE has to contain any external 2075 ingress or egress interfaces. For example, Figure 10 shows two 2076 cascading FEs. FE #1 contains one external ingress interface but 2077 no external egress interface, while FE #2 contains one external 2078 egress interface but no ingress interfce. It is possible to 2079 connect these two FEs together via their internal interfaces to 2080 achieve the complete ingress-to-egress packet processing function. 2081 This provides the flexibility to spread the functions across 2082 multiple FEs and interconnect them together later for certain 2083 applications. 2085 While the inter-FE communication protocol is out of scope for 2086 ForCES, it is up to the CE to query and understand how multiple FEs 2087 are inter-connected to perform a complete ingress-egress packet 2088 processing function, like that described in Figure 10. The inter- 2089 FE topology information may be provided by FEs, may be hard-coded 2090 into CE, or may be provided by some other entity (e.g., a bus 2091 manager) independent of the FEs. So while the ForCES protocol 2092 supports FE topology query from FEs, it is optional for the CE to 2093 use it, assuming the CE has other means to gather such topology 2094 information. 2096 +-----------------------------------------------------+ 2097 | +---------+ +------------+ +---------+ | 2098 input| | | | | | output | 2099 ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ 2100 | | port | |Decompressor| |Forwarder| FE | | 2101 | +---------+ +------------+ +---------+ #1 | | 2102 +-----------------------------------------------------+ V 2103 | 2104 +-----------------------<-----------------------------+ 2105 | 2106 | +----------------------------------------+ 2107 V | +------------+ +----------+ | 2108 | input | | | | output | 2109 +->--+->|Header |-->| Egress |---------+--> 2110 | |Compressor | | port | FE | 2111 | +------------+ +----------+ #2 | 2112 +----------------------------------------+ 2114 Figure 10. An example of two FEs connected together. 2116 Once the inter-FE topology is discovered by the CE after this 2117 query, it is assumed that the inter-FE topology remains static. 2118 However, it is possible that an FE may go down during the NE 2119 operation, or a board may be inserted and a new FE activated, so 2120 the inter-FE topology will be affected. It is up to the ForCES 2121 protocol to provide mechanism for the CE to detect such events and 2122 deal with the change in FE topology. FE topology is outside the 2123 scope of the FE model. 2125 9.2. FE Capability Declarations 2127 FEs will have many types of limitations. Some of the limitations 2128 must be expressed to the CEs as part of the capability model. The 2129 CEs must be able to query these capabilities on a per-FE basis. 2130 Examples: 2131 . Metadata passing capabilities of the FE. Understanding these 2132 capabilities will help the CE to evaluate the feasibility of 2133 LFB topologies, and hence to determine the availability of 2134 certain services. 2135 . Global resource query limitations (applicable to all LFBs of 2136 the FE). 2137 . LFB supported by the FE. 2138 . LFB class instantiation limit. 2140 . LFB topological limitations (linkage constraint, ordering 2141 etc.) 2143 9.3. LFB Topology and Topology Configurability Query 2145 The ForCES protocol must provide the means for the CEs to discover 2146 the current set of LFB instances in an FE and the interconnections 2147 between the LFBs within the FE. In addition, there should be 2148 sufficient information provided on whether the FE supports any CE- 2149 initiated (dynamic) changes to the LFB topology, and if so, what 2150 are the allowed topologies. Topology configurability can also be 2151 considered as part of the FE capability query as described in 2152 Section 9.3. 2154 9.4. LFB Capability Declarations 2156 LFB class specifications will define a generic set of capabilities. 2157 When an LFB instance is implemented (instantiated) on a vendor's 2158 FE, some additional limitations may be introduced. Note that we 2159 discuss here only limitations that are within the flexibility of 2160 the LFB class specification, that is, the LFB instance will remain 2161 compliant with the LFB class specification despite these 2162 limitations. For example, certain features of an LFB class may be 2163 optional, in which case it must be possible for the CE to determine 2164 if an optional feature is supported by a given LFB instance or not. 2165 Also, the LFB class definitions will probably contain very few 2166 quantitative limits (e.g., size of tables), since these limits are 2167 typically imposed by the implementation. Therefore, quantitative 2168 limitations should always be expressed by capability arguments. 2170 LFB instances in the model of a particular FE implementation will 2171 possess limitations on the capabilities defined in the 2172 corresponding LFB class. The LFB class specifications must define 2173 a set of capability arguments, and the CE must be able to query the 2174 actual capabilities of the LFB instance via querying the value of 2175 such arguments. The capability query will typically happen when 2176 the LFB is first detected by the CE. Capabilities need not be re- 2177 queried in case of static limitations. In some cases, however, some 2178 capabilities may change in time (e.g., as a result of 2179 adding/removing other LFBs, or configuring certain attributes of 2180 some other LFB when the LFBs share physical resources), in which 2181 case additional mechanisms must be implemented to inform the CE 2182 about the changes. 2184 The following two broad types of limitations will exist: 2185 . Qualitative restrictions. For example, a standardized multi- 2186 field classifier LFB class may define a large number of 2187 classification fields, but a given FE may support only a 2188 subset of those fields. 2189 . Quantitative restrictions, such as the maximum size of tables, 2190 etc. 2192 The capability parameters that can be queried on a given LFB class 2193 will be part of the LFB class specification. The capability 2194 parameters should be regarded as special attributes of the LFB. The 2195 actual values of these arguments may be, therefore, obtained using 2196 the same attribute query mechanisms as used for other LFB 2197 attributes. 2199 Capability attributes will typically be read-only arguments, but in 2200 certain cases they may be configurable. For example, the size of a 2201 lookup table may be limited by the hardware (read-only), in other 2202 cases it may be configurable (read-write, within some hard limits). 2204 Assuming that capabilities will not change frequently, the 2205 efficiency of the protocol/schema/encoding is of secondary concern. 2207 9.5. State Query of LFB Attributes 2209 This feature must be provided by all FEs. The ForCES protocol and 2210 the data schema/encoding conveyed by the protocol must together 2211 satisfy the following requirements to facilitate state query of the 2212 LFB attributes: 2213 . Must permit FE selection. This is primarily to refer to a 2214 single FE, but referring to a group of (or all) FEs may 2215 optional be supported. 2216 . Must permit LFB instance selection. This is primarily to refer 2217 to a single LFB instance of an FE, but optionally addressing 2218 of a group of LFBs (or all) may be supported. 2219 . Must support addressing of individual attribute of an LFB. 2220 . Must provide efficient encoding and decoding of the addressing 2221 info and the configured data. 2222 . Must provide efficient data transmission of the attribute 2223 state over the wire (to minimize communication load on the CE- 2224 FE link). 2226 9.6. LFB Attribute Manipulation 2228 This is a place-holder for all operations that the CE will use to 2229 populate, manipulate, and delete attributes of the LFB instances on 2230 the FEs. This is how the CE configures an individual LFB instance. 2232 The same set of requirements as described in Section 9.5 for 2233 attribute query applies here for attribute manipulation as well. 2235 Support for various levels of feedback from the FE to the CE (e.g., 2236 request received, configuration completed), as well as multi- 2237 attribute configuration transactions with atomic commit and 2238 rollback, may be necessary in some circumstances. 2240 (Editor's note: It remains an open issue as to whether or not other 2241 methods are needed in addition to "get attribute" and "set 2242 attribute" (such as multi-attribute transactions). If the answer 2243 to that question is yes, it is not clear whether such methods 2244 should be supported by the FE model itself or the ForCES protocol.) 2246 9.7. LFB Topology Re-configuration 2248 Operations that will be needed to reconfigure LFB topology: 2249 . Create a new instance of a given LFB class on a given FE. 2250 . Connect a given output of LFB x to the given input of LFB y. 2251 . Disconnect: remove a link between a given output of an LFB and 2252 a given input of another LFB. 2253 . Delete a given LFB (automatically removing all interconnects 2254 to/from the LFB). 2256 10. Acknowledgments 2258 The authors would also like to thank the following individuals for 2259 their invaluable technical input: David Putzolu, Hormuzd Khosravi, 2260 Eric Johnson, David Durham, Andrzej Matejko, T. Sridhar, Jamal Hadi 2261 Salim, Alex Audu, Gamil Cain. 2263 11. Security Considerations 2265 The FE model describes the representation and organization of data 2266 sets and attributes in the FEs. ForCES framework document [2] 2267 provides a comprehensive security analysis for the overall ForCES 2268 architecture. For example, the ForCES protocol entities must be 2269 authenticated per the ForCES requirements before they can access 2270 the information elements described in this document via ForCES. 2271 The access to the information contained in the FE model is 2272 accomplished via the ForCES protocol which will be defined in 2273 separate documents and so the security issues will be addressed 2274 there. 2276 12. Normative References 2278 [1] Khosravi, H. et al., "Requirements for Separation of IP Control 2279 and Forwarding", work in progress, July 2003, . 2282 13. Informative References 2284 [2] Yang, L. et al., "Forwarding and Control Element Separation 2285 (ForCES) Framework", work in progress, July 2003, . 2288 [3] Bernet, Y. et al., "An Informal Management Model for Diffserv 2289 Routers", May 2002. 2291 [4] Chan, K. et al., "Differentiated Services Quality of Service 2292 Policy Information Base", March 2003. 2294 [5] Sahita, R. et al., "Framework Policy Information Base", RFC 2295 3318, March 2003. 2297 [6] Moore, B. et al., "Information Model for Describing Network 2298 Device QoS Datapath Mechanisms", work in progress, May 2002, 2299 . 2301 [7] Snir, Y. et al., "Policy Framework QoS Information Model", work 2302 in progress, Nov 2001, . 2307 [9] Quittek, J. et Al., "Requirements for IP Flow Information 2308 Export", work in progress, June 2003, . 2311 [10] Duffield, N., "A Framework for Passive Packet Measurement ", 2312 work in progress, June 2003, . 2314 [11] Pras, A. and Schoenwaelder, J., FRC 3444 "On the Difference 2315 between Information Models and Data Models", January 2003. 2317 14. Authors' Addresses 2319 L. Lily Yang 2320 Intel Labs 2321 2111 NE 25th Avenue 2322 Hillsboro, OR 97124, USA 2323 Phone: +1 503 264 8813 2324 Email: lily.l.yang@intel.com 2325 Joel M. Halpern 2326 Megisto Systems, Inc. 2327 20251 Century Blvd. 2328 Germantown, MD 20874-1162, USA 2329 Phone: +1 301 444-1783 2330 Email: jhalpern@megisto.com 2332 Ram Gopal 2333 Nokia Research Center 2334 5, Wayside Road, 2335 Burlington, MA 01803, USA 2336 Phone: +1 781 993 3685 2337 Email: ram.gopal@nokia.com 2339 Alan DeKok 2340 IDT Inc. 2341 1575 Carling Ave. 2342 Ottawa, ON K1G 0T3, Canada 2343 Phone: +1 613 724 6004 ext. 231 2344 Email: alan.dekok@idt.com 2346 Zsolt Haraszti 2347 Ericsson 2348 920 Main Campus Dr, St. 500 2349 Raleigh, NC 27606, USA 2350 Phone: +1 919 472 9949 2351 Email: zsolt.haraszti@ericsson.com 2353 Steven Blake 2354 Ericsson 2355 920 Main Campus Dr, St. 500 2356 Raleigh, NC 27606, USA 2357 Phone: +1 919 472 9913 2358 Email: steven.blake@ericsson.com 2360 15. Intellectual Property Right 2362 The authors are not aware of any intellectual property right issues 2363 pertaining to this document. 2365 16. IANA consideration 2367 A namespace is needed to uniquely identify the LFB type in the LFB 2368 class library. 2370 Frame type supported on input and output of LFB must also be 2371 uniquely identified. 2373 A set of metadata supported by the LFB model must also be uniquely 2374 identified with names.