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