idnits 2.17.1 draft-ietf-forces-model-06.txt: -(2846): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3229): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3255): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == There are 19 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 15. IANA consideration' ) ** The document seems to lack an Authors' Addresses Section. ** There are 791 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 25 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 740 has weird spacing: '...e other outpu...' -- 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 (March 2006) is 6617 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 162 -- Looks like a reference, but probably isn't: 'N' on line 3393 -- Looks like a reference, but probably isn't: '1-9' on line 3578 -- Looks like a reference, but probably isn't: '0-9' on line 3578 == Unused Reference: '3' is defined on line 5366, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 5375, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 5378, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3654 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3746 (ref. '2') Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft L. Yang 3 Expiration: September 2006 Intel Corp. 4 File: draft-ietf-forces-model-06.txt J. Halpern 5 Working Group: ForCES Megisto Systems 6 R. Gopal 7 Nokia 8 A. DeKok 9 Infoblox, Inc. 10 Z. Haraszti 11 Clovis Solutions 12 E. Deleganes 13 Intel Corp. 14 March 2006 16 ForCES Forwarding Element Model 18 draft-ietf-forces-model-06.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than a "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.html. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Abstract 50 This document defines the forwarding element (FE) model used in the 51 Forwarding and Control Element Separation (ForCES) protocol. The 52 model represents the capabilities, state and configuration of 53 forwarding elements within the context of the ForCES protocol, so 54 that control elements (CEs) can control the FEs accordingly. More 55 specifically, the model describes the logical functions that are 56 present in an FE, what capabilities these functions support, and how 57 these functions are or can be interconnected. This FE model is 58 intended to satisfy the model requirements specified in the ForCES 59 requirements draft, RFC 3564 [1]. A list of the basic logical 60 functional blocks (LFBs) is also defined in the LFB class library to 61 aid the effort in defining individual LFBs. 63 Table of Contents 65 Abstract...........................................................1 66 1. Definitions.....................................................4 67 2. Introduction....................................................5 68 2.1. Requirements on the FE model...............................6 69 2.2. The FE Model in Relation to FE Implementations.............6 70 2.3. The FE Model in Relation to the ForCES Protocol............7 71 2.4. Modeling Language for the FE Model.........................7 72 2.5. Document Structure.........................................8 73 3. FE Model Concepts...............................................8 74 3.1. FE Capability Model and State Model........................8 75 3.2. LFB (Logical Functional Block) Modeling...................11 76 3.2.1. LFB Outputs..........................................13 77 3.2.2. LFB Inputs...........................................16 78 3.2.3. Packet Type..........................................19 79 3.2.4. Metadata.............................................19 80 3.2.5. LFB Events...........................................26 81 3.2.6. LFB Element Properties...............................27 82 3.2.7. LFB Versioning.......................................27 83 3.2.8. LFB Inheritance......................................27 84 3.3. FE Datapath Modeling......................................28 85 3.3.1. Alternative Approaches for Modeling FE Datapaths.....29 86 3.3.2. Configuring the LFB Topology.........................33 87 4. Model and Schema for LFB Classes...............................37 88 4.1. Namespace.................................................37 89 4.2. Element......................................37 90 4.3. Element............................................39 91 4.4. Element for Frame Type Declarations...........39 92 4.5. Element for Data Type Definitions..........40 93 4.5.1. Element for Aliasing Existing Data Types...42 94 4.5.2. Element for Deriving New Atomic Types.......42 95 4.5.3. Element to Define Arrays.....................43 96 4.5.4. Element to Define Structures................47 97 4.5.5. Element to Define Union Types................48 98 4.5.6. Augmentations........................................48 99 4.6. Element for Metadata Definitions...........49 100 4.7. Element for LFB Class Definitions..........50 101 4.7.1. Element to Express LFB Inheritance.....52 102 4.7.2. Element to Define LFB Inputs............52 103 4.7.3. Element to Define LFB Outputs..........55 104 4.7.4. Element to Define LFB Operational 105 Attributes..................................................56 106 4.7.5. Element to Define LFB Capability 107 Attributes..................................................59 108 4.7.6. Element for LFB Notification Generation.....60 109 4.7.7. Element for LFB Operational Specification 110 ............................................................64 111 4.8. Properties................................................64 112 4.9. XML Schema for LFB Class Library Documents................70 113 5. FE Attributes and Capabilities.................................81 114 5.1. XML for FEObject Class definition.........................81 115 5.2. FE Capabilities...........................................87 116 5.2.1. ModifiableLFBTopology................................88 117 5.2.2. SupportedLFBs and SupportedLFBType...................88 118 5.3. FEAttributes..............................................90 119 5.3.1. FEStatus.............................................90 120 5.3.2. LFBSelectors and LFBSelectorType.....................90 121 5.3.3. LFBTopology and LFBLinkType..........................91 122 5.3.4. FENeighbors an FEConfiguredNeighborType..............91 123 6. Satisfying the Requirements on FE Model........................92 124 6.1. Port Functions............................................93 125 6.2. Forwarding Functions......................................93 126 6.3. QoS Functions.............................................93 127 6.4. Generic Filtering Functions...............................94 128 6.5. Vendor Specific Functions.................................94 129 6.6. High-Touch Functions......................................94 130 6.7. Security Functions........................................94 131 6.8. Off-loaded Functions......................................94 132 6.9. IPFLOW/PSAMP Functions....................................95 133 7. Using the FE model in the ForCES Protocol......................95 134 7.1. FE Topology Query.........................................97 135 7.2. FE Capability Declarations................................98 136 7.3. LFB Topology and Topology Configurability Query...........98 137 7.4. LFB Capability Declarations...............................98 138 7.5. State Query of LFB Attributes.............................99 139 7.6. LFB Attribute Manipulation...............................100 140 7.7. LFB Topology Re-configuration............................100 141 8. Example.......................................................100 142 8.1. Data Handling............................................108 143 8.1.1. Setting up a DLCI...................................108 144 8.1.2. Error Handling......................................109 145 8.2. LFB Attributes...........................................109 146 8.3. Capabilities.............................................110 147 8.4. Events...................................................110 148 9. Acknowledgments...............................................111 149 10. Security Considerations......................................112 150 11. Normative References.........................................112 151 12. Informative References.......................................112 152 13. Authors' Addresses...........................................113 153 14. Intellectual Property Right..................................114 154 15. IANA consideration...........................................114 155 16. Copyright Statement..........................................114 157 Conventions used in this document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC-2119]. 163 1. Definitions 165 Terminology associated with the ForCES requirements is defined in 166 RFC 3564 [1] and is not copied here. The following list of 167 terminology relevant to the FE model is defined in this section. 169 FE Model -- The FE model is designed to model the logical processing 170 functions of an FE. The FE model proposed in this document includes 171 three components: the modeling of individual logical functional 172 blocks (LFB model), the logical interconnection between LFBs (LFB 173 topology) and the FE level attributes, including FE capabilities. 174 The FE model provides the basis to define the information elements 175 exchanged between the CE and the FE in the ForCES protocol. 177 Datapath -- A conceptual path taken by packets within the forwarding 178 plane inside an FE. Note that more than one datapath can exist 179 within an FE. 181 LFB (Logical Functional Block) Class (or type) -- A template that 182 representing a fine-grained, logically separable aspect of FE 183 processing. Most LFBs relate to packet processing in the data path. 184 LFB classes are the basic building blocks of the FE model. 186 LFB Instance -- As a packet flows through an FE along a datapath, it 187 flows through one or multiple LFB instances, where each LFB is an 188 instance of a specific LFB class. Multiple instances of the same 189 LFB class can be present in an FE's datapath. Note that we often 190 refer to LFBs without distinguishing between an LFB class and LFB 191 instance when we believe the implied reference is obvious for the 192 given context. 194 LFB Model -- The LFB model describes the content and structures in 195 an LFB, plus the associated data definition. Four types of 196 information are defined in the LFB model. The core part of the LFB 197 model is the LFB class definitions; the other three types define the 198 associated data including common data types, supported frame formats 199 and metadata. 201 LFB Metadata -- Metadata is used to communicate per-packet state 202 from one LFB to another, but is not sent across the network. The FE 203 model defines how such metadata is identified, produced and consumed 204 by the LFBs, but not how the per-packet state is implemented within 205 actual hardware. Metadata is sent between the FE and the CE on 206 redirect packets. 208 LFB Attribute -- Operational parameters of the LFBs that must be 209 visible to the CEs are conceptualized in the FE model as the LFB 210 attributes. The LFB attributes include: flags, single parameter 211 arguments, complex arguments, and tables that the CE can read or/and 212 write via the ForCES protocol. 214 LFB Topology -- A representation of the logical interconnection and 215 the placement of LFB instances along the datapath within one FE. 216 Sometimes this representation is called intra-FE topology, to be 217 distinguished from inter-FE topology. LFB topology is outside of 218 the LFB model, but is part of the FE model. 220 FE Topology -- A representation of how multiple FEs within a single 221 NE are interconnected. Sometimes this is called inter-FE topology, 222 to be distinguished from intra-FE topology (i.e., LFB topology). An 223 individual FE might not have the global knowledge of the full FE 224 topology, but the local view of its connectivity with other FEs is 225 considered to be part of the FE model. The FE topology is 226 discovered by the ForCES base protocol or by some other means. 228 Inter-FE Topology -- See FE Topology. 230 Intra-FE Topology -- See LFB Topology. 232 LFB class library -- A set of LFB classes that has been identified 233 as the most common functions found in most FEs and hence should be 234 defined first by the ForCES Working Group. 236 2. Introduction 238 RFC 3746 [2] specifies a framework by which control elements (CEs) 239 can configure and manage one or more separate forwarding elements 240 (FEs) within a networking element (NE) using the ForCES protocol. 241 The ForCES architecture allows Forwarding Elements of varying 242 functionality to participate in a ForCES network element. The 243 implication of this varying functionality is that CEs can make only 244 minimal assumptions about the functionality provided by FEs in an 245 NE. Before CEs can configure and control the forwarding behavior of 246 FEs, CEs need to query and discover the capabilities and states of 247 their FEs. RFC 3654 [1] mandates that the capabilities, states and 248 configuration information be expressed in the form of an FE model. 250 RFC 3444 [11] observed that information models (IMs) and data models 251 (DMs) are different because they serve different purposes. "The 252 main purpose of an IM is to model managed objects at a conceptual 253 level, independent of any specific implementations or protocols 254 used". "DMs, conversely, are defined at a lower level of 255 abstraction and include many details. They are intended for 256 implementors and include protocol-specific constructs." Sometimes 257 it is difficult to draw a clear line between the two. The FE model 258 described in this document is primarily an information model, but 259 also includes some aspects of a data model, such as explicit 260 definitions of the LFB class schema and FE schema. It is expected 261 that this FE model will be used as the basis to define the payload 262 for information exchange between the CE and FE in the ForCES 263 protocol. 265 2.1. Requirements on the FE model 267 RFC 3654 [1] defines requirements that must be satisfied by a ForCES 268 FE model. To summarize, an FE model must define: 269 . Logically separable and distinct packet forwarding operations 270 in an FE datapath (logical functional blocks or LFBs); 271 . The possible topological relationships (and hence the sequence 272 of packet forwarding operations) between the various LFBs; 273 . The possible operational capabilities (e.g., capacity limits, 274 constraints, optional features, granularity of configuration) 275 of each type of LFB; 276 . The possible configurable parameters (i.e., attributes) of each 277 type of LFB; 278 . Metadata that may be exchanged between LFBs. 280 2.2. The FE Model in Relation to FE Implementations 282 The FE model proposed here is based on an abstraction of distinct 283 logical functional blocks (LFBs), which are interconnected in a 284 directed graph, and receive, process, modify, and transmit packets 285 along with metadata. The FE model should be designed such that 286 different implementations of the forwarding datapath can be 287 logically mapped onto the model with the functionality and sequence 288 of operations correctly captured. However, the model is not 289 intended to directly address how a particular implementation maps to 290 an LFB topology. It is left to the forwarding plane vendors to 291 define how the FE functionality is represented using the FE model. 292 Our goal is to design the FE model such that it is flexible enough 293 to accommodate most common implementations. 295 The LFB topology model for a particular datapath implementation must 296 correctly capture the sequence of operations on the packet. 297 Metadata generation by certain LFBs MUST always precede any use of 298 that metadata by subsequent LFBs in the topology graph; this is 299 required for logically consistent operation. Further, modification 300 of packet fields that are subsequently used as inputs for further 301 processing MUST occur in the order specified in the model for that 302 particular implementation to ensure correctness. 304 2.3. The FE Model in Relation to the ForCES Protocol 306 The ForCES base protocol is used by the CEs and FEs to maintain the 307 communication channel between the CEs and FEs. The ForCES protocol 308 may be used to query and discover the inter-FE topology. The 309 details of a particular datapath implementation inside an FE, 310 including the LFB topology, along with the operational capabilities 311 and attributes of each individual LFB, are conveyed to the CE within 312 information elements in the ForCES protocol. The model of an LFB 313 class should define all of the information that needs to be 314 exchanged between an FE and a CE for the proper configuration and 315 management of that LFB. 317 Specifying the various payloads of the ForCES messages in a 318 systematic fashion is difficult without a formal definition of the 319 objects being configured and managed (the FE and the LFBs within). 320 The FE Model document defines a set of classes and attributes for 321 describing and manipulating the state of the LFBs within an FE. 322 These class definitions themselves will generally not appear in the 323 ForCES protocol. Rather, ForCES protocol operations will reference 324 classes defined in this model, including relevant attributes and the 325 defined operations. 327 Section 7 provides more detailed discussion on how the FE model 328 should be used by the ForCES protocol. 330 2.4. Modeling Language for the FE Model 332 Even though not absolutely required, it is beneficial to use a 333 formal data modeling language to represent the conceptual FE model 334 described in this document. Use of a formal language can help to 335 enforce consistency and logical compatibility among LFBs. A full 336 specification will be written using such a data modeling language. 337 The formal definition of the LFB classes may facilitate the eventual 338 automation of some of the code generation process and the functional 339 validation of arbitrary LFB topologies. 341 Human readability was the most important factor considered when 342 selecting the specification language, whereas encoding, decoding and 343 transmission performance was not a selection factor. The encoding 344 method for over the wire transport is not dependent on the 345 specification language chosen and is outside the scope of this 346 document and up to the ForCES protocol to define. 348 XML was chosen as the specification language in this document, 349 because XML has the advantage of being both human and machine 350 readable with widely available tools support. 352 2.5. Document Structure 354 Section 3 provides a conceptual overview of the FE model, laying the 355 foundation for the more detailed discussion and specifications in 356 the sections that follow. Section 4 and 5 constitute the core of 357 the FE model, detailing the two major components in the FE model: 358 LFB model and FE level attributes including capability and LFB 359 topology. Section 6 directly addresses the model requirements 360 imposed by the ForCES requirement draft [1] while Section 7 explains 361 how the FE model should be used in the ForCES protocol. 363 3. FE Model Concepts 365 Some of the important concepts used throughout this document are 366 introduced in this section. Section 3.1 explains the difference 367 between a state model and a capability model, and describes how the 368 two can be combined in the FE model. Section 3.2 introduces the 369 concept of LFBs (Logical Functional Blocks) as the basic functional 370 building blocks in the FE model. Section 3.3 discusses the logical 371 inter-connection and ordering between LFB instances within an FE, 372 that is, the LFB topology. 374 The FE model proposed in this document is comprised of two major 375 components: the LFB model and FE level attributes, including FE 376 capabilities and LFB topology. The LFB model provides the content 377 and data structures to define each individual LFB class. FE 378 attributes provide information at the FE level, particularly the 379 capabilities of the FE at a coarse level. Part of the FE level 380 information is the LFB topology, which expresses the logical inter- 381 connection between the LFB instances along the datapath(s) within 382 the FE. Details of these components are described in Section 4 and 383 5. The intent of this section is to discuss these concepts at the 384 high level and lay the foundation for the detailed description in 385 the following sections. 387 3.1. FE Capability Model and State Model 389 The ForCES FE model includes both a capability and a state model. 390 The FE capability model describes the capabilities and capacities of 391 an FE by specifying the variation in functions supported and any 392 limitations. The FE state model describes the current state of the 393 FE, that is, the instantaneous values or operational behavior of the 394 FE. 396 Conceptually, the FE capability model tells the CE which states are 397 allowed on an FE, with capacity information indicating certain 398 quantitative limits or constraints. Thus, the CE has general 399 knowledge about configurations that are applicable to a particular 400 FE. For example, an FE capability model may describe the FE at a 401 coarse level such as: 403 . this FE can handle IPv4 and IPv6 forwarding; 404 . this FE can perform classification on the following fields: 405 source IP address, destination IP address, source port number, 406 destination port number, etc; 407 . this FE can perform metering; 408 . this FE can handle up to N queues (capacity); 409 . this FE can add and remove encapsulating headers of types 410 including IPSec, GRE, L2TP. 412 While one could try and build an object model to fully represent the 413 FE capabilities, other efforts found this to be a significant 414 undertaking. The main difficulty arises in describing detailed 415 limits, such as the maximum number of classifiers, queues, buffer 416 pools, and meters the FE can provide. We believe that a good 417 balance between simplicity and flexibility can be achieved for the 418 FE model by combining coarse level capability reporting with an 419 error reporting mechanism. That is, if the CE attempts to instruct 420 the FE to set up some specific behavior it cannot support, the FE 421 will return an error indicating the problem. Examples of similar 422 approaches include DiffServ PIB [4] and Framework PIB [5]. 424 There is one common and shared aspect of capability that will be 425 handled in a separate fashion. For all elements of information, 426 certain property information is needed. All elements need 427 information as to whether they are supported and if so whether the 428 element is readable or writeable. Based on their type, many 429 elements have additional common properties (for example, arrays have 430 their current size.) There is a specific model and protocol 431 mechanism for referencing this form of property information about 432 elements of the model. 434 The FE state model presents the snapshot view of the FE to the CE. 435 For example, using an FE state model, an FE may be described to its 436 corresponding CE as the following: 438 . on a given port, the packets are classified using a given 439 classification filter; 440 . the given classifier results in packets being metered in a 441 certain way, and then marked in a certain way; 442 . the packets coming from specific markers are delivered into a 443 shared queue for handling, while other packets are delivered to 444 a different queue; 446 . a specific scheduler with specific behavior and parameters will 447 service these collected queues. 449 Figure 1 shows the concepts of FE state, capabilities and 450 configuration in the context of CE-FE communication via the ForCES 451 protocol. 453 +-------+ +-------+ 454 | | FE capabilities: what it can/cannot do. | | 455 | |<-----------------------------------------| | 456 | | | | 457 | CE | FE state: what it is now. | FE | 458 | |<-----------------------------------------| | 459 | | | | 460 | | FE configuration: what it should be. | | 461 | |----------------------------------------->| | 462 +-------+ +-------+ 464 Figure 1. Illustration of FE state, capabilities and configuration 465 exchange in the context of CE-FE communication via ForCES. 467 The concepts relating to LFBs, particularly capability at the LFB 468 level and LFB topology will be discussed in the rest of this 469 section. 471 Capability information at the LFB level is an integral part of the 472 LFB model, and is modeled the same way as the other operational 473 parameters inside an LFB. For example, when certain features of an 474 LFB class are optional, the CE MUST be able to determine whether 475 those optional features are supported by a given LFB instance. Such 476 capability information can be modeled as a read-only attribute in 477 the LFB instance, see Section 4.7.5 for details. 479 Capability information at the FE level may describe the LFB classes 480 that the FE can instantiate; the number of instances of each that 481 can be created; the topological (linkage) limitations between these 482 LFB instances, etc. Section 5 defines the FE level attributes 483 including capability information. 485 Once the FE capability is described to the CE, the FE state 486 information can be represented by two levels. The first level is 487 the logically separable and distinct packet processing functions, 488 called Logical Functional Blocks (LFBs). The second level of 489 information describes how these individual LFBs are ordered and 490 placed along the datapath to deliver a complete forwarding plane 491 service. The interconnection and ordering of the LFBs is called LFB 492 Topology. Section 3.2 discusses high level concepts around LFBs, 493 whereas Section 3.3 discusses LFB topology issues. 495 3.2. LFB (Logical Functional Block) Modeling 497 Each LFB performs a well-defined action or computation on the 498 packets passing through it. Upon completion of its prescribed 499 function, either the packets are modified in certain ways (e.g., 500 decapsulator, marker), or some results are generated and stored, 501 often in the form of metadata (e.g., classifier). Each LFB 502 typically performs a single action. Classifiers, shapers and meters 503 are all examples of such LFBs. Modeling LFBs at such a fine 504 granularity allows us to use a small number of LFBs to express the 505 higher-order FE functions (such as an IPv4 forwarder) precisely, 506 which in turn can describe more complex networking functions and 507 vendor implementations of software and hardware. These LFBs will be 508 defined in detail in one or more documents. 510 An LFB has one or more inputs, each of which takes a packet P, and 511 optionally metadata M; and produces one or more outputs, each of 512 which carries a packet P', and optionally metadata M'. Metadata is 513 data associated with the packet in the network processing device 514 (router, switch, etc.) and is passed from one LFB to the next, but 515 is not sent across the network. In general, multiple LFBs are 516 contained in one FE, as shown in Figure 2, and all the LFBs share 517 the same ForCES protocol termination point that implements the 518 ForCES protocol logic and maintains the communication channel to and 519 from the CE. 521 +-----------+ 522 | CE | 523 +-----------+ 524 ^ 525 | Fp reference point 526 | 527 +--------------------------|-----------------------------------+ 528 | FE | | 529 | v | 530 | +----------------------------------------------------------+ | 531 | | ForCES protocol | | 532 | | termination point | | 533 | +----------------------------------------------------------+ | 534 | ^ ^ | 535 | : : Internal control | 536 | : : | 537 | +---:----------+ +---:----------| | 538 | | :LFB1 | | : LFB2 | | 539 | =====>| v |============>| v |======>...| 540 | Inputs| +----------+ |Outputs | +----------+ | | 541 | (P,M) | |Attributes| |(P',M') | |Attributes| |(P",M") | 542 | | +----------+ | | +----------+ | | 543 | +--------------+ +--------------+ | 544 | | 545 +--------------------------------------------------------------+ 547 Figure 2. Generic LFB Diagram 549 An LFB, as shown in Figure 2, has inputs, outputs and attributes 550 that can be queried and manipulated by the CE indirectly via an Fp 551 reference point (defined in RFC 3746 [2]) and the ForCES protocol 552 termination point. The horizontal axis is in the forwarding plane 553 for connecting the inputs and outputs of LFBs within the same FE. 554 The vertical axis between the CE and the FE denotes the Fp reference 555 point where bidirectional communication between the CE and FE 556 occurs: the CE to FE communication is for configuration, control and 557 packet injection while FE to CE communication is used for packet re- 558 direction to the control plane, monitoring and accounting 559 information, errors, etc. Note that the interaction between the CE 560 and the LFB is only abstract and indirect. The result of such an 561 interaction is for the CE to indirectly manipulate the attributes of 562 the LFB instances. 564 A namespace is used to associate a unique name or ID with each LFB 565 class. The namespace MUST be extensible so that a new LFB class can 566 be added later to accommodate future innovation in the forwarding 567 plane. 569 LFB operation is specified in the model to allow the CE to 570 understand the behavior of the forwarding datapath. For instance, 571 the CE must understand at what point in the datapath the IPv4 header 572 TTL is decremented. That is, the CE needs to know if a control 573 packet could be delivered to it either before or after this point in 574 the datapath. In addition, the CE MUST understand where and what 575 type of header modifications (e.g., tunnel header append or strip) 576 are performed by the FEs. Further, the CE MUST verify that the 577 various LFBs along a datapath within an FE are compatible to link 578 together. 580 There is value to vendors if the operation of LFB classes can be 581 expressed in sufficient detail so that physical devices implementing 582 different LFB functions can be integrated easily into an FE design. 583 Therefore, a semi-formal specification is needed; that is, a text 584 description of the LFB operation (human readable), but sufficiently 585 specific and unambiguous to allow conformance testing and efficient 586 design, so that interoperability between different CEs and FEs can 587 be achieved. 589 The LFB class model specifies information such as: 591 . number of inputs and outputs (and whether they are 592 configurable) 593 . metadata read/consumed from inputs; 594 . metadata produced at the outputs; 595 . packet type(s) accepted at the inputs and emitted at the 596 outputs; 597 . packet content modifications (including encapsulation or 598 decapsulation); 599 . packet routing criteria (when multiple outputs on an LFB are 600 present); 601 . packet timing modifications; 602 . packet flow ordering modifications; 603 . LFB capability information; 604 . Events that can be detected by the LFB, with notification to 605 the CE; 606 . LFB operational attributes, etc. 608 Section 4 of this document provides a detailed discussion of the LFB 609 model with a formal specification of LFB class schema. The rest of 610 Section 3.2 only intends to provide a conceptual overview of some 611 important issues in LFB modeling, without covering all the specific 612 details. 614 3.2.1. LFB Outputs 616 An LFB output is a conceptual port on an LFB that can send 617 information to another LFB. The information is typically a packet 618 and its associated metadata, although in some cases it might consist 619 of only metadata, i.e., with no packet data. 621 A single LFB output can be connected to only one LFB input. This is 622 required to make the packet flow through the LFB topology 623 unambiguously. 625 Some LFBs will have a single output, as depicted in Figure 3.a. 627 +---------------+ +-----------------+ 628 | | | | 629 | | | OUT +--> 630 ... OUT +--> ... | 631 | | | EXCEPTIONOUT +--> 632 | | | | 633 +---------------+ +-----------------+ 635 a. One output b. Two distinct outputs 637 +---------------+ +-----------------+ 638 | | | EXCEPTIONOUT +--> 639 | OUT:1 +--> | | 640 ... OUT:2 +--> ... OUT:1 +--> 641 | ... +... | OUT:2 +--> 642 | OUT:n +--> | ... +... 643 +---------------+ | OUT:n +--> 644 +-----------------+ 646 c. One output group d. One output and one output group 648 Figure 3. Examples of LFBs with various output combinations. 650 To accommodate a non-trivial LFB topology, multiple LFB outputs are 651 needed so that an LFB class can fork the datapath. Two mechanisms 652 are provided for forking: multiple singleton outputs and output 653 groups, which can be combined in the same LFB class. 655 Multiple separate singleton outputs are defined in an LFB class to 656 model a pre-determined number of semantically different outputs. 657 That is, the LFB class definition MUST include the number of 658 outputs, implying the number of outputs is known when the LFB class 659 is defined. Additional singleton outputs cannot be created at LFB 660 instantiation time, nor can they be created on the fly after the LFB 661 is instantiated. 663 For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one 664 output(OUT) to send those packets for which the LPM look-up was 665 successful, passing a META_ROUTEID as metadata; and have another 666 output (EXCEPTIONOUT) for sending exception packets when the LPM 667 look-up failed. This example is depicted in Figure 3.b. Packets 668 emitted by these two outputs not only require different downstream 669 treatment, but they are a result of two different conditions in the 670 LFB and each output carries different metadata. This concept 671 assumes the number of distinct outputs is known when the LFB class 672 is defined. For each singleton output, the LFB class definition 673 defines the types of frames and metadata the output emits. 675 An output group, on the other hand, is used to model the case where 676 a flow of similar packets with an identical set of metadata needs to 677 be split into multiple paths. In this case, the number of such paths 678 is not known when the LFB class is defined because it is not an 679 inherent property of the LFB class. An output group consists of a 680 number of outputs, called the output instances of the group, where 681 all output instances share the same frame and metadata emission 682 definitions (see Figure 3.c). Each output instance can connect to a 683 different downstream LFB, just as if they were separate singleton 684 outputs, but the number of output instances can differ between LFB 685 instances of the same LFB class. The class definition may include a 686 lower and/or an upper limit on the number of outputs. In addition, 687 for configurable FEs, the FE capability information may define 688 further limits on the number of instances in specific output groups 689 for certain LFBs. The actual number of output instances in a group 690 is an attribute of the LFB instance, which is read-only for static 691 topologies, and read-write for dynamic topologies. The output 692 instances in a group are numbered sequentially, from 0 to N-1, and 693 are addressable from within the LFB. The LFB has a built-in 694 mechanism to select one specific output instance for each packet. 695 This mechanism is described in the textual definition of the class 696 and is typically configurable via some attributes of the LFB. 698 For example, consider a re-director LFB, whose sole purpose is to 699 direct packets to one of N downstream paths based on one of the 700 metadata associated with each arriving packet. Such an LFB is 701 fairly versatile and can be used in many different places in a 702 topology. For example, a redirector can be used to divide the data 703 path into an IPv4 and an IPv6 path based on a FRAMETYPE metadata 704 (N=2), or to fork into color specific paths after metering using the 705 COLOR metadata (red, yellow, green; N=3), etc. 707 Using an output group in the above LFB class provides the desired 708 flexibility to adapt each instance of this class to the required 709 operation. The metadata to be used as a selector for the output 710 instance is a property of the LFB. For each packet, the value of 711 the specified metadata may be used as a direct index to the output 712 instance. Alternatively, the LFB may have a configurable selector 713 table that maps a metadata value to output instance. 715 Note that other LFBs may also use the output group concept to build 716 in similar adaptive forking capability. For example, a classifier 717 LFB with one input and N outputs can be defined easily by using the 718 output group concept. Alternatively, a classifier LFB with one 719 singleton output in combination with an explicit N-output re- 720 director LFB models the same processing behavior. The decision of 721 whether to use the output group model for a certain LFB class is 722 left to the LFB class designers. 724 The model allows the output group to be combined with other 725 singleton output(s) in the same class, as demonstrated in Figure 726 3.d. The LFB here has two types of outputs, OUT, for normal packet 727 output, and EXCEPTIONOUT for packets that triggered some exception. 728 The normal OUT has multiple instances, thus, it is an output group. 730 In summary, the LFB class may define one output, multiple singleton 731 outputs, one or more output groups, or a combination thereof. 732 Multiple singleton outputs should be used when the LFB must provide 733 for forking the datapath, and at least one of the following 734 conditions hold: 736 . the number of downstream directions are inherent from the 737 definition of the class and hence fixed; 738 . the frame type and set of metadata emitted on any of the 739 outputs are substantially different from what is emitted on 740 the other outputs (i.e., they cannot share frame-type and 741 metadata definitions); 743 An output group is appropriate when the LFB must provide for forking 744 the datapath, and at least one of the following conditions hold: 746 . the number of downstream directions is not known when the LFB 747 class is defined; 748 . the frame type and set of metadata emitted on these outputs are 749 sufficiently similar or ideally identical, such they can share 750 the same output definition. 752 3.2.2. LFB Inputs 754 An LFB input is a conceptual port on an LFB where the LFB can 755 receive information from other LFBs. The information is typically a 756 packet and associated metadata, although in some cases it might 757 consist of only metadata, without any packet data. 759 For LFB instances that receive packets from more than one other LFB 760 instance (fan-in). There are three ways to model fan-in, all 761 supported by the LFB model and can be combined in the same LFB: 763 . Implicit multiplexing via a single input 764 . Explicit multiplexing via multiple singleton inputs 765 . Explicit multiplexing via a group of inputs (input group) 767 The simplest form of multiplexing uses a singleton input (Figure 768 4.a). Most LFBs will have only one singleton input. Multiplexing 769 into a single input is possible because the model allows more than 770 one LFB output to connect to the same LFB input. This property 771 applies to any LFB input without any special provisions in the LFB 772 class. Multiplexing into a single input is applicable when the 773 packets from the upstream LFBs are similar in frame-type and 774 accompanying metadata, and require similar processing. Note that 775 this model does not address how potential contention is handled when 776 multiple packets arrive simultaneously. If contention handling 777 needs to be explicitly modeled, one of the other two modeling 778 solutions must be used. 780 The second method to model fan-in uses individually defined 781 singleton inputs (Figure 4.b). This model is meant for situations 782 where the LFB needs to handle distinct types of packet streams, 783 requiring input-specific handling inside the LFB, and where the 784 number of such distinct cases is known when the LFB class is 785 defined. For example, a Layer 2 Decapsulation/Encapsulation LFB may 786 have two inputs, one for receiving Layer 2 frames for decapsulation, 787 and one for receiving Layer 3 frames for encapsulation. This LFB 788 type expects different frames (L2 vs. L3) at its inputs, each with 789 different sets of metadata, and would thus apply different 790 processing on frames arriving at these inputs. This model is 791 capable of explicitly addressing packet contention by defining how 792 the LFB class handles the contending packets. 794 +--------------+ +------------------------+ 795 | LFB X +---+ | | 796 +--------------+ | | | 797 | | | 798 +--------------+ v | | 799 | LFB Y +---+-->|input Meter LFB | 800 +--------------+ ^ | | 801 | | | 802 +--------------+ | | | 803 | LFB Z |---+ | | 804 +--------------+ +------------------------+ 806 (a) An LFB connects with multiple upstream LFBs via a single input. 808 +--------------+ +------------------------+ 809 | LFB X +---+ | | 810 +--------------+ +-->|layer2 | 811 +--------------+ | | 812 | LFB Y +------>|layer3 LFB | 813 +--------------+ +------------------------+ 815 (b) An LFB connects with multiple upstream LFBs via two separate 816 singleton inputs. 818 +--------------+ +------------------------+ 819 | Queue LFB #1 +---+ | | 820 +--------------+ | | | 821 | | | 822 +--------------+ +-->|in:0 \ | 823 | Queue LFB #2 +------>|in:1 | input group | 824 +--------------+ |... | | 825 +-->|in:N-1 / | 826 ... | | | 827 +--------------+ | | | 828 | Queue LFB #N |---+ | Scheduler LFB | 829 +--------------+ +------------------------+ 831 (c) A Scheduler LFB uses an input group to differentiate which queue 832 LFB packets are coming from. 834 Figure 3. Input modeling concepts (examples). 836 The third method to model fan-in uses the concept of an input group. 837 The concept is similar to the output group introduced in the 838 previous section, and is depicted in Figure 4.c. An input group 839 consists of a number of input instances, all sharing the properties 840 (same frame and metadata expectations). The input instances are 841 numbered from 0 to N-1. From the outside, these inputs appear as 842 normal inputs, i.e., any compatible upstream LFB can connect its 843 output to one of these inputs. When a packet is presented to the 844 LFB at a particular input instance, the index of the input where the 845 packet arrived is known to the LFB and this information may be used 846 in the internal processing. For example, the input index can be 847 used as a table selector, or as an explicit precedence selector to 848 resolve contention. As with output groups, the number of input 849 instances in an input group is not defined in the LFB class. 850 However, the class definition may include restrictions on the range 851 of possible values. In addition, if an FE supports configurable 852 topologies, it may impose further limitations on the number of 853 instances for a particular port group(s) of a particular LFB class. 854 Within these limitations, different instances of the same class may 855 have a different number of input instances. The number of actual 856 input instances in the group is an attribute of the LFB class, which 857 is read-only for static topologies, and is read-write for 858 configurable topologies. 860 As an example for the input group, consider the Scheduler LFB 861 depicted in Figure 3.c. Such an LFB receives packets from a number 862 of Queue LFBs via a number of input instances, and uses the input 863 index information to control contention resolution and scheduling. 865 In summary, the LFB class may define one input, multiple singleton 866 inputs, one or more input groups, or a combination thereof. Any 867 input allows for implicit multiplexing of similar packet streams via 868 connecting multiple outputs to the same input. Explicit multiple 869 singleton inputs are useful when either the contention handling must 870 be handled explicitly, or when the LFB class must receive and 871 process a known number of distinct types of packet streams. An 872 input group is suitable when contention handling must be modeled 873 explicitly, but the number of inputs are not inherent from the class 874 (and hence is not known when the class is defined), or when it is 875 critical for LFB operation to know exactly on which input the packet 876 was received. 878 3.2.3. Packet Type 880 When LFB classes are defined, the input and output packet formats 881 (e.g., IPv4, IPv6, Ethernet, etc.) MUST be specified. These are the 882 types of packets a given LFB input is capable of receiving and 883 processing, or a given LFB output is capable of producing. This 884 requires distinct packet types be uniquely labeled with a symbolic 885 name and/or ID. 887 Note that each LFB has a set of packet types that it operates on, 888 but does not care whether the underlying implementation is passing a 889 greater portion of the packets. For example, an IPv4 LFB might only 890 operate on IPv4 packets, but the underlying implementation may or 891 may not be stripping the L2 header before handing it over -- whether 892 that is happening or not is opaque to the CE. 894 3.2.4. Metadata 896 Metadata is the per-packet state that is passed from one LFB to 897 another. The metadata is passed with the packet to assist subsequent 898 LFBs to process that packet. The ForCES model captures how the per- 899 packet state information is propagated from one LFB to other LFBs. 900 Practically, such metadata propagation can happen within one FE, or 901 cross the FE boundary between two interconnected FEs. We believe 902 that the same metadata model can be used for either situation; 903 however, our focus here is for intra-FE metadata. 905 3.2.4.1. Metadata Vocabulary 907 Metadata has historically been understood to mean "data about data". 908 While this definition is a start, it is inadequate to describe the 909 multiple forms of metadata, which may appear within a complex 910 network element. The discussion here categorizes forms of metadata 911 by two orthogonal axes. 913 The first axis is "internal" versus "external", which describes 914 where the metadata exists in the network model or implementation. 915 For example, a particular vendor implementation of an IPv4 forwarder 916 may make decisions inside of a chip that are not visible externally. 917 Those decisions are metadata for the packet that is "internal" to 918 the chip. When a packet is forwarded out of the chip, it may be 919 marked with a traffic management header. That header, which is 920 metadata for the packet, is visible outside of the chip, and is 921 therefore called "external" metadata. 923 The second axis is "implicit" versus "expressed", which specifies 924 whether or not the metadata has a visible physical representation. 925 For example, the traffic management header described in the previous 926 paragraph may be represented as a series of bits in some format, and 927 that header is associated with the packet. Those bits have physical 928 representation, and are therefore "expressed" metadata. If the 929 metadata does not have a physical representation, it is called 930 "implicit" metadata. This situation occurs, for example, when a 931 particular path through a network device is intended to be traversed 932 only by particular kinds of packets, such as an IPv4 router. An 933 implementation may not mark every packet along this path as being of 934 type "IPv4", but the intention of the designers is that every packet 935 is of that type. This understanding can be thought of as metadata 936 about the packet, which is implicitly attached to the packet through 937 the intent of the designers. 939 In the ForCES model, we do not discuss or represent metadata 940 "internal" to vendor implementations of LFBs. Our focus is solely 941 on metadata "external" to the LFBs, and therefore visible in the 942 ForCES model. The metadata discussed within this model may, or may 943 not be visible outside of the particular FE implementing the LFB 944 model. In this regard, the scope of the metadata within ForCES is 945 very narrowly defined. 947 Note also that while we define metadata within this model, it is 948 only a model. There is no requirement that vendor implementations 949 of ForCES use the exact metadata representations described in this 950 document. The only implementation requirement is that vendors 951 implement the ForCES protocol, not the model. 953 3.2.4.2. Metadata lifecycle within the ForCES model 955 Each metadata can be conveniently modeled as a pair, 956 where the label identifies the type of information, (e.g., "color"), 957 and its value holds the actual information (e.g., "red"). The tag 958 here is shown as a textual label, but it can be replaced or 959 associated with a unique numeric value (identifier). 961 The metadata life-cycle is defined in this model using three types 962 of events: "write", "read" and "consume". The first "write" 963 implicitly creates and initializes the value of the metadata, and 964 hence starts the life-cycle. The explicit "consume" event 965 terminates the life-cycle. Within the life-cycle, that is, after a 966 "write" event, but before the next "consume" event, there can be an 967 arbitrary number of "write" and "read" events. These "read" and 968 "write" events can be mixed in an arbitrary order within the life- 969 cycle. Outside of the life-cycle of the metadata, that is, before 970 the first "write" event, or between a "consume" event and the next 971 "write" event, the metadata should be regarded non-existent or non- 972 initialized. Thus, reading a metadata outside of its life-cycle is 973 considered an error. 975 To ensure inter-operability between LFBs, the LFB class 976 specification must define what metadata the LFB class "reads" or 977 "consumes" on its input(s) and what metadata it "produces" on its 978 output(s). For maximum extensibility, this definition should 979 neither specify which LFBs the metadata is expected to come from for 980 a consumer LFB, nor which LFBs are expected to consume metadata for 981 a given producer LFB. 983 While it is important to define the metadata types passing between 984 LFBs, it is not appropriate to define the exact encoding mechanism 985 used by LFBs for that metadata. Different implementations are 986 allowed to use different encoding mechanisms for metadata. For 987 example, one implementation may store metadata in registers or 988 shared memory, while another implementation may encode metadata in- 989 band as a preamble in the packets. In order to allow the CE to 990 understand and control the meta-data related operations, the model 991 represents each metadata tag as a 32-bit integer. Each LFB 992 definition indicates in its metadata declarations the 32-bit value 993 associated with a given metadata tag. Ensuring consistency of usage 994 of tags is important, and outside the scope of the model. 996 At any link between two LFBs, the packet is marked with a finite set 997 of active metadata, where active means the metadata is within its 998 life-cycle. There are two corollaries of this model: 1000 1. No un-initialized metadata exists in the model. 1002 2. No more than one occurrence of each metadata tag can be 1003 associated with a packet at any given time. 1005 3.2.4.3. LFB Operations on Metadata 1007 When the packet is processed by an LFB (i.e., between the time it is 1008 received and forwarded by the LFB), the LFB may perform read, write 1009 and/or consume operations on any active metadata associated with the 1010 packet. If the LFB is considered to be a black box, one of the 1011 following operations is performed on each active metadata. 1013 . IGNORE: ignores and forwards the metadata 1014 . READ: reads and forwards the metadata 1015 . READ/RE-WRITE: reads, over-writes and forwards the metadata 1016 . WRITE: writes and forwards the metadata 1017 (can also be used to create new metadata) 1018 . READ-AND-CONSUME: reads and consumes the metadata 1019 . CONSUME consumes metadata without reading 1021 The last two operations terminate the life-cycle of the metadata, 1022 meaning that the metadata is not forwarded with the packet when the 1023 packet is sent to the next LFB. 1025 In our model, a new metadata is generated by an LFB when the LFB 1026 applies a WRITE operation to a metadata type that was not present 1027 when the packet was received by the LFB. Such implicit creation may 1028 be unintentional by the LFB, that is, the LFB may apply the WRITE 1029 operation without knowing or caring if the given metadata existed or 1030 not. If it existed, the metadata gets over-written; if it did not 1031 exist, the metadata is created. 1033 For LFBs that insert packets into the model, WRITE is the only 1034 meaningful metadata operation. 1036 For LFBs that remove the packet from the model, they may either 1037 READ-AND-CONSUME (read) or CONSUME (ignore) each active metadata 1038 associated with the packet. 1040 3.2.4.4. Metadata Production and Consumption 1042 For a given metadata on a given packet path, there MUST be at least 1043 one producer LFB that creates that metadata and SHOULD be at least 1044 one consumer LFB that needs that metadata. In this model, the 1045 producer and consumer LFBs of a metadata are not required to be 1046 adjacent. In addition, there may be multiple producers and 1047 consumers for the same metadata. When a packet path involves 1048 multiple producers of the same metadata, then subsequent producers 1049 overwrite that metadata value. 1051 The metadata that is produced by an LFB is specified by the LFB 1052 class definition on a per output port group basis. A producer may 1053 always generate the metadata on the port group, or may generate it 1054 only under certain conditions. We call the former an 1055 "unconditional" metadata, whereas the latter is a "conditional" 1056 metadata. In the case of conditional metadata, it should be 1057 possible to determine from the definition of the LFB when a 1058 "conditional" metadata is produced. 1059 The consumer behavior of an LFB, that is, the metadata that the LFB 1060 needs for its operation, is defined in the LFB class definition on a 1061 per input port group basis. An input port group may "require" a 1062 given metadata, or may treat it as "optional" information. In the 1063 latter case, the LFB class definition MUST explicitly define what 1064 happens if an optional metadata is not provided. One approach is to 1065 specify a default value for each optional metadata, and assume that 1066 the default value is used if the metadata is not provided with the 1067 packet. 1069 When a consumer LFB requires a given metadata, it has dependencies 1070 on its up-stream LFBs. That is, the consumer LFB can only function 1071 if there is at least one producer of that metadata and no 1072 intermediate LFB consumes the metadata. 1074 The model should expose these inter-dependencies. Furthermore, it 1075 should be possible to take inter-dependencies into consideration 1076 when constructing LFB topologies, and also that the dependencies can 1077 be verified when validating topologies. 1079 For extensibility reasons, the LFB specification SHOULD define what 1080 metadata the LFB requires without specifying which LFB(s) it expects 1081 a certain metadata to come from. Similarly, LFBs SHOULD specify 1082 what metadata they produce without specifying which LFBs the 1083 metadata is meant for. 1085 When specifying the metadata tags, some harmonization effort must be 1086 made so that the producer LFB class uses the same tag as its 1087 intended consumer(s), or vice versa. 1089 3.2.4.5. Fixed, Variable and Configurable Tag 1091 When the produced metadata is defined for a given LFB class, most 1092 metadata will be specified with a fixed tag. For example, a Rate 1093 Meter LFB will always produce the "Color" metadata. 1095 A small subset of LFBs need the capability to produce one or more of 1096 their metadata with tags that are not fixed in the LFB class 1097 definition, but instead can be selected per LFB instance. An 1098 example of such an LFB class is a Generic Classifier LFB. We call 1099 this capability "variable tag metadata production". If an LFB 1100 produces metadata with a variable tag, the corresponding LFB 1101 attribute, called the tag selector, specifies the tag for each such 1102 metadata. This mechanism improves the versatility of certain multi- 1103 purpose LFB classes, since it allows the same LFB class to be used 1104 in different topologies, producing the right metadata tags according 1105 to the needs of the topology. This selection of tags is variable in 1106 that the produced output may have any number of different tags. The 1107 meaning of the various tags is still defined by the metadata 1108 declaration associated with the LFB class definition. This also 1109 allows the CE to correctly set the tag values in the table to match 1110 the declared meanings of the metadata tag values. 1112 Depending on the capability of the FE, the tag selector can be 1113 either a read-only or a read-write attribute. If the selector is 1114 read-only, the tag cannot be modified by the CE. If the selector is 1115 read-write, the tag can be configured by the CE, hence we call this 1116 "configurable tag metadata production." Note that using this 1117 definition, configurable tag metadata production is a subset of 1118 variable tag metadata production. 1120 Similar concepts can be introduced for the consumer LFBs to satisfy 1121 different metadata needs. Most LFB classes will specify their 1122 metadata needs using fixed metadata tags. For example, a Next Hop 1123 LFB may always require a "NextHopId" metadata; but the Redirector 1124 LFB may need a "ClassID" metadata in one instance, and a 1125 "ProtocolType" metadata in another instance as a basis for selecting 1126 the right output port. In this case, an LFB attribute is used to 1127 provide the required metadata tag at run-time. This metadata tag 1128 selector attribute may be read-only or read-write, depending on the 1129 capabilities of the LFB instance and the FE. 1131 3.2.4.6. Metadata Usage Categories 1133 Depending on the role and usage of a metadata, various amounts of 1134 encoding information MUST be provided when the metadata is defined, 1135 where some cases offer less flexibility in the value selection than 1136 others. 1138 There are three types of metadata related to metadata usage: 1140 . Relational (or binding) metadata 1141 . Enumerated metadata 1142 . Explicit/external value metadata 1144 The purpose of the relational metadata is to refer in one LFB 1145 instance (producer LFB) to a "thing" in another downstream LFB 1146 instance (consumer LFB), where the "thing" is typically an entry in 1147 a table attribute of the consumer LFB. 1149 For example, the Prefix Lookup LFB executes an LPM search using its 1150 prefix table and resolves to a next-hop reference. This reference 1151 needs to be passed as metadata by the Prefix Lookup LFB (producer) 1152 to the Next Hop LFB (consumer), and must refer to a specific entry 1153 in the next-hop table within the consumer. 1155 Expressing and propagating such a binding relationship is probably 1156 the most common usage of metadata. One or more objects in the 1157 producer LFB are bound to a specific object in the consumer LFB. 1158 Such a relationship is established by the CE explicitly by properly 1159 configuring the attributes in both LFBs. Available methods include 1160 the following: 1162 The binding may be expressed by tagging the involved objects in both 1163 LFBs with the same unique, but otherwise arbitrary, identifier. The 1164 value of the tag is explicitly configured by the CE by writing the 1165 value into both LFBs, and this value is also carried by the metadata 1166 between the LFBs. 1168 Another way of setting up binding relations is to use a naturally 1169 occurring unique identifier of the consumer's object as a reference 1170 and as a value of the metadata (e.g., the array index of a table 1171 entry). In this case, the index is either read or inferred by the 1172 CE by communicating with the consumer LFB. Once the CE obtains the 1173 index, it needs to write it into the producer LFB to establish the 1174 binding. 1176 Important characteristics of the binding usage of metadata are: 1178 . The value of the metadata shows up in the CE-FE communication 1179 for both the consumer and the producer. That is, the metadata 1180 value MUST be carried over the ForCES protocol. Using the 1181 tagging technique, the value is written to both LFBs. Using 1182 the other technique, the value is written to only the producer 1183 LFB and may be READ from the consumer LFB. 1185 . The metadata value is irrelevant to the CE, the binding is 1186 simply expressed by using the same value at the consumer and 1187 producer LFBs. 1189 . Hence the metadata definition is not required to include value 1190 assignments. The only exception is when some special value(s) 1191 of the metadata must be reserved to convey special events. 1192 Even though these special cases must be defined with the 1193 metadata specification, their encoded values can be selected 1194 arbitrarily. For example, for the Prefix Lookup LFB example, a 1195 special value may be reserved to signal the NO-MATCH case, and 1196 the value of zero may be assigned for this purpose. 1198 The second class of metadata is the enumerated type. An example is 1199 the "Color" metadata that is produced by a Meter LFB. As the name 1200 suggests, enumerated metadata has a relatively small number of 1201 possible values, each with a specific meaning. All possible cases 1202 must be enumerated when defining this class of metadata. Although a 1203 value encoding must be included in the specification, the actual 1204 values can be selected arbitrarily (e.g., 1205 and would be both valid encodings, what 1206 is important is that an encoding is specified). 1208 The value of the enumerated metadata may or may not be conveyed via 1209 the ForCES protocol between the CE and FE. 1211 The third class of metadata is the explicit type. This refers to 1212 cases where the metadata value is explicitly used by the consumer 1213 LFB to change some packet header fields. In other words, the value 1214 has a direct and explicit impact on some field and will be visible 1215 externally when the packet leaves the NE. Examples are: TTL 1216 increment given to a Header Modifier LFB, and DSCP value for a 1217 Remarker LFB. For explicit metadata, the value encoding MUST be 1218 explicitly provided in the metadata definition. The values cannot 1219 be selected arbitrarily and should conform to what is commonly 1220 expected. For example, a TTL increment metadata should be encoded 1221 as zero for the no increment case, one for the single increment 1222 case, etc. A DSCP metadata should use 0 to encode DSCP=0, 1 to 1223 encode DSCP=1, etc. 1225 3.2.5. LFB Events 1227 During operation, various conditions may occur that can be detected 1228 by LFBs. Examples range from link failure or restart to timer 1229 expiration in special purpose LFBs. The CE may wish to be notified 1230 of the occurrence of such events. The PL protocol provides for such 1231 notifications. The LFB definition includes the necessary 1232 declarations of events. The declarations include identifiers 1233 necessary for subscribing to events (so that the CE can indicate to 1234 the FE which events it wishes to receive) and to indicate in event 1235 notification messages which event is being reported. 1237 The declaration of an event defines a condition that an FE can 1238 detect, and may report. From a conceptual point of view, event 1239 processing is split into triggering (the detection of the condition) 1240 and reporting (the generation of the notification of the event.) In 1241 between these two conceptual points there is event filtering. 1242 Properties associated with the event in the LFB instance can define 1243 filtering conditions to suppress the reporting of that event. The 1244 model thus describes event processing as if events always occur, and 1245 filtering may suppress reporting. Implementations may function in 1246 this manner, or may have more complex logic that eliminates some 1247 event processing if the reporting would be suppressed. Any 1248 implementation producing an effect equivalent to the model 1249 description is valid. 1251 3.2.6. LFB Element Properties 1253 LFBs are made up of elements, containing the information that the CE 1254 needs to see and / or change about the functioning of the LFB. 1255 These elements, as described in detail elsewhere, may be basic 1256 values, complex structures, or tables (containing values, 1257 structures, or tables.) Some of these elements are optional. Some 1258 elements may be readable or writeable at the discretion of the FE 1259 implementation. The CE needs to know these properties. 1260 Additionally, certain kinds of elements (arrays, aliases, and events 1261 as of this writing) have additional property information that the CE 1262 may need to read or write. This model defines the structure of the 1263 property information for all defined data types. 1265 The reports with events are designed to allow for the common, 1266 closely related information that the CE can be strongly expected to 1267 need to react to the event. It is not intended to carry information 1268 the CE already has, nor large volumes of information, nor 1269 information related in complex fashions. 1271 3.2.7. LFB Versioning 1273 LFB class versioning is a method to enable incremental evolution of 1274 LFB classes. In general, an FE is not allowed to contain an LFB 1275 instance for more than one version of a particular class. 1276 Inheritance (discussed next in Section 3.2.6) has special rules. If 1277 an FE datapath model containing an LFB instance of a particular 1278 class C also simultaneously contains an LFB instance of a class C' 1279 inherited from class C; C could have a different version than C'. 1281 LFB class versioning is supported by requiring a version string in 1282 the class definition. CEs may support multiple versions of a 1283 particular LFB class to provide backward compatibility, but FEs MUST 1284 NOT support more than one version of a particular class. 1286 3.2.8. LFB Inheritance 1288 LFB class inheritance is supported in the FE model as a method to 1289 define new LFB classes. This also allows FE vendors to add vendor- 1290 specific extensions to standardized LFBs. An LFB class 1291 specification MUST specify the base class and version number it 1292 inherits from (the default is the base LFB class). Multiple- 1293 inheritance is not allowed, however, to avoid unnecessary 1294 complexity. 1296 Inheritance should be used only when there is significant reuse of 1297 the base LFB class definition. A separate LFB class should be 1298 defined if little or no reuse is possible between the derived and 1299 the base LFB class. 1301 An interesting issue related to class inheritance is backward 1302 compatibility between a descendant and an ancestor class. Consider 1303 the following hypothetical scenario where a standardized LFB class 1304 "L1" exists. Vendor A builds an FE that implements LFB "L1" and 1305 vendor B builds a CE that can recognize and operate on LFB "L1". 1306 Suppose that a new LFB class, "L2", is defined based on the existing 1307 "L1" class by extending its capabilities incrementally. Let us 1308 examine the FE backward compatibility issue by considering what 1309 would happen if vendor B upgrades its FE from "L1" to "L2" and 1310 vendor C's CE is not changed. The old L1-based CE can interoperate 1311 with the new L2-based FE if the derived LFB class "L2" is indeed 1312 backward compatible with the base class "L1". 1314 The reverse scenario is a much less problematic case, i.e., when CE 1315 vendor B upgrades to the new LFB class "L2", but the FE is not 1316 upgraded. Note that as long as the CE is capable of working with 1317 older LFB classes, this problem does not affect the model; hence we 1318 will use the term "backward compatibility" to refer to the first 1319 scenario concerning FE backward compatibility. 1321 Backward compatibility can be designed into the inheritance model by 1322 constraining LFB inheritance to require the derived class be a 1323 functional superset of the base class (i.e. the derived class can 1324 only add functions to the base class, but not remove functions). 1325 Additionally, the following mechanisms are required to support FE 1326 backward compatibility: 1328 1. When detecting an LFB instance of an LFB type that is unknown 1329 to the CE, the CE MUST be able to query the base class of such 1330 an LFB from the FE. 1331 2. The LFB instance on the FE SHOULD support a backward 1332 compatibility mode (meaning the LFB instance reverts itself 1333 back to the base class instance), and the CE SHOULD be able to 1334 configure the LFB to run in such a mode. 1336 3.3. FE Datapath Modeling 1338 Packets coming into the FE from ingress ports generally flow through 1339 multiple LFBs before leaving out of the egress ports. How an FE 1340 treats a packet depends on many factors, such as type of the packet 1341 (e.g., IPv4, IPv6 or MPLS), actual header values, time of arrival, 1342 etc. The result of LFB processing may have an impact on how the 1343 packet is to be treated in downstream LFBs. This differentiation of 1344 packet treatment downstream can be conceptualized as having 1345 alternative datapaths in the FE. For example, the result of a 6- 1346 tuple classification performed by a classifier LFB could control 1347 which rate meter is applied to the packet by a rate meter LFB in a 1348 later stage in the datapath. 1350 LFB topology is a directed graph representation of the logical 1351 datapaths within an FE, with the nodes representing the LFB 1352 instances and the directed link depicting the packet flow direction 1353 from one LFB to the next. Section 3.3.1 discusses how the FE 1354 datapaths can be modeled as LFB topology; while Section 3.3.2 1355 focuses on issues related to LFB topology reconfiguration. 1357 3.3.1. Alternative Approaches for Modeling FE Datapaths 1359 There are two basic ways to express the differentiation in packet 1360 treatment within an FE, one represents the datapath directly and 1361 graphically (topological approach) and the other utilizes metadata 1362 (the encoded state approach). 1364 . Topological Approach 1366 Using this approach, differential packet treatment is expressed by 1367 splitting the LFB topology into alternative paths. In other 1368 words, if the result of an LFB operation controls how the packet 1369 is further processed, then such an LFB will have separate output 1370 ports, one for each alternative treatment, connected to separate 1371 sub-graphs, each expressing the respective treatment downstream. 1373 . Encoded State Approach 1375 An alternate way of expressing differential treatment is by using 1376 metadata. The result of the operation of an LFB can be encoded in 1377 a metadata, which is passed along with the packet to downstream 1378 LFBs. A downstream LFB, in turn, can use the metadata and its 1379 value (e.g., as an index into some table) to determine how to 1380 treat the packet. 1382 Theoretically, either approach could substitute for the other, so 1383 one could consider using a single pure approach to describe all 1384 datapaths in an FE. However, neither model by itself results in the 1385 best representation for all practically relevant cases. For a given 1386 FE with certain logical datapaths, applying the two different 1387 modeling approaches will result in very different looking LFB 1388 topology graphs. A model using only the topological approach may 1389 require a very large graph with many links or paths, and nodes 1390 (i.e., LFB instances) to express all alternative datapaths. On the 1391 other hand, a model using only the encoded state model would be 1392 restricted to a string of LFBs, which is not an intuitive way to 1393 describe different datapaths (such as MPLS and IPv4). Therefore, a 1394 mix of these two approaches will likely be used for a practical 1395 model. In fact, as we illustrate below, the two approaches can be 1396 mixed even within the same LFB. 1398 Using a simple example of a classifier with N classification outputs 1399 followed by other LFBs, Figure 5(a) shows what the LFB topology 1400 looks like when using the pure topological approach. Each output 1401 from the classifier goes to one of the N LFBs where no metadata is 1402 needed. The topological approach is simple, straightforward and 1403 graphically intuitive. However, if N is large and the N nodes 1404 following the classifier (LFB#1, LFB#2, ..., LFB#N) all belong to 1405 the same LFB type (e.g., meter), but each has its own independent 1406 attributes, the encoded state approach gives a much simpler topology 1407 representation, as shown in Figure 5(b). The encoded state approach 1408 requires that a table of N rows of meter attributes is provided in 1409 the Meter node itself, with each row representing the attributes for 1410 one meter instance. A metadata M is also needed to pass along with 1411 the packet P from the classifier to the meter, so that the meter can 1412 use M as a look-up key (index) to find the corresponding row of the 1413 attributes that should be used for any particular packet P. 1415 What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same 1416 type? For example, if LFB#1 is a queue while the rest are all 1417 meters, what is the best way to represent such datapaths? While it 1418 is still possible to use either the pure topological approach or the 1419 pure encoded state approach, the natural combination of the two 1420 appears to be the best option. Figure 5(c) depicts two different 1421 functional datapaths using the topological approach while leaving 1422 the N-1 meter instances distinguished by metadata only, as shown in 1423 Figure 5(c). 1424 +----------+ 1425 P | LFB#1 | 1426 +--------->|(Attrib-1)| 1427 +-------------+ | +----------+ 1428 | 1|------+ P +----------+ 1429 | 2|---------------->| LFB#2 | 1430 | classifier 3| |(Attrib-2)| 1431 | ...|... +----------+ 1432 | N|------+ ... 1433 +-------------+ | P +----------+ 1434 +--------->| LFB#N | 1435 |(Attrib-N)| 1436 +----------+ 1438 5(a) Using pure topological approach 1440 +-------------+ +-------------+ 1441 | 1| | Meter | 1442 | 2| (P, M) | (Attrib-1) | 1443 | 3|---------------->| (Attrib-2) | 1444 | ...| | ... | 1445 | N| | (Attrib-N) | 1446 +-------------+ +-------------+ 1448 5(b) Using pure encoded state approach to represent the LFB 1449 topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the 1450 same type (e.g., meter). 1452 +-------------+ 1453 +-------------+ (P, M) | queue | 1454 | 1|------------->| (Attrib-1) | 1455 | 2| +-------------+ 1456 | 3| (P, M) +-------------+ 1457 | ...|------------->| Meter | 1458 | N| | (Attrib-2) | 1459 +-------------+ | ... | 1460 | (Attrib-N) | 1461 +-------------+ 1463 5(c) Using a combination of the two, if LFB#1, LFB#2, ..., and 1464 LFB#N are of different types (e.g., queue and meter). 1466 Figure 5. An example of how to model FE datapaths 1468 From this example, we demonstrate that each approach has a distinct 1469 advantage depending on the situation. Using the encoded state 1470 approach, fewer connections are typically needed between a fan-out 1471 node and its next LFB instances of the same type because each packet 1472 carries metadata the following nodes can interpret and hence invoke 1473 a different packet treatment. For those cases, a pure topological 1474 approach forces one to build elaborate graphs with many more 1475 connections and often results in an unwieldy graph. On the other 1476 hand, a topological approach is the most intuitive for representing 1477 functionally different datapaths. 1479 For complex topologies, a combination of the two is the most 1480 flexible. A general design guideline is provided to indicate which 1481 approach is best used for a particular situation. The topological 1482 approach should primarily be used when the packet datapath forks to 1483 distinct LFB classes (not just distinct parameterizations of the 1484 same LFB class), and when the fan-outs do not require changes, such 1485 as adding/removing LFB outputs, or require only very infrequent 1486 changes. Configuration information that needs to change frequently 1487 should be expressed by using the internal attributes of one or more 1488 LFBs (and hence using the encoded state approach). 1490 +---------------------------------------------+ 1491 | | 1492 +----------+ V +----------+ +------+ | 1493 | | | | |if IP-in-IP| | | 1494 ---->| ingress |->+----->|classifier|---------->|Decap.|---->---+ 1495 | ports | | |----+ | | 1496 +----------+ +----------+ |others+------+ 1497 | 1498 V 1499 (a) The LFB topology with a logical loop 1501 +-------+ +-----------+ +------+ +-----------+ 1502 | | | |if IP-in-IP | | | | 1503 --->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|-> 1504 | ports | | |----+ | | | | 1505 +-------+ +-----------+ |others +------+ +-----------+ 1506 | 1507 V 1508 The LFB topology without the loop utilizing two independent 1509 classifier instances. 1511 Figure 6. An LFB topology example. 1513 It is important to point out that the LFB topology described here is 1514 the logical topology, not the physical topology of how the FE 1515 hardware is actually laid out. Nevertheless, the actual 1516 implementation may still influence how the functionality is mapped 1517 to the LFB topology. Figure 6 shows one simple FE example. In this 1518 example, an IP-in-IP packet from an IPSec application like VPN may 1519 go to the classifier first and have the classification done based on 1520 the outer IP header; upon being classified as an IP-in-IP packet, 1521 the packet is then sent to a decapsulator to strip off the outer IP 1522 header, followed by a classifier again to perform classification on 1523 the inner IP header. If the same classifier hardware or software is 1524 used for both outer and inner IP header classification with the same 1525 set of filtering rules, a logical loop is naturally present in the 1526 LFB topology, as shown in Figure 6(a). However, if the 1527 classification is implemented by two different pieces of hardware or 1528 software with different filters (i.e., one set of filters for the 1529 outer IP header and another set for the inner IP header), then it is 1530 more natural to model them as two different instances of classifier 1531 LFB, as shown in Figure 6(b). 1533 To distinguish between multiple instances of the same LFB class, 1534 each LFB instance has its own LFB instance ID. One way to encode 1535 the LFB instance ID is to encode it as x.y where x is the LFB class 1536 ID and y is the instance ID within each LFB class. 1538 3.3.2. Configuring the LFB Topology 1540 While there is little doubt that an individual LFB must be 1541 configurable, the configurability question is more complicated for 1542 LFB topology. Since the LFB topology is really the graphic 1543 representation of the datapaths within an FE, configuring the LFB 1544 topology means dynamically changing the datapaths, including 1545 changing the LFBs along the datapaths on an FE (e.g., creating, 1546 instantiating or deleting LFBs) and setting up or deleting 1547 interconnections between outputs of upstream LFBs to inputs of 1548 downstream LFBs. 1550 Why would the datapaths on an FE ever change dynamically? The 1551 datapaths on an FE are set up by the CE to provide certain data 1552 plane services (e.g., DiffServ, VPN, etc.) to the Network Element's 1553 (NE) customers. The purpose of reconfiguring the datapaths is to 1554 enable the CE to customize the services the NE is delivering at run 1555 time. The CE needs to change the datapaths when the service 1556 requirements change, such as adding a new customer or when an 1557 existing customer changes their service. However, note that not all 1558 datapath changes result in changes in the LFB topology graph. 1559 Changes in the graph are dependent on the approach used to map the 1560 datapaths into LFB topology. As discussed in 3.3.1, the topological 1561 approach and encoded state approach can result in very different 1562 looking LFB topologies for the same datapaths. In general, an LFB 1563 topology based on a pure topological approach is likely to 1564 experience more frequent topology reconfiguration than one based on 1565 an encoded state approach. However, even an LFB topology based 1566 entirely on an encoded state approach may have to change the 1567 topology at times, for example, to bypass some LFBs or insert new 1568 LFBs. Since a mix of these two approaches is used to model the 1569 datapaths, LFB topology reconfiguration is considered an important 1570 aspect of the FE model. 1572 We want to point out that allowing a configurable LFB topology in 1573 the FE model does not mandate that all FEs are required to have this 1574 capability. Even if an FE supports configurable LFB topology, the 1575 FE may impose limitations on what can actually be configured. 1576 Performance-optimized hardware implementations may have zero or very 1577 limited configurability, while FE implementations running on network 1578 processors may provide more flexibility and configurability. It is 1579 entirely up to the FE designers to decide whether or not the FE 1580 actually implements reconfiguration and if so, how much. Whether a 1581 simple runtime switch is used to enable or disable (i.e., bypass) 1582 certain LFBs, or more flexible software reconfiguration is used, is 1583 implementation detail internal to the FE and outside of the scope of 1584 FE model. In either case, the CE(s) MUST be able to learn the FE's 1585 configuration capabilities. Therefore, the FE model MUST provide a 1586 mechanism for describing the LFB topology configuration capabilities 1587 of an FE. These capabilities may include (see Section 5 for full 1588 details): 1590 . Which LFB classes the FE can instantiate 1591 . Maximum number of instances of the same LFB class that can be 1592 created 1593 . Any topological limitations, For example: 1594 o The maximum number of instances of the same class or any 1595 class that can be created on any given branch of the graph 1596 o Ordering restrictions on LFBs (e.g., any instance of LFB 1597 class A must be always downstream of any instance of LFB 1598 class B). 1600 Note that even when the CE is allowed to configure LFB topology for 1601 the FE, the CE is not expected to be able to interpret an arbitrary 1602 LFB topology and determine which specific service or application 1603 (e.g. VPN, DiffServ, etc.) is supported by the FE. However, once 1604 the CE understands the coarse capability of an FE, the CE MUST 1605 configure the LFB topology to implement the network service the NE 1606 is supposed to provide. Thus, the mapping the CE has to understand 1607 is from the high level NE service to a specific LFB topology, not 1608 the other way around. The CE is not expected to have the ultimate 1609 intelligence to translate any high level service policy into the 1610 configuration data for the FEs. However, it is conceivable that 1611 within a given network service domain, a certain amount of 1612 intelligence can be programmed into the CE to give the CE a general 1613 understanding of the LFBs involved to allow the translation from a 1614 high level service policy to the low level FE configuration to be 1615 done automatically. Note that this is considered an implementation 1616 issue internal to the control plane and outside the scope of the FE 1617 model. Therefore, it is not discussed any further in this draft. 1619 +----------+ +-----------+ 1620 ---->| Ingress |---->|classifier |--------------+ 1621 | | |chip | | 1622 +----------+ +-----------+ | 1623 v 1624 +-------------------------------------------+ 1625 +--------+ | Network Processor | 1626 <----| Egress | | +------+ +------+ +-------+ | 1627 +--------+ | |Meter | |Marker| |Dropper| | 1628 ^ | +------+ +------+ +-------+ | 1629 | | | 1630 +----------+-------+ | 1631 | | | 1632 | +---------+ +---------+ +------+ +---------+ | 1633 | |Forwarder|<------|Scheduler|<--|Queue | |Counter | | 1634 | +---------+ +---------+ +------+ +---------+ | 1635 |--------------------------------------------------------------+ 1637 (a) The Capability of the FE, reported to the CE 1639 +-----+ +-------+ +---+ 1640 | A|--->|Queue1 |--------------------->| | 1641 ------>| | +-------+ | | +---+ 1642 | | | | | | 1643 | | +-------+ +-------+ | | | | 1644 | B|--->|Meter1 |----->|Queue2 |------>| |->| | 1645 | | | | +-------+ | | | | 1646 | | | |--+ | | | | 1647 +-----+ +-------+ | +-------+ | | +---+ 1648 classifier +-->|Dropper| | | IPv4 1649 +-------+ +---+ Fwd. 1650 Scheduler 1652 (b) One LFB topology as configured by the CE and 1653 accepted by the FE 1654 Queue1 1655 +---+ +--+ 1656 | A|------------------->| |--+ 1657 +->| | | | | 1658 | | B|--+ +--+ +--+ +--+ | 1659 | +---+ | | | | | | 1660 | Meter1 +->| |-->| | | 1661 | | | | | | 1662 | +--+ +--+ | Ipv4 1663 | Counter1 Dropper1 Queue2| +--+ Fwd. 1664 +---+ | +--+ +--->|A | +-+ 1665 | A|---+ | |------>|B | | | 1666 ------>| B|------------------------------>| | +--->|C |->| |-> 1667 | C|---+ +--+ | +->|D | | | 1668 | D|-+ | | | +--+ +-+ 1669 +---+ | | +---+ Queue3| | Scheduler 1670 Classifier1 | | | A|------------> +--+ | | 1671 | +->| | | |--+ | 1672 | | B|--+ +--+ +-------->| | | 1673 | +---+ | | | | +--+ | 1674 | Meter2 +->| |-+ | 1675 | | | | 1676 | +--+ Queue4 | 1677 | Marker1 +--+ | 1678 +---------------------------->| |----+ 1679 | | 1680 +--+ 1681 (c) Another LFB topology as configured by the CE and 1682 accepted by the FE 1684 Figure 7. An example of configuring LFB topology. 1686 Figure 7 shows an example where a QoS-enabled router has several 1687 line cards that have a few ingress ports and egress ports, a 1688 specialized classification chip, a network processor containing 1689 codes for FE blocks like meter, marker, dropper, counter, queue, 1690 scheduler and Ipv4 forwarder. Some of the LFB topology is already 1691 fixed and has to remain static due to the physical layout of the 1692 line cards. For example, all of the ingress ports might be hard- 1693 wired into the classification chip so all packets flow from the 1694 ingress port into the classification engine. On the other hand, the 1695 LFBs on the network processor and their execution order are 1696 programmable. However, certain capacity limits and linkage 1697 constraints could exist between these LFBs. Examples of the capacity 1698 limits might be: 8 meters; 16 queues in one FE; the scheduler can 1699 handle at most up to 16 queues; etc. The linkage constraints might 1700 dictate that the classification engine may be followed by a meter, 1701 marker, dropper, counter, queue or IPv4 forwarder, but not a 1702 scheduler; queues can only be followed by a scheduler; a scheduler 1703 must be followed by the IPv4 forwarder; the last LFB in the datapath 1704 before going into the egress ports must be the IPv4 forwarder, etc. 1706 Once the FE reports these capabilities and capacity limits to the 1707 CE, it is now up to the CE to translate the QoS policy into a 1708 desirable configuration for the FE. Figure 7(a) depicts the FE 1709 capability while 7(b) and 7(c) depict two different topologies that 1710 the CE may request the FE to configure. Note that both the ingress 1711 and egress are omitted in (b) and (c) to simplify the 1712 representation. The topology in 7(c) is considerably more complex 1713 than 7(b) but both are feasible within the FE capabilities, and so 1714 the FE should accept either configuration request from the CE. 1716 4. Model and Schema for LFB Classes 1718 The main goal of the FE model is to provide an abstract, generic, 1719 modular, implementation-independent representation of the FEs. This 1720 is facilitated using the concept of LFBs, which are instantiated 1721 from LFB classes. LFB classes and associated definitions will be 1722 provided in a collection of XML documents. The collection of these 1723 XML documents is called a LFB class library, and each document is 1724 called an LFB class library document (or library document, for 1725 short). Each of the library documents will conform to the schema 1726 presented in this section. The root element of the library document 1727 is the element. 1729 It is not expected that library documents will be exchanged between 1730 FEs and CEs "over-the-wire". But the model will serve as an 1731 important reference for the design and development of the CEs 1732 (software) and FEs (mostly the software part). It will also serve 1733 as a design input when specifying the ForCES protocol elements for 1734 CE-FE communication. 1736 4.1. Namespace 1738 The LFBLibrary element and all of its sub-elements are defined in 1739 the following namespace: 1741 http://ietf.org/forces/1.0/lfbmodel 1743 4.2. Element 1745 The element serves as a root element of all library 1746 documents. It contains one or more of the following main blocks: 1748 . for the frame declarations; 1749 . for defining common data types; 1750 . for defining metadata, and 1751 . for defining LFB classes. 1753 Each block is optional, that is, one library document may contain 1754 only metadata definitions, another may contain only LFB class 1755 definitions, yet another may contain all of the above. 1757 In addition to the above main blocks, a library document can import 1758 other library documents if it needs to refer to definitions 1759 contained in the included document. This concept is similar to the 1760 "#include" directive in C. Importing is expressed by the 1761 elements, which must precede all the above elements in the document. 1762 For unique referencing, each LFBLibrary instance document has a 1763 unique label defined in the "provide" attribute of the LFBLibrary 1764 element. 1766 The element also includes an optional 1767 element, which can be used to provide textual description about the 1768 library document. 1770 The following is a skeleton of a library document: 1772 1773 1776 1777 ... 1778 1780 1781 1782 ... 1784 1785 1786 ... 1787 1789 1790 1791 ... 1792 1794 1795 1796 ... 1798 1800 1801 1802 ... 1803 1804 1806 4.3. Element 1808 This element is used to refer to another LFB library document. 1809 Similar to the "#include" directive in C, this makes the objects 1810 (metadata types, data types, etc.) defined in the referred library 1811 document available for referencing in the current document. 1813 The load element MUST contain the label of the library document to 1814 be included and may contain a URL to specify where the library can 1815 be retrieved. The load element can be repeated unlimited times. 1816 Three examples for the elements: 1818 1819 1820 1823 4.4. Element for Frame Type Declarations 1825 Frame names are used in the LFB definition to define the types of 1826 frames the LFB expects at its input port(s) and emits at its output 1827 port(s). The optional element in the library document 1828 contains one or more elements, each declaring one frame 1829 type. 1831 Each frame definition MUST contain a unique name (NMTOKEN) and a 1832 brief synopsis. In addition, an optional detailed description may 1833 be provided. 1835 Uniqueness of frame types MUST be ensured among frame types defined 1836 in the same library document and in all directly or indirectly 1837 included library documents. 1839 The following example defines two frame types: 1841 1842 1843 ipv4 1844 IPv4 packet 1845 1846 This frame type refers to an IPv4 packet. 1847 1848 1849 1850 ipv6 1851 IPv6 packet 1852 1853 This frame type refers to an IPv6 packet. 1854 1855 1856 ... 1857 1859 4.5. Element for Data Type Definitions 1861 The (optional) element can be used to define commonly 1862 used data types. It contains one or more elements, 1863 each defining a data type with a unique name. Such data types can be 1864 used in several places in the library documents, including: 1866 . Defining other data types 1867 . Defining attributes of LFB classes 1869 This is similar to the concept of having a common header file for 1870 shared data types. 1872 Each element MUST contain a unique name (NMTOKEN), a 1873 brief synopsis, an optional longer description, and a type 1874 definition element. The name MUST be unique among all data types 1875 defined in the same library document and in any directly or 1876 indirectly included library documents. For example: 1878 1879 1880 ieeemacaddr 1881 48-bit IEEE MAC address 1882 ... type definition ... 1883 1884 1885 ipv4addr 1886 IPv4 address 1887 ... type definition ... 1888 1889 ... 1890 1891 There are two kinds of data types: atomic and compound. Atomic data 1892 types are appropriate for single-value variables (e.g. integer, 1893 ASCII string, byte array). 1895 The following built-in atomic data types are provided, but 1896 additional atomic data types can be defined with the and 1897 elements: 1899 Meaning 1900 ---- ------- 1901 char 8-bit signed integer 1902 uchar 8-bit unsigned integer 1903 int16 16-bit signed integer 1904 uint16 16-bit unsigned integer 1905 int32 32-bit signed integer 1906 uint32 32-bit unsigned integer 1907 int64 64-bit signed integer 1908 uint64 64-bit unisgned integer 1909 boolean A true / false value where 1910 0 = false, 1 = true 1911 string[N] ASCII null-terminated string with 1912 buffer of N characters (string max 1913 length is N-1) 1914 string ASCII null-terminated string without 1915 length limitation 1916 byte[N] A byte array of N bytes 1917 octetstring[N] A buffer of N octets, which may 1918 contain fewer than N octets. Hence 1919 the encoded value will always have 1920 a length. 1921 float16 16-bit floating point number 1922 float32 32-bit IEEE floating point number 1923 float64 64-bit IEEE floating point number 1925 These built-in data types can be readily used to define metadata or 1926 LFB attributes, but can also be used as building blocks when 1927 defining new data types. The boolean data type is defined here 1928 because it is so common, even though it can be built by sub-ranging 1929 the uchar data type. 1931 Compound data types can build on atomic data types and other 1932 compound data types. Compound data types can be defined in one of 1933 four ways. They may be defined as an array of elements of some 1934 compound or atomic data type. They may be a structure of named 1935 elements of compound or atomic data types (ala C structures). They 1936 may be a union of named elements of compound or atomic data types 1937 (ala C unions). They may also be defined as augmentations 1938 (explained below in 4.5.6) of existing compound data types. 1940 Given that the FORCES protocol will be getting and setting attribute 1941 values, all atomic data types used here must be able to be conveyed 1942 in the FORCES protocol. Further, the FORCES protocol will need a 1943 mechanism to convey compound data types. However, the details of 1944 such representations are for the protocol document to define, not 1945 the model document. 1947 For the definition of the actual type in the element, 1948 the following elements are available: , , , 1949 , and . 1951 The predefined type alias is somewhere between the atomic and 1952 compound data types. It behaves like a structure, one element of 1953 which has special behavior. Given that the special behavior is tied 1954 to the other parts of the structure, the compound result is treated 1955 as a predefined construct. 1957 4.5.1. Element for Aliasing Existing Data Types 1959 The element refers to an existing data type by its name. 1960 The referred data type MUST be defined either in the same library 1961 document, or in one of the included library documents. If the 1962 referred data type is an atomic data type, the newly defined type 1963 will also be regarded as atomic. If the referred data type is a 1964 compound type, the new type will also be compound. Some usage 1965 examples follow: 1967 1968 short 1969 Alias to int16 1970 int16 1971 1972 1973 ieeemacaddr 1974 48-bit IEEE MAC address 1975 byte[6] 1976 1978 4.5.2. Element for Deriving New Atomic Types 1980 The element allows the definition of a new atomic type from 1981 an existing atomic type, applying range restrictions and/or 1982 providing special enumerated values. Note that the element 1983 can only use atomic types as base types, and its result MUST be 1984 another atomic type. 1986 For example, the following snippet defines a new "dscp" data type: 1988 1989 dscp 1990 Diffserv code point. 1991 1992 uchar 1993 1994 1995 1996 1997 1998 DSCP-BE 1999 Best Effort 2000 2001 ... 2002 2003 2004 2006 4.5.3. Element to Define Arrays 2008 The element can be used to create a new compound data type 2009 as an array of a compound or an atomic data type. The type of the 2010 array entry can be specified either by referring to an existing type 2011 (using the element) or defining an unnamed type inside the 2012 element using any of the , , , or 2013 elements. 2015 The array can be "fixed-size" or "variable-size", which is specified 2016 by the "type" attribute of the element. The default is 2017 "variable-size". For variable size arrays, an optional "max-length" 2018 attribute specifies the maximum allowed length. This attribute 2019 should be used to encode semantic limitations, not implementation 2020 limitations. The latter should be handled by capability attributes 2021 of LFB classes, and should never be included in data type 2022 definitions. If the "max-length" attribute is not provided, the 2023 array is regarded as of unlimited-size. 2025 For fixed-size arrays, a "length" attribute MUST be provided that 2026 specifies the constant size of the array. 2028 The result of this construct MUST always be a compound type, even if 2029 the array has a fixed size of 1. 2031 Arrays MUST only be subscripted by integers, and will be presumed to 2032 start with index 0. 2034 In addition to their subscripts, arrays may be declared to have 2035 content keys. Such a declaration has several effects: 2037 . Any declared key can be used in the ForCES protocol to select 2038 an element for operations (for details, see the protocol). 2040 . In any instance of the array, each declared key must be unique 2041 within that instance. No two elements of an array may have the 2042 same values on all the fields which make up a key. 2044 Each key is declared with a keyID for use in the protocol, where the 2045 unique key is formed by combining one or more specified key fields. 2046 To support the case where an array of an atomic type with unique 2047 values can be referenced by those values, the key field identifier 2048 may be "*" (i.e., the array entry is the key). If the value type of 2049 the array is a structure or an array, then the key is one or more 2050 fields, each identified by name. Since the field may be an element 2051 of the structure, the element of an element of a structure, or 2052 further nested, the field name is actually a concatenated sequence 2053 of part identifiers, separated by decimal points ("."). The syntax 2054 for key field identification is given following the array examples. 2056 The following example shows the definition of a fixed size array 2057 with a pre-defined data type as the array elements: 2059 2060 dscp-mapping-table 2061 2062 A table of 64 DSCP values, used to re-map code space. 2063 2064 2065 dscp 2066 2067 2069 The following example defines a variable size array with an upper 2070 limit on its size: 2072 2073 mac-alias-table 2074 A table with up to 8 IEEE MAC addresses 2075 2076 ieeemacaddr 2077 2078 2080 The following example shows the definition of an array with a local 2081 (unnamed) type definition: 2083 2084 classification-table 2085 2086 A table of classification rules and result opcodes. 2087 2088 2089 2090 2091 rule 2092 The rule to match 2093 classrule 2094 2095 2096 opcode 2097 The result code 2098 opcode 2099 2100 2101 2102 2104 In the above example, each entry of the array is a of two 2105 fields ("rule" and "opcode"). 2107 The following example shows a table of IP Prefix information that 2108 can be accessed by a multi-field content key on the IP Address and 2109 prefix length. This means that in any instance of this table, no 2110 two entries can have the same IP address and prefix length. 2112 2113 ipPrefixInfo_table 2114 2115 A table of information about known prefixes 2116 2117 2118 2119 2120 address-prefix 2121 the prefix being described 2122 ipv4Prefix 2123 2124 2125 source 2126 2127 the protocol or process providing this information 2128 2129 uint16 2130 2131 2132 prefInfo 2133 the information we care about 2134 hypothetical-info-type 2135 2136 2137 2138 address-prefix.ipv4addr 2139 address-prefix.prefixlen 2140 source 2141 2142 2143 2145 Note that the keyField elements could also have been simply address- 2146 prefix and source, since all of the fields of address-prefix are 2147 being used. 2149 4.5.3.1 Key Field References 2151 In order to use key declarations, one must refer to fields that are 2152 potentially nested inside other fields in the array. If there are 2153 nested arrays, one might even use an array element as a key (but 2154 great care would be needed to ensure uniqueness.) 2156 The key is the combination of the values of each field declared in a 2157 keyField element. 2159 Therefore, the value of a keyField element MUST be a concatenated 2160 Sequence of field identifiers, separated by a "." (period) 2161 character. Whitespace is permitted and ignored. 2163 A valid string for a single field identifier within a keyField 2164 depends upon the current context. Initially, in an array key 2165 declaration, the context is the type of the array. Progressively, 2166 the context is whatever type is selected by the field identifiers 2167 processed so far in the current key field declaration. 2169 When the current context is an array, (e.g., when declaring a key 2170 for an array whose content is an array) then the only valid value 2171 for the field identifier is an explicit number. 2173 When the current context is a structure, the valid values for the 2174 field identifiers are the names of the elements of the structure. 2175 In the special case of declaring a key for an array containing an 2176 atomic type, where that content is unique and is to be used as a 2177 key, the value "*" can be used as the single key field identifier. 2179 4.5.4. Element to Define Structures 2181 A structure is comprised of a collection of data elements. Each 2182 data element has a data type (either an atomic type or an existing 2183 compound type) and is assigned a name unique within the scope of the 2184 compound data type being defined. These serve the same function as 2185 "struct" in C, etc. 2187 The actual type of the field can be defined by referring to an 2188 existing type (using the element), or can be a locally 2189 defined (unnamed) type created by any of the , , 2190 , or elements. 2192 A structure definition is a series of element declarations. Each 2193 element carries an elementID for use by the ForCES protocol. In 2194 addition, the element contains the name, a synopsis, an optional 2195 description, an optional declaration that the element itself is 2196 optional, and the typeRef declaration that specifies the element 2197 type. 2199 For a dataTypeDef of a struct, the structure definition may be 2200 inherited from, and augment, a previously defined structured type. 2201 This is indicated by including the derivedFrom attribute on the 2202 struct declaration. 2204 The result of this construct MUST be a compound type, even when the 2205 contains only one field. 2207 An example: 2209 2210 ipv4prefix 2211 2212 IPv4 prefix defined by an address and a prefix length 2213 2214 2215 2216 address 2217 Address part 2218 ipv4addr 2219 2220 2221 prefixlen 2222 Prefix length part 2223 2224 uchar 2225 2226 2227 2229 2230 2231 2232 2234 4.5.5. Element to Define Union Types 2236 Similar to the union declaration in C, this construct allows the 2237 definition of overlay types. Its format is identical to the 2238 element. 2240 The result of this construct MUST be a compound type, even when the 2241 union contains only one element. 2243 4.5.6 Element 2245 It is sometimes necessary to have an element in an LFB or structure 2246 refer to information in other LFBs. The declaration creates 2247 the constructs for this. The content of an element MUST be a 2248 named type. It can be a base type of a derived type. The actual 2249 value referenced by an alias is known as its target. When a GET or 2250 SET operation references the alias element, the value of the target 2251 is returned or replaced. Write access to an alias element is 2252 permitted if write access to both the alias and the target are 2253 permitted. 2255 The target of an element is determined by its properties. 2256 Like all elements, the properties MUST include the support / read / 2257 write permission for the alias. In addition, there are several 2258 fields in the properties which define the target of the alias. 2259 These fields are the ID of the LFB class of the target, the ID of 2260 the LFB instance of the target, and a sequence of integers 2261 representing the path within the target LFB instance to the target 2262 element. The type of the target element must match the declared 2263 type of the alias. Details of the alias property structure in in 2264 the section of this document on properties. 2266 Note that the read / write property of the alias refers to the 2267 value. The CE can only determine if it can write the target 2268 selection properties of the alias by attempting such a write 2269 operation. (Property elements do not themselves have properties.) 2271 4.5.6. Augmentations 2273 Compound types can also be defined as augmentations of existing 2274 compound types. If the existing compound type is a structure, 2275 augmentation may add new elements to the type. The type of an 2276 existing element can only be replaced with an augmentation derived 2277 from the current type, an existing element cannot be deleted. If 2278 the existing compound type is an array, augmentation means 2279 augmentation of the array element type. 2281 One consequence of this is that augmentations are compatible with 2282 the compound type from which they are derived. As such, 2283 augmentations are useful in defining attributes for LFB subclasses 2284 with backward compatibility. In addition to adding new attributes 2285 to a class, the data type of an existing attribute may be replaced 2286 by an augmentation of that attribute, and still meet the 2287 compatibility rules for subclasses. 2289 For example, consider a simple base LFB class A that has only one 2290 attribute (attr1) of type X. One way to derive class A1 from A can 2291 be by simply adding a second attribute (of any type). Another way 2292 to derive a class A2 from A can be by replacing the original 2293 attribute (attr1) in A of type X with one of type Y, where Y is an 2294 augmentation of X. Both classes A1 and A2 are backward compatible 2295 with class A. 2297 The syntax for augmentations is to include a derivedFrom element in 2298 a structure definition, indicating what structure type is being 2299 augmented. Element names and element IDs within the augmentation 2300 must not be the same as those in the structure type being augmented. 2302 4.6. Element for Metadata Definitions 2304 The (optional) element in the library document 2305 contains one or more elements. Each 2306 element defines a metadata. 2308 Each element MUST contain a unique name (NMTOKEN). 2309 Uniqueness is defined to be over all metadata defined in this 2310 library document and in all directly or indirectly included library 2311 documents. The element MUST also contain a brief 2312 synopsis, the mandatory tag value to be used for this metadata, an 2313 optional detailed description, and a mandatory type definition 2314 information. Only atomic data types can be used as value types for 2315 metadata. 2317 Two forms of type definitions are allowed. The first form uses the 2318 element to refer to an existing atomic data type defined 2319 in the element of the same library document or in one 2320 of the included library documents. The usage of the 2321 element is identical to how it is used in the 2322 elements, except here it can only refer to atomic types. 2323 The latter restriction is not yet enforced by the XML schema. 2325 The second form is an explicit type definition using the 2326 element. This element is used here in the same way as in the 2327 elements. 2329 The following example shows both usages: 2331 2332 2333 NEXTHOPID 2334 Refers to a Next Hop entry in NH LFB 2335 17 2336 int32 2337 2338 2339 CLASSID 2340 2341 Result of classification (0 means no match). 2342 2343 21 2344 2345 int32 2346 2347 2348 NOMATCH 2349 2350 Classification didn�t result in match. 2351 2352 2353 2354 2355 2356 2358 4.7. Element for LFB Class Definitions 2360 The (optional) element can be used to define one or 2361 more LFB classes using elements. Each 2362 element MUST define an LFB class and include the following elements: 2364 . provides the symbolic name of the LFB class. Example: 2365 "ipv4lpm" 2366 . provides a short synopsis of the LFB class. Example: 2367 "IPv4 Longest Prefix Match Lookup LFB" 2368 . is the version indicator 2369 . is the inheritance indicator 2370 . lists the input ports and their specifications 2371 . lists the output ports and their specifications 2372 . defines the operational attributes of the LFB 2373 . defines the capability attributes of the LFB 2374 . contains the operational specification of the LFB 2375 . The LFBClassID attribute of the LFBClassDef element defines the 2376 ID for this class. These must be globally unique. 2377 . defines the events that can be generated by instances 2378 of this LFB. 2380 [EDITOR: LFB class names should be unique not only among classes 2381 defined in this document and in all included documents, but also 2382 unique across a large collection of libraries. Obviously some global 2383 control is needed to ensure such uniqueness. This subject requires 2384 further study. The uniqueness of the class IDs also requires further 2385 study.] 2387 Here is a skeleton of an example LFB class definition: 2389 2390 2391 ipv4lpm 2392 IPv4 Longest Prefix Match Lookup LFB 2393 1.0 2394 baseclass 2396 2397 ... 2398 2400 2401 ... 2402 2404 2405 ... 2406 2408 2409 ... 2410 2412 2413 This LFB represents the IPv4 longest prefix match lookup 2414 operation. 2415 The modeled behavior is as follows: 2416 Blah-blah-blah. 2417 2419 2420 ... 2421 2422 The individual attributes and capabilities will have elementIDs for 2423 use by the ForCES protocol. These parallel the elementIDs used in 2424 structs, and are used the same way. Attribute and capability 2425 elementIDs must be unique within the LFB class definition. 2427 Note that the , , and elements are 2428 required, all other elements are optional in . However, 2429 when they are present, they must occur in the above order. 2431 4.7.1. Element to Express LFB Inheritance 2433 The optional element can be used to indicate that this 2434 class is a derivative of some other class. The content of this 2435 element MUST be the unique name () of another LFB class. The 2436 referred LFB class MUST be defined in the same library document or 2437 in one of the included library documents. 2439 [EDITOR: The element will likely need to specify the 2440 version of the ancestor, which is not included in the schema yet. 2441 The process and rules of class derivation are still being studied.] 2443 It is assumed that the derived class is backwards compatible with 2444 the base class. 2446 4.7.2. Element to Define LFB Inputs 2448 The optional element is used to define input ports. An 2449 LFB class may have zero, one, or more inputs. If the LFB class has 2450 no input ports, the element MUST be omitted. The 2451 element can contain one or more elements, 2452 one for each port or port-group. We assume that most LFBs will have 2453 exactly one input. Multiple inputs with the same input type are 2454 modeled as one input group. Input groups are defined the same way 2455 as input ports by the element, differentiated only by an 2456 optional "group" attribute. 2458 Multiple inputs with different input types should be avoided if 2459 possible (see discussion in Section 3.2.1). Some special LFBs will 2460 have no inputs at all. For example, a packet generator LFB does not 2461 need an input. 2463 Single input ports and input port groups are both defined by the 2464 element; they are differentiated by only an optional 2465 "group" attribute. 2467 The element MUST contain the following elements: 2469 . provides the symbolic name of the input. Example: "in". 2470 Note that this symbolic name must be unique only within the scope 2471 of the LFB class. 2472 . contains a brief description of the input. Example: 2473 "Normal packet input". 2474 . lists all allowed frame formats. Example: {"ipv4" 2475 and "ipv6"}. Note that this list should refer to names specified 2476 in the element of the same library document or in any 2477 included library documents. The element can also 2478 provide a list of required metadata. Example: {"classid", 2479 "vifid"}. This list should refer to names of metadata defined in 2480 the element in the same library document or in any 2481 included library documents. For each metadata, it must be 2482 specified whether the metadata is required or optional. For each 2483 optional metadata, a default value must be specified, which is 2484 used by the LFB if the metadata is not provided with a packet. 2486 In addition, the optional "group" attribute of the 2487 element can specify if the port can behave as a port group, i.e., it 2488 is allowed to be instantiated. This is indicated by a "yes" value 2489 (the default value is "no"). 2491 An example element, defining two input ports, the 2492 second one being an input port group: 2494 2495 2496 in 2497 Normal input 2498 2499 2500 ipv4 2501 ipv6 2502 2503 2504 classid 2505 vifid 2506 vrfid 2507 2508 2509 2510 2511 ... another input port ... 2512 2513 2515 For each , the frame type expectations are defined by the 2516 element using one or more elements (see 2517 example above). When multiple frame types are listed, it means that 2518 "one of these" frame types is expected. A packet of any other frame 2519 type is regarded as incompatible with this input port of the LFB 2520 class. The above example list two frames as expected frame types: 2521 "ipv4" and "ipv6". 2523 Metadata expectations are specified by the 2524 element. In its simplest form, this element can contain a list of 2525 elements, each referring to a metadata. When multiple 2526 instances of metadata are listed by elements, it means that 2527 "all of these" metadata must be received with each packet (except 2528 metadata that are marked as "optional" by the "dependency" attribute 2529 of the corresponding element). For a metadata that is 2530 specified "optional", a default value MUST be provided using the 2531 "defaultValue" attribute. The above example lists three metadata as 2532 expected metadata, two of which are mandatory ("classid" and 2533 "vifid"), and one being optional ("vrfid"). 2535 [EDITOR: How to express default values for byte[N] atomic types is 2536 yet to be defined.] 2538 The schema also allows for more complex definitions of metadata 2539 expectations. For example, using the element, a list of 2540 metadata can be specified to express that at least one of the 2541 specified metadata must be present with any packet. For example: 2543 2544 2545 prefixmask 2546 prefixlen 2547 2548 2550 The above example specifies that either the "prefixmask" or the 2551 "prefixlen" metadata must be provided with any packet. 2553 The two forms can also be combined, as it is shown in the following 2554 example: 2556 2557 classid 2558 vifid 2559 vrfid 2560 2561 prefixmask 2562 prefixlen 2563 2564 2565 Although the schema is constructed to allow even more complex 2566 definitions of metadata expectations, we do not discuss those here. 2568 4.7.3. Element to Define LFB Outputs 2570 The optional element is used to define output ports. 2571 An LFB class may have zero, one, or more outputs. If the LFB class 2572 has no output ports, the element MUST be omitted. The 2573 element can contain one or more elements, 2574 one for each port or port-group. If there are multiple outputs with 2575 the same output type, we model them as an output port group. Some 2576 special LFBs may have no outputs at all (e.g., Dropper). 2578 Single output ports and output port groups are both defined by the 2579 element; they are differentiated by only an optional 2580 "group" attribute. 2582 The element MUST contain the following elements: 2584 . provides the symbolic name of the output. Example: "out". 2585 Note that the symbolic name must be unique only within the scope 2586 of the LFB class. 2587 . contains a brief description of the output port. 2588 Example: "Normal packet output". 2589 . lists the allowed frame formats. Example: {"ipv4", 2590 "ipv6"}. Note that this list should refer to symbols specified in 2591 the element in the same library document or in any 2592 included library documents. The element may also 2593 contain the list of emitted (generated) metadata. Example: 2594 {"classid", "color"}. This list should refer to names of metadata 2595 specified in the element in the same library 2596 document or in any included library documents. For each generated 2597 metadata, it should be specified whether the metadata is always 2598 generated or generated only in certain conditions. This 2599 information is important when assessing compatibility between 2600 LFBs. 2602 In addition, the optional "group" attribute of the 2603 element can specify if the port can behave as a port group, i.e., it 2604 is allowed to be instantiated. This is indicated by a "yes" value 2605 (the default value is "no"). 2607 The following example specifies two output ports, the second being 2608 an output port group: 2610 2611 2612 out 2613 Normal output 2614 2615 2616 ipv4 2617 ipv4bis 2618 2619 2620 nhid 2621 nhtabid 2622 2623 2624 2625 2626 exc 2627 Exception output port group 2628 2629 2630 ipv4 2631 ipv4bis 2632 2633 2634 errorid 2635 2636 2637 2638 2640 The types of frames and metadata the port produces are defined 2641 inside the element in each . Within the 2642 element, the list of frame types the port produces is 2643 listed in the element. When more than one frame is 2644 listed, it means that "one of" these frames will be produced. 2646 The list of metadata that is produced with each packet is listed in 2647 the optional element of the . In its 2648 simplest form, this element can contain a list of elements, 2649 each referring to a metadata type. The meaning of such a list is 2650 that "all of" these metadata are provided with each packet, except 2651 those that are listed with the optional "availability" attribute set 2652 to "conditional". Similar to the element of the 2653 , the element supports more complex 2654 forms, which we do not discuss here further. 2656 4.7.4. Element to Define LFB Operational Attributes 2658 Operational parameters of the LFBs that must be visible to the CEs 2659 are conceptualized in the model as the LFB attributes. These 2660 include, for example, flags, single parameter arguments, complex 2661 arguments, and tables. Note that the attributes here refer to only 2662 those operational parameters of the LFBs that must be visible to the 2663 CEs. Other variables that are internal to LFB implementation are 2664 not regarded as LFB attributes and hence are not covered. 2666 Some examples for LFB attributes are: 2668 . Configurable flags and switches selecting between operational 2669 modes of the LFB 2670 . Number of inputs or outputs in a port group 2671 . Metadata CONSUME vs.PROPAGATE mode selector 2672 . Various configurable lookup tables, including interface tables, 2673 prefix tables, classification tables, DSCP mapping tables, MAC 2674 address tables, etc. 2675 . Packet and byte counters 2676 . Various event counters 2677 . Number of current inputs or outputs for each input or output 2678 group 2680 There may be various access permission restrictions on what the CE 2681 can do with an LFB attribute. The following categories may be 2682 supported: 2684 . No-access attributes. This is useful when multiple access 2685 modes may be defined for a given attribute to allow some 2686 flexibility for different implementations. 2687 . Read-only attributes. 2688 . Read-write attributes. 2689 . Write-only attributes. This could be any configurable data for 2690 which read capability is not provided to the CEs. (e.g., the 2691 security key information) 2692 . Read-reset attributes. The CE can read and reset this 2693 resource, but cannot set it to an arbitrary value. Example: 2694 Counters. 2695 . Firing-only attributes. A write attempt to this resource will 2696 trigger some specific actions in the LFB, but the actual value 2697 written is ignored. 2699 The LFB class may define more than one possible access mode for a 2700 given attribute (for example, "write-only" and "read-write"), in 2701 which case it is left to the actual implementation to pick one of 2702 the modes. In such cases, a corresponding capability attribute must 2703 inform the CE about the access mode the actual LFB instance supports 2704 (see next subsection on capability attributes). 2706 The attributes of the LFB class are listed in the 2707 element. Each attribute is defined by an element. An 2708 element MUST contain the following elements: 2710 . defines the name of the attribute. This name must be 2711 unique among the attributes of the LFB class. Example: 2712 "version". 2713 . should provide a brief description of the purpose of 2714 the attribute. 2715 . indicates that this attribute is optional. 2716 . The data type of the attribute can be defined either via a 2717 reference to a predefined data type or providing a local 2718 definition of the type. The former is provided by using the 2719 element, which must refer to the unique name of an 2720 existing data type defined in the element in the 2721 same library document or in any of the included library 2722 documents. When the data type is defined locally (unnamed 2723 type), one of the following elements can be used: , 2724 , , and . Their usage is identical to how 2725 they are used inside elements (see Section 4.5). 2726 . The optional element can specify a default value 2727 for the attribute, which is applied when the LFB is initialized 2728 or reset. [EDITOR: A convention to define default values for 2729 compound data types and byte[N] atomic types is yet to be 2730 defined.] 2732 The attribute element also MUST have an elementID attribute, which 2733 is a numeric value used by the ForCES protocol. 2735 In addition to the above elements, the element includes 2736 an optional "access" attribute, which can take any of the following 2737 values or even a list of these values: "read-only", "read-write", 2738 "write-only", "read-reset", and "trigger-only". The default access 2739 mode is "read-write". 2741 Whether optional elements are supported, and whether elements 2742 defined as read-write can actually be written can be determined for 2743 a given LFB instance by the CE by reading the property information 2744 of that element. 2746 The following example defines two attributes for an LFB: 2748 2749 2750 foo 2751 number of things 2752 uint32 2753 2754 2755 bar 2756 number of this other thing 2757 2758 uint32 2759 2760 2761 2762 2763 10 2764 2765 2767 The first attribute ("foo") is a read-only 32-bit unsigned integer, 2768 defined by referring to the built-in "uint32" atomic type. The 2769 second attribute ("bar") is also an integer, but uses the 2770 element to provide additional range restrictions. This attribute has 2771 two possible access modes, "read-write" or "write-only". A default 2772 value of 10 is provided. 2774 Note that not all attributes are likely to exist at all times in a 2775 particular implementation. While the capabilities will frequently 2776 indicate this non-existence, CEs may attempt to reference non- 2777 existent or non-permitted attributes anyway. The FORCES protocol 2778 mechanisms should include appropriate error indicators for this 2779 case. 2781 The mechanism defined above for non-supported attributes can also 2782 apply to attempts to reference non-existent array elements or to set 2783 read-only elements. 2785 4.7.5. Element to Define LFB Capability Attributes 2787 The LFB class specification provides some flexibility for the FE 2788 implementation regarding how the LFB class is implemented. For 2789 example, the instance may have some limitations that are not 2790 inherent from the class definition, but rather the result of some 2791 implementation limitations. For example, an array attribute may be 2792 defined in the class definition as "unlimited" size, but the 2793 physical implementation may impose a hard limit on the size of the 2794 array. 2796 Such capability related information is expressed by the capability 2797 attributes of the LFB class. The capability attributes are always 2798 read-only attributes, and they are listed in a separate 2799 element in the . The 2800 element contains one or more elements, each defining 2801 one capability attribute. The format of the element is 2802 almost the same as the element, it differs in two 2803 aspects: it lacks the access mode attribute (because it is always 2804 read-only), and it lacks the element (because default 2805 value is not applicable to read-only attributes). 2807 Some examples of capability attributes follow: 2809 . The version of the LFB class that this LFB instance complies 2810 with; 2811 . Supported optional features of the LFB class; 2812 . Maximum number of configurable outputs for an output group; 2813 . Metadata pass-through limitations of the LFB; 2814 . Maximum size of configurable attribute tables; 2815 . Additional range restriction on operational attributes; 2816 . Supported access modes of certain attributes (if the access 2817 mode of an operational attribute is specified as a list of two 2818 or mode modes). 2820 The following example lists two capability attributes: 2822 2823 2824 version 2825 2826 LFB class version this instance is compliant with. 2827 2828 version 2829 2830 2831 limitBar 2832 2833 Maximum value of the "bar" attribute. 2834 2835 uint16 2836 2837 2839 4.7.6. Element for LFB Notification Generation 2841 The element contains the information about the occurrences 2842 for which instances of this LFB class can generate notifications to 2843 the CE. 2845 The definition needs a baseID attributevalue, which is 2846 normally . The value of the baseID is the 2847 starting element for the path which identifies events. It must not 2848 be the same as the elementID of any top level attribute or 2849 capability of the LFB class. In derived LFBs (i.e. ones with a 2850 element) where the parent LFB class has an events 2851 declaration, the baseID must not be present. Instead, the value 2852 from the parent class is used. 2854 [editors note: There is an open issue with regard to how baseID is 2855 used for an LFBclass and another class derived from it. Currently, 2856 the derived class does not declare a baseID. It may make sense to 2857 instead to require the baseID attribute and require that it have the 2858 same value as the parent class events baseID. Both choices 2859 (omission or inclusion of baseID in derived classes) leave room for 2860 errors not covered by the XML Schema.] 2862 The element contains 0 or more elements, each of 2863 which declares a single event. The element has an eventID 2864 attribute giving the unique ID of the event. The element will 2865 include: 2867 . element indicating which LFB field is tested to 2868 generate the event; 2869 . condition element indicating what condition on the field will 2870 generate the event from a list of defined conditions; 2871 . element indicating what values are to be 2872 reported in the notification of the event. 2874 4.7.6.1 Element 2876 The element contains information identifying a field 2877 in the LFB. Specifically, the element contains one or more 2878 or elements. These elements represent 2879 the textual equivalent of a path select component of the LFB. The 2880 element contains the name of an element in the LFB or 2881 struct. The first element in a MUST be an 2882 element and MUST name a field in the LFB. The following element 2883 MUST identify a valid field within the containing context. If an 2884 identifies an array, and is not the last element in the 2885 target, then the next element MUST be an . 2886 elements MUST occur only after names 2887 that identifies an array. An may contain a numeric 2888 value to indicate that this event applies to a specific element of 2889 the array. More commonly, the event is being defined across all 2890 elements of the array. In that case, will contain 2891 a name. The name in an element is not a field 2892 name. It is a variable name for use in the elements of 2893 this LFB definition. This name MUST be distinct from any field name 2894 that can validly occur in the clause. Hence it SHOULD 2895 be distinct from any field name used in the LFB or in structures 2896 used within the LFB. 2898 The provides additional components for the path used 2899 to reference the event. The path will be the baseID for events, 2900 followed by the ID for the specific event, followed by a value for 2901 each element in the . This will 2902 identify a specific occurrence of the event. So, for example, it 2903 will appear in the event notification LFB. It is also used for the 2904 SET-PROPERTY operation to subscribe to a specific event. A SET- 2905 PROPERTY of the subscription property (but not of any other 2906 writeable properties) may be sent by the CE with any prefix of the 2907 path of the event. So, for an event defined on a table, a SET- 2908 PROPERTY with a path of the baseID and the eventID will subscribe 2909 the CE to all occurrences of that event on any element of the table. 2910 This is particularly useful for the and 2911 conditions. Events using those conditions will 2912 generally be defined with a field / subscript sequence that 2913 identifies an array and ends with an element. 2914 Thus, the event notification will indicate which array entry has 2915 been created or destroyed. A typical subscriber will subscribe for 2916 the array, as opposed to a specific element in an array, so it will 2917 use a shorter path. 2919 Thus, if there is an LFB with an event baseID of 7, and a specific 2920 event with an event ID of 8, then one can subscribe to the event by 2921 referencing the properties of the LFB element with path 7.8. If the 2922 event target has no subscripts (for example, it is a simple 2923 attribute of the LFB) then one can also reference the event 2924 threshold and filtering properties via the properties on element 2925 7.8. If the event target is defined as an element of an array, then 2926 the target definition will include an element. In 2927 that case, one can subscribe to the event for the entire array by 2928 referencing the properties of 7.8. One can also subscribe to a 2929 specific element, x, of the array by referencing the subscription 2930 property of 7.8.x and also access the threshold and filtering 2931 properties of 7.8.x. If the event is targeting an element of an 2932 array within an array, then there will be two (or conceivably more) 2933 elements in the target. If so, for the case of two 2934 elements, one would reference the properties of 7.8.x.y to get to 2935 the threshold and filtering properties of an individual event. 2937 [Editors note: As currently defined, threshold and filtering can 2938 only be applied to individual elements, not entire arrays. Should 2939 this be changed to allow application to an array? If so, we would 2940 add the complication of having it potentially set differently on the 2941 element and the array as a whole.] 2943 4.7.6.2 Element Conditions 2945 The condition element represents a condition that triggers a 2946 notification. The list of conditions is: 2948 . the target must be an array, ending with a 2949 subscript indication. The event is generated when an entry in 2950 the array is created. This occurs even if the entry is created 2951 by CE direction. 2952 . the target must be an array, ending with a 2953 subscript indication. The event is generated when an entry in 2954 the array is destroyed. This occurs even if the entry is 2955 destroyed by CE direction. 2956 . the event is generated whenever the target 2957 element changes in any way. For binary attributes such as 2958 up/down, this reflects a change in state. It can also be used 2959 with numeric attributes, in which case any change in value 2960 results in a detected trigger. 2961 . the event is generated whenever the target 2962 element becomes greater than the threshold. The threshold is 2963 an event property. 2964 . the event is generated whenever the target 2965 element becomes less than the threshold. The threshold is an 2966 event property. 2968 As described in the Event Properties section, event items have 2969 properties associated with them. These properties include the 2970 subscription information (indicating whether the CE wishes the FE to 2971 generate event reports for the event at all, thresholds for events 2972 related to level crossing, and filtering conditions that may reduce 2973 the set of event notifications generated by the FE. Details of the 2974 filtering conditions that can be applied are given in that section. 2975 The filtering conditions allow the FE to suppress floods of events 2976 that could result from oscillation around a condition value. For FEs 2977 that do not wish to support filtering, the filter properties can 2978 either be read only or not supported. 2980 4.7.6.3 Element 2982 The element of an describes the information 2983 to be delivered by the FE along with the notification of the 2984 occurrence of the event. The element contains one or more 2985 elements. Each element identifies a piece of 2986 data from the LFB to be reported. The notification carries that 2987 data as if the collection of elements had been defined 2988 in a structure. Each element thus MUST identify a 2989 field in the LFB. The syntax is exactly the same as used in the 2990 element, using and 2991 elements. may contain integers. If they contain 2992 names, they MUST be names from elements of the 2993 . The selection for the report will use the value for 2994 the subscript that identifies that specific element triggering the 2995 event. This can be used to reference the structure / field causing 2996 the event, or to reference related information in parallel tables. 2997 This event reporting structure is designed to allow the LFB designer 2998 to specify information that is likely not known a priori by the CE 2999 and is likely needed by the CE to process the event. While the 3000 structure allows for pointing at large blocks of information (full 3001 arrays or complex structures) this is not recommended. Also, the 3002 variable reference / subscripting in reporting only captures a small 3003 portion of the kinds of related information. Chaining through index 3004 fields stored in a table, for example, is not supported. In 3005 general, the mechanism is an optimization for cases 3006 that have been found to be common, saving the CE from having to 3007 query for information it needs to understand the event. It does not 3008 represent all possible information needs. 3010 If any elements referenced by the eventReport are optional, then the 3011 report MUST support optional elements. Any components which do not 3012 exist are not reported. 3014 4.7.7. Element for LFB Operational Specification 3016 The element of the provides unstructured 3017 text (in XML sense) to verbally describe what the LFB does. 3019 4.8.Properties 3021 Elements of LFBs have properties which are important to the CE. The 3022 most important property is the existence / readability / 3023 writeability of the element. Depending up the type of the element, 3024 other information may be of importance. 3026 The model provides the definition of the structure of property 3027 information. There is a base class of property information. For 3028 the array, alias, and event elements there are subclasses of 3029 property information providing additional fields. This information 3030 is accessed by the CE (and updated where applicable) via the PL 3031 protocol. While some property information is writeable, there is no 3032 mechanism currently provided for checking the properties of a 3033 property element. Writeability can only be checked by attempting to 3034 modify the value. 3036 4.8.1 Basic Properties 3038 The basic property definition, along with the scalar for 3039 accessibility is below. Note that this access permission 3040 information is generally read-only. 3042 3043 accessPermissionValues 3044 3045 The possible values of attribute access permission 3046 3047 3048 uchar 3049 3050 3051 None 3052 Access is prohibited 3053 3054 3055 Read-Only 3056 Access is read only 3057 3058 3059 Write-Only 3060 3061 The attribute may be written, but not read 3062 3063 3064 3065 Read-Write 3066 3067 The attribute may be read or written 3068 3069 3070 3071 3072 3074 3075 baseElementProperties 3076 basic properties, accessibility 3077 3078 3079 accessibility 3080 3081 does the element exist, and 3082 can it be read or written 3083 3084 accessPermissionValues 3085 3086 3087 3089 4.8.2 Array Properties 3091 The properties for an array add a number of important pieces of 3092 information. These properties are also read-only. 3094 3095 arrayElementProperties 3096 3097 baseElementProperties 3098 3099 entryCount 3100 the number of entries in the array 3101 uint32 3102 3103 3104 highestUsedSubscript 3105 the last used subscript in the array 3106 uint32 3107 3108 3109 firstUnusedSubscript 3110 3111 The subscript of the first unused array element 3112 3113 uint32 3114 3115 3116 3118 4.8.3 Event Properties 3120 The properties for an event add three (usually) writeable fields. 3121 One is the subscription field. 0 means no notification is 3122 generated. Any non-zero value (typically 1 is used) means that a 3123 notification is generated. The hysteresis field is used to suppress 3124 generation of notifications for oscillations around a condition 3125 value, and is described in the text for events. The threshold field 3126 is used for the and conditions. 3127 It indicates the value to compare the event target against. Using 3128 the properties allows the CE to set the level of interest. FEs 3129 which do not supporting setting the threshold for events will make 3130 this field read-only. 3132 3133 eventElementProperties 3134 3135 baseElementProperties 3136 3137 registration 3138 3139 has the CE registered to be notified of this event 3140 3141 uint32 3142 3143 3144 threshold 3145 comparison value for level crossing events 3146 3147 uint32 3149 3150 3151 eventHysteresis 3152 region to suppress event recurrence notices 3153 3154 3155 uint32 3156 3157 3158 eventCount 3159 number of occurrences to suppress 3160 3161 3162 uint32 3163 3164 3165 eventHysteresis 3166 time interval in ms between notifications 3167 3168 3169 uint32 3170 3171 3172 3174 4.8.3.1 Common Event Filtering 3176 The event properties have values for controlling several filter 3177 conditions. Support of these conditions is optional, but all 3178 conditions SHOULD be supported. Events which are reliably known not 3179 to be subject to rapid occurrence or other concerns may not support 3180 all filter conditions. 3182 Currently, three different filter condition variables are defined. 3183 These are eventCount, eventInterval, and eventHysteris. Setting the 3184 condition variables to 0 (their default value) means that the 3185 condition is not checked. 3187 Conceptually, when an event is triggered, all configured conditions 3188 are checked. If no filter conditions are triggered, or if any 3189 trigger conditions are met, the event notification is generated. If 3190 there are filter conditions, and no condition is met, then no event 3191 notification is generated. Event filter conditions have reset 3192 behavior when an event notification is generated. If any condition 3193 is passed, and the notification is generated, the the notification 3194 reset behavior is performed on all conditions, even those which had 3195 not passed. This provides a clean definition of the interaction of 3196 the various event conditions. 3198 An example of the interaction of conditions is an event with an 3199 eventCount property set to 5 and an eventInterval property set to 3200 500 milliseconds. Suppose that a burst of occurrences of this event 3201 is detected by the FE. The first occurrence will cause a 3202 notification to be sent to the CE. Then, if four more occurrences 3203 are detected rapidly (less than 0.5 seconds) they will not result in 3204 notifications. If two more occurrences are detected, then the 3205 second of those will result in a notification. Alternatively, if 3206 more than 500 miliseconds has passed since the notification and an 3207 occurrence is detected, that will result in a notification. In 3208 either case, the count and time interval suppression is reset no 3209 matter which condition actually caused the notification. 3211 4.8.3.2 Event Hysteresis Filtering 3213 Events with numeric conditions can have hysteresis filters applied 3214 to them. The hystersis level is defined by a property of the event. 3215 This allows the FE to notify the CE of the hysteresis applied, and 3216 if it chooses, the FE can allow the CE to modify the hysteresis. 3217 This applies to for a numeric field, and to 3218 and . The content of a 3219 element is a numeric value. When supporting hysteresis, 3220 the FE MUST track the value of the element and make sure that the 3221 condition has become untrue by at least the hysteresis from the 3222 event property. To be specific, if the hysteresis is V, then 3224 . For a condition, if the last notification was 3225 for value X, then the notification MUST NOT be 3226 generated until the value reaches X +/- V. 3227 . For a condition with threshold T, once the 3228 event has been generated at least once it MUST NOT be generated 3229 again until the field first becomes less than or equal to T � 3230 V, and then exceeds T. 3231 . For a condition with threshold T, once the 3232 event has been generate at least once it MUST NOT be generated 3233 again until the field first becomes greater than or equal to T 3234 + V, and then becomes less than T. 3236 4.8.3.3 Event Count Filtering 3238 Events may have a count filtering condition. This property, if set 3239 to a non-zero value, indicates the number of occurrences of the event 3240 that should be considered redundant and not result in a notification. 3241 Thus, if this property is set to 1, and no other conditions apply, 3242 then every other detected occurrence of the event will result in a 3243 notification. This particular meaning is chosen so that the value 1 3244 has a distinct meaning from the value 0. 3246 A conceptual implementation (not required) for this might be an 3247 internal suppression counter. Whenever an event is triggered, the 3248 counter is checked. If the counter is 0, a notification is 3249 generated. Whether a notification is generated or not, the counter 3250 is incremented. If the counter exceeds the configured value, it is 3251 reset to 0. In this conceptual implementation the reset behavior 3252 when a notification is generated can be thought of as setting the 3253 counter to 1. 3255 [Editor�s note: a better description of the conceptual algorithm is 3256 sought.] 3258 4.8.3.4 Event Time Filtering 3260 Events may have a time filtering condition. This property 3261 represents the minimum time interval (in the absence of some other 3262 filtering condition being passed) between generating notifications of 3263 detected events. This condition MUST only be passed if the time 3264 since the last notification of the event is longer than the 3265 configured interval in milliseconds. 3267 Conceptually, this can be thought of as a stored timestamp which is 3268 compared with the detection time, or as a timer that is running that 3269 resets a suppression flag. In either case, if a notification is 3270 generated due to passing any condition then the time interval 3271 detection MUST be restarted. 3273 4.8.4 Alias Properties 3275 The properties for an alias add three (usually) writeable fields. 3276 These combine to identify the target element the subject alias 3277 refers to. 3279 3280 aliasElementProperties 3281 3282 baseElementProperties 3283 3284 targetLFBClass 3285 the class ID of the alias target 3286 uint32 3287 3288 3289 targetLFBInstance 3290 the instand ID of the alias target 3291 uint32 3292 3293 3294 targetElementPath 3295 3296 the path to the element target 3297 each 4 octets is read as one path element, 3298 using the path construction in the PL protocol. 3299 3300 octetstring[128] 3301 3302 3303 3305 4.9. XML Schema for LFB Class Library Documents 3307 3308 3314 3315 3316 Schema for Defining LFB Classes and associated types (frames, 3317 data types for LFB attributes, and metadata). 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3329 3331 3333 3335 3337 3338 3339 3340 3341 3342 3343 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3419 3421 3422 3423 3424 3425 3426 3427 3429 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3453 3454 3455 3457 3458 3460 3461 3462 3463 3464 3465 3466 3467 3468 3470 3471 3472 3473 3474 3475 3476 3477 3478 3480 3481 3482 3483 3485 3486 3487 3488 3489 3490 3491 3493 3494 3496 3497 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3534 3536 3538 3540 3543 3545 3546 3547 3549 3550 3553 3554 3555 3556 3557 3558 3559 3560 3561 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3596 3597 3598 3599 3600 3601 3602 3603 3605 3606 3607 3608 3609 3610 3611 3612 3613 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3640 3641 3642 3643 3644 3645 3646 3647 3649 3650 3651 3652 3653 3654 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3667 3668 3669 3670 3671 3672 3673 3675 3677 3678 3679 3680 3681 3682 3683 3685 3686 3688 3689 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3736 3737 3739 3740 3741 3742 3743 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3786 3787 3788 3790 3791 3792 3793 3796 3797 3798 3799 3801 3803 3805 3807 3809 3810 3811 3812 3813 3814 3815 3817 3819 3821 3822 3823 3825 3826 3827 3828 3829 3830 3831 3832 3833 3835 5. FE Attributes and Capabilities 3837 A ForCES forwarding element handles traffic on behalf of a ForCES 3838 control element. While the standards will describe the protocol and 3839 mechanisms for this control, different implementations and different 3840 instances will have different capabilities. The CE MUST be able to 3841 determine what each instance it is responsible for is actually 3842 capable of doing. As stated previously, this is an approximation. 3843 The CE is expected to be prepared to cope with errors in requests 3844 and variations in detail not captured by the capabilities 3845 information about an FE. 3847 In addition to its capabilities, an FE will have attribute 3848 information that can be used in understanding and controlling the 3849 forwarding operations. Some of the attributes will be read only, 3850 while others will also be writeable. 3852 In order to make the FE attribute information easily accessible, the 3853 information will be stored in an LFB. This LFB will have a class, 3854 FEObject. The LFBClassID for this class is 1. Only one instance of 3855 this class will ever be present, and the instance ID of that 3856 instance in the protocol is 1. Thus, by referencing the elements of 3857 class:1, instance:1 a CE can get all the information about the FE. 3858 For model completeness, this LFB Class is described in this section. 3860 There will also be an FEProtocol LFB Class. LFBClassID 2 is 3861 reserved for that class. There will be only one instance of that 3862 class as well. Details of that class are defined in the ForCES 3863 protocol document. 3865 5.1. XML for FEObject Class definition 3867 3868 3872 3873 3874 3875 LFBAdjacencyLimitType 3876 Describing the Adjacent LFB 3877 3878 3879 NeighborLFB 3880 ID for that LFB Class 3881 uint32 3882 3883 3884 ViaPorts 3885 3886 the ports on which we can connect 3887 3888 3889 string 3890 3891 3892 3893 3894 3895 PortGroupLimitType 3896 3897 Limits on the number of ports in a given group 3898 3899 3900 3901 PortGroupName 3902 Group Name 3903 string 3904 3905 3906 MinPortCount 3907 Minimum Port Count 3908 3909 uint32 3910 3911 3912 MaxPortCount 3913 Max Port Count 3914 3915 uint32 3916 3917 3918 3919 3920 SupportedLFBType 3921 table entry for supported LFB 3922 3923 3924 LFBName 3925 3926 The name of a supported LFB Class 3927 3928 string 3929 3930 3931 LFBClassID 3932 the id of a supported LFB Class 3933 uint32 3934 3935 3936 LFBOccurrenceLimit 3937 3938 the upper limit of instances of LFBs of this class 3939 3940 3941 uint32 3942 3943 3945 3946 PortGroupLimits 3947 Table of Port Group Limits 3948 3949 3950 PortGroupLimitType 3951 3952 3953 3954 3955 CanOccurAfters 3956 3957 List of LFB Classes that this LFB class can follow 3958 3959 3960 3961 LFBAdjacencyLimitType 3962 3963 3964 3966 3967 CanOccurBefores 3968 3969 List of LFB Classes that can follow this LFB class 3970 3971 3972 3973 LFBAdjacencyLimitType 3974 3975 3976 3977 3978 3979 FEStatusValues 3980 The possible values of status 3981 3982 uchar 3983 3984 3985 AdminDisable 3986 3987 FE is administratively disabled 3988 3989 3990 3991 OperDisable 3992 FE is operatively disabled 3993 3994 3995 OperEnable 3996 FE is operating 3997 3998 3999 4000 4001 4002 FEConfiguredNeighborType 4003 Details of the FE's Neighbor 4004 4005 4006 NeighborID 4007 Neighbors FEID 4008 uint32 4009 4010 4011 InterfaceToNeighbor 4012 4013 FE's interface that connects to this neighbor 4014 4015 4016 string 4017 4018 4019 NeighborNetworkAddress 4020 4021 The network layer address of the neighbor. 4022 Presumably, the network type can be 4023 determined from the interface information. 4024 4025 octetsting[16] 4026 4027 4028 NeighborMACAddress 4029 4030 The media access control address of the neighbor. 4032 Again, it is presumed the type can be determined 4033 from the interface information. 4034 4035 octetstring[8] 4036 4037 4038 4039 4040 LFBSelectorType 4041 4042 Unique identification of an LFB class-instance 4043 4044 4045 4046 LFBClassID 4047 LFB Class Identifier 4048 uint32 4049 4050 4051 LFBInstanceID 4052 LFB Instance ID 4053 uint32 4054 4055 4056 4057 4058 LFBLinkType 4059 4060 Link between two LFB instances of topology 4061 4062 4063 4064 FromLFBID 4065 LFB src 4066 LFBSelectorType 4067 4068 4069 FromPortGroup 4070 src port group 4071 string 4072 4073 4074 FromPortIndex 4075 src port index 4076 uint32 4077 4078 4079 ToLFBID 4080 dst LFBID 4081 LFBSelectorType 4082 4083 4084 ToPortGroup 4085 dst port group 4086 string 4087 4088 4089 ToPortIndex 4090 dst port index 4091 uint32 4092 4093 4094 4095 4096 4097 4098 FEObject 4099 Core LFB: FE Object 4100 1.0 4101 4102 4103 LFBTopology 4104 the table of known Topologies 4105 4106 LFBLinkType 4107 4108 4109 4110 LFBSelectors 4111 4112 table of known active LFB classes and 4113 instances 4114 4115 4116 LFBSelectorType 4117 4118 4119 4120 FEName 4121 name of this FE 4122 string[40] 4123 4124 4125 FEID 4126 ID of this FE 4127 uint32 4128 4129 4130 FEVendor 4131 vendor of this FE 4132 string[40] 4133 4134 4135 FEModel 4136 model of this FE 4137 string[40] 4138 4139 4140 FEState 4141 model of this FE 4142 FEStatusValues 4143 4144 4145 FENeighbors 4146 table of known neighbors 4147 4148 FEConfiguredNeighborType 4149 4150 4151 4152 4153 4154 ModifiableLFBTopology 4155 4156 Whether Modifiable LFB is supported 4157 4158 4159 boolean 4160 4161 4162 SupportedLFBs 4163 List of all supported LFBs 4164 4165 4166 SupportedLFBType 4167 4168 4169 4170 4171 4172 4174 5.2. FE Capabilities 4176 The FE Capability information is contained in the capabilities 4177 element of the class definition. As described elsewhere, capability 4178 information is always considered to be read-only. 4180 The currently defined capabilities are ModifiableLFBTopology and 4181 SupportedLFBs. Information as to which attributes of the FE LFB are 4182 supported is accessed by the properties information for those 4183 elements. 4185 5.2.1. ModifiableLFBTopology 4187 This element has a boolean value that indicates whether the LFB 4188 topology of the FE may be changed by the CE. If the element is 4189 absent, the default value is assumed to be true, and the CE presumes 4190 the LFB topology may be changed. If the value is present and set to 4191 false, the LFB topology of the FE is fixed. If the topology is 4192 fixed, the LFBs supported clause may be omitted, and the list of 4193 supported LFBs is inferred by the CE from the LFB topology 4194 information. If the list of supported LFBs is provided when 4195 ModifiableLFBTopology is false, the CanOccurBefore and CanOccurAfter 4196 information should be omitted. 4198 5.2.2. SupportedLFBs and SupportedLFBType 4200 One capability that the FE should include is the list of supported 4201 LFB classes. The SupportedLFBs element, is an array that contains 4202 the information about each supported LFB Class. The array structure 4203 type is defined as the SupportedLFBType dataTypeDef. 4205 Each occurrence of the SupportedLFBs array element describes an LFB 4206 class that the FE supports. In addition to indicating that the FE 4207 supports the class, FEs with modifiable LFB topology should include 4208 information about how LFBs of the specified class may be connected 4209 to other LFBs. This information should describe which LFB classes 4210 the specified LFB class may succeed or precede in the LFB topology. 4211 The FE should include information as to which port groups may be 4212 connected to the given adjacent LFB class. If port group 4213 information is omitted, it is assumed that all port groups may be 4214 used. 4216 5.2.2.1. LFBName 4218 This element has as its value the name of the LFB being described. 4220 5.2.2.2. LFBOccurrenceLimit 4222 This element, if present, indicates the largest number of instances 4223 of this LFB class the FE can support. For FEs that do not have the 4224 capability to create or destroy LFB instances, this can either be 4225 omitted or be the same as the number of LFB instances of this class 4226 contained in the LFB list attribute. 4228 5.2.2.3. PortGroupLimits and PortGroupLimitType 4230 The PortGroupLimits element is an array of information about the 4231 port groups supported by the LFB class. The structure of the port 4232 group limit information is defined by the PortGroupLimitType 4233 dataTypeDef. 4235 Each PortGroupLimits array element contains information describing a 4236 single port group of the LFB class. Each array element contains the 4237 name of the port group in the PortGroupName element, the fewest 4238 number of ports that can exist in the group in the MinPortCount 4239 element, and the largest number of ports that can exist in the group 4240 in the MaxPortCount element. 4242 5.2.2.4.CanOccurAfters and LFBAdjacencyLimitType 4244 The CanOccurAfters element is an array that contains the list of 4245 LFBs the described class can occur after. The array elements are 4246 defined in the LFBAdjacencyLimitType dataTypeDef. 4248 The array elements describe a permissible positioning of the 4249 described LFB class, referred to here as the SupportedLFB. 4250 Specifically, each array element names an LFB that can topologically 4251 precede that LFB class. That is, the SupportedLFB can have an input 4252 port connected to an output port of an LFB that appears in the 4253 CanOccurAfters array. The LFB class that the SupportedLFB can 4254 follow is identified by the NeighborLFB element of the 4255 LFBAdjacencyLimitType array element. If this neighbor can only be 4256 connected to a specific set of input port groups, then the viaPort 4257 element is included. This element occurs once for each input port 4258 group of the SupportedLFB that can be connected to an output port of 4259 the NeighborLFB. 4261 [e.g., Within a SupportedLFBs element, each array element of the 4262 CanOccurAfters array must have a unique NeighborLFB, and within each 4263 array element each viaPort must represent a distinct and valid input 4264 port group of the SupportedLFB. The LFB Class definition schema 4265 does not yet support uniqueness declarations] 4267 5.2.2.5. CanOccurBefores and LFBAdjacencyLimitType 4269 The CanOccurBefores array holds the information about which LFB 4270 classes can follow the described class. Structurally this element 4271 parallels CanOccurAfters, and uses the same type definition for the 4272 array element. 4274 The array elements list those LFB classes that the SupportedLFB may 4275 precede in the topology. In this element, the 4276 viaPort element of the array value represents the output port group 4277 of the SupportedLFB that may be connected to the NeighborLFB. As 4278 with CanOccurAfters, viaPort may occur multiple times if multiple 4279 output ports may legitimately connect to the given NeighborLFB 4280 class. 4282 [And a similar set of uniqueness constraints apply to the 4283 CanOccurBefore clauses, even though an LFB may occur both in 4284 CanOccurAfter and CanOccurBefore.] 4286 5.2.2.6. LFBClassCapabilities 4288 This element contains capability information about the subject LFB 4289 class whose structure and semantics are defined by the LFB class 4290 definition. 4292 [Note: Important Omissions] 4294 However, this element does not appear in the definition, because the 4295 author can not figure out how to write it. 4297 5.3. FEAttributes 4299 The attributes element is included if the class definition contains 4300 the attributes of the FE that are not considered "capabilities". 4301 Some of these attributes are writeable, and some are read-only, 4302 which should be indicated by the capability information. 4304 [Editors note - At the moment, the set of attributes is woefully 4305 incomplete.] 4307 5.3.1. FEStatus 4309 This attribute carries the overall state of the FE. For now, it is 4310 restricted to the strings AdminDisable, OperDisable and OperEnable. 4312 5.3.2. LFBSelectors and LFBSelectorType 4314 The LFBSelectors element is an array of information about the LFBs 4315 currently accessible via ForCES in the FE. The structure of the LFB 4316 information is defined by the LFBSelectorType. 4318 Each entry in the array describes a single LFB instance in the FE. 4319 The array element contains the numeric class ID of the class of the 4320 LFB instance and the numeric instance ID for this instance. 4322 5.3.3. LFBTopology and LFBLinkType 4324 The optional LFBTopology element contains information about each 4325 inter-LFB link inside the FE, where each link is described in an 4326 LFBLinkType element. The LFBLinkType element contains sufficient 4327 information to identify precisely the end points of a link. The 4328 FromLFBID and ToLFBID fields specify the LFB instances at each end 4329 of the link, and must reference LFBs in the LFB instance table. The 4330 FromPortGroup and ToPortGroup must identify output and input port 4331 groups defined in the LFB classes of the LFB instances identified by 4332 FromLFBID and ToLFBID. The FromPortIndex and ToPortIndex fields 4333 select the elements from the port groups that this link connects. 4334 All links are uniquely identified by the FromLFBID, FromPortGroup, 4335 and FromPortIndex fields. Multiple links may have the same ToLFBID, 4336 ToPortGroup, and ToPortIndex as this model supports fan in of inter- 4337 LFB links but not fan out. 4339 5.3.4. FENeighbors an FEConfiguredNeighborType 4341 The FENeighbors element is an array of information about manually 4342 configured adjacencies between this FE and other FEs. The content 4343 of the array is defined by the FEConfiguredNeighborType element. 4345 This array is intended to capture information that may be configured 4346 on the FE and is needed by the CE, where one array entry corresponds 4347 to each configured neighbor. Note that this array is not intended 4348 to represent the results of any discovery protocols, as those will 4349 have their own LFBs. 4351 Similarly, the MAC address information in the table is intended to 4352 be used in situations where neighbors are configured by MAC address. 4353 Resolution of network layer to MAC address information should be 4354 captured in ARP LFBs and not duplicated in this table. Note that 4355 the same neighbor may be reached through multiple interfaces or at 4356 multiple addresses. There is no uniqueness requirement of any sort 4357 on occurrences of the FENeighbors element. 4359 Information about the intended forms of exchange with a given 4360 neighbor is not captured here, only the adjacency information is 4361 included. 4363 5.3.4.1.NeighborID 4365 This is the ID in some space meaningful to the CE for the neighbor. 4366 If this table remains, we probably should add an FEID from the same 4367 space as an attribute of the FE. 4369 5.3.4.2.NeighborInterface 4371 This identifies the interface through which the neighbor is reached. 4373 [Editors note: As the port structures become better defined, the 4374 type for this should be filled in with the types necessary to 4375 reference the various possible neighbor interfaces, include physical 4376 interfaces, logical tunnels, virtual circuits, etc.] 4378 5.3.4.3. NeighborNetworkAddress 4380 Neighbor configuration is frequently done on the basis of a network 4381 layer address. For neighbors configured in that fashion, this is 4382 where that address is stored. 4384 5.3.4.4.NeighborMacAddress 4386 Neighbors are sometimes configured using MAC level addresses 4387 (Ethernet MAC address, circuit identifiers, etc.) If such addresses 4388 are used to configure the adjacency, then that information is stored 4389 here. Note that over some ports such as physical point to point 4390 links or virtual circuits considered as individual interfaces, there 4391 is no need for either form of address. 4393 6. Satisfying the Requirements on FE Model 4395 This section describes how the proposed FE model meets the 4396 requirements outlined in Section 5 of RFC 3654 [1]. The 4397 requirements can be separated into general requirements (Sections 5, 4398 5.1 - 5.4) and the specification of the minimal set of logical 4399 functions that the FE model must support (Section 5.5). 4401 The general requirement on the FE model is that it be able to 4402 express the logical packet processing capability of the FE, through 4403 both a capability and a state model. In addition, the FE model is 4404 expected to allow flexible implementations and be extensible to 4405 allow defining new logical functions. 4407 A major component of the proposed FE model is the Logical Function 4408 Block (LFB) model. Each distinct logical function in an FE is 4409 modeled as an LFB. Operational parameters of the LFB that must be 4410 visible to the CE are conceptualized as LFB attributes. These 4411 attributes express the capability of the FE and support flexible 4412 implementations by allowing an FE to specify which optional features 4413 are supported. The attributes also indicate whether they are 4414 configurable by the CE for an LFB class. Configurable attributes 4415 provide the CE some flexibility in specifying the behavior of an 4416 LFB. When multiple LFBs belonging to the same LFB class are 4417 instantiated on an FE, each of those LFBs could be configured with 4418 different attribute settings. By querying the settings of the 4419 attributes for an instantiated LFB, the CE can determine the state 4420 of that LFB. 4422 Instantiated LFBs are interconnected in a directed graph that 4423 describes the ordering of the functions within an FE. This directed 4424 graph is described by the topology model. The combination of the 4425 attributes of the instantiated LFBs and the topology describe the 4426 packet processing functions available on the FE (current state). 4428 Another key component of the FE model is the FE attributes. The FE 4429 attributes are used mainly to describe the capabilities of the FE, 4430 but they also convey information about the FE state. 4432 The FE model also includes a definition of the minimal set of LFBs 4433 that is required by Section 5.5 of RFC 3564[1]. The sections that 4434 follow provide more detail on the specifics of each of those LFBs. 4435 Note that the details of the LFBs are contained in a separate LFB 4436 Class Library document. [EDITOR - need to add a reference to that 4437 document]. 4439 6.1. Port Functions 4441 The FE model can be used to define a Port LFB class and its 4442 technology-specific subclasses to map the physical port of the 4443 device to the LFB model with both static and configurable 4444 attributes. The static attributes model the type of port, link 4445 speed, etc. The configurable attributes model the addressing, 4446 administrative status, etc. 4448 6.2. Forwarding Functions 4450 Because forwarding function is one of the most common and important 4451 functions in the forwarding plane, it requires special attention in 4452 modeling to allow design flexibility, implementation efficiency, 4453 modeling accuracy and configuration simplicity. Toward that end, it 4454 is recommended that the core forwarding function being modeled by 4455 the combination of two LFBs -- Longest Prefix Match (LPM) classifier 4456 LFB and Next Hop LFB. Special header writer LFB is also needed to 4457 take care of TTL decrement and checksum etc. 4459 6.3. QoS Functions 4461 The LFB class library includes descriptions of the Meter, Queue, 4462 Scheduler, Counter and Dropper LFBs to support the QoS functions in 4463 the forwarding path. The FE model can also be used to define other 4464 useful QoS functions as needed. These LFBs allow the CE to 4465 manipulate the attributes to model IntServ or DiffServ functions. 4467 6.4. Generic Filtering Functions 4469 Various combinations of Classifier, Redirector, Meter and Dropper 4470 LFBs can be used to model a complex set of filtering functions. 4472 6.5. Vendor Specific Functions 4474 New LFB classes can be defined according to the LFB model as 4475 described in Section 4 to support vendor specific functions. A new 4476 LFB class can also be derived from an existing LFB class through 4477 inheritance. 4479 6.6.High-Touch Functions 4481 High-touch functions are those that take action on the contents or 4482 headers of a packet based on content other than what is found in the 4483 IP header. Examples of such functions include NAT, ALG, firewall, 4484 tunneling and L7 content recognition. It is not practical to 4485 include all possible high-touch functions in the initial LFB library 4486 due to the number and complexity. However, the flexibility of the 4487 LFB model and the power of interconnection in LFB topology should 4488 make it possible to model any high-touch functions. 4490 6.7. Security Functions 4492 Security functions are not included in the initial LFB class 4493 library. However, the FE model is flexible and powerful enough to 4494 model the types of encryption and/or decryption functions that an FE 4495 supports and the associated attributes for such functions. 4497 The IP Security Policy (IPSP) Working Group in the IETF has started 4498 work in defining the IPSec Policy Information Base [8]. We will try 4499 to reuse as much of the work as possible. 4501 6.8. Off-loaded Functions 4503 In addition to the packet processing functions typically found on 4504 the FEs, some logical functions may also be executed asynchronously 4505 by some FEs, as directed by a finite-state machine and triggered not 4506 only by packet events, but by timer events as well. Examples of 4507 such functions include; finite-state machine execution required by 4508 TCP termination or OSPF Hello processing off-loaded from the CE. By 4509 defining LFBs for such functions, the FE model is capable of 4510 expressing these asynchronous functions to allow the CE to take 4511 advantage of such off-loaded functions on the FEs. 4513 6.9. IPFLOW/PSAMP Functions 4515 RFC 3917 [9] defines an architecture for IP traffic flow monitoring, 4516 measuring and exporting. The LFB model supports statistics 4517 collection on the LFB by including statistical attributes (Section 4518 4.7.4) in the LFB class definitions; in addition, special statistics 4519 collection LFBs such as meter LFBs and counter LFBs can also be used 4520 to support accounting functions in the FE. 4522 [10] describes a framework to define a standard set of capabilities 4523 for network elements to sample subsets of packets by statistical and 4524 other methods. Time event generation, filter LFB, and counter/meter 4525 LFB are the elements needed to support packet filtering and sampling 4526 functions -- these elements can all be supported in the FE model. 4528 7. Using the FE model in the ForCES Protocol 4530 The actual model of the forwarding plane in a given NE is something 4531 the CE must learn and control by communicating with the FEs (or by 4532 other means). Most of this communication will happen in the post- 4533 association phase using the ForCES protocol. The following types of 4534 information must be exchanged between CEs and FEs via the ForCES 4535 protocol: 4537 1) FE topology query; 4538 2) FE capability declaration; 4539 3) LFB topology (per FE) and configuration capabilities query; 4540 4) LFB capability declaration; 4541 5) State query of LFB attributes; 4542 6) Manipulation of LFB attributes; 4543 7) LFB topology reconfiguration. 4545 Items 1) through 5) are query exchanges, where the main flow of 4546 information is from the FEs to the CEs. Items 1) through 4) are 4547 typically queried by the CE(s) in the beginning of the post- 4548 association (PA) phase, though they may be repeatedly queried at any 4549 time in the PA phase. Item 5) (state query) will be used at the 4550 beginning of the PA phase, and often frequently during the PA phase 4551 (especially for the query of statistical counters). 4553 Items 6) and 7) are "command" types of exchanges, where the main 4554 flow of information is from the CEs to the FEs. Messages in Item 6) 4555 (the LFB re-configuration commands) are expected to be used 4556 frequently. Item 7) (LFB topology re-configuration) is needed only 4557 if dynamic LFB topologies are supported by the FEs and it is 4558 expected to be used infrequently. 4560 Among the seven types of payload information the ForCES protocol 4561 carries between CEs and FEs, the FE model covers all of them except 4562 item 1), which concerns the inter-FE topology. The FE model focuses 4563 on the LFB and LFB topology within a single FE. Since the 4564 information related to item 1) requires global knowledge about all 4565 of the FEs and their inter-connection with each other, this exchange 4566 is part of the ForCES base protocol instead of the FE model. 4568 The relationship between the FE model and the seven post-association 4569 messages are visualized in Figure 9: 4571 +--------+ 4572 ..........-->| CE | 4573 /----\ . +--------+ 4574 \____/ FE Model . ^ | 4575 | |................ (1),2 | | 6, 7 4576 | | (off-line) . 3, 4, 5 | | 4577 \____/ . | v 4578 . +--------+ 4579 e.g. RFCs ..........-->| FE | 4580 +--------+ 4582 Figure 9. Relationship between the FE model and the ForCES protocol 4583 messages, where (1) is part of the ForCES base protocol, and the 4584 rest are defined by the FE model. 4586 The actual encoding of these messages is defined by the ForCES 4587 protocol and beyond the scope of the FE model. Their discussion is 4588 nevertheless important here for the following reasons: 4590 . These PA model components have considerable impact on the FE 4591 model. For example, some of the above information can be 4592 represented as attributes of the LFBs, in which case such 4593 attributes must be defined in the LFB classes. 4594 . The understanding of the type of information that must be 4595 exchanged between the FEs and CEs can help to select the 4596 appropriate protocol format and the actual encoding method 4597 (such as XML, TLVs). 4598 . Understanding the frequency of these types of messages should 4599 influence the selection of the protocol format (efficiency 4600 considerations). 4602 An important part of the FE model is the port the FE uses for its 4603 message exchanges to and from the CE. In the case that a dedicated 4604 port is used for CE-FE communication, we propose to use a special 4605 port LFB, called the CE-FE Port LFB (a subclass of the general Port 4606 LFB in Section 6.1), to model this dedicated CE-FE port. The CE-FE 4607 Port LFB acts as both a source and sink for the traffic from and to 4608 the CE. Sometimes the CE-FE traffic does not have its own dedicated 4609 port, instead the data fabric is shared for the data plane traffic 4610 and the CE-FE traffic. A special processing LFB can be used to 4611 model the ForCES packet encapsulation and decapsulation in such 4612 cases. 4614 The remaining sub-sections of this section address each of the seven 4615 message types. 4617 7.1. FE Topology Query 4619 An FE may contain zero, one or more external ingress ports. 4620 Similarly, an FE may contain zero, one or more external egress 4621 ports. In other words, not every FE has to contain any external 4622 ingress or egress interfaces. For example, Figure 10 shows two 4623 cascading FEs. FE #1 contains one external ingress interface but no 4624 external egress interface, while FE #2 contains one external egress 4625 interface but no ingress interface. It is possible to connect these 4626 two FEs together via their internal interfaces to achieve the 4627 complete ingress-to-egress packet processing function. This provides 4628 the flexibility to spread the functions across multiple FEs and 4629 interconnect them together later for certain applications. 4631 While the inter-FE communication protocol is out of scope for 4632 ForCES, it is up to the CE to query and understand how multiple FEs 4633 are inter-connected to perform a complete ingress-egress packet 4634 processing function, such as the one described in Figure 10. The 4635 inter-FE topology information may be provided by FEs, may be hard- 4636 coded into CE, or may be provided by some other entity (e.g., a bus 4637 manager) independent of the FEs. So while the ForCES protocol 4638 supports FE topology query from FEs, it is optional for the CE to 4639 use it, assuming the CE has other means to gather such topology 4640 information. 4642 +-----------------------------------------------------+ 4643 | +---------+ +------------+ +---------+ | 4644 input| | | | | | output | 4645 ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ 4646 | | port | |Decompressor| |Forwarder| FE | | 4647 | +---------+ +------------+ +---------+ #1 | | 4648 +-----------------------------------------------------+ V 4649 | 4650 +-----------------------<-----------------------------+ 4651 | 4652 | +----------------------------------------+ 4653 V | +------------+ +----------+ | 4654 | input | | | | output | 4655 +->--+->|Header |-->| Egress |---------+--> 4656 | |Compressor | | port | FE | 4657 | +------------+ +----------+ #2 | 4658 +----------------------------------------+ 4660 Figure 10. An example of two FEs connected together. 4662 Once the inter-FE topology is discovered by the CE after this query, 4663 it is assumed that the inter-FE topology remains static. However, 4664 it is possible that an FE may go down during the NE operation, or a 4665 board may be inserted and a new FE activated, so the inter-FE 4666 topology will be affected. It is up to the ForCES protocol to 4667 provide a mechanism for the CE to detect such events and deal with 4668 the change in FE topology. FE topology is outside the scope of the 4669 FE model. 4671 7.2. FE Capability Declarations 4673 FEs will have many types of limitations. Some of the limitations 4674 must be expressed to the CEs as part of the capability model. The 4675 CEs must be able to query these capabilities on a per-FE basis. 4676 Examples: 4678 . Metadata passing capabilities of the FE. Understanding these 4679 capabilities will help the CE to evaluate the feasibility of 4680 LFB topologies, and hence to determine the availability of 4681 certain services. 4682 . Global resource query limitations (applicable to all LFBs of 4683 the FE). 4684 . LFB supported by the FE. 4685 . LFB class instantiation limit. 4686 . LFB topological limitations (linkage constraint, ordering etc.) 4688 7.3. LFB Topology and Topology Configurability Query 4690 The ForCES protocol must provide the means for the CEs to discover 4691 the current set of LFB instances in an FE and the interconnections 4692 between the LFBs within the FE. In addition, sufficient information 4693 should be available to determine whether the FE supports any CE- 4694 initiated (dynamic) changes to the LFB topology, and if so, 4695 determine the allowed topologies. Topology configurability can also 4696 be considered as part of the FE capability query as described in 4697 Section 9.3. 4699 7.4. LFB Capability Declarations 4701 LFB class specifications define a generic set of capabilities. 4702 When an LFB instance is implemented (instantiated) on a vendor's FE, 4703 some additional limitations may be introduced. Note that we discuss 4704 only those limitations that are within the flexibility of the LFB 4705 class specification. That is, the LFB instance will remain 4706 compliant with the LFB class specification despite these 4707 limitations. For example, certain features of an LFB class may be 4708 optional, in which case it must be possible for the CE to determine 4709 if an optional feature is supported by a given LFB instance or not. 4710 Also, the LFB class definitions will probably contain very few 4711 quantitative limits (e.g., size of tables), since these limits are 4712 typically imposed by the implementation. Therefore, quantitative 4713 limitations should always be expressed by capability arguments. 4715 LFB instances in the model of a particular FE implementation will 4716 possess limitations on the capabilities defined in the corresponding 4717 LFB class. The LFB class specifications must define a set of 4718 capability arguments, and the CE must be able to query the actual 4719 capabilities of the LFB instance via querying the value of such 4720 arguments. The capability query will typically happen when the LFB 4721 is first detected by the CE. Capabilities need not be re-queried in 4722 case of static limitations. In some cases, however, some 4723 capabilities may change in time (e.g., as a result of 4724 adding/removing other LFBs, or configuring certain attributes of 4725 some other LFB when the LFBs share physical resources), in which 4726 case additional mechanisms must be implemented to inform the CE 4727 about the changes. 4729 The following two broad types of limitations will exist: 4731 . Qualitative restrictions. For example, a standardized multi- 4732 field classifier LFB class may define a large number of 4733 classification fields, but a given FE may support only a subset 4734 of those fields. 4735 . Quantitative restrictions, such as the maximum size of tables, 4736 etc. 4738 The capability parameters that can be queried on a given LFB class 4739 will be part of the LFB class specification. The capability 4740 parameters should be regarded as special attributes of the LFB. The 4741 actual values of these arguments may be, therefore, obtained using 4742 the same attribute query mechanisms as used for other LFB 4743 attributes. 4745 Capability attributes will typically be read-only arguments, but in 4746 certain cases they may be configurable. For example, the size of a 4747 lookup table may be limited by the hardware (read-only), in other 4748 cases it may be configurable (read-write, within some hard limits). 4750 Assuming that capabilities will not change frequently, the 4751 efficiency of the protocol/schema/encoding is of secondary concern. 4753 7.5. State Query of LFB Attributes 4755 This feature must be provided by all FEs. The ForCES protocol and 4756 the data schema/encoding conveyed by the protocol must together 4757 satisfy the following requirements to facilitate state query of the 4758 LFB attributes: 4760 . Must permit FE selection. This is primarily to refer to a 4761 single FE, but referring to a group of (or all) FEs may 4762 optional be supported. 4763 . Must permit LFB instance selection. This is primarily to refer 4764 to a single LFB instance of an FE, but optionally addressing of 4765 a group of LFBs (or all) may be supported. 4766 . Must support addressing of individual attribute of an LFB. 4767 . Must provide efficient encoding and decoding of the addressing 4768 info and the configured data. 4769 . Must provide efficient data transmission of the attribute state 4770 over the wire (to minimize communication load on the CE-FE 4771 link). 4773 7.6. LFB Attribute Manipulation 4775 This is a place-holder for all operations that the CE will use to 4776 populate, manipulate, and delete attributes of the LFB instances on 4777 the FEs. These operations allow the CE to configure an individual 4778 LFB instance. 4780 The same set of requirements as described in Section 9.5 for 4781 attribute query applies here for attribute manipulation as well. 4783 Support for various levels of feedback from the FE to the CE (e.g., 4784 request received, configuration completed), as well as multi- 4785 attribute configuration transactions with atomic commit and 4786 rollback, may be necessary in some circumstances. 4788 (Editor's note: It remains an open issue as to whether or not other 4789 methods are needed in addition to "get attribute" and "set 4790 attribute" (such as multi-attribute transactions). If the answer to 4791 that question is yes, it is not clear whether such methods should be 4792 supported by the FE model itself or the ForCES protocol.) 4794 7.7. LFB Topology Re-configuration 4796 Operations that will be needed to reconfigure LFB topology: 4797 . Create a new instance of a given LFB class on a given FE. 4798 . Connect a given output of LFB x to the given input of LFB y. 4799 . Disconnect: remove a link between a given output of an LFB and 4800 a given input of another LFB. 4801 . Delete a given LFB (automatically removing all interconnects 4802 to/from the LFB). 4804 8. Example 4805 This section contains an example LFB definition. While some 4806 properties of LFBs are shown by the FE Object LFB, this endeavors to 4807 show how a data plain LFB might be build. This example is a 4808 fictional case of an interface supporting a coarse WDM optical 4809 interface carry Frame Relay traffic. The statistical information 4810 (including error statistics) is omitted.) 4812 4813 4817 4818 4819 FRFrame 4820 4821 A frame relay frame, with DLCI without 4822 stuffing) 4823 4824 4825 4826 IPFrame 4827 An IP Packet 4828 4829 4830 4831 4832 frequencyInformationType 4833 4834 Information about a single CWDM frequency 4835 4836 4837 4838 LaserFrequency 4839 encoded frequency(channel) 4840 uint32 4841 4842 4843 FrequencyState 4844 state of this frequency 4845 PortStatusValues 4846 4847 4848 LaserPower 4849 current observed power 4850 uint32 4851 4852 4853 FrameRelayCircuits 4854 4855 Information about circuits on this Frequency 4856 4857 4858 frameCircuitsType 4859 4860 4861 4862 4863 4864 frameCircuitsType 4865 4866 Information about a single Frame Relay circuit 4867 4868 4869 4870 DLCI 4871 DLCI of the circuit 4872 uint32 4873 4874 4875 CircuitStatus 4876 state of the circuit 4877 PortStatusValues 4878 4879 4880 isLMI 4881 is this the LMI circuit 4882 boolean 4883 4884 4885 associatedPort 4886 4887 which input / output port is associated 4888 with this circuit 4889 4890 uint32 4891 4892 4893 4894 4895 PortStatusValues 4896 4897 The possible values of status. Used for both 4898 administrative and operation status 4899 4900 4901 uchar 4902 4903 4904 Disabled 4905 the component is disabled 4906 4907 4908 Enable 4909 FE is operatively disabled 4910 4911 4912 4913 4914 4915 4916 4917 DLCI 4918 The DLCI the frame arrived on 4919 12 4920 uint32 4921 4922 4923 LaserChannel 4924 The index of the laser channel 4925 34 4926 uint32 4927 4928 4929 4930 4931 FrameLaserLFB 4932 Fictional LFB for Demonstartions 4933 1.0 4934 4935 4936 LMIfromFE 4937 4938 Ports for LMI traffic, for transmission 4939 4940 4941 4942 FRFrame 4943 4944 4945 DLCI 4946 LaserChannel 4947 4948 4949 4950 4951 DatafromFE 4952 4953 Ports for data to be sent on circuits 4954 4955 4956 4957 IPFrame 4958 4959 4960 DLCI 4961 LaserChannel 4962 4963 4964 4965 4966 4967 4968 LMItoFE 4969 4970 Ports for LMI traffic for processing 4971 4972 4973 4974 FRFrame 4975 4976 4977 DLCI 4978 LaserChannel 4979 4980 4981 4982 4983 DatatoFE 4984 4985 Ports for Data traffic for processing 4986 4987 4988 4989 IPFrame 4990 4991 4992 DLCI 4993 LaserChannel 4994 4995 4996 4997 4998 4999 5000 AdminPortState 5001 is this port allowed to function 5002 PortStatusValues 5003 5004 5005 FrequencyInformation 5006 5007 table of information per CWDM frequency 5008 5009 5010 frequencyInformationType 5011 5012 5013 5014 5015 5016 OperationalState 5017 5018 whether the port over all is operational 5019 5020 PortStatusValues 5021 5022 5023 MaximumFrequencies 5024 5025 how many laser frequencies are there 5026 5027 uint16 5028 5029 5030 MaxTotalCircuits 5031 5032 Total supportable Frame Relay Circuits, across 5033 all laser frequencies 5034 5035 5036 uint32 5037 5038 5039 5040 5041 FrequencyState 5042 5043 The state of a frequency has changed 5044 5045 5046 FrequencyInformation 5047 _FrequencyIndex_ 5048 FrequencyState 5050 5051 5052 5053 5054 5055 FrequencyInformation 5056 _FrequencyIndex_ 5057 FrequencyState 5058 5059 5060 5061 5062 CreatedFrequency 5063 A new frequency has appeared 5064 5065 FrequencyInformation> 5066 _FrequencyIndex_ 5067 5068 5069 5070 5071 FrequencyInformation 5072 _FrequencyIndex_ 5073 LaserFrequency 5074 5075 5076 5077 5078 DeletedFrequency 5079 5080 A frequency Table entry has been deleted 5081 5082 5083 FrequencyInformation 5084 _FrequencyIndex_ 5085 5086 5087 5088 5089 PowerProblem 5090 5091 there are problems with the laser power level 5092 5093 5094 FrequencyInformation 5095 _FrequencyIndex_ 5096 LaserPower 5097 5098 5099 5100 5101 FrequencyInformation 5102 _FrequencyIndex_ 5103 LaserPower 5104 5105 5106 FrequencyInformation 5107 _FrequencyIndex_ 5108 LaserFrequency 5109 5110 5111 5112 5113 FrameCircuitChanged 5114 5115 the state of an Fr circuit on a frequency 5116 has changed 5117 5118 5119 FrequencyInformation 5120 _FrequencyIndex_ 5121 FrameRelayCircuits 5122 FrameCircuitIndex 5123 CircuitStatus 5124 5125 5126 5127 5128 FrequencyInformation 5129 _FrequencyIndex_ 5130 FrameRelayCircuits 5131 FrameCircuitIndex 5132 CircuitStatus 5133 5134 5135 FrequencyInformation 5136 _FrequencyIndex_ 5137 FrameRelayCircuits 5138 FrameCircuitIndex 5139 DLCI 5140 5141 5142 5143 5144 5145 5146 5148 8.1.Data Handling 5150 This LFB is designed to handle data packets coming in from or going 5151 out to the external world. It is not a full port, and it lacks many 5152 useful statistics. But it serves to show many of the relevant 5153 behaviors. 5155 Packets arriving without error from the physical interface come in 5156 on a Frame Relay DLCI on a laser channel. These two values are used 5157 by the LFB too look up the handling for the packet. If the handling 5158 indicates that the packet is LMI, then the output index is used to 5159 select an LFB port from the LMItoFE port group. The packet is sent 5160 as a full Frame Relay frame (without any bit or byte stuffing) on 5161 the selected port. The laser channel and DLCI are sent as meta- 5162 data, even though the DLCI is also still in the packet. 5164 Good packets that arrive and are not LMI and have a frame relay type 5165 indicator of IP are sent as IP packets on the port in the DatatoFE 5166 port group, using the same index field from the table based on the 5167 laser channel and DLCI. The channel and DLCI are attached as meta- 5168 data for other use (classifiers, for example.) 5170 The current definition does not specify what to do if the Frame 5171 Relay type information is not IP. 5173 Packets arriving on input ports arrive with the Lasesr Channel and 5174 Frame Relay DLCI as meta-data. As such, a single input port could 5175 have been used. With the structure that is defined (which parallels 5176 the output structure), the selection of channel and DLCI could be 5177 restricted by the arriving input port group (LMI vs data) and port 5178 index. As an alternative LFB design, the structures could require a 5179 1-1 relationship between DLCI and LFB port, in which case no meta- 5180 data would be needed. This would however be quite complex and 5181 noisy. The intermediate level of structure here allows parallelism 5182 between input and output, without requiring excessive ports. 5184 8.1.1. Setting up a DLCI 5186 When a CE chooses to establish a DLCI on a specific laser channel, 5187 it sends a SET request directed to this LFB. The request might look 5188 like 5190 T = SET-OPERATION 5191 T = PATH-DATA 5192 Path: flags = first-avail, length = 4, path = 2, channel, 4 5193 DataRaw: DLCI, Enable(1), false, out-idx 5195 Which would esbalish the DLCI as enabled, with traffic going to a 5196 specific element of the output port group DatatoFE. (The CE would 5197 ensure that output port is connected to the right place before 5198 issuing this request. 5200 The response to the operation would include the actual index 5201 assigned to this Frame Relay circuit. This table is structured to 5202 use separate internal indices and DLCIs. An alternative design 5203 could have used the DLCI as index, trading off complexities. 5205 One could also imagine that the FE has an LMI LFB. Such an LFB 5206 would be connected to the LMItoFE and LMIfromFE port groups. It 5207 would process LMI information. It might be the LFBs job to set up 5208 the frame relay circuits. The LMI LFB would have an alias entry 5209 that points to the Frame Relay circuits table it manages, so that it 5210 can manipulate those entities. 5212 8.1.2. Error Handling 5214 The LFB will receive invalid packets over the wire. Many of these 5215 will simply result in incrementing counters. The LFB designer might 5216 also specify some error rate measures. This puts more work on the 5217 FE, but allows for more meaningful alarms. 5219 There may be some error conditions that should cause parts of the 5220 packet to be sent to the CE. The error itself is not something that 5221 can cause an event in the LFB. There are two ways this can be 5222 handled. 5224 One way is to define a specific field to count the error, and a 5225 field in the LFB to hold the required portion of the packet. The 5226 field could be defined to hold the portion of the packet from the 5227 most recent error. One could then define an event that occurs 5228 whenever the error count changes, and declare that reporting the 5229 event includes the LFB field with the packet portion. For rare but 5230 extremely critical errors, this is an effective solution. It 5231 ensures reliable delivery of the notification. And it allows the CE 5232 to control if it wants the notification. (Use of the event variance 5233 property would suppress multiple notifications. It would suppress 5234 them even if they were many hours apart, so the CE is unlikely to 5235 use that.) 5237 Another approach is for the LFB to have a port that connects to a 5238 redirect sink. The LFB would attach the laser channel, the DLCI, 5239 and the error indication as meta-data, and ship the packet to the 5240 CE. 5242 Other aspects of error handling are discussed under events below. 5244 8.2. LFB Attributes 5245 This LFB is defined to have two top level attributes. One reflects 5246 the administrative state of the LFB. This allows the CE to disable 5247 the LFB completely. 5249 The other attribute is the table of information about the laser 5250 channels. It is a variable sized array. Each array entry contains 5251 an identifier for what laser frequency this entry is associated 5252 with, whether that frequency is operational, the power of the laser 5253 at that frequency, and a table of information about frame relay 5254 circuits on this frequency. There is no administrative status since 5255 a CE can disable an entry simply by removing it. (Frequency and 5256 laser power of a non-operational channel are not particularly 5257 useful. Knowledge about what frequencies can be supported would be 5258 a table in the capabilities section.) 5260 The Frame Relay circuit information contains the DLCI, the 5261 operational circuit status, whether this circuit is to be treated as 5262 carrying LMI information, and which port in the output port group of 5263 the LFB traffic is to be sent to. As mentioned above, the circuit 5264 index could, in some designs, be combined with the DLCI. 5266 8.3. Capabilities 5268 The capability information for this LFB includes whether the 5269 underlying interface is operational, how many frequencies are 5270 supported, and how many total circuits, across all channels, are 5271 permitted. The maximum number for a given laser channel can be 5272 determined from the properties of the FrameRelayCircuits table. A 5273 GET-Properties on path 2.channel.4 will give the CE the properties 5274 of the array which include the number of entries used, the first 5275 available entry, and the maximum number of entries permitted. 5277 8.4. Events 5279 This LFB is defined to be able to generate several events that the 5280 CE may be interested in. There are events to report changes in 5281 operational state of frequencies, and the creation and deletion of 5282 frequency entries. There is an event for changes in status of 5283 individual frame relay circuits. So an event notification of 5284 61.5.3.11 would indicate that there had been a circuit status change 5285 on subscript 11 of the circuit table in subscript 3 of the frequency 5286 table. The event report would include the new status of the circuit 5287 and the DLCI of the circuit. Arguably, the DLCI is redundant, since 5288 the CE presumably knows the DLCI based on the circuit index. It is 5289 included here to show including two pieces of information in an 5290 event report. 5292 As described above, the event declaration defines the event target, 5293 the event condition, and the event report content. The event 5294 properties indicate whether the CE is subscribed to the event, the 5295 specific threshold for the event, and any filter conditions for the 5296 event. 5298 Another event shown is a laser power problem. This event is 5299 generated whenever the laser falls below the specified threshold. 5300 Thus, a CE can register for the event of laser power loss on all 5301 circuits. It would do this by: 5303 T = SET-Properties 5304 Path-TLV: flags=0, length = 2, path = 61.4 5305 Path-TLV: flags = property-field, length = 1, path = 2 5306 Content = 1 (register) 5307 Path-TLV: flags = property-field, length = 1, path = 3 5308 Content = 15 (threshold) 5310 This would set the registration for the event on all entries in the 5311 table. It would also set the threshold for the event, causing 5312 reporting if the power falls below 15. (Presumably, the CE knows 5313 what the scale is for power, and has chosen 15 as a meaningful 5314 problem level.) 5316 If a laser oscillates in power near the 15 mark, one could get a lot 5317 of notifications. (If it flips back and forth between 9 and 10, 5318 each flip down will generate an event.) Suppose that the CE decides 5319 to suppress this oscillation somewhat on laser channel 5. It can do 5320 this by setting the variance property on that event. The request 5321 would look like: 5323 T = SET-Properties 5324 Path-TLV: flags=0, length = 3, path = 61.4.5 5325 Path-TLV: flags = property-field, length = 1, path = 4 5326 Content = 2 (hysteresis) 5328 Setting the hysteresis to 2 suppress a lot of spurious 5329 notifications. When the level first falls below 10, a notification 5330 is generated. If the power level increases to 10 or 11, and then 5331 falls back below 10, an event will not be generated. The power has 5332 to recover to at least 12 and fall back below 10 to generate another 5333 event. Once common cause of this form of osciallation is when the 5334 actual value is right near the border. If it is really 9.5, tiny 5335 changes might flip it back and forth between 9 and 10. A variance 5336 level of 1 will suppress this sort of condition. Many other events 5337 have osciallations that are somewhat wider, so larger variance 5338 settings can be used with those. 5340 9. Acknowledgments 5341 Many of the colleagues in our companies and participants in the 5342 ForCES mailing list have provided invaluable input into this work. 5344 10. Security Considerations 5346 The FE model describes the representation and organization of data 5347 sets and attributes in the FEs. The ForCES framework document [2] 5348 provides a comprehensive security analysis for the overall ForCES 5349 architecture. For example, the ForCES protocol entities must be 5350 authenticated per the ForCES requirements before they can access the 5351 information elements described in this document via ForCES. Access 5352 to the information contained in the FE model is accomplished via the 5353 ForCES protocol, which will be defined in separate documents, and 5354 thus the security issues will be addressed there. 5356 11. Normative References 5358 [1] Khosravi, H. et al., "Requirements for Separation of IP Control 5359 and Forwarding", RFC 3654, November 2003. 5361 [2] Yang, L. et al., "Forwarding and Control Element Separation 5362 (ForCES) Framework", RFC 3746, April 2004. 5364 12. Informative References 5366 [3] Bernet, Y. et al., "An Informal Management Model for Diffserv 5367 Routers", RFC 3290, May 2002. 5369 [4] Chan, K. et al., "Differentiated Services Quality of Service 5370 Policy Information Base", RFC 3317, March 2003. 5372 [5] Sahita, R. et al., "Framework Policy Information Base", RFC 5373 3318, March 2003. 5375 [6] Moore, B. et al., "Information Model for Describing Network 5376 Device QoS Datapath Mechanisms", RFC 3670, January 2004. 5378 [7] Snir, Y. et al., "Policy Framework QoS Information Model", RFC 5379 3644, Nov 2003. 5381 [8] Li, M. et al., "IPsec Policy Information Base", work in 5382 progress, April 2004, . 5384 [9] Quittek, J. et Al., "Requirements for IP Flow Information 5385 Export", RFC 3917, October 2004. 5387 [10] Duffield, N., "A Framework for Packet Selection and Reporting", 5388 work in progress, January 2005, . 5390 [11] Pras, A. and Schoenwaelder, J., RFC 3444 "On the Difference 5391 between Information Models and Data Models", January 2003. 5393 13. Authors' Addresses 5395 L. Lily Yang 5396 Intel Corp. 5397 Mail Stop: JF3-206 5398 2111 NE 25th Avenue 5399 Hillsboro, OR 97124, USA 5400 Phone: +1 503 264 8813 5401 Email: lily.l.yang@intel.com 5403 Joel M. Halpern 5404 Megisto Systems, Inc. 5405 20251 Century Blvd. 5406 Germantown, MD 20874-1162, USA 5407 Phone: +1 301 444-1783 5408 Email: jhalpern@megisto.com 5410 Ram Gopal 5411 Nokia Research Center 5412 5, Wayside Road, 5413 Burlington, MA 01803, USA 5414 Phone: +1 781 993 3685 5415 Email: ram.gopal@nokia.com 5417 Alan DeKok 5418 Infoblox, Inc. 5419 475 Potrero Ave, 5420 Sunnyvale CA 94085 5421 Phone: 5422 Email: alan.dekok@infoblox.com 5424 Zsolt Haraszti 5425 Clovis Solutions 5426 1310 Redwood Way, Suite B 5427 Petaluma, CA 94954 5428 Phone: 707-796-7110 5429 Email: zsolt@clovissolutions.com 5430 Ellen Deleganes 5431 Intel Corp. 5432 Mail Stop: CO5-156 5433 15400 NW Greenbrier Parkway 5434 Beaverton, OR 97006 5435 Phone: +1 503 677-4996 5436 Email: ellen.m.deleganes@intel.com 5438 14. Intellectual Property Right 5440 The authors are not aware of any intellectual property right issues 5441 pertaining to this document. 5443 15. IANA consideration 5445 A namespace is needed to uniquely identify the LFB type in the LFB 5446 class library. 5448 Frame type supported on input and output of LFB must also be 5449 uniquely identified. 5451 A set of metadata supported by the LFB model must also be uniquely 5452 identified with names or IDs. 5454 16. Copyright Statement 5456 "Copyright (C) The Internet Society (2006). This document is 5457 subject to the rights, licenses and restrictions contained in BCP 5458 78, and except as set forth therein, the authors retain all their 5459 rights." 5461 "This document and the information contained herein are provided on 5462 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 5463 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 5464 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 5465 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5466 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5467 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."