idnits 2.17.1 draft-ietf-forces-model-11.txt: 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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 5804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5828. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance 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 IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 25, 2008) is 5905 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: 'N' on line 3741 -- Looks like a reference, but probably isn't: '1-9' on line 3926 -- Looks like a reference, but probably isn't: '0-9' on line 3926 -- No information found for draft-ietf - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group: ForCES J. Halpern 3 Internet-Draft Self 4 Expires: August 28, 2008 E. Deleganes 5 Intel Corp. 6 J. Hadi Salim 7 Znyx Networks 8 February 25, 2008 10 ForCES Forwarding Element Model 11 draft-ietf-forces-model-11.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Comments are solicited and should be addressed to the working group's 43 mailing list at forces@peach.ease.lsoft.com and/or the author(s). 45 Abstract 47 This document defines the forwarding element (FE) model used in the 48 Forwarding and Control Element Separation (ForCES) protocol [2]. The 49 model represents the capabilities, state and configuration of 50 forwarding elements within the context of the ForCES protocol, so 51 that control elements (CEs) can control the FEs accordingly. More 52 specifically, the model describes the logical functions that are 53 present in an FE, what capabilities these functions support, and how 54 these functions are or can be interconnected. This FE model is 55 intended to satisfy the model requirements specified in the ForCES 56 requirements document, RFC3654 [4]. 58 Table of Contents 60 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.1. Requirements on the FE model . . . . . . . . . . . . . . 7 63 2.2. The FE Model in Relation to FE Implementations . . . . . 8 64 2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8 65 2.4. Modeling Language for the FE Model . . . . . . . . . . . 9 66 2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9 67 3. ForCES Model Concepts . . . . . . . . . . . . . . . . . . . . 10 68 3.1. ForCES Capability Model and State Model . . . . . . . . . 11 69 3.1.1. FE Capability Model and State Model . . . . . . . . . 12 70 3.1.2. Relating LFB and FE Capability and State Model . . . 13 71 3.2. Logical Functional Block (LFB) Modeling . . . . . . . . . 14 72 3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 17 73 3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 20 74 3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 23 75 3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 24 76 3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 26 77 3.2.6. Component Properties . . . . . . . . . . . . . . . . 27 78 3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 28 79 3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 28 80 3.3. ForCES Model Addressing . . . . . . . . . . . . . . . . . 29 81 3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 31 82 3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 32 83 3.4.1. Alternative Approaches for Modeling FE Datapaths . . 32 84 3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 36 85 4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40 86 4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 41 87 4.2. Element . . . . . . . . . . . . . . . . . . 41 88 4.3. Element . . . . . . . . . . . . . . . . . . . . . 42 89 4.4. Element for Frame Type Declarations . . . . . 43 90 4.5. Element for Data Type Definitions . . . . 44 91 4.5.1. Element for Aliasing Existing Data Types . 46 92 4.5.2. Element for Deriving New Atomic Types . . . 47 93 4.5.3. Element to Define Arrays . . . . . . . . . . 47 94 4.5.4. Element to Define Structures . . . . . . . . 52 95 4.5.5. Element to Define Union Types . . . . . . . . 53 96 4.5.6. Element . . . . . . . . . . . . . . . . . . . 53 97 4.5.7. Augmentations . . . . . . . . . . . . . . . . . . . . 54 98 4.6. Element for Metadata Definitions . . . . . 55 99 4.7. Element for LFB Class Definitions . . . . 56 100 4.7.1. Element to Express LFB Inheritance . . 58 101 4.7.2. Element to Define LFB Inputs . . . . . . 59 102 4.7.3. Element to Define LFB Outputs . . . . . 61 103 4.7.4. Element to Define LFB Operational 104 Components . . . . . . . . . . . . . . . . . . . . . 64 105 4.7.5. Element to Define LFB Capability 106 Components . . . . . . . . . . . . . . . . . . . . . 66 107 4.7.6. Element for LFB Notification Generation . . 68 108 4.7.7. Element for LFB Operational 109 Specification . . . . . . . . . . . . . . . . . . . . 75 110 4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 75 111 4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 75 112 4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 77 113 4.8.3. String Properties . . . . . . . . . . . . . . . . . . 77 114 4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 78 115 4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 79 116 4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 82 117 4.9. XML Schema for LFB Class Library Documents . . . . . . . 83 118 5. FE Components and Capabilities . . . . . . . . . . . . . . . 94 119 5.1. XML for FEObject Class definition . . . . . . . . . . . . 95 120 5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 101 121 5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 101 122 5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 102 123 5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 104 124 5.3.1. FEState . . . . . . . . . . . . . . . . . . . . . . . 104 125 5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 105 126 5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 105 127 5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 105 128 6. Satisfying the Requirements on FE Model . . . . . . . . . . . 106 129 7. Using the FE model in the ForCES Protocol . . . . . . . . . . 107 130 7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 109 131 7.2. FE Capability Declarations . . . . . . . . . . . . . . . 110 132 7.3. LFB Topology and Topology Configurability Query . . . . . 111 133 7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 111 134 7.5. State Query of LFB Components . . . . . . . . . . . . . . 112 135 7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 113 136 7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 113 137 8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 113 138 8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 120 139 8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 121 140 8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 122 141 8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 122 142 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 123 143 8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 123 145 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 146 9.1. URN Namespace Registration . . . . . . . . . . . . . . . 124 147 9.2. LFB Class Names and LFB Class Identifiers . . . . . . . . 125 148 10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 126 149 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 126 150 12. Security Considerations . . . . . . . . . . . . . . . . . . . 127 151 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 152 13.1. Normative References . . . . . . . . . . . . . . . . . . 127 153 13.2. Informative References . . . . . . . . . . . . . . . . . 127 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 128 155 Intellectual Property and Copyright Statements . . . . . . . . . 129 157 1. Definitions 159 The use of compliance terminology (MUST, SHOULD, MAY) is used in 160 accordance with RFC2119 [1]. Such terminology is used in describing 161 the required behavior of ForCES forwarding elements or control 162 elements in supporting or manipulating information described in this 163 model. 165 Terminology associated with the ForCES requirements is defined in 166 RFC3654 [4] and is not copied here. The following list of 167 terminology relevant to the FE model is defined in this section. 169 FE Model -- The FE model is designed to model the logical processing 170 functions of an FE. The FE model proposed in this document includes 171 three components: the modeling of individual logical functional 172 blocks (LFB model), the logical interconnection between LFBs (LFB 173 topology) and the FE level attributes, including FE capabilities. 174 The FE model provides the basis to define the information elements 175 exchanged between the CE and the FE in the ForCES Protocol [2]. 177 Datapath -- A conceptual path taken by packets within the forwarding 178 plane inside an FE. Note that more than one datapath can exist 179 within an FE. 181 LFB (Logical Functional Block) Class (or type) -- A template that 182 representing a fine-grained, logically separable aspect of FE 183 processing. Most LFBs relate to packet processing in the data path. 184 LFB classes are the basic building blocks of the FE model. 186 LFB Instance -- As a packet flows through an FE along a datapath, it 187 flows through one or multiple LFB instances, where each LFB is an 188 instance of a specific LFB class. Multiple instances of the same LFB 189 class can be present in an FE's datapath. Note that we often refer 190 to LFBs without distinguishing between an LFB class and LFB instance 191 when we believe the implied reference is obvious for the given 192 context. 194 LFB Model -- The LFB model describes the content and structures in an 195 LFB, plus the associated data definition. XML is used to provide a 196 formal definition of the necessary structures for the modeling. Four 197 types of information are defined in the LFB model. The core part of 198 the LFB model is the LFB class definitions; the other three types of 199 information define constructs associated with and used by the class 200 definition. These are reusable data types, supported frame formats, 201 and metadata. 203 Element -- Element is generally used in this document in accordance 204 with the XML usage of the term. It refers to an XML tagged part of 205 an XML document. For a precise definition, please see the full set 206 of XML specifications from the W3C. This term is included in this 207 list for completeness because ForCES formal model uses XML. 209 Attribute -- Attribute is used in the ForCES formal modelling in 210 accordance with standard XML usage of the term. i.e to provide 211 attribute information include in an XML tag. 213 LFB Metadata -- Metadata is used to communicate per-packet state from 214 one LFB to another, but is not sent across the network. The FE model 215 defines how such metadata is identified, produced and consumed by the 216 LFBs, but not how the per-packet state is implemented within actual 217 hardware. Metadata is sent between the FE and the CE on redirect 218 packets. 220 ForCES Component -- a ForCES Component is a well defined, uniquely 221 identifiable and addressable ForCES model building block. A 222 component has a 32-bit ID, name, type and an optional synopsis 223 description. These are often referred to simply as components. 225 LFB Component -- A ForCES component that defines the Operational 226 parameters of the LFBs that must be visible to the CEs. 228 Structure Component -- A ForCES component that is part of a complex 229 data structure to be used in LFB data definitions. The individual 230 parts which make up a structured set of data are referred to as 231 Structure Components. These can themselves be of any valid data 232 type, including tables and structures. 234 Property -- ForCES components have properties associated with them, 235 such as readability. Other examples include lengths for variable 236 sized components. These properties are acessed by the CE for reading 237 (or, where appropriate, writing.) Details on the ForCES properties 238 are found in section 4.8. 240 LFB Topology -- A representation of the logical interconnection and 241 the placement of LFB instances along the datapath within one FE. 242 Sometimes this representation is called intra-FE topology, to be 243 distinguished from inter-FE topology. LFB topology is outside of the 244 LFB model, but is part of the FE model. 246 FE Topology -- A representation of how multiple FEs within a single 247 NE are interconnected. Sometimes this is called inter-FE topology, 248 to be distinguished from intra-FE topology (i.e., LFB topology). An 249 individual FE might not have the global knowledge of the full FE 250 topology, but the local view of its connectivity with other FEs is 251 considered to be part of the FE model. The FE topology is discovered 252 by the ForCES base protocol or by some other means. 254 Inter-FE Topology -- See FE Topology. 256 Intra-FE Topology -- See LFB Topology. 258 LFB class library -- A set of LFB classes that has been identified as 259 the most common functions found in most FEs and hence should be 260 defined first by the ForCES Working Group. 262 2. Introduction 264 RFC3746 [5] specifies a framework by which control elements (CEs) can 265 configure and manage one or more separate forwarding elements (FEs) 266 within a networking element (NE) using the ForCES protocol. The 267 ForCES architecture allows Forwarding Elements of varying 268 functionality to participate in a ForCES network element. The 269 implication of this varying functionality is that CEs can make only 270 minimal assumptions about the functionality provided by FEs in an NE. 271 Before CEs can configure and control the forwarding behavior of FEs, 272 CEs need to query and discover the capabilities and states of their 273 FEs. RFC3654 [4] mandates that the capabilities, states and 274 configuration information be expressed in the form of an FE model. 276 RFC3444 [8] observed that information models (IMs) and data models 277 (DMs) are different because they serve different purposes. "The main 278 purpose of an IM is to model managed objects at a conceptual level, 279 independent of any specific implementations or protocols used". 280 "DMs, conversely, are defined at a lower level of abstraction and 281 include many details. They are intended for implementors and include 282 protocol-specific constructs." Sometimes it is difficult to draw a 283 clear line between the two. The FE model described in this document 284 is primarily an information model, but also includes some aspects of 285 a data model, such as explicit definitions of the LFB class schema 286 and FE schema. It is expected that this FE model will be used as the 287 basis to define the payload for information exchange between the CE 288 and FE in the ForCES protocol. 290 2.1. Requirements on the FE model 292 RFC3654 [4]defines requirements that must be satisfied by a ForCES FE 293 model. To summarize, an FE model must define: 295 o Logically separable and distinct packet forwarding operations in 296 an FE datapath (logical functional blocks or LFBs); 298 o The possible topological relationships (and hence the sequence of 299 packet forwarding operations) between the various LFBs; 301 o The possible operational capabilities (e.g., capacity limits, 302 constraints, optional features, granularity of configuration) of 303 each type of LFB; 305 o The possible configurable parameters (e.g., components) of each 306 type of LFB; 308 o Metadata that may be exchanged between LFBs. 310 2.2. The FE Model in Relation to FE Implementations 312 The FE model proposed here is based on an abstraction using distinct 313 logical functional blocks (LFBs), which are interconnected in a 314 directed graph, and receive, process, modify, and transmit packets 315 along with metadata. The FE model is designed, and any defined LFB 316 classes should be designed, such that different implementations of 317 the forwarding datapath can be logically mapped onto the model with 318 the functionality and sequence of operations correctly captured. 319 However, the model is not intended to directly address how a 320 particular implementation maps to an LFB topology. It is left to the 321 forwarding plane vendors to define how the FE functionality is 322 represented using the FE model. Our goal is to design the FE model 323 such that it is flexible enough to accommodate most common 324 implementations. 326 The LFB topology model for a particular datapath implementation must 327 correctly capture the sequence of operations on the packet. Metadata 328 generation by certain LFBs MUST always precede any use of that 329 metadata by subsequent LFBs in the topology graph; this is required 330 for logically consistent operation. Further, modification of packet 331 fields that are subsequently used as inputs for further processing 332 MUST occur in the order specified in the model for that particular 333 implementation to ensure correctness. 335 2.3. The FE Model in Relation to the ForCES Protocol 337 The ForCES base Protocol [2] is used by the CEs and FEs to maintain 338 the communication channel between the CEs and FEs. The ForCES 339 protocol may be used to query and discover the inter-FE topology. 340 The details of a particular datapath implementation inside an FE, 341 including the LFB topology, along with the operational capabilities 342 and attributes of each individual LFB, are conveyed to the CE within 343 information elements in the ForCES protocol. The model of an LFB 344 class should define all of the information that needs to be exchanged 345 between an FE and a CE for the proper configuration and management of 346 that LFB. 348 Specifying the various payloads of the ForCES messages in a 349 systematic fashion is difficult without a formal definition of the 350 objects being configured and managed (the FE and the LFBs within). 351 The FE Model document defines a set of classes and components for 352 describing and manipulating the state of the LFBs within an FE. 353 These class definitions themselves will generally not appear in the 354 ForCES protocol. Rather, ForCES protocol operations will reference 355 classes defined in this model, including relevant components and the 356 defined operations. 358 Section 7 provides more detailed discussion on how the FE model 359 should be used by the ForCES protocol. 361 2.4. Modeling Language for the FE Model 363 Even though not absolutely required, it is beneficial to use a formal 364 data modeling language to represent the conceptual FE model described 365 in this document. Use of a formal language can help to enforce 366 consistency and logical compatibility among LFBs. A full 367 specification will be written using such a data modeling language. 368 The formal definition of the LFB classes may facilitate the eventual 369 automation of some of the code generation process and the functional 370 validation of arbitrary LFB topologies. These class definitions form 371 the LFB Library. Documents which describe LFB Classes are therefore 372 referred to as LFB Library documents. 374 Human readability was the most important factor considered when 375 selecting the specification language, whereas encoding, decoding and 376 transmission performance was not a selection factor. The encoding 377 method for over the wire transport is not dependent on the 378 specification language chosen and is outside the scope of this 379 document and up to the ForCES protocol to define. 381 XML is chosen as the specification language in this document, because 382 XML has the advantage of being both human and machine readable with 383 widely available tools support. This document uses XML Schema to 384 define the structure of the LFB Library documents, as defined in [9] 385 and [10] and [11]. While these LFB Class definitions are not sent in 386 the ForCES protocol, these definitions comply with the 387 recommendations in RFC3470 [9] on the use of XML in IETF protocols. 389 2.5. Document Structure 391 Section 3 provides a conceptual overview of the FE model, laying the 392 foundation for the more detailed discussion and specifications in the 393 sections that follow. Section 4 and Section 5 constitute the core of 394 the FE model, detailing the two major aspects of the FE model: a 395 general LFB model and a definition of the FE Object LFB, with its 396 components, including FE capabilities and LFB topology information. 398 Section 6 directly addresses the model requirements imposed by the 399 ForCES requirements defined in RFC3654 [4] while Section 7 explains 400 how the FE model should be used in the ForCES protocol. 402 3. ForCES Model Concepts 404 Some of the important ForCES concepts used throughout this document 405 are introduced in this section. These include the capability and 406 state abstraction, the FE and LFB model construction, and the unique 407 addressing of the different model structures. Details of these 408 aspects are described in Section 4 and Section 5. The intent of this 409 section is to discuss these concepts at the high level and lay the 410 foundation for the detailed description in the following sections. 412 The ForCES FE model includes both a capability and a state 413 abstraction. 415 o The FE/LFB capability model describes the capabilities and 416 capacities of an FE/LFB by specifying the variation in functions 417 supported and any limitations. Capacity describes the limits of 418 specific components (example would be a table size limit). 420 o The state model describes the current state of the FE/LFB, that 421 is, the instantaneous values or operational behavior of the FE/ 422 LFB. 424 Section 3.1 explains the difference between a capability model and a 425 state model, and describes how the two can be combined in the FE 426 model. 428 The ForCES model construction laid out in this document allows an FE 429 to provide information about its structure for operation. This can 430 be thought of as FE level information and information about the 431 individual instances of LFBs provided by the FE. 433 o The ForCES model includes the constructions for defining the class 434 of logical function blocks (LFBS) that an FE may support. These 435 classes are defined in this and other documents. The definition 436 of such a class provides the information content for monitoring 437 and controlling instances of the LFB class for ForCES purposes. 438 Each LFB model class formally defines the operational LFB 439 components, LFB capabilities, and LFB events. Essentially, 440 Section 3.2 introduces the concept of LFBs as the basic functional 441 building blocks in the ForCES model. 443 o The FE model also provides the construction necessary to monitor 444 and control the FE as a whole for ForCES purposes. For 445 consistency of operation and simplicity, this information is 446 represented as an LFB, the FE Object LFB class and a singular LFB 447 instance of that class, defined using the LFB model. The FE 448 Object class defines the components to provide information at the 449 FE level, particularly the capabilities of the FE at a coarse 450 level, i.e. not all possible capabilities nor all details about 451 the capabilities of the FE. Part of the FE level information is 452 the LFB topology, which expresses the logical inter-connection 453 between the LFB instances along the datapath(s) within the FE. 454 Section 3.3 discusses the LFB topology. The FE Object also 455 includes information about what LFB classes the FE can support. 457 The ForCES model allows for unique identification of the different 458 constructs it defines. This includes identification of the LFB 459 classes, and of LFB instances within those classes, as well as 460 identification of components within those instances. 462 The ForCES Protocol [2] encapsulates target address(es) to eventually 463 get to a fine-grained entity being referenced by the CE. The 464 addressing hierarchy is broken into the following: 466 o An FE is uniqueuely identified by a 32 bit FEID. 468 o Each Class of LFB is uniquely identified by a 32 bit LFB ClassID. 469 The LFB ClassIDs are global within the Network Element and may be 470 issued by IANA. 472 o Within an FE, there can be multiple instances of each LFB class. 473 Each LFB Class instance is identified by a 32 bit identifier which 474 is unique within a particular LFB class on that FE. 476 o All the components within an LFB instance are further defined 477 using 32 bit identifiers. 479 Refer to Section 3.3 for more details where we go into details on 480 addressing. 482 3.1. ForCES Capability Model and State Model 484 Capability and state modelling applies to both the FE and LFB 485 abstraction. 487 Figure 1 shows the concepts of FE state, capabilities and 488 configuration in the context of CE-FE communication via the ForCES 489 protocol. 491 +-------+ +-------+ 492 | | FE capabilities: what it can/cannot do. | | 493 | |<-----------------------------------------| | 494 | | | | 495 | CE | FE state: what it is now. | FE | 496 | |<-----------------------------------------| | 497 | | | | 498 | | FE configuration: what it should be. | | 499 | |----------------------------------------->| | 500 +-------+ +-------+ 502 Figure 1: Illustration of FE capabilities, state and configuration 503 exchange in the context of CE-FE communication via ForCES. 505 3.1.1. FE Capability Model and State Model 507 Conceptually, the FE capability model tells the CE which states are 508 allowed on an FE, with capacity information indicating certain 509 quantitative limits or constraints. Thus, the CE has general 510 knowledge about configurations that are applicable to a particular 511 FE. 513 3.1.1.1. FE Capability Model 515 The FE capability model may be used to describe an FE at a coarse 516 level. For example, an FE may be defined as follows: 518 o the FE can handle IPv4 and IPv6 forwarding; 520 o the FE can perform classification based on the following fields: 521 source IP address, destination IP address, source port number, 522 destination port number, etc; 524 o the FE can perform metering; 526 o the FE can handle up to N queues (capacity); 528 o the FE can add and remove encapsulating headers of types including 529 IPsec, GRE, L2TP. 531 While one could try to build an object model to fully represent the 532 FE capabilities, other efforts found this approach to be a 533 significant undertaking. The main difficulty arises in describing 534 detailed limits, such as the maximum number of classifiers, queues, 535 buffer pools, and meters that the FE can provide. We believe that a 536 good balance between simplicity and flexibility can be achieved for 537 the FE model by combining coarse level capability reporting with an 538 error reporting mechanism. That is, if the CE attempts to instruct 539 the FE to set up some specific behavior it cannot support, the FE 540 will return an error indicating the problem. Examples of similar 541 approaches include DiffServ PIB RFC3317 [6] and Framework PIB RFC3318 542 [7]. 544 3.1.1.2. FE State Model 546 The FE state model presents the snapshot view of the FE to the CE. 547 For example, using an FE state model, an FE may be described to its 548 corresponding CE as the following: 550 o on a given port, the packets are classified using a given 551 classification filter; 553 o the given classifier results in packets being metered in a certain 554 way and then marked in a certain way; 556 o the packets coming from specific markers are delivered into a 557 shared queue for handling, while other packets are delivered to a 558 different queue; 560 o a specific scheduler with specific behavior and parameters will 561 service these collected queues. 563 3.1.1.3. LFB Capability and State Model 565 Both LFB Capability and State information is defined formally using 566 LFB modelling XML schema. 568 Capability information at the LFB level is an integral part of the 569 LFB model and provides for powerful semantics. For example, when 570 certain features of an LFB class are optional, the CE MUST be able to 571 determine whether those optional features are supported by a given 572 LFB instance. The schema for the definition of LFB classes provides 573 a means for identifying such components. 575 State information is defined formally using LFB components 576 constructs. 578 3.1.2. Relating LFB and FE Capability and State Model 580 Capability information at the FE level describes the LFB classes that 581 the FE can instantiate, the number of instances of each that can be 582 created, the topological (linkage) limitations between these LFB 583 instances, etc. Section 5 defines the FE level components including 584 capability information. Since all information is represented as 585 LFBs, this is provided by a single instance of the FE Object LFB 586 Class. By using a single instance with a known LFB Class and a known 587 instance identification, the ForCES protocol can allow a CE to access 588 this information whenever it needs to, including while the CE is 589 establishing the control of the FE. 591 Once the FE capability is described to the CE, the FE state 592 information can be represented by two levels. The first level is the 593 logically separable and distinct packet processing functions, called 594 LFBs. The second level of information describes how these individual 595 LFBs are ordered and placed along the datapath to deliver a complete 596 forwarding plane service. The interconnection and ordering of the 597 LFBs is called LFB Topology. Section 3.2 discusses high level 598 concepts around LFBs, whereas Section 3.3 discusses LFB topology 599 issues. This topology information is represented as components of 600 the FE Object LFB instance, to allow the CE to fetch and manipulate 601 this. 603 3.2. Logical Functional Block (LFB) Modeling 605 Each LFB performs a well-defined action or computation on the packets 606 passing through it. Upon completion of its prescribed function, 607 either the packets are modified in certain ways (e.g., decapsulator, 608 marker), or some results are generated and stored, often in the form 609 of metadata (e.g., classifier). Each LFB typically performs a single 610 action. Classifiers, shapers and meters are all examples of such 611 LFBs. Modeling LFBs at such a fine granularity allows us to use a 612 small number of LFBs to express the higher-order FE functions (such 613 as an IPv4 forwarder) precisely, which in turn can describe more 614 complex networking functions and vendor implementations of software 615 and hardware. These LFBs will be defined in detail in one or more 616 documents. 618 It is also the case that LFBs may exist in order to provide a set of 619 components for control of FE operation by the CE (i.e. a locus of 620 control), without tying that control to specific packets or specific 621 parts of the data path. An example of such an LFB is the FE Object 622 which provides the CE with information about the FE as a whole, and 623 allows the FE to control some aspects of the FE, such as the datapath 624 itself. Such FEs will not have the packet oriented properties 625 described in this section. 627 An LFB can have one or more inputs. Each input takes a pair of a 628 packet and its associated metadata. Depending upon the LFB input 629 port definition, the packet or the metadata may be allowed to be 630 empty (or equivalently to not be provided.) At least one of the two 631 must be non-empty, or there is no input. The LFB processes the 632 input, and produces one or more outputs, each of which is a pair of a 633 packet and its associated metadata. Again, depending upon the LFB 634 output port definition, either the packet or the metadata may be 635 allowed to be empty (or equivalently to be absent.) Metadata is 636 control information, typically associated with a packet, used in the 637 network processing device (router, switch, etc.) and is passed from 638 one LFB to the next, but is not sent across the network. In general, 639 multiple LFBs are contained in one FE, as shown in Figure 2, and all 640 the LFBs share the same ForCES protocol termination point that 641 implements the ForCES protocol logic and maintains the communication 642 channel to and from the CE. 644 +-----------+ 645 | CE | 646 +-----------+ 647 ^ 648 | Fp reference point 649 | 650 +--------------------------|-----------------------------------+ 651 | FE | | 652 | v | 653 | +----------------------------------------------------------+ | 654 | | ForCES protocol | | 655 | | termination point | | 656 | +----------------------------------------------------------+ | 657 | ^ ^ | 658 | : : Internal control | 659 | : : | 660 | +---:----------+ +---:----------| | 661 | | :LFB1 | | : LFB2 | | 662 | =====>| v |============>| v |======>...| 663 | Inputs| +----------+ |Outputs | +----------+ | | 664 | (P,M) | |Components| |(P',M') | |Components| |(P",M") | 665 | | +----------+ | | +----------+ | | 666 | +--------------+ +--------------+ | 667 | | 668 +--------------------------------------------------------------+ 670 Figure 2: Generic LFB Diagram 672 An LFB, as shown in Figure 2, may have inputs, outputs and components 673 that can be queried and manipulated by the CE via an Fp reference 674 point (defined in RFC3746 [5]) and the ForCES protocol termination 675 point. The horizontal axis is in the forwarding plane for connecting 676 the inputs and outputs of LFBs within the same FE. The vertical axis 677 between the CE and the FE denotes the Fp reference point where 678 bidirectional communication between the CE and FE occurs: the CE to 679 FE communication is for configuration, control, and packet injection, 680 while FE to CE communication is used for packet redirection to the 681 control plane, reporting of monitoring and accounting information, 682 reporting of errors, etc. Note that the interaction between the CE 683 and the LFB is only abstract and indirect. The result of such an 684 interaction is for the CE to manipulate the components of the LFB 685 instances. 687 A namespace is used to associate a unique name and ID with each LFB 688 class. The namespace MUST be extensible so that a new LFB class can 689 be added later to accommodate future innovation in the forwarding 690 plane. 692 LFB operation is specified in the model to allow the CE to understand 693 the behavior of the forwarding datapath. For instance, the CE must 694 understand at what point in the datapath the IPv4 header TTL is 695 decremented. That is, the CE needs to know if a control packet could 696 be delivered to it either before or after this point in the datapath. 697 In addition, the CE MUST understand where and what type of header 698 modifications (e.g., tunnel header append or strip) are performed by 699 the FEs. Further, the CE MUST verify that the various LFBs along a 700 datapath within an FE are compatible to link together. 702 There is value to vendors if the operation of LFB classes can be 703 expressed in sufficient detail so that physical devices implementing 704 different LFB functions can be integrated easily into an FE design. 705 Therefore, a semi-formal specification is needed; that is, a text 706 description of the LFB operation (human readable), but sufficiently 707 specific and unambiguous to allow conformance testing and efficient 708 design, so that interoperability between different CEs and FEs can be 709 achieved. 711 The LFB class model specifies information such as: 713 o number of inputs and outputs (and whether they are configurable) 715 o metadata read/consumed from inputs; 717 o metadata produced at the outputs; 719 o packet type(s) accepted at the inputs and emitted at the outputs; 721 o packet content modifications (including encapsulation or 722 decapsulation); 724 o packet routing criteria (when multiple outputs on an LFB are 725 present); 727 o packet timing modifications; 728 o packet flow ordering modifications; 730 o LFB capability information components; 732 o events that can be detected by the LFB, with notification to the 733 CE; 735 o LFB operational components, etc. 737 Section 4 of this document provides a detailed discussion of the LFB 738 model with a formal specification of LFB class schema. The rest of 739 Section 3.2 only intends to provide a conceptual overview of some 740 important issues in LFB modeling, without covering all the specific 741 details. 743 3.2.1. LFB Outputs 745 An LFB output is a conceptual port on an LFB that can send 746 information to another LFB. The information is typically a packet 747 and its associated metadata, although in some cases it might consist 748 of only metadata. 750 A single LFB output can be connected to only one LFB input. This is 751 required to make the packet flow through the LFB topology 752 unambiguously. 754 Some LFBs will have a single output, as depicted in Figure 3.a. 756 +---------------+ +-----------------+ 757 | | | | 758 | | | OUT +--> 759 ... OUT +--> ... | 760 | | | EXCEPTIONOUT +--> 761 | | | | 762 +---------------+ +-----------------+ 764 a. One output b. Two distinct outputs 766 +---------------+ +-----------------+ 767 | | | EXCEPTIONOUT +--> 768 | OUT:1 +--> | | 769 ... OUT:2 +--> ... OUT:1 +--> 770 | ... +... | OUT:2 +--> 771 | OUT:n +--> | ... +... 772 +---------------+ | OUT:n +--> 773 +-----------------+ 775 c. One output group d. One output and one output group 777 Figure 3: Examples of LFBs with various output combinations. 779 To accommodate a non-trivial LFB topology, multiple LFB outputs are 780 needed so that an LFB class can fork the datapath. Two mechanisms 781 are provided for forking: multiple singleton outputs and output 782 groups, which can be combined in the same LFB class. 784 Multiple separate singleton outputs are defined in an LFB class to 785 model a pre-determined number of semantically different outputs. 786 That is, the LFB class definition MUST include the number of outputs, 787 implying the number of outputs is known when the LFB class is 788 defined. Additional singleton outputs cannot be created at LFB 789 instantiation time, nor can they be created on the fly after the LFB 790 is instantiated. 792 For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one 793 output (OUT) to send those packets for which the LPM look-up was 794 successful, passing a META_ROUTEID as metadata; and have another 795 output (EXCEPTIONOUT) for sending exception packets when the LPM 796 look-up failed. This example is depicted in Figure 3.b. Packets 797 emitted by these two outputs not only require different downstream 798 treatment, but they are a result of two different conditions in the 799 LFB and each output carries different metadata. This concept assumes 800 the number of distinct outputs is known when the LFB class is 801 defined. For each singleton output, the LFB class definition defines 802 the types of frames and metadata the output emits. 804 An output group, on the other hand, is used to model the case where a 805 flow of similar packets with an identical set of metadata needs to be 806 split into multiple paths. In this case, the number of such paths is 807 not known when the LFB class is defined because it is not an inherent 808 property of the LFB class. An output group consists of a number of 809 outputs, called the output instances of the group, where all output 810 instances share the same frame and metadata emission definitions (see 811 Figure 3.c). Each output instance can connect to a different 812 downstream LFB, just as if they were separate singleton outputs, but 813 the number of output instances can differ between LFB instances of 814 the same LFB class. The class definition may include a lower and/or 815 an upper limit on the number of outputs. In addition, for 816 configurable FEs, the FE capability information may define further 817 limits on the number of instances in specific output groups for 818 certain LFBs. The actual number of output instances in a group is an 819 component of the LFB instance, which is read-only for static 820 topologies, and read-write for dynamic topologies. The output 821 instances in a group are numbered sequentially, from 0 to N-1, and 822 are addressable from within the LFB. The LFB has a built-in 823 mechanism to select one specific output instance for each packet. 824 This mechanism is described in the textual definition of the class 825 and is typically configurable via some attributes of the LFB. 827 For example, consider a redirector LFB, whose sole purpose is to 828 direct packets to one of N downstream paths based on one of the 829 metadata associated with each arriving packet. Such an LFB is fairly 830 versatile and can be used in many different places in a topology. 831 For example, a redirector can be used to divide the data path into an 832 IPv4 and an IPv6 path based on a FRAMETYPE metadata (N=2), or to fork 833 into color specific paths after metering using the COLOR metadata 834 (red, yellow, green; N=3), etc. 836 Using an output group in the above LFB class provides the desired 837 flexibility to adapt each instance of this class to the required 838 operation. The metadata to be used as a selector for the output 839 instance is a property of the LFB. For each packet, the value of the 840 specified metadata may be used as a direct index to the output 841 instance. Alternatively, the LFB may have a configurable selector 842 table that maps a metadatum value to output instance. 844 Note that other LFBs may also use the output group concept to build 845 in similar adaptive forking capability. For example, a classifier 846 LFB with one input and N outputs can be defined easily by using the 847 output group concept. Alternatively, a classifier LFB with one 848 singleton output in combination with an explicit N-output re- 849 director LFB models the same processing behavior. The decision of 850 whether to use the output group model for a certain LFB class is left 851 to the LFB class designers. 853 The model allows the output group to be combined with other singleton 854 output(s) in the same class, as demonstrated in Figure 3.d. The LFB 855 here has two types of outputs, OUT, for normal packet output, and 856 EXCEPTIONOUT for packets that triggered some exception. The normal 857 OUT has multiple instances, thus, it is an output group. 859 In summary, the LFB class may define one output, multiple singleton 860 outputs, one or more output groups, or a combination thereof. 861 Multiple singleton outputs should be used when the LFB must provide 862 for forking the datapath and at least one of the following conditions 863 hold: 865 o the number of downstream directions is inherent from the 866 definition of the class and hence fixed; 868 o the frame type and set of metadata emitted on any of the outputs 869 are substantially different from what is emitted on the other 870 outputs (i.e., they cannot share frame-type and metadata 871 definitions). 873 An output group is appropriate when the LFB must provide for forking 874 the datapath and at least one of the following conditions hold: 876 o the number of downstream directions is not known when the LFB 877 class is defined; 879 o the frame type and set of metadata emitted on these outputs are 880 sufficiently similar or, ideally, identical, such they can share 881 the same output definition. 883 3.2.2. LFB Inputs 885 An LFB input is a conceptual port on an LFB on which the LFB can 886 receive information from other LFBs. The information is typically a 887 packet and associated metadata, although in some cases it might 888 consist of only metadata. 890 For LFB instances that receive packets from more than one other LFB 891 instance (fan-in) there are three ways to model fan-in, all supported 892 by the LFB model and can all be combined in the same LFB: 894 o Implicit multiplexing via a single input 896 o Explicit multiplexing via multiple singleton inputs 897 o Explicit multiplexing via a group of inputs (input group) 899 The simplest form of multiplexing uses a singleton input (Figure 4 900 .a). Most LFBs will have only one singleton input. Multiplexing 901 into a single input is possible because the model allows more than 902 one LFB output to connect to the same LFB input. This property 903 applies to any LFB input without any special provisions in the LFB 904 class. Multiplexing into a single input is applicable when the 905 packets from the upstream LFBs are similar in frame-type and 906 accompanying metadata, and require similar processing. Note that 907 this model does not address how potential contention is handled when 908 multiple packets arrive simultaneously. If contention handling needs 909 to be explicitly modeled, one of the other two modeling solutions 910 must be used. 912 The second method to model fan-in uses individually defined singleton 913 inputs (Figure 4.b). This model is meant for situations where the 914 LFB needs to handle distinct types of packet streams, requiring 915 input-specific handling inside the LFB, and where the number of such 916 distinct cases is known when the LFB class is defined. For example, 917 a Layer 2 Decapsulation/Encapsulation LFB may have two inputs, one 918 for receiving Layer 2 frames for decapsulation, and one for receiving 919 Layer 3 frames for encapsulation. This LFB type expects different 920 frames (L2 vs. L3) at its inputs, each with different sets of 921 metadata, and would thus apply different processing on frames 922 arriving at these inputs. This model is capable of explicitly 923 addressing packet contention by defining how the LFB class handles 924 the contending packets. 926 +--------------+ +------------------------+ 927 | LFB X +---+ | | 928 +--------------+ | | | 929 | | | | 930 +--------------+ v | | 931 | LFB Y +---+-->|input Meter LFB | 932 +--------------+ ^ | | 933 | | | | 934 +--------------+ | | | 935 | LFB Z |---+ | | 936 +--------------+ +------------------------+ 938 (a) An LFB connects with multiple upstream LFBs via a single input. 940 +--------------+ +------------------------+ 941 | LFB X +---+ | | 942 +--------------+ +-->|layer2 | 943 +--------------+ | | 944 | LFB Y +------>|layer3 LFB | 945 +--------------+ +------------------------+ 947 (b) An LFB connects with multiple upstream LFBs via two separate 948 singleton inputs. 950 +--------------+ +------------------------+ 951 | Queue LFB #1 +---+ | | 952 +--------------+ | | | 953 | | | 954 +--------------+ +-->|in:0 \ | 955 | Queue LFB #2 +------>|in:1 | input group | 956 +--------------+ |... | | 957 +-->|in:N-1 / | 958 ... | | | 959 +--------------+ | | | 960 | Queue LFB #N |---+ | Scheduler LFB | 961 +--------------+ +------------------------+ 963 (c) A Scheduler LFB uses an input group to differentiate which queue 964 LFB packets are coming from. 966 Figure 4: Examples of LFBs with various input combinations. 968 The third method to model fan-in uses the concept of an input group. 969 The concept is similar to the output group introduced in the previous 970 section and is depicted in Figure 4.c. An input group consists of a 971 number of input instances, all sharing the properties (same frame and 972 metadata expectations). The input instances are numbered from 0 to 973 N-1. From the outside, these inputs appear as normal inputs, i.e., 974 any compatible upstream LFB can connect its output to one of these 975 inputs. When a packet is presented to the LFB at a particular input 976 instance, the index of the input where the packet arrived is known to 977 the LFB and this information may be used in the internal processing. 978 For example, the input index can be used as a table selector, or as 979 an explicit precedence selector to resolve contention. As with 980 output groups, the number of input instances in an input group is not 981 defined in the LFB class. However, the class definition may include 982 restrictions on the range of possible values. In addition, if an FE 983 supports configurable topologies, it may impose further limitations 984 on the number of instances for a particular port group(s) of a 985 particular LFB class. Within these limitations, different instances 986 of the same class may have a different number of input instances. 987 The number of actual input instances in the group is a component 988 defined in the LFB class, which is read-only for static topologies, 989 and is read-write for configurable topologies. 991 As an example for the input group, consider the Scheduler LFB 992 depicted in Figure 4.c. Such an LFB receives packets from a number 993 of Queue LFBs via a number of input instances, and uses the input 994 index information to control contention resolution and scheduling. 996 In summary, the LFB class may define one input, multiple singleton 997 inputs, one or more input groups, or a combination thereof. Any 998 input allows for implicit multiplexing of similar packet streams via 999 connecting multiple outputs to the same input. Explicit multiple 1000 singleton inputs are useful when either the contention handling must 1001 be handled explicitly, or when the LFB class must receive and process 1002 a known number of distinct types of packet streams. An input group 1003 is suitable when contention handling must be modeled explicitly, but 1004 the number of inputs is not inherent from the class (and hence is not 1005 known when the class is defined), or when it is critical for LFB 1006 operation to know exactly on which input the packet was received. 1008 3.2.3. Packet Type 1010 When LFB classes are defined, the input and output packet formats 1011 (e.g., IPv4, IPv6, Ethernet, etc.) MUST be specified. These are the 1012 types of packets that a given LFB input is capable of receiving and 1013 processing, or that a given LFB output is capable of producing. This 1014 model requires that distinct packet types be uniquely labeled with a 1015 symbolic name and/or ID. 1017 Note that each LFB has a set of packet types that it operates on, but 1018 does not care whether the underlying implementation is passing a 1019 greater portion of the packets. For example, an IPv4 LFB might only 1020 operate on IPv4 packets, but the underlying implementation may or may 1021 not be stripping the L2 header before handing it over. Whether such 1022 processing is happening or not is opaque to the CE. 1024 3.2.4. Metadata 1026 Metadata is state that is passed from one LFB to another alongside a 1027 packet. The metadata passed with the packet assists subsequent LFBs 1028 to process that packet. 1030 The ForCES model defines metadata as precise atomic definitions in 1031 the form of label, value pairs. 1033 The ForCES model provides to the authors of LFB classes a way to 1034 formally define how to achieve metadata creation, modification, 1035 reading, as well as consumption(deletion). 1037 Inter-FE metadata, i.e, metadata crossing FEs, while likely 1038 semantically similar to this metadata, is out of scope for this 1039 document. 1041 Section 4 has informal details on metadata. 1043 3.2.4.1. Metadata lifecycle within the ForCES model 1045 Each metadata is modeled as a pair, where the label 1046 identifies the type of information, (e.g., "color"), and its value 1047 holds the actual information (e.g., "red"). The tag here is shown as 1048 a textual label, but it can be replaced or associated with a unique 1049 numeric value (identifier). 1051 To ensure inter-operability between LFBs, the LFB class specification 1052 must define what metadata the LFB class "reads" or "consumes" on its 1053 input(s) and what metadata it "produces" on its output(s). For 1054 maximum extensibility, this definition should neither specify which 1055 LFBs the metadata is expected to come from for a consumer LFB, nor 1056 which LFBs are expected to consume metadata for a given producer LFB. 1058 3.2.4.2. Metadata Production and Consumption 1060 For a given metadata on a given packet path, there MUST be at least 1061 one producer LFB that creates that metadata and SHOULD be at least 1062 one consumer LFB that needs that metadata. 1064 In the ForCES model, the producer and consumer LFBs of a metadatum 1065 are not required to be adjacent. In addition, there may be multiple 1066 producers and consumers for the same metadata. When a packet path 1067 involves multiple producers of the same metadata, then subsequent 1068 producers overwrite that metadata value. 1070 The metadata that is produced by an LFB is specified by the LFB class 1071 definition on a per-output-port-group basis. A producer may always 1072 generate the metadata on the port group, or may generate it only 1073 under certain conditions. We call the former an "unconditional" 1074 metadata, whereas the latter is a "conditional" metadata. In the 1075 case of conditional metadata, it should be possible to determine from 1076 the definition of the LFB when a "conditional" metadata is produced. 1077 The consumer behavior of an LFB, that is, the metadata that the LFB 1078 needs for its operation, is defined in the LFB class definition on a 1079 per-input-port-group basis. An input port group may "require" a 1080 given metadata, or may treat it as "optional" information. In the 1081 latter case, the LFB class definition MUST explicitly define what 1082 happens if an optional metadata is not provided. One approach is to 1083 specify a default value for each optional metadata, and assume that 1084 the default value is used if the metadata is not provided with the 1085 packet. 1087 When specifying the metadata tags, some harmonization effort must be 1088 made so that the producer LFB class uses the same tag as its intended 1089 consumer(s), or vice versa. 1091 3.2.4.3. LFB Operations on Metadata 1093 When the packet is processed by an LFB (i.e., between the time it is 1094 received and forwarded by the LFB), the LFB may perform read, write, 1095 and/or consume operations on any active metadata associated with the 1096 packet. If the LFB is considered to be a black box, one of the 1097 following operations is performed on each active metadata. 1099 * IGNORE: ignores and forwards the metadata 1101 * READ: reads and forwards the metadata 1103 * READ/RE-WRITE: reads, over-writes and forwards the metadata 1105 * WRITE: writes and forwards the metadata (can also be used to 1106 create new metadata) 1108 * READ-AND-CONSUME: reads and consumes the metadata 1109 * CONSUME consumes metadata without reading 1111 The last two operations terminate the life-cycle of the metadata, 1112 meaning that the metadata is not forwarded with the packet when the 1113 packet is sent to the next LFB. 1115 In the ForCES model, a new metadata is generated by an LFB when the 1116 LFB applies a WRITE operation to a metadatum type that was not 1117 present when the packet was received by the LFB. Such implicit 1118 creation may be unintentional by the LFB, that is, the LFB may apply 1119 the WRITE operation without knowing or caring if the given metadata 1120 existed or not. If it existed, the metadata gets over-written; if it 1121 did not exist, the metadata is created. 1123 For LFBs that insert packets into the model, WRITE is the only 1124 meaningful metadata operation. 1126 For LFBs that remove the packet from the model, they may either READ- 1127 AND-CONSUME (read) or CONSUME (ignore) each active metadata 1128 associated with the packet. 1130 3.2.5. LFB Events 1132 During operation, various conditions may occur that can be detected 1133 by LFBs. Examples range from link failure or restart to timer 1134 expiration in special purpose LFBs. The CE may wish to be notified 1135 of the occurrence of such events. The PL protocol provides for such 1136 notifications. 1138 Events are declared in the LFB class definition. The LFB event 1139 declaration constitutes: 1141 o a unique 32 bit identifier. 1143 o An LFB component which is used to trigger the event. This entity 1144 is known as the event target. 1146 o A condition that will happen to the event target that will result 1147 in a generation of an event to the CE. Example of a condition 1148 include something getting created, deleted, config change, etc. 1150 o What should be reported to the CE by the FE if the declared 1151 condition is met. 1153 The declaration of an event within an LFB class essentially defines 1154 what part of the LFB component(s) need to be monitored for events, 1155 what condition on the LFB monitored LFB component an FE should detect 1156 to trigger such an event, and what to report to the CE when the event 1157 is triggered. 1159 While events may be declared by the LFB class definition, runtime 1160 activity is controlled using built-in event properties using LFB 1161 component Properties (discussed in Section 3.2.6). A CE subscribes 1162 to the events on an LFB class instance by setting an event property 1163 for subscription. Each event has a subscription property which is by 1164 default off. A CE wishing to receive a specific event needs to turn 1165 on the subscription property at runtime. 1167 Event properties also provide semantics for runtime event filtering. 1168 A CE may set an event property to further suppress subscribed to 1169 events. The LFB model defines such filters to include threshold 1170 values, hysteris, time intervals, number of events, etc. 1172 The reports with events are designed to allow for the common, closely 1173 related information that the CE can be strongly expected to need to 1174 react to the event. It is not intended to carry information the CE 1175 already has, nor large volumes of information, nor information 1176 related in complex fashions. 1178 From a conceptual point of view, at runtime, event processing is 1179 split into: 1181 1. detection of something happening to the (declared during LFB 1182 class definition) event target. Processing the next step happens 1183 if the CE subscribed (at runtime) to the event. 1185 2. checking of the (declared during LFB class definition) condition 1186 on the LFB event target. If the condition is met, proceed with 1187 the next step. 1189 3. checking (runtime set) event filters if they exist to see if the 1190 event should be reported or suppressed. If the event is to be 1191 reported proceed to the next step. 1193 4. Submitting of the declared report to the CE. 1195 Section 4.7.6 discusses events in more details. 1197 3.2.6. Component Properties 1199 LFBs and structures are made up of components, containing the 1200 information that the CE needs to see and/or change about the 1201 functioning of the LFB. These Components, as described in detail in 1202 Section 4.7, may be basic values, complex structures (containing 1203 multiple Components themselves, each of which can be values, 1204 structures, or tables), or tables (which contain values, structures 1205 or tables). Some of these Components are optional. Components may 1206 be readable or writeable at the discretion of the FE implementation. 1207 The CE needs to know these properties. Additionally, certain kinds 1208 of Components (arrays / tables, aliases, and events as of this 1209 writing) have additional property information that the CE may need to 1210 read or write. This model defines the structure of the property 1211 information for all defined data types. 1213 Section 4.8 describes properties in more details. 1215 3.2.7. LFB Versioning 1217 LFB class versioning is a method to enable incremental evolution of 1218 LFB classes. In general, an FE is not allowed to contain an LFB 1219 instance for more than one version of a particular class. 1220 Inheritance (discussed next in Section 3.2.6) has special rules. If 1221 an FE datapath model containing an LFB instance of a particular class 1222 C also simultaneously contains an LFB instance of a class C' 1223 inherited from class C; C could have a different version than C'. 1225 LFB class versioning is supported by requiring a version string in 1226 the class definition. CEs may support multiple versions of a 1227 particular LFB class to provide backward compatibility, but FEs MUST 1228 NOT support more than one version of a particular class. 1230 Versioning is not restricted to making backwards compatible changes. 1231 It is specifically expected to be used to make changes that cannot be 1232 represented by inheritance. Often this will be to correct errors, 1233 and hence may not be backwards compatible. It may also be used to 1234 remove components which are not considered useful (particularly if 1235 they were previously mandatory, and hence were an implementation 1236 impediment.) 1238 3.2.8. LFB Inheritance 1240 LFB class inheritance is supported in the FE model as a method to 1241 define new LFB classes. This also allows FE vendors to add vendor- 1242 specific extensions to standardized LFBs. An LFB class specification 1243 MUST specify the base class and version number it inherits from (the 1244 default is the base LFB class). Multiple inheritance is not allowed, 1245 however, to avoid unnecessary complexity. 1247 Inheritance should be used only when there is significant reuse of 1248 the base LFB class definition. A separate LFB class should be 1249 defined if little or no reuse is possible between the derived and the 1250 base LFB class. 1252 An interesting issue related to class inheritance is backward 1253 compatibility between a descendant and an ancestor class. Consider 1254 the following hypothetical scenario where a standardized LFB class 1255 "L1" exists. Vendor A builds an FE that implements LFB "L1" and 1256 vendor B builds a CE that can recognize and operate on LFB "L1". 1257 Suppose that a new LFB class, "L2", is defined based on the existing 1258 "L1" class by extending its capabilities incrementally. Let us 1259 examine the FE backward compatibility issue by considering what would 1260 happen if vendor B upgrades its FE from "L1" to "L2" and vendor C's 1261 CE is not changed. The old L1-based CE can interoperate with the new 1262 L2-based FE if the derived LFB class "L2" is indeed backward 1263 compatible with the base class "L1". 1265 The reverse scenario is a much less problematic case, i.e., when CE 1266 vendor B upgrades to the new LFB class "L2", but the FE is not 1267 upgraded. Note that as long as the CE is capable of working with 1268 older LFB classes, this problem does not affect the model; hence we 1269 will use the term "backward compatibility" to refer to the first 1270 scenario concerning FE backward compatibility. 1272 Backward compatibility can be designed into the inheritance model by 1273 constraining LFB inheritance to require the derived class be a 1274 functional superset of the base class (i.e. the derived class can 1275 only add functions to the base class, but not remove functions). 1276 Additionally, the following mechanisms are required to support FE 1277 backward compatibility: 1279 1. When detecting an LFB instance of an LFB type that is unknown to 1280 the CE, the CE MUST be able to query the base class of such an 1281 LFB from the FE. 1283 2. The LFB instance on the FE SHOULD support a backward 1284 compatibility mode (meaning the LFB instance reverts itself back 1285 to the base class instance), and the CE SHOULD be able to 1286 configure the LFB to run in such a mode. 1288 3.3. ForCES Model Addressing 1290 Figure 5 demonstrates the abstraction of the different ForCES model 1291 entities. The ForCES protocol provides the mechanism to uniquely 1292 identify any of the LFB Class instance components. 1294 FE Address = FE01 1295 +--------------------------------------------------------------+ 1296 | | 1297 | +--------------+ +--------------+ | 1298 | | LFB ClassID 1| |LFB ClassID 91| | 1299 | | InstanceID 3 |============>|InstanceID 3 |======>... | 1300 | | +----------+ | | +----------+ | | 1301 | | |Components| | | |Components| | | 1302 | | +----------+ | | +----------+ | | 1303 | +--------------+ +--------------+ | 1304 | | 1305 +--------------------------------------------------------------+ 1307 Figure 5: FE Entity Hierarchy 1309 At the top of the addressing hierachy is the FE identifier. In the 1310 example above, the 32-bit FE identifier is illustrated with the 1311 mnemonic FE01. The next 32-bit entity selector is the LFB ClassID. 1312 In the illustration above, two LFB classes with identifiers 1 and 91 1313 are demonstrated. The example above further illustrates one instance 1314 of each of the two classes. The scope of the 32-bit LFB class 1315 instance identifier is valid only within the LFB class. To emphasize 1316 that point, each of class 1 and 91 has an instance of 3. 1318 Using the described addressing scheme, a message could be sent to 1319 address FE01, LFB ClassID 1, LFB InstanceID 3, utilizing the ForCES 1320 protocol. However, to be effective, such a message would have to 1321 target entities within an LFB. These entities could be carrying 1322 state, capability, etc. These are further illustrated in Figure 6 1323 below. 1325 LFB Class ID 1,InstanceID 3 Components 1326 +-------------------------------------+ 1327 | | 1328 | LFB ComponentID 1 | 1329 | +----------------------+ | 1330 | | | | 1331 | +----------------------+ | 1332 | | 1333 | LFB ComponentID 31 | 1334 | +----------------------+ | 1335 | | | | 1336 | +----------------------+ | 1337 | | 1338 | LFB ComponentID 51 | 1339 | +----------------------+ | 1340 | | LFB ComponentID 89 | | 1341 | | +-----------------+ | | 1342 | | | | | | 1343 | | +-----------------+ | | 1344 | +----------------------+ | 1345 | | 1346 | | 1347 +-------------------------------------+ 1349 Figure 6: LFB Hierarchy 1351 Figure 6 zooms into the components carried by LFB Class ID 1, LFB 1352 InstanceID 3 from Figure 5. 1354 The example shows three components with 32-bit component identifiers 1355 1, 31, and 51. LFB ComponentID 51 is a complex structure 1356 encapsulating within it an entity with LFB ComponentID 89. LFB 1357 ComponentID 89 could be a complex structure itself but is restricted 1358 in the example for the sake of clarity. 1360 3.3.1. Addressing LFB Components: Paths and Keys 1362 As mentioned above, LFB components could be complex structures, such 1363 as a table, or even more complex structures such as a table whose 1364 cells are further tables, etc. The ForCES model XML schema 1365 (Figure 5) allows for uniquely identifying anything with such 1366 complexity, utilizing the concept of dot-annotated static paths and 1367 content addressing of paths as derived from keys. As an example, the 1368 path to LFB ComponentID 89 above will be 51.89. If ComponentID 51 1369 was a table which was key index-able, then a key describing content 1370 could also be passed by the CE which upon computation by the FE would 1371 resolve to LFB ComponentID 89. 1373 3.4. FE Datapath Modeling 1375 Packets coming into the FE from ingress ports generally flow through 1376 one or more LFBs before leaving out of the egress ports. How an FE 1377 treats a packet depends on many factors, such as type of the packet 1378 (e.g., IPv4, IPv6, or MPLS), header values, time of arrival, etc. 1379 The result of LFB processing may have an impact on how the packet is 1380 to be treated in downstream LFBs. This differentiation of packet 1381 treatment downstream can be conceptualized as having alternative 1382 datapaths in the FE. For example, the result of a 6- tuple 1383 classification performed by a classifier LFB could control which rate 1384 meter is applied to the packet by a rate meter LFB in a later stage 1385 in the datapath. 1387 LFB topology is a directed graph representation of the logical 1388 datapaths within an FE; with the nodes representing the LFB instances 1389 and the directed link depicting the packet flow direction from one 1390 LFB to the next. Section 3.4.1 discusses how the FE datapaths can be 1391 modeled as LFB topology; while Section 3.4.2 focuses on issues 1392 related to LFB topology reconfiguration. 1394 3.4.1. Alternative Approaches for Modeling FE Datapaths 1396 There are two basic ways to express the differentiation in packet 1397 treatment within an FE, one represents the datapath directly and 1398 graphically (topological approach) and the other utilizes metadata 1399 (the encoded state approach). 1401 o Topological Approach 1403 Using this approach, differential packet treatment is expressed by 1404 splitting the LFB topology into alternative paths. In other words, 1405 if the result of an LFB operation controls how the packet is further 1406 processed, then such an LFB will have separate output ports, one for 1407 each alternative treatment, connected to separate sub-graphs, each 1408 expressing the respective treatment downstream. 1410 o Encoded State Approach 1412 An alternate way of expressing differential treatment is by using 1413 metadata. The result of the operation of an LFB can be encoded in a 1414 metadatum, which is passed along with the packet to downstream LFBs. 1415 A downstream LFB, in turn, can use the metadata and its value (e.g., 1416 as an index into some table) to determine how to treat the packet. 1418 Theoretically, either approach could substitute for the other, so one 1419 could consider using a single pure approach to describe all datapaths 1420 in an FE. However, neither model by itself results in the best 1421 representation for all practically relevant cases. For a given FE 1422 with certain logical datapaths, applying the two different modeling 1423 approaches will result in very different looking LFB topology graphs. 1424 A model using only the topological approach may require a very large 1425 graph with many links or paths, and nodes (i.e., LFB instances) to 1426 express all alternative datapaths. On the other hand, a model using 1427 only the encoded state model would be restricted to a string of LFBs, 1428 which is not an intuitive way to describe different datapaths (such 1429 as MPLS and IPv4). Therefore, a mix of these two approaches will 1430 likely be used for a practical model. In fact, as we illustrate 1431 below, the two approaches can be mixed even within the same LFB. 1433 Using a simple example of a classifier with N classification outputs 1434 followed by other LFBs, Figure 7.a shows what the LFB topology looks 1435 like when using the pure topological approach. Each output from the 1436 classifier goes to one of the N LFBs where no metadata is needed. 1437 The topological approach is simple, straightforward and graphically 1438 intuitive. However, if N is large and the N nodes following the 1439 classifier (LFB#1, LFB#2, ..., LFB#N) all belong to the same LFB type 1440 (e.g., meter), but each has its own independent components, the 1441 encoded state approach gives a much simpler topology representation, 1442 as shown in Figure 7.b. The encoded state approach requires that a 1443 table of N rows of meter components is provided in the Meter node 1444 itself, with each row representing the attributes for one meter 1445 instance. A metadatum M is also needed to pass along with the packet 1446 P from the classifier to the meter, so that the meter can use M as a 1447 look-up key (index) to find the corresponding row of the attributes 1448 that should be used for any particular packet P. 1450 What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same 1451 type? For example, if LFB#1 is a queue while the rest are all 1452 meters, what is the best way to represent such datapaths? While it 1453 is still possible to use either the pure topological approach or the 1454 pure encoded state approach, the natural combination of the two 1455 appears to be the best option. Figure 7.c depicts two different 1456 functional datapaths using the topological approach while leaving the 1457 N-1 meter instances distinguished by metadata only, as shown in 1458 Figure 7.c. 1460 +----------+ 1461 P | LFB#1 | 1462 +--------->|(Compon-1)| 1463 +-------------+ | +----------+ 1464 | 1|------+ P +----------+ 1465 | 2|---------------->| LFB#2 | 1466 | classifier 3| |(Compon-2)| 1467 | ...|... +----------+ 1468 | N|------+ ... 1469 +-------------+ | P +----------+ 1470 +--------->| LFB#N | 1471 |(Compon-N)| 1472 +----------+ 1474 (a) Using pure topological approach 1476 +-------------+ +-------------+ 1477 | 1| | Meter | 1478 | 2| (P, M) | (Compon-1) | 1479 | 3|---------------->| (Compon-2) | 1480 | ...| | ... | 1481 | N| | (Compon-N) | 1482 +-------------+ +-------------+ 1484 (b) Using pure encoded state approach to represent the LFB 1485 topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the 1486 same type (e.g., meter). 1488 +-------------+ 1489 +-------------+ (P, M) | queue | 1490 | 1|------------->| (Compon-1) | 1491 | 2| +-------------+ 1492 | 3| (P, M) +-------------+ 1493 | ...|------------->| Meter | 1494 | N| | (Compon-2) | 1495 +-------------+ | ... | 1496 | (Compon-N) | 1497 +-------------+ 1499 (c) Using a combination of the two, if LFB#1, LFB#2, ..., and 1500 LFB#N are of different types (e.g., queue and meter). 1502 Figure 7: An example of how to model FE datapaths 1504 From this example, we demonstrate that each approach has a distinct 1505 advantage depending on the situation. Using the encoded state 1506 approach, fewer connections are typically needed between a fan-out 1507 node and its next LFB instances of the same type because each packet 1508 carries metadata the following nodes can interpret and hence invoke a 1509 different packet treatment. For those cases, a pure topological 1510 approach forces one to build elaborate graphs with many more 1511 connections and often results in an unwieldy graph. On the other 1512 hand, a topological approach is the most intuitive for representing 1513 functionally different datapaths. 1515 For complex topologies, a combination of the two is the most 1516 flexible. A general design guideline is provided to indicate which 1517 approach is best used for a particular situation. The topological 1518 approach should primarily be used when the packet datapath forks to 1519 distinct LFB classes (not just distinct parameterizations of the same 1520 LFB class), and when the fan-outs do not require changes, such as 1521 adding/removing LFB outputs, or require only very infrequent changes. 1522 Configuration information that needs to change frequently should be 1523 expressed by using the internal attributes of one or more LFBs (and 1524 hence using the encoded state approach). 1526 +---------------------------------------------+ 1527 | | 1528 +----------+ V +----------+ +------+ | 1529 | | | | |if IP-in-IP| | | 1530 ---->| ingress |->+----->|classifier|---------->|Decap.|---->---+ 1531 | ports | | |---+ | | 1532 +----------+ +----------+ |others +------+ 1533 | 1534 V 1535 (a) The LFB topology with a logical loop 1537 +-------+ +-----------+ +------+ +-----------+ 1538 | | | |if IP-in-IP | | | | 1539 --->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|-> 1540 | ports | | |----+ | | | | 1541 +-------+ +-----------+ |others +------+ +-----------+ 1542 | 1543 V 1544 (b)The LFB topology without the loop utilizing two independent 1545 classifier instances. 1547 Figure 8: An LFB topology example. 1549 It is important to point out that the LFB topology described here is 1550 the logical topology, not the physical topology of how the FE 1551 hardware is actually laid out. Nevertheless, the actual 1552 implementation may still influence how the functionality is mapped to 1553 the LFB topology. Figure 8 shows one simple FE example. In this 1554 example, an IP-in-IP packet from an IPSec application like VPN may go 1555 to the classifier first and have the classification done based on the 1556 outer IP header; upon being classified as an IP-in-IP packet, the 1557 packet is then sent to a decapsulator to strip off the outer IP 1558 header, followed by a classifier again to perform classification on 1559 the inner IP header. If the same classifier hardware or software is 1560 used for both outer and inner IP header classification with the same 1561 set of filtering rules, a logical loop is naturally present in the 1562 LFB topology, as shown in Figure 8.a. However, if the classification 1563 is implemented by two different pieces of hardware or software with 1564 different filters (i.e., one set of filters for the outer IP header 1565 and another set for the inner IP header), then it is more natural to 1566 model them as two different instances of classifier LFB, as shown in 1567 Figure 8.b. 1569 3.4.2. Configuring the LFB Topology 1571 While there is little doubt that an individual LFB must be 1572 configurable, the configurability question is more complicated for 1573 LFB topology. Since the LFB topology is really the graphic 1574 representation of the datapaths within an FE, configuring the LFB 1575 topology means dynamically changing the datapaths, including changing 1576 the LFBs along the datapaths on an FE (e.g., creating/instantiating, 1577 updating or deleting LFBs) and setting up or deleting 1578 interconnections between outputs of upstream LFBs to inputs of 1579 downstream LFBs. 1581 Why would the datapaths on an FE ever change dynamically? The 1582 datapaths on an FE are set up by the CE to provide certain data plane 1583 services (e.g., DiffServ, VPN, etc.) to the Network Element's (NE) 1584 customers. The purpose of reconfiguring the datapaths is to enable 1585 the CE to customize the services the NE is delivering at run time. 1586 The CE needs to change the datapaths when the service requirements 1587 change, such as adding a new customer or when an existing customer 1588 changes their service. However, note that not all datapath changes 1589 result in changes in the LFB topology graph. Changes in the graph 1590 are dependent on the approach used to map the datapaths into LFB 1591 topology. As discussed in Section 3.3.1, the topological approach 1592 and encoded state approach can result in very different looking LFB 1593 topologies for the same datapaths. In general, an LFB topology based 1594 on a pure topological approach is likely to experience more frequent 1595 topology reconfiguration than one based on an encoded state approach. 1596 However, even an LFB topology based entirely on an encoded state 1597 approach may have to change the topology at times, for example, to 1598 bypass some LFBs or insert new LFBs. Since a mix of these two 1599 approaches is used to model the datapaths, LFB topology 1600 reconfiguration is considered an important aspect of the FE model. 1602 We want to point out that allowing a configurable LFB topology in the 1603 FE model does not mandate that all FEs are required to have this 1604 capability. Even if an FE supports configurable LFB topology, the FE 1605 may impose limitations on what can actually be configured. 1606 Performance-optimized hardware implementations may have zero or very 1607 limited configurability, while FE implementations running on network 1608 processors may provide more flexibility and configurability. It is 1609 entirely up to the FE designers to decide whether or not the FE 1610 actually implements reconfiguration and if so, how much. Whether a 1611 simple runtime switch is used to enable or disable (i.e., bypass) 1612 certain LFBs, or more flexible software reconfiguration is used, is 1613 an implementation detail internal to the FE and outside of the scope 1614 of FE model. In either case, the CE(s) MUST be able to learn the 1615 FE's configuration capabilities. Therefore, the FE model MUST 1616 provide a mechanism for describing the LFB topology configuration 1617 capabilities of an FE. These capabilities may include (see Section 5 1618 for full details): 1620 o Which LFB classes the FE can instantiate 1622 o The maximum number of instances of the same LFB class that can be 1623 created 1625 o Any topological limitations, for example: 1627 * The maximum number of instances of the same class or any class 1628 that can be created on any given branch of the graph 1630 * Ordering restrictions on LFBs (e.g., any instance of LFB class 1631 A must be always downstream of any instance of LFB class B). 1633 The CE needs some programming help in order to cope with the range of 1634 complexity. In other words, even when the CE is allowed to configure 1635 LFB topology for the FE, the CE is not expected to be able to 1636 interpret an arbitrary LFB topology and determine which specific 1637 service or application (e.g. VPN, DiffServ, etc.) is supported by 1638 the FE. However, once the CE understands the coarse capability of an 1639 FE, the CE MUST configure the LFB topology to implement the network 1640 service the NE is supposed to provide. Thus, the mapping the CE has 1641 to understand is from the high level NE service to a specific LFB 1642 topology, not the other way around. The CE is not expected to have 1643 the ultimate intelligence to translate any high level service policy 1644 into the configuration data for the FEs. However, it is conceivable 1645 that within a given network service domain, a certain amount of 1646 intelligence can be programmed into the CE to give the CE a general 1647 understanding of the LFBs involved to allow the translation from a 1648 high level service policy to the low level FE configuration to be 1649 done automatically. Note that this is considered an implementation 1650 issue internal to the control plane and outside the scope of the FE 1651 model. Therefore, it is not discussed any further in this draft. 1653 +----------+ +-----------+ 1654 ---->| Ingress |---->|classifier |--------------+ 1655 | | |chip | | 1656 +----------+ +-----------+ | 1657 v 1658 +-------------------------------------------+ 1659 +--------+ | Network Processor | 1660 <----| Egress | | +------+ +------+ +-------+ | 1661 +--------+ | |Meter | |Marker| |Dropper| | 1662 ^ | +------+ +------+ +-------+ | 1663 | | | 1664 +----------+-------+ | 1665 | | | 1666 | +---------+ +---------+ +------+ +---------+ | 1667 | |Forwarder|<------|Scheduler|<--|Queue | |Counter | | 1668 | +---------+ +---------+ +------+ +---------+ | 1669 +--------------------------------------------------------------+ 1671 Figure 9: The Capability of an FE as reported to the CE 1673 Figure 9 shows an example where a QoS-enabled router has several line 1674 cards that have a few ingress ports and egress ports, a specialized 1675 classification chip, and a network processor containing codes for FE 1676 blocks like meter, marker, dropper, counter, queue, scheduler, and 1677 Ipv4 forwarder. Some of the LFB topology is already fixed and has to 1678 remain static due to the physical layout of the line cards. For 1679 example, all of the ingress ports might be hardwired into the 1680 classification chip so all packets flow from the ingress port into 1681 the classification engine. On the other hand, the LFBs on the 1682 network processor and their execution order are programmable. 1683 However, certain capacity limits and linkage constraints could exist 1684 between these LFBs. Examples of the capacity limits might be: 1686 o 8 meters 1688 o 16 queues in one FE 1690 o the scheduler can handle at most up to 16 queues 1692 o The linkage constraints might dictate that: 1694 * the classification engine may be followed by: 1696 + a meter 1698 + marker 1700 + dropper 1702 + counter 1704 + queue or IPv4 forwarder, but not a scheduler 1706 * queues can only be followed by a scheduler 1708 * a scheduler must be followed by the IPv4 forwarder 1710 * the last LFB in the datapath before going into the egress ports 1711 must be the IPv4 forwarder 1713 +-----+ +-------+ +---+ 1714 | A|--->|Queue1 |--------------------->| | 1715 ------>| | +-------+ | | +---+ 1716 | | | | | | 1717 | | +-------+ +-------+ | | | | 1718 | B|--->|Meter1 |----->|Queue2 |------>| |->| | 1719 | | | | +-------+ | | | | 1720 | | | |--+ | | | | 1721 +-----+ +-------+ | +-------+ | | +---+ 1722 classifier +-->|Dropper| | | IPv4 1723 +-------+ +---+ Fwd. 1724 Scheduler 1726 Figure 10: An LFB topology as configured by the CE and accepted by 1727 the FE 1729 Once the FE reports these capabilities and capacity limits to the CE, 1730 it is now up to the CE to translate the QoS policy into a desirable 1731 configuration for the FE. Figure 9 depicts the FE capability while 1732 Figure 10 and Figure 11 depict two different topologies that the CE 1733 may request the FE to configure. 1735 Queue1 1736 +---+ +--+ 1737 | A|------------------->| |--+ 1738 +->| | | | | 1739 | | B|--+ +--+ +--+ +--+ | 1740 | +---+ | | | | | | 1741 | Meter1 +->| |-->| | | 1742 | | | | | | 1743 | +--+ +--+ | Ipv4 1744 | Counter1 Dropper1 Queue2| +--+ Fwd. 1745 +---+ | +--+ +--->|A | +-+ 1746 | A|---+ | |------>|B | | | 1747 ------>| B|------------------------------>| | +--->|C |->| |-> 1748 | C|---+ +--+ | +->|D | | | 1749 | D|-+ | | | +--+ +-+ 1750 +---+ | | +---+ Queue3| | Scheduler 1751 Classifier1 | | | A|------------> +--+ | | 1752 | +->| | | |--+ | 1753 | | B|--+ +--+ +-------->| | | 1754 | +---+ | | | | +--+ | 1755 | Meter2 +->| |-+ | 1756 | | | | 1757 | +--+ Queue4 | 1758 | Marker1 +--+ | 1759 +---------------------------->| |----+ 1760 | | 1761 +--+ 1763 Figure 11: Another LFB topology as configured by the CE and accepted 1764 by the FE 1766 Note that both the ingress and egress are omitted in Figure 10 and 1767 Figure 11 to simplify the representation. The topology in Figure 11 1768 is considerably more complex than Figure 10 but both are feasible 1769 within the FE capabilities, and so the FE should accept either 1770 configuration request from the CE. 1772 4. Model and Schema for LFB Classes 1774 The main goal of the FE model is to provide an abstract, generic, 1775 modular, implementation-independent representation of the FEs. This 1776 is facilitated using the concept of LFBs, which are instantiated from 1777 LFB classes. LFB classes and associated definitions will be provided 1778 in a collection of XML documents. The collection of these XML 1779 documents is called a LFB class library, and each document is called 1780 an LFB class library document (or library document, for short). Each 1781 of the library documents MUST conform to the schema presented in this 1782 section. The root element of the library document is the 1783 element. 1785 It is not expected that library documents will be exchanged between 1786 FEs and CEs "over-the-wire". But the model will serve as an 1787 important reference for the design and development of the CEs 1788 (software) and FEs (mostly the software part). It will also serve as 1789 a design input when specifying the ForCES protocol elements for CE-FE 1790 communication. 1792 4.1. Namespace 1794 A namespace is needed to uniquely identify the LFB type in the LFB 1795 class library. The reference to the namespace definition is 1796 contained in Section 9, IANA Considerations. 1798 4.2. Element 1800 The element serves as a root element of all library 1801 documents. It contains one or more of the following main XML 1802 elements: 1804 o for the frame declarations; 1806 o for defining common data types; 1808 o for defining metadata, and 1810 o for defining LFB classes. 1812 Each element is optional, that is, one library document may contain 1813 only metadata definitions, another may contain only LFB class 1814 definitions, yet another may contain all of the above. 1816 In addition to the above main elements, a library document can import 1817 other library documents if it needs to refer to definitions contained 1818 in the included document. This concept is similar to the "#include" 1819 directive in C. Importing is expressed by the use of elements, 1820 which must precede all the above elements in the document. For 1821 unique referencing, each LFBLibrary instance document has a unique 1822 label defined in the "provide" attribute of the LFBLibrary element. 1823 Note that what this performs is a ForCES inclusion, not an XML 1824 inclusion. The semantic content of the library referenced by the 1825 element is included, not the xml content. 1827 The element also includes an optional 1828 element, which can be used to provide textual description about the 1829 library document. 1831 The following is a skeleton of a library document: 1833 1834 1837 1839 1841 1842 1843 ... 1845 1846 1847 ... 1848 1850 1851 1852 ... 1853 1855 1856 1857 ... 1858 1860 1864 1866 1867 1869 4.3. Element 1871 This element is used to refer to another LFB library document. 1872 Similar to the "#include" directive in C, this makes the objects 1873 (metadata types, data types, etc.) defined in the referred library 1874 document available for referencing in the current document. 1876 The load element MUST contain the label of the library document to be 1877 included and may contain a URL to specify where the library can be 1878 retrieved. The load element can be repeated unlimited times. Three 1879 examples for the elements: 1881 1882 1883 1886 4.4. Element for Frame Type Declarations 1888 Frame names are used in the LFB definition to define the types of 1889 frames the LFB expects at its input port(s) and emits at its output 1890 port(s). The optional element in the library document 1891 contains one or more elements, each declaring one frame 1892 type. 1894 Each frame definition MUST contain a unique name (NMTOKEN) and a 1895 brief synopsis. In addition, an optional detailed description may be 1896 provided. 1898 Uniqueness of frame types MUST be ensured among frame types defined 1899 in the same library document and in all directly or indirectly 1900 included library documents. 1902 The following example defines two frame types: 1904 1905 1906 ipv4 1907 IPv4 packet 1908 1909 This frame type refers to an IPv4 packet. 1910 1911 1912 1913 ipv6 1914 IPv6 packet 1915 1916 This frame type refers to an IPv6 packet. 1917 1918 1919 ... 1920 1922 4.5. Element for Data Type Definitions 1924 The (optional) element can be used to define commonly 1925 used data types. It contains one or more elements, 1926 each defining a data type with a unique name. Such data types can be 1927 used in several places in the library documents, including: 1929 o Defining other data types 1931 o Defining components of LFB classes 1933 This is similar to the concept of having a common header file for 1934 shared data types. 1936 Each element MUST contain a unique name (NMTOKEN), a 1937 brief synopsis, an optional longer description, and a type definition 1938 element. The name MUST be unique among all data types defined in the 1939 same library document and in any directly or indirectly included 1940 library documents. For example: 1942 1943 1944 ieeemacaddr 1945 48-bit IEEE MAC address 1946 ... type definition ... 1947 1948 1949 ipv4addr 1950 IPv4 address 1951 ... type definition ... 1952 1953 ... 1954 1956 There are two kinds of data types: atomic and compound. Atomic data 1957 types are appropriate for single-value variables (e.g. integer, 1958 string, byte array). 1960 The following built-in atomic data types are provided, but additional 1961 atomic data types can be defined with the and 1962 elements: 1964 Meaning 1965 ---- ------- 1966 char 8-bit signed integer 1967 uchar 8-bit unsigned integer 1968 int16 16-bit signed integer 1969 uint16 16-bit unsigned integer 1970 int32 32-bit signed integer 1971 uint32 32-bit unsigned integer 1972 int64 64-bit signed integer 1973 uint64 64-bit unsigned integer 1974 boolean A true / false value where 1975 0 = false, 1 = true 1976 string[N] A UTF-8 string represented in at most 1977 N Octets. 1978 string A UTF-8 string without a configured 1979 storage length limit. 1980 byte[N] A byte array of N bytes 1981 octetstring[N] A buffer of N octets, which may 1982 contain fewer than N octets. Hence 1983 the encoded value will always have 1984 a length. 1985 float16 16-bit floating point number 1986 float32 32-bit IEEE floating point number 1987 float64 64-bit IEEE floating point number 1989 These built-in data types can be readily used to define metadata or 1990 LFB attributes, but can also be used as building blocks when defining 1991 new data types. The boolean data type is defined here because it is 1992 so common, even though it can be built by sub-ranging the uchar data 1993 type. 1995 Compound data types can build on atomic data types and other compound 1996 data types. Compound data types can be defined in one of four ways. 1997 They may be defined as an array of components of some compound or 1998 atomic data type. They may be a structure of named components of 1999 compound or atomic data types (ala C structures). They may be a 2000 union of named components of compound or atomic data types (ala C 2001 unions). They may also be defined as augmentations (explained in 2002 Section 4.5.7) of existing compound data types. 2004 Given that the FORCES protocol will be getting and setting component 2005 values, all atomic data types used here must be able to be conveyed 2006 in the FORCES protocol. Further, the FORCES protocol will need a 2007 mechanism to convey compound data types. However, the details of 2008 such representations are for the ForCES Protocol [2] document to 2009 define, not the model document. Strings and octetstrings must be 2010 conveyed with their length, as they are not delimited, and are 2011 variable length. 2013 With regard to strings, this model defines a small set of 2014 restrictions and definitions on how they are structured. String and 2015 octetstring length limits can be specified in the LFB Class 2016 definitions. The component properties for string and octetstring 2017 components also contain actual lengths and length limits. This 2018 duplication of limits is to allow for implementations with smaller 2019 limits than the maximum limits specified in the LFB Class definition. 2020 In all cases, these lengths are specified in octets, not in 2021 characters. In terms of protocol operation, as long as the specified 2022 length is within the FE's supported capabilities, the FE stores the 2023 contents of a string exactly as provided by the CE, and returns those 2024 contents when requested. No canonicalization, transformations, or 2025 equivalences are performed by the FE. components of type string (or 2026 string[n]) may be used to hold identifiers for correlation with 2027 components in other LFBs. In such cases, an exact octet for octet 2028 match is used. No equivalences are used by the FE or CE in 2029 performing that matching. The ForCES Protocol [2] does not perform 2030 or require validation of the content of UTF-8 strings. However, 2031 UTF-8 strings SHOULD be encoded in the shortest form to avoid 2032 potential security issues described in [12]. Any entity displaying 2033 such strings is expected to perform its own validation (for example 2034 for correct multi-byte characters, and for ensuring that the string 2035 does not end in the middle of a multi-byte sequence.) Specific LFB 2036 class definitions may restrict the valid contents of a string as 2037 suited to the particular usage (for example, a component that holds a 2038 DNS name would be restricted to hold only octets valid in such a 2039 name.) FEs should validate the contents of SET requests for such 2040 restricted components at the time the set is performed, just as range 2041 checks for range limited components are performed. The ForCES 2042 protocol behavior defines the normative processing for requests using 2043 that protocol. 2045 For the definition of the actual type in the element, 2046 the following elements are available: , , , 2047 , and . 2049 The predefined type alias is somewhere between the atomic and 2050 compound data types. It behaves like a structure, one component of 2051 which has special behavior. Given that the special behavior is tied 2052 to the other parts of the structure, the compound result is treated 2053 as a predefined construct. 2055 4.5.1. Element for Aliasing Existing Data Types 2057 The element refers to an existing data type by its name. 2058 The referred data type MUST be defined either in the same library 2059 document, or in one of the included library documents. If the 2060 referred data type is an atomic data type, the newly defined type 2061 will also be regarded as atomic. If the referred data type is a 2062 compound type, the new type will also be compound. Some usage 2063 examples follow: 2065 2066 short 2067 Alias to int16 2068 int16 2069 2070 2071 ieeemacaddr 2072 48-bit IEEE MAC address 2073 byte[6] 2074 2076 4.5.2. Element for Deriving New Atomic Types 2078 The element allows the definition of a new atomic type from 2079 an existing atomic type, applying range restrictions and/or providing 2080 special enumerated values. Note that the element can only 2081 use atomic types as base types, and its result MUST be another atomic 2082 type. 2084 For example, the following snippet defines a new "dscp" data type: 2086 2087 dscp 2088 Diffserv code point. 2089 2090 uchar 2091 2092 2093 2094 2095 2096 DSCP-BE 2097 Best Effort 2098 2099 ... 2100 2101 2102 2104 4.5.3. Element to Define Arrays 2106 The element can be used to create a new compound data type as 2107 an array of a compound or an atomic data type. Depending upon 2108 context, this document, and others, refer to such arrays as tables or 2109 arrays interchangeably, without semantic or syntactic implication. 2110 The type of the array entry can be specified either by referring to 2111 an existing type (using the element) or defining an unnamed 2112 type inside the element using any of the , , 2113 , or elements. 2115 The array can be "fixed-size" or "variable-size", which is specified 2116 by the "type" attribute of the element. The default is 2117 "variable-size". For variable size arrays, an optional "max-length" 2118 attribute specifies the maximum allowed length. This attribute 2119 should be used to encode semantic limitations, not implementation 2120 limitations. The latter should be handled by capability components 2121 of LFB classes, and should never be included in a data type array 2122 which is regarded as of unlimited-size. 2124 For fixed-size arrays, a "length" attribute MUST be provided that 2125 specifies the constant size of the array. 2127 The result of this construct MUST always be a compound type, even if 2128 the array has a fixed size of 1. 2130 Arrays MUST only be subscripted by integers, and will be presumed to 2131 start with index 0. 2133 In addition to their subscripts, arrays may be declared to have 2134 content keys. Such a declaration has several effects: 2136 o Any declared key can be used in the ForCES protocol to select a 2137 component for operations (for details, see the ForCES Protocol 2138 [2]). 2140 o In any instance of the array, each declared key must be unique 2141 within that instance. No two components of an array may have the 2142 same values on all the fields which make up a key. 2144 Each key is declared with a keyID for use in the ForCES Protocol [2], 2145 where the unique key is formed by combining one or more specified key 2146 fields. To support the case where an array of an atomic type with 2147 unique values can be referenced by those values, the key field 2148 identifier may be "*" (i.e., the array entry is the key). If the 2149 value type of the array is a structure or an array, then the key is 2150 one or more components of the value type, each identified by name. 2151 Since the field may be a component of the contained structure, a 2152 component of a component of a structure, or further nested, the field 2153 name is actually a concatenated sequence of component identifiers, 2154 separated by decimal points ("."). The syntax for key field 2155 identification is given following the array examples. 2157 The following example shows the definition of a fixed size array with 2158 a pre-defined data type as the array content type: 2160 2161 dscp-mapping-table 2162 2163 A table of 64 DSCP values, used to re-map code space. 2164 2165 2166 dscp 2167 2168 2170 The following example defines a variable size array with an upper 2171 limit on its size: 2173 2174 mac-alias-table 2175 A table with up to 8 IEEE MAC addresses 2176 2177 ieeemacaddr 2178 2179 2181 The following example shows the definition of an array with a local 2182 (unnamed) content type definition: 2184 2185 classification-table 2186 2187 A table of classification rules and result opcodes. 2188 2189 2190 2191 2192 rule 2193 The rule to match 2194 classrule 2195 2196 2197 opcode 2198 The result code 2199 opcode 2200 2201 2202 2203 2205 In the above example, each entry of the array is a of two 2206 components ("rule" and "opcode"). 2208 The following example shows a table of IP Prefix information that can 2209 be accessed by a multi-field content key on the IP Address and prefix 2210 length. This means that in any instance of this table, no two 2211 entries can have the same IP address and prefix length. 2213 2214 ipPrefixInfo_table 2215 2216 A table of information about known prefixes 2217 2218 2219 2220 2221 address-prefix 2222 the prefix being described 2223 ipv4Prefix 2224 2225 2226 source 2227 2228 the protocol or process providing this information 2229 2230 uint16 2231 2232 2233 prefInfo 2234 the information we care about 2235 hypothetical-info-type 2236 2237 2238 2239 address-prefix.ipv4addr 2240 address-prefix.prefixlen 2241 source 2242 2243 2244 2246 Note that the keyField elements could also have been simply address- 2247 prefix and source, since all of the fields of address-prefix are 2248 being used. 2250 4.5.3.1. Key Field References 2252 In order to use key declarations, one must refer to components that 2253 are potentially nested inside other components in the array. If 2254 there are nested arrays, one might even use an array element as a key 2255 (but great care would be needed to ensure uniqueness.) 2256 The key is the combination of the values of each field declared in a 2257 keyField element. 2259 Therefore, the value of a keyField element MUST be a concatenated 2260 Sequence of field identifiers, separated by a "." (period) character. 2261 Whitespace is permitted and ignored. 2263 A valid string for a single field identifier within a keyField 2264 depends upon the current context. Initially, in an array key 2265 declaration, the context is the type of the array. Progressively, 2266 the context is whatever type is selected by the field identifiers 2267 processed so far in the current key field declaration. 2269 When the current context is an array, (e.g., when declaring a key for 2270 an array whose content is an array) then the only valid value for the 2271 field identifier is an explicit number. 2273 When the current context is a structure, the valid values for the 2274 field identifiers are the names of the components of the structure. 2275 In the special case of declaring a key for an array containing an 2276 atomic type, where that content is unique and is to be used as a key, 2277 the value "*" can be used as the single key field identifier. 2279 4.5.4. Element to Define Structures 2281 A structure is comprised of a collection of data components. Each 2282 data components has a data type (either an atomic type or an existing 2283 compound type) and is assigned a name unique within the scope of the 2284 compound data type being defined. These serve the same function as 2285 "struct" in C, etc. 2287 The actual type of the component can be defined by referring to an 2288 existing type (using the element), or can be a locally 2289 defined (unnamed) type created by any of the , , 2290 , or elements. 2292 A structure definition is a series of component declarations. Each 2293 component carries a componentID for use by the ForCES protocol. In 2294 addition, the component declaration contains the name of the 2295 component, a synopsis, an optional description, an optional 2296 declaration that the component itself is optional, and the typeRef 2297 declaration that specifies the component type. 2299 For a dataTypeDef of a struct, the structure definition may be 2300 inherited from, and augment, a previously defined structured type. 2301 This is indicated by including the derivedFrom attribute on the 2302 struct declaration. 2304 The result of this construct MUST be a compound type, even when the 2305 contains only one field. 2307 An example: 2309 2310 ipv4prefix 2311 2312 IPv4 prefix defined by an address and a prefix length 2313 2314 2315 2316 address 2317 Address part 2318 ipv4addr 2319 2320 2321 prefixlen 2322 Prefix length part 2323 2324 uchar 2325 2326 2327 2328 2329 2330 2331 2333 4.5.5. Element to Define Union Types 2335 Similar to the union declaration in C, this construct allows the 2336 definition of overlay types. Its format is identical to the 2337 element. 2339 The result of this construct MUST be a compound type, even when the 2340 union contains only one element. 2342 4.5.6. Element 2344 It is sometimes necessary to have a component in an LFB or structure 2345 refer to information (a component) in other LFBs. The 2346 declaration creates the constructs for this. The content of an 2347 element MUST be a named type. Whatever component the alias 2348 references (whcih is determined by the alias component properties, as 2349 described below) that component must be of the same type as that 2350 declared for the alias. Thus, when the CE or FE dereferences the 2351 alias component, the type of the information returned is known. The 2352 type can be a base type or a derived type. The actual value 2353 referenced by an alias is known as its target. When a GET or SET 2354 operation references the alias element, the value of the target is 2355 returned or replaced. Write access to an alias element is permitted 2356 if write access to both the alias and the target are permitted. 2358 The target of a component declared by an element is 2359 determined by it the components properties. Like all components, the 2360 properties MUST include the support / read / write permission for the 2361 alias. In addition, there are several fields (components) in the 2362 alias properties which define the target of the alias. These 2363 components are the ID of the LFB class of the target, the ID of the 2364 LFB instance of the target, and a sequence of integers representing 2365 the path within the target LFB instance to the target component. The 2366 type of the target element must match the declared type of the alias. 2367 Details of the alias property structure are described in Section 4.8 2368 of this document on properties. 2370 Note that the read / write property of the alias refers to the value. 2371 The CE can only determine if it can write the target selection 2372 properties of the alias by attempting such a write operation. 2373 (Property components do not themselves have properties.) 2375 4.5.7. Augmentations 2377 Compound types can also be defined as augmentations of existing 2378 compound types. If the existing compound type is a structure, 2379 augmentation may add new elements to the type. The type of an 2380 existing component can be replaced in the definition of an augmenting 2381 structure, but only with an augmentation derived from the current 2382 type of the existing component. An existing component cannot be 2383 deleted. If the existing compound type is an array, augmentation 2384 means augmentation of the array element type. 2386 One consequence of this is that augmentations are backwards 2387 compatible with the compound type from which they are derived. As 2388 such, augmentations are useful in defining components for LFB 2389 subclasses with backward compatibility. In addition to adding new 2390 components to a class, the data type of an existing components may be 2391 replaced by an augmentation of that component, and still meet the 2392 compatibility rules for subclasses. 2394 For example, consider a simple base LFB class A that has only one 2395 component (comp1) of type X. One way to derive class A1 from A can be 2396 by simply adding a second component (of any type). Another way to 2397 derive a class A2 from A can be by replacing the original component 2398 (comp1) in A of type X with one of type Y, where Y is an augmentation 2399 of X. Both classes A1 and A2 are backward compatible with class A. 2401 The syntax for augmentations is to include a element in 2402 a structure definition, indicating what structure type is being 2403 augmented. Component names and component IDs within the augmentation 2404 must not be the same as those in the structure type being augmented. 2406 4.6. Element for Metadata Definitions 2408 The (optional) element in the library document 2409 contains one or more elements. Each 2410 element defines a metadatum. 2412 Each element MUST contain a unique name (NMTOKEN). 2413 Uniqueness is defined to be over all metadata defined in this library 2414 document and in all directly or indirectly included library 2415 documents. The element MUST also contain a brief 2416 synopsis, the mandatory tag value to be used for this metadata, an 2417 optional detailed description, and a mandatory type definition 2418 information. Only atomic data types can be used as value types for 2419 metadata. 2421 Two forms of type definitions are allowed. The first form uses the 2422 element to refer to an existing atomic data type defined in 2423 the element of the same library document or in one of 2424 the included library documents. The usage of the element 2425 is identical to how it is used in the elements, except 2426 here it can only refer to atomic types. The latter restriction is 2427 not yet enforced by the XML schema. 2429 The second form is an explicit type definition using the 2430 element. This element is used here in the same way as in the 2431 elements. 2433 The following example shows both usages: 2435 2436 2437 NEXTHOPID 2438 Refers to a Next Hop entry in NH LFB 2439 17 2440 int32 2441 2442 2443 CLASSID 2444 2445 Result of classification (0 means no match). 2446 2447 21 2448 2449 int32 2450 2451 2452 NOMATCH 2453 2454 Classification didn't result in match. 2455 2456 2457 2458 2459 2460 2462 4.7. Element for LFB Class Definitions 2464 The (optional) element can be used to define one or 2465 more LFB classes using elements. Each 2466 element MUST define an LFB class and include the following elements: 2468 o provides the symbolic name of the LFB class. Example: 2469 "ipv4lpm" 2471 o provides a short synopsis of the LFB class. Example: 2472 "IPv4 Longest Prefix Match Lookup LFB" 2474 o is the version indicator 2476 o is the inheritance indicator 2478 o lists the input ports and their specifications 2480 o lists the output ports and their specifications 2481 o defines the operational components of the LFB 2483 o defines the capability components of the LFB 2485 o contains the operational specification of the LFB 2487 o The LFBClassID attribute of the LFBClassDef element defines the ID 2488 for this class. These must be globally unique. 2490 o defines the events that can be generated by instances of 2491 this LFB. 2493 LFB Class Names must be unique, in order to enable other documents to 2494 reference the classes by name, and to enable human readers to 2495 understand references to class names. While a complex naming 2496 structure could be created, simplicity is preferred. As given in the 2497 IANA considerations section of this document, the IANA will maintain 2498 a registry of LFB Class names and Class identifiers, along with a 2499 reference to the document defining the class. 2501 Here is a skeleton of an example LFB class definition: 2503 2504 2505 ipv4lpm 2506 IPv4 Longest Prefix Match Lookup LFB 2507 1.0 2508 baseclass 2510 2511 ... 2512 2514 2515 ... 2516 2518 2519 ... 2520 2522 2523 ... 2524 2526 2527 This LFB represents the IPv4 longest prefix match lookup 2528 operation. 2529 The modeled behavior is as follows: 2530 Blah-blah-blah. 2531 2533 2534 ... 2535 2537 The individual components and capabilities will have componentIDs for 2538 use by the ForCES protocol. These parallel the componentIDs used in 2539 structs, and are used the same way. Component and capability 2540 componentIDs must be unique within the LFB class definition. 2542 Note that the , , and elements are 2543 required, all other elements are optional in . However, 2544 when they are present, they must occur in the above order. 2546 4.7.1. Element to Express LFB Inheritance 2548 The optional element can be used to indicate that this 2549 class is a derivative of some other class. The content of this 2550 element MUST be the unique name () of another LFB class. The 2551 referred LFB class MUST be defined in the same library document or in 2552 one of the included library documents. 2554 It is assumed that the derived class is backwards compatible with the 2555 base class. 2557 4.7.2. Element to Define LFB Inputs 2559 The optional element is used to define input ports. An 2560 LFB class may have zero, one, or more inputs. If the LFB class has 2561 no input ports, the element MUST be omitted. The 2562 element can contain one or more elements, 2563 one for each port or port-group. We assume that most LFBs will have 2564 exactly one input. Multiple inputs with the same input type are 2565 modeled as one input group. Input groups are defined the same way as 2566 input ports by the element, differentiated only by an 2567 optional "group" attribute. 2569 Multiple inputs with different input types should be avoided if 2570 possible (see discussion in Section 4.7.3). Some special LFBs will 2571 have no inputs at all. For example, a packet generator LFB does not 2572 need an input. 2574 Single input ports and input port groups are both defined by the 2575 element; they are differentiated by only an optional 2576 "group" attribute. 2578 The element MUST contain the following elements: 2580 o provides the symbolic name of the input. Example: "in". 2581 Note that this symbolic name must be unique only within the scope 2582 of the LFB class. 2584 o contains a brief description of the input. Example: 2585 "Normal packet input". 2587 o lists all allowed frame formats. Example: {"ipv4" 2588 and "ipv6"}. Note that this list should refer to names specified 2589 in the element of the same library document or in any 2590 included library documents. The element can also 2591 provide a list of required metadata. Example: {"classid", 2592 "vifid"}. This list should refer to names of metadata defined in 2593 the element in the same library document or in any 2594 included library documents. For each metadata, it must be 2595 specified whether the metadata is required or optional. For each 2596 optional metadata, a default value must be specified, which is 2597 used by the LFB if the metadata is not provided with a packet. 2599 In addition, the optional "group" attribute of the 2600 element can specify if the port can behave as a port group, i.e., it 2601 is allowed to be instantiated. This is indicated by a "true" value 2602 (the default value is "false"). 2604 An example element, defining two input ports, the second 2605 one being an input port group: 2607 2608 2609 in 2610 Normal input 2611 2612 2613 ipv4 2614 ipv6 2615 2616 2617 classid 2618 vifid 2619 vrfid 2620 2621 2622 2623 2624 ... another input port ... 2625 2626 2628 For each , the frame type expectations are defined by the 2629 element using one or more elements (see example 2630 above). When multiple frame types are listed, it means that "one of 2631 these" frame types is expected. A packet of any other frame type is 2632 regarded as incompatible with this input port of the LFB class. The 2633 above example list two frames as expected frame types: "ipv4" and 2634 "ipv6". 2636 Metadata expectations are specified by the 2637 element. In its simplest form, this element can contain a list of 2638 elements, each referring to a metadatum. When multiple 2639 instances of metadata are listed by elements, it means that 2640 "all of these" metadata must be received with each packet (except 2641 metadata that are marked as "optional" by the "dependency" attribute 2642 of the corresponding element). For a metadatum that is 2643 specified "optional", a default value MUST be provided using the 2644 "defaultValue" attribute. The above example lists three metadata as 2645 expected metadata, two of which are mandatory ("classid" and 2646 "vifid"), and one being optional ("vrfid"). 2648 The schema also allows for more complex definitions of metadata 2649 expectations. For example, using the element, a list of 2650 metadata can be specified to express that at least one of the 2651 specified metadata must be present with any packet. For example: 2653 2654 2655 prefixmask 2656 prefixlen 2657 2658 2660 The above example specifies that either the "prefixmask" or the 2661 "prefixlen" metadata must be provided with any packet. 2663 The two forms can also be combined, as it is shown in the following 2664 example: 2666 2667 classid 2668 vifid 2669 vrfid 2670 2671 prefixmask 2672 prefixlen 2673 2674 2676 Although the schema is constructed to allow even more complex 2677 definitions of metadata expectations, we do not discuss those here. 2679 4.7.3. Element to Define LFB Outputs 2681 The optional element is used to define output ports. 2682 An LFB class may have zero, one, or more outputs. If the LFB class 2683 has no output ports, the element MUST be omitted. The 2684 element can contain one or more elements, 2685 one for each port or port-group. If there are multiple outputs with 2686 the same output type, we model them as an output port group. Some 2687 special LFBs may have no outputs at all (e.g., Dropper). 2689 Single output ports and output port groups are both defined by the 2690 element; they are differentiated by only an optional 2691 "group" attribute. 2693 The element MUST contain the following elements: 2695 o provides the symbolic name of the output. Example: "out". 2696 Note that the symbolic name must be unique only within the scope 2697 of the LFB class. 2699 o contains a brief description of the output port. 2700 Example: "Normal packet output". 2702 o lists the allowed frame formats. Example: {"ipv4", 2703 "ipv6"}. Note that this list should refer to symbols specified in 2704 the element in the same library document or in any 2705 included library documents. The element may also 2706 contain the list of emitted (generated) metadata. Example: 2707 {"classid", "color"}. This list should refer to names of metadata 2708 specified in the element in the same library 2709 document or in any included library documents. For each generated 2710 metadata, it should be specified whether the metadata is always 2711 generated or generated only in certain conditions. This 2712 information is important when assessing compatibility between 2713 LFBs. 2715 In addition, the optional "group" attribute of the 2716 element can specify if the port can behave as a port group, i.e., it 2717 is allowed to be instantiated. This is indicated by a "true" value 2718 (the default value is "false"). 2720 The following example specifies two output ports, the second being an 2721 output port group: 2723 2724 2725 out 2726 Normal output 2727 2728 2729 ipv4 2730 ipv4bis 2731 2732 2733 nhid 2734 nhtabid 2735 2736 2737 2738 2739 exc 2740 Exception output port group 2741 2742 2743 ipv4 2744 ipv4bis 2745 2746 2747 errorid 2748 2749 2750 2751 2753 The types of frames and metadata the port produces are defined inside 2754 the element in each . Within the 2755 element, the list of frame types the port produces is listed in the 2756 element. When more than one frame is listed, it 2757 means that "one of" these frames will be produced. 2759 The list of metadata that is produced with each packet is listed in 2760 the optional element of the . In its 2761 simplest form, this element can contain a list of elements, 2762 each referring to a metadatum type. The meaning of such a list is 2763 that "all of" these metadata are provided with each packet, except 2764 those that are listed with the optional "availability" attribute set 2765 to "conditional". Similar to the element of the 2766 , the element supports more complex 2767 forms, which we do not discuss here further. 2769 4.7.4. Element to Define LFB Operational Components 2771 Operational parameters of the LFBs that must be visible to the CEs 2772 are conceptualized in the model as the LFB components. These 2773 include, for example, flags, single parameter arguments, complex 2774 arguments, and tables. Note that the components here refer to only 2775 those operational parameters of the LFBs that must be visible to the 2776 CEs. Other variables that are internal to LFB implementation are not 2777 regarded as LFB components and hence are not covered. 2779 Some examples for LFB components are: 2781 o Configurable flags and switches selecting between operational 2782 modes of the LFB 2784 o Number of inputs or outputs in a port group 2786 o Metadata CONSUME vs.PROPAGATE mode selector 2788 o Various configurable lookup tables, including interface tables, 2789 prefix tables, classification tables, DSCP mapping tables, MAC 2790 address tables, etc. 2792 o Packet and byte counters 2794 o Various event counters 2796 o Number of current inputs or outputs for each input or output group 2798 There may be various access permission restrictions on what the CE 2799 can do with an LFB component. The following categories may be 2800 supported: 2802 o No-access components. This is useful when multiple access modes 2803 may be defined for a given component to allow some flexibility for 2804 different implementations. 2806 o Read-only components. 2808 o Read-write components. 2810 o Write-only components. This could be any configurable data for 2811 which read capability is not provided to the CEs. (e.g., the 2812 security key information) 2814 o Read-reset components. The CE can read and reset this resource, 2815 but cannot set it to an arbitrary value. Example: Counters. 2817 o Firing-only components. A write attempt to this resource will 2818 trigger some specific actions in the LFB, but the actual value 2819 written is ignored. 2821 The LFB class may define only one possible access mode for a given 2822 component. 2824 The components of the LFB class are listed in the 2825 element. Each component is defined by an element. An 2826 element MUST contain the following elements: 2828 o defines the name of the component.This name must be unique 2829 among the components of the LFB class. Example: "version". 2831 o should provide a brief description of the purpose of 2832 the component. 2834 o indicates that this component is optional. 2836 o The data type of the component can be defined either via a 2837 reference to a predefined data type or providing a local 2838 definition of the type. The former is provided by using the 2839 element, which must refer to the unique name of an 2840 existing data type defined in the element in the 2841 same library document or in any of the included library documents. 2842 When the data type is defined locally (unnamed type), one of the 2843 following elements can be used: , , , and 2844 . Their usage is identical to how they are used inside 2845 elements (see Section 4.5). 2847 o The optional element can specify a default value 2848 for the component, which is applied when the LFB is initialized or 2849 reset. 2851 The element also MUST have an componentID attribute, 2852 which is a numeric value used by the ForCES protocol. 2854 In addition to the above elements, the element includes 2855 an optional "access" attribute, which can take any of the following 2856 values: "read-only", "read-write", "write-only", "read-reset", and 2857 "trigger-only". The default access mode is "read-write". 2859 Whether optional components are supported, and whether components 2860 defined as read-write can actually be written can be determined for a 2861 given LFB instance by the CE by reading the property information of 2862 that component. An access control setting of "trigger-only" means 2863 that this component is included only for use in event detection. 2865 The following example defines two components for an LFB: 2867 2868 2869 foo 2870 number of things 2871 uint32 2872 2873 2874 bar 2875 number of this other thing 2876 2877 uint32 2878 2879 2880 2881 2882 10 2883 2884 2886 The first component ("foo") is a read-only 32-bit unsigned integer, 2887 defined by referring to the built-in "uint32" atomic type. The 2888 second component ("bar") is also an integer, but uses the 2889 element to provide additional range restrictions. This component has 2890 access mode of read-write allowing it to be both read and written. A 2891 default value of 10 is provided for bar. although the access for bar 2892 is read-write, some implementations may offer only more restrictive 2893 access, and this would be reported in the component properties. 2895 Note that not all components are likely to exist at all times in a 2896 particular implementation. While the capabilities will frequently 2897 indicate this non-existence, CEs may attempt to reference non- 2898 existent or non-permitted components anyway. The FORCES protocol 2899 mechanisms should include appropriate error indicators for this case. 2901 The mechanism defined above for non-supported component can also 2902 apply to attempts to reference non-existent array elements or to set 2903 read-only components. 2905 4.7.5. Element to Define LFB Capability Components 2907 The LFB class specification provides some flexibility for the FE 2908 implementation regarding how the LFB class is implemented. For 2909 example, the instance may have some limitations that are not inherent 2910 from the class definition, but rather the result of some 2911 implementation limitations. Some of these limitations are captured 2912 by the property information of the LFB components. The model allows 2913 for the notion of additional capability information. 2915 Such capability related information is expressed by the capability 2916 components of the LFB class. The capability components are always 2917 read-only attributes, and they are listed in a separate 2918 element in the . The 2919 element contains one or more elements, each defining one 2920 capability component. The format of the element is 2921 almost the same as the element, it differs in two 2922 aspects: it lacks the access mode attribute (because it is always 2923 read-only), and it lacks the element (because default 2924 value is not applicable to read-only attributes). 2926 Some examples of capability components follow: 2928 o The version of the LFB class that this LFB instance complies with; 2930 o Supported optional features of the LFB class; 2932 o Maximum number of configurable outputs for an output group; 2934 o Metadata pass-through limitations of the LFB; 2936 o Additional range restriction on operational components; 2938 The following example lists two capability attributes: 2940 2941 2942 version 2943 2944 LFB class version this instance is compliant with. 2945 2946 version 2947 2948 2949 limitBar 2950 2951 Maximum value of the "bar" attribute. 2952 2953 uint16 2954 2955 2957 4.7.6. Element for LFB Notification Generation 2959 The element contains the information about the occurrences 2960 for which instances of this LFB class can generate notifications to 2961 the CE. High level view on the declaration and operation of LFB 2962 events is described in Section 3.2.5. 2964 The element contains 0 or more elements, each of 2965 which declares a single event. The element has an eventID 2966 attribute giving the unique (per LFB class) ID of the event. The 2967 element will include: 2969 o element indicating which LFB field (component) is 2970 tested to generate the event; 2972 o element indicating what condition on the field will 2973 generate the event from a list of defined conditions; 2975 o element indicating what values are to be reported 2976 in the notification of the event. 2978 The example below demonstrates the different constructs. 2980 The element has a baseID attribute value, which is normally 2981 . The value of the baseID is the starting 2982 componentID for the path which identifies events. It must not be the 2983 same as the componentID of any top level components (including 2984 capabilities) of the LFB class. In derived LFBs (i.e. ones with a 2985 element) where the parent LFB class has an events 2986 declaration, the baseID must not be present in the derived LFB 2987 element. Instead, the baseID value from the parent LFB 2988 class is used. In the example shown the baseID is 7. 2990 2991 2992 Foochanged 2993 2994 An example event for a scalar 2995 2996 2997 foo 2998 2999 3000 3001 3002 3003 foo 3004 3006 3007 3009 3010 Goof1changed 3011 3012 An example event for a complex structure 3013 3014 3015 3016 goo 3017 f1 3018 3019 3020 3021 3022 3023 goo 3024 f1 3025 3026 3027 3029 3030 NewbarEntry 3031 3032 Event for a new entry created on table bar 3033 3034 3035 bar 3036 _barIndex_ 3037 3038 3039 3040 3041 bar 3042 _barIndex_ 3043 3044 3045 foo 3046 3047 3048 3050 3051 Gah11changed 3052 3053 Event for table gah, entry index 11 changing 3055 3056 3057 gah 3058 11 3059 3060 3061 3062 3063 gah 3064 11 3065 3066 3067 3069 3070 Gah10field1 3071 3072 Event for table gah, entry index 10, column field1 changing 3073 3074 3075 gah 3076 10 3077 field1 3078 3079 3080 3081 3082 gah 3083 10 3084 3085 3086 3087 3089 4.7.6.1. Element 3091 The element contains information identifying a field in 3092 the LFB that is to be monitored for events. 3094 The element contains one or more each of 3095 which may be followed by one or more elements. Each 3096 of these two elements represent the textual equivalent of a path 3097 select component of the LFB. 3099 The element contains the name of a component in the LFB 3100 or a component nested in an array or structure within the LFB. The 3101 name used in MUST identify a valid component within the 3102 containing LFB context. The first element in a MUST be 3103 an element. In the example shown, four LFB components 3104 foo, goo, bar and gah are used as s. 3106 In the simple case, an identifies an atomic component. 3107 This is the case illustrated in the event named Foochanged. 3108 is also used to address complex components such as 3109 arrays or structures. 3111 The first defined event, Foochanged, demonstrates how a scalar LFB 3112 component, foo, could be monitored to trigger an event. 3114 The second event, Goof1changed, demonstrates how a member of the 3115 complex structure goo could be monitored to trigger an event. 3117 The events named NewbarEntry, Gah11changed and Gah10field1 3118 represent monitoring of arrays bar and gah in differing details. 3120 If an identifies a complex component then a further 3121 may be used to refine the path to the target element. 3122 Defined event Goof1changed demonstrates how a second is 3123 used to point to member f1 of the structure goo. 3125 If an identifies an array then the following rules 3126 apply: 3128 o elements MUST be present as the next XML element 3129 after an which identifies an array component. 3130 MUST NOT occur other than after an array 3131 reference, as it is only meaningful in that context. 3133 o An may contain: 3135 * A numeric value to indicate that the event applies to a 3136 specific entry (by index) of the array. As an example, event 3137 Gah11changed shows how table gah's index 11 is being targeted 3138 for monitoring. 3140 * It is expected that the more common usage is to have the event 3141 being defined across all elements of the array (i.e a wildcard 3142 for all indices). In that case, the value of the 3143 MUST be a name rather than a numeric value. 3144 That same name can then be used as the value of 3145 in elements as described below. 3146 An example of a wild card table index is shown in event 3147 NewBarentry where the value is named 3148 _barIndex_ 3150 o An may follow an to further refine 3151 the path to the target element (Note: this is in the same spirit 3152 as the case where is used to further refine 3153 in the earlier example of a complex structure example 3154 of Goof1changed). The example event Gah10field1 illustrates how 3155 the column field1 of table gah is monitored for changes. 3157 It should be emphasized that the name in an element 3158 in defined event NewbarEntry is not a component name. It is a 3159 variable name for use in the elements (described in 3160 Section 4.7.6.3) of the given LFB definition. This name MUST be 3161 distinct from any component name that can validly occur in the 3162 clause. 3164 4.7.6.2. Element 3166 The event condition element represents a condition that triggers a 3167 notification. The list of conditions is: 3169 o the target must be an array, ending with a 3170 subscript indication. The event is generated when an entry in the 3171 array is created. This occurs even if the entry is created by CE 3172 direction. The event example NewbarEntry demonstrates the 3173 condition. 3175 o the target must be an array, ending with a 3176 subscript indication. The event is generated when an entry in the 3177 array is destroyed. This occurs even if the entry is destroyed by 3178 CE direction. 3180 o the event is generated whenever the target 3181 component changes in any way. For binary components such as up/ 3182 down, this reflects a change in state. It can also be used with 3183 numeric attributes, in which case any change in value results in a 3184 detected trigger. Event examples Foochanged, Gah11changed, and 3185 Gah10field1 illustrate the condition. 3187 o the event is generated whenever the target 3188 component becomes greater than the threshold. The threshold is an 3189 event property. 3191 o the event is generated whenever the target 3192 component becomes less than the threshold. The threshold is an 3193 event property. 3195 4.7.6.3. Element 3197 The element of an declare the information to 3198 be delivered by the FE along with the notification of the occurrence 3199 of the event. 3201 The element contains one or more 3202 elements. Each element identifies a piece of data from 3203 the LFB class to be reported. The notification carries that data as 3204 if the collection of elements had been defined in a 3205 structure. The syntax is exactly the same as used in the 3206 element, using and 3207 elements and so the same rules apply. Each element 3208 thus MUST identify a component in the LFB class. may 3209 contain integers. If they contain names, they MUST be names from 3210 elements of the in the event. The 3211 selection for the report will use the value for the subscript that 3212 identifies that specific element triggering the event. This can be 3213 used to reference the component causing the event, or to reference 3214 related information in parallel tables. 3216 In the example shown, in the case of the event Foochanged, the report 3217 will carry the value of foo; in the case of the defined event 3218 NewbarEntry acting on LFB component bar, which is an array, there are 3219 two items that are reported as indicated by the two 3220 declarations: 3222 o The first details what new entry was added in the 3223 table bar. Recall that _barIndex_ is declared as the event's 3224 and that by virtue of using a name 3225 instead of a numeric value, the is implied to be a 3226 wildcard and will carry whatever index of the new entry. 3228 o The second includes the value of LFB component foo 3229 at the time the new entry was created in bar. Reporting foo in 3230 this case is provided to demonstrate the flexibility of event 3231 reporting. 3233 This event reporting structure is designed to allow the LFB designer 3234 to specify information that is likely not known a priori by the CE 3235 and is likely needed by the CE to process the event. While the 3236 structure allows for pointing at large blocks of information (full 3237 arrays or complex structures) this is not recommended. Also, the 3238 variable reference/subscripting in reporting only captures a small 3239 portion of the kinds of related information. Chaining through index 3240 fields stored in a table, for example, is not supported. In general, 3241 the mechanism is an optimization for cases that have 3242 been found to be common, saving the CE from having to query for 3243 information it needs to understand the event. It does not represent 3244 all possible information needs. 3246 If any components referenced by the eventReport are optional, then 3247 the The report MUST use a protocol format that supports optional 3248 elements and allows for the non-existence of such elements. Any 3249 components which do not exist are not reported. 3251 4.7.6.4. Runtime control of events 3253 High level view on the declaration and operation of LFB events is 3254 described in Section 3.2.5. 3256 The provides additional components used in the path to 3257 reference the event. The path constitutes the baseID for events, 3258 followed by the ID for the specific event, followed by a value for 3259 each element if it exists in the . 3261 The event path will uniquely identify a specific occurrence of the 3262 event in the event notification to the CE. In the example provided, 3263 a notification with path of 7.7 uniquely identifies the event to be 3264 that caused by the change of foo; an event with path 7.9.100 uniquely 3265 identifies the event to be that caused by a creation of table bar 3266 entry with index/subscript 100. 3268 As described in the Section 4.8.5, event elements have properties 3269 associated with them. These properties include the subscription 3270 information indicating whether the CE wishes the FE to generate event 3271 reports for the event at all, thresholds for events related to level 3272 crossing, and filtering conditions that may reduce the set of event 3273 notifications generated by the FE. Details of the filtering 3274 conditions that can be applied are given in that section. The 3275 filtering conditions allow the FE to suppress floods of events that 3276 could result from oscillation around a condition value. For FEs that 3277 do not wish to support filtering, the filter properties can either be 3278 read only or not supported. 3280 In addition to identifying the event sources, the CE also uses the 3281 event path to activate runtime control of the event via the event 3282 properties (defined in Section 4.8.5) utilizing SET-PROP as defined 3283 in ForCES Protocol [2] operation. 3285 To activate event generation on the FE, a SET-PROP message 3286 referencing the event and registration property of the event is 3287 issued to the FE by the CE with any prefix of the path of the event. 3288 So, for an event defined on the example table bar, a SET-PROP with a 3289 path of 7.9 will subscribe the CE to all occurrences of that event on 3290 any entry of the table. This is particularly useful for the 3291 and conditions on tables. Events 3292 using those conditions will generally be defined with a field/ 3293 subscript sequence that identifies an array and ends with an 3294 element. Thus, the event notification will indicate 3295 which array entry has been created or destroyed. A typical 3296 subscriber will subscribe for the array, as opposed to a specific 3297 entry in an array, so it will use a shorter path. 3299 In the example provided, subscribing to 7.8 implies receiving all 3300 declared events from table bar. Subscribing to 7.8.100 implies 3301 receiving an event when subscript/index 100 table entry is created. 3303 Threshold and filtering conditions can only be applied to individual 3304 events. For events defined on elements of an array, this 3305 specification does not allow for defining a threshold or filtering 3306 condition on an event for all elements of an array. 3308 4.7.7. Element for LFB Operational Specification 3310 The element of the provides unstructured 3311 text (in XML sense) to verbally describe what the LFB does. 3313 4.8. Properties 3315 Components of LFBs have properties which are important to the CE. 3316 The most important property is the existence / readability / 3317 writeability of the element. Depending on the type of the component, 3318 other information may be of importance. 3320 The model provides the definition of the structure of property 3321 information. There is a base class of property information. For the 3322 array, alias, and event components there are subclasses of property 3323 information providing additional fields. This information is 3324 accessed by the CE (and updated where applicable) via the PL 3325 protocol. While some property information is writeable, there is no 3326 mechanism currently provided for checking the properties of a 3327 property element. Writeability can only be checked by attempting to 3328 modify the value. 3330 4.8.1. Basic Properties 3332 The basic property definition, along with the scalar dataTypeDef for 3333 accessibility is below. Note that this access permission information 3334 is generally read-only. 3336 3337 accessPermissionValues 3338 3339 The possible values of component access permission 3340 3341 3342 uchar 3343 3344 3345 None 3346 Access is prohibited 3347 3348 3349 Read-Only 3350 3351 Access to the component is read only 3352 3353 3354 3355 Write-Only 3356 3357 The component may be written, but not read 3358 3359 3360 3361 Read-Write 3362 3363 The component may be read or written 3364 3365 3366 3367 3368 3369 3370 baseElementProperties 3371 basic properties, accessibility 3372 3373 3374 accessibility 3375 3376 does the component exist, and 3377 can it be read or written 3378 3379 accessPermissionValues 3380 3381 3382 3384 4.8.2. Array Properties 3386 The properties for an array add a number of important pieces of 3387 information. These properties are also read-only. 3389 3390 arrayElementProperties 3391 3392 baseElementProperties 3393 3394 entryCount 3395 the number of entries in the array 3396 uint32 3397 3398 3399 highestUsedSubscript 3400 the last used subscript in the array 3401 uint32 3402 3403 3404 firstUnusedSubscript 3405 3406 The subscript of the first unused array element 3407 3408 uint32 3409 3410 3411 3413 4.8.3. String Properties 3415 The properties of a string specify the actual octet length and the 3416 maximum octet length for the element. The maximum length is included 3417 because an FE implementation may limit a string to be shorter than 3418 the limit in the LFB Class definition. 3420 3421 stringElementProperties 3422 3423 baseElementProperties 3424 3425 stringLength 3426 the number of octets in the string 3427 uint32 3428 3429 3430 maxStringLength 3431 3432 the maximum number of octets in the string 3433 3434 uint32 3435 3436 3437 3439 4.8.4. Octetstring Properties 3441 The properties of an octetstring specify the actual length and the 3442 maximum length, since the FE implementation may limit an octetstring 3443 to be shorter than the LFB Class definition. 3445 3446 octetstringElementProperties 3447 3448 baseElementProperties 3449 3450 octetstringLength 3451 3452 the number of octets in the octetstring 3453 3454 uint32 3455 3456 3457 maxOctetstringLength 3458 3459 the maximum number of octets in the octetstring 3460 3461 uint32 3462 3463 3464 3466 4.8.5. Event Properties 3468 The properties for an event add three (usually) writeable fields. 3469 One is the subscription field. 0 means no notification is generated. 3470 Any non-zero value (typically 1 is used) means that a notification is 3471 generated. The hysteresis field is used to suppress generation of 3472 notifications for oscillations around a condition value, and is 3473 described in the text for events. The threshold field is used for 3474 the and conditions. It 3475 indicates the value to compare the event target against. Using the 3476 properties allows the CE to set the level of interest. FEs which do 3477 not supporting setting the threshold for events will make this field 3478 read-only. 3480 3481 eventElementProperties 3482 3483 baseElementProperties 3484 3485 registration 3486 3487 has the CE registered to be notified of this event 3488 3489 uint32 3490 3491 3492 threshold 3493 comparison value for level crossing events 3494 3495 uint32 3497 3498 3499 eventHysteresis 3500 region to suppress event recurrence notices 3501 3502 3503 uint32 3504 3505 3506 eventCount 3507 number of occurrences to suppress 3508 3509 3510 uint32 3511 3512 3513 eventInterval 3514 time interval in ms between notifications 3515 3516 3517 uint32 3518 3519 3520 3522 4.8.5.1. Common Event Filtering 3524 The event properties have values for controlling several filter 3525 conditions. Support of these conditions is optional, but all 3526 conditions SHOULD be supported. Events which are reliably known not 3527 to be subject to rapid occurrence or other concerns may not support 3528 all filter conditions. 3530 Currently, three different filter condition variables are defined. 3531 These are eventCount, eventInterval, and eventHysteresis. Setting 3532 the condition variables to 0 (their default value) means that the 3533 condition is not checked. 3535 Conceptually, when an event is triggered, all configured conditions 3536 are checked. If no filter conditions are triggered, or if any 3537 trigger conditions are met, the event notification is generated. If 3538 there are filter conditions, and no condition is met, then no event 3539 notification is generated. Event filter conditions have reset 3540 behavior when an event notification is generated. If any condition 3541 is passed, and the notification is generated, the notification reset 3542 behavior is performed on all conditions, even those which had not 3543 passed. This provides a clean definition of the interaction of the 3544 various event conditions. 3546 An example of the interaction of conditions is an event with an 3547 eventCount property set to 5 and an eventInterval property set to 500 3548 milliseconds. Suppose that a burst of occurrences of this event is 3549 detected by the FE. The first occurrence will cause a notification 3550 to be sent to the CE. Then, if four more occurrences are detected 3551 rapidly (less than 0.5 seconds) they will not result in 3552 notifications. If two more occurrences are detected, then the second 3553 of those will result in a notification. Alternatively, if more than 3554 500 milliseconds has passed since the notification and an occurrence 3555 is detected, that will result in a notification. In either case, the 3556 count and time interval suppression is reset no matter which 3557 condition actually caused the notification. 3559 4.8.5.2. Event Hysteresis Filtering 3561 Events with numeric conditions can have hysteresis filters applied to 3562 them. The hysteresis level is defined by a property of the event. 3563 This allows the FE to notify the CE of the hysteresis applied, and if 3564 it chooses, the FE can allow the CE to modify the hysteresis. This 3565 applies to for a numeric field, and to 3566 and . The content of a 3567 element is a numeric value. When supporting hysteresis, 3568 the FE MUST track the value of the element and make sure that the 3569 condition has become untrue by at least the hysteresis from the event 3570 property. To be specific, if the hysteresis is V, then 3572 o For a condition, if the last notification was for 3573 value X, then the notification MUST NOT be generated 3574 until the value reaches X +/- V. 3576 o For a condition with threshold T, once the 3577 event has been generated at least once it MUST NOT be generated 3578 again until the field first becomes less than or equal to T - V, 3579 and then exceeds T. 3581 o For a condition with threshold T, once the event 3582 has been generate at least once it MUST NOT be generated again 3583 until the field first becomes greater than or equal to T + V, and 3584 then becomes less than T. 3586 4.8.5.3. Event Count Filtering 3588 Events may have a count filtering condition. This property, if set 3589 to a non-zero value, indicates the number of occurrences of the event 3590 that should be considered redundant and not result in a notification. 3591 Thus, if this property is set to 1, and no other conditions apply, 3592 then every other detected occurrence of the event will result in a 3593 notification. This particular meaning is chosen so that the value 1 3594 has a distinct meaning from the value 0. 3596 A conceptual implementation (not required) for this might be an 3597 internal suppression counter. Whenever an event is triggered, the 3598 counter is checked. If the counter is 0, a notification is 3599 generated. Whether a notification is generated or not, the counter 3600 is incremented. If the counter exceeds the configured value, it is 3601 reset to 0. In this conceptual implementation the reset behavior 3602 when a notification is generated can be thought of as setting the 3603 counter to 1. 3605 4.8.5.4. Event Time Filtering 3607 Events may have a time filtering condition. This property represents 3608 the minimum time interval (in the absence of some other filtering 3609 condition being passed) between generating notifications of detected 3610 events. This condition MUST only be passed if the time since the 3611 last notification of the event is longer than the configured interval 3612 in milliseconds. 3614 Conceptually, this can be thought of as a stored timestamp which is 3615 compared with the detection time, or as a timer that is running that 3616 resets a suppression flag. In either case, if a notification is 3617 generated due to passing any condition then the time interval 3618 detection MUST be restarted. 3620 4.8.6. Alias Properties 3622 The properties for an alias add three (usually) writeable fields. 3623 These combine to identify the target component the subject alias 3624 refers to. 3626 3627 aliasElementProperties 3628 3629 baseElementProperties 3630 3631 targetLFBClass 3632 the class ID of the alias target 3633 uint32 3634 3635 3636 targetLFBInstance 3637 the instance ID of the alias target 3638 uint32 3639 3640 3641 targetComponentPath 3642 3643 the path to the component target 3644 each 4 octets is read as one path element, 3645 using the path construction in the PL protocol, 3646 [2]. 3647 3648 octetstring[128] 3649 3650 3651 3653 4.9. XML Schema for LFB Class Library Documents 3655 3656 3662 3663 3664 Schema for Defining LFB Classes and associated types (frames, 3665 data types for LFB attributes, and metadata). 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3677 3679 3681 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 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3767 3770 3771 3772 3773 3774 3775 3776 3778 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3802 3803 3804 3806 3807 3809 3810 3811 3812 3813 3814 3815 3816 3817 3819 3820 3821 3822 3823 3824 3825 3826 3827 3829 3830 3831 3832 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3845 3846 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3883 3885 3887 3889 3891 3893 3894 3895 3897 3898 3901 3902 3903 3904 3905 3906 3907 3908 3909 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3944 3945 3946 3947 3948 3949 3950 3951 3953 3954 3955 3956 3957 3958 3959 3960 3961 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3988 3989 3990 3991 3992 3993 3994 3995 3997 3998 3999 4000 4001 4002 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4015 4016 4017 4018 4019 4020 4021 4023 4025 4026 4027 4028 4029 4030 4031 4033 4034 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4083 4084 4086 4087 4088 4089 4090 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4133 4134 4135 4137 4138 4139 4140 4142 4143 4144 4145 4147 4149 4151 4153 4155 4156 4157 4158 4159 4160 4161 4163 4165 4167 4168 4169 4171 4172 4173 4174 4175 4176 4177 4178 4179 4181 5. FE Components and Capabilities 4183 A ForCES forwarding element handles traffic on behalf of a ForCES 4184 control element. While the standards will describe the protocol and 4185 mechanisms for this control, different implementations and different 4186 instances will have different capabilities. The CE MUST be able to 4187 determine what each instance it is responsible for is actually 4188 capable of doing. As stated previously, this is an approximation. 4189 The CE is expected to be prepared to cope with errors in requests and 4190 variations in detail not captured by the capabilities information 4191 about an FE. 4193 In addition to its capabilities, an FE will have information that can 4194 be used in understanding and controlling the forwarding operations. 4195 Some of this information will be read only, while others parts may 4196 also be writeable. 4198 In order to make the FE information easily accessible, the 4199 information is represented in an LFB. This LFB has a class, 4200 FEObject. The LFBClassID for this class is 1. Only one instance of 4201 this class will ever be present in an FE, and the instance ID of that 4202 instance in the protocol is 1. Thus, by referencing the components 4203 of class:1, instance:1 a CE can get the general information about the 4204 FE. The FEObject LFB Class is described in this section. 4206 There will also be an FEProtocol LFB Class. LFBClassID 2 is reserved 4207 for that class. There will be only one instance of that class as 4208 well. Details of that class are defined in the ForCES Protocol [2] 4209 document. 4211 5.1. XML for FEObject Class definition 4213 4214 4217 4218 4219 LFBAdjacencyLimitType 4220 Describing the Adjacent LFB 4221 4222 4223 NeighborLFB 4224 ID for that LFB Class 4225 uint32 4226 4227 4228 ViaPorts 4229 4230 the ports on which we can connect 4231 4232 4233 string 4234 4235 4236 4237 4238 4239 PortGroupLimitType 4240 4241 Limits on the number of ports in a given group 4242 4243 4244 4245 PortGroupName 4246 Group Name 4247 string 4249 4250 4251 MinPortCount 4252 Minimum Port Count 4253 4254 uint32 4255 4256 4257 MaxPortCount 4258 Max Port Count 4259 4260 uint32 4261 4262 4263 4264 4265 SupportedLFBType 4266 table entry for supported LFB 4267 4268 4269 LFBName 4270 4271 The name of a supported LFB Class 4272 4273 string 4274 4275 4276 LFBClassID 4277 the id of a supported LFB Class 4278 uint32 4279 4280 4281 LFBVersion 4282 4283 The version of the LFB Class used 4284 by this FE. 4285 4286 string 4287 4288 4289 LFBOccurrenceLimit 4290 4291 the upper limit of instances of LFBs of this class 4292 4293 4294 uint32 4295 4296 4298 4299 PortGroupLimits 4300 Table of Port Group Limits 4301 4302 4303 PortGroupLimitType 4304 4305 4306 4307 4308 CanOccurAfters 4309 4310 List of LFB Classes that this LFB class can follow 4311 4312 4313 4314 LFBAdjacencyLimitType 4315 4316 4317 4319 4320 CanOccurBefores 4321 4322 List of LFB Classes that can follow this LFB class 4323 4324 4325 4326 LFBAdjacencyLimitType 4327 4328 4329 4330 4331 4332 FEStateValues 4333 The possible values of status 4334 4335 uchar 4336 4337 4338 AdminDisable 4339 4340 FE is administratively disabled 4341 4342 4343 4344 OperDisable 4345 FE is operatively disabled 4346 4347 4348 OperEnable 4349 FE is operating 4350 4351 4352 4353 4354 4355 FEConfiguredNeighborType 4356 Details of the FE's Neighbor 4357 4358 4359 NeighborID 4360 Neighbors FEID 4361 uint32 4362 4363 4364 InterfaceToNeighbor 4365 4366 FE's interface that connects to this neighbor 4367 4368 4369 string 4370 4371 4372 NeighborInterface 4373 4374 The name of the interface on the neighbor to 4375 which this FE is adjacent. This is required 4376 In case two FEs are adjacent on more than 4377 one interface. 4378 4379 4380 string 4381 4382 4383 4384 4385 LFBSelectorType 4386 4387 Unique identification of an LFB class-instance 4388 4389 4390 4391 LFBClassID 4392 LFB Class Identifier 4393 uint32 4394 4395 4396 LFBInstanceID 4397 LFB Instance ID 4398 uint32 4399 4400 4401 4402 4403 LFBLinkType 4404 4405 Link between two LFB instances of topology 4406 4407 4408 4409 FromLFBID 4410 LFB src 4411 LFBSelectorType 4412 4413 4414 FromPortGroup 4415 src port group 4416 string 4417 4418 4419 FromPortIndex 4420 src port index 4421 uint32 4422 4423 4424 ToLFBID 4425 dst LFBID 4426 LFBSelectorType 4427 4428 4429 ToPortGroup 4430 dst port group 4431 string 4432 4433 4434 ToPortIndex 4435 dst port index 4436 uint32 4437 4438 4439 4440 4441 4442 4443 FEObject 4444 Core LFB: FE Object 4445 1.0 4446 4447 4448 LFBTopology 4449 the table of known Topologies 4450 4451 LFBLinkType 4452 4453 4454 4455 LFBSelectors 4456 4457 table of known active LFB classes and 4458 instances 4459 4460 4461 LFBSelectorType 4462 4463 4464 4465 FEName 4466 name of this FE 4467 string[40] 4468 4469 4470 FEID 4471 ID of this FE 4472 uint32 4473 4474 4475 FEVendor 4476 vendor of this FE 4477 string[40] 4478 4479 4480 FEModel 4481 model of this FE 4482 string[40] 4483 4484 4485 FEState 4486 State of this FE 4487 FEStateValues 4488 4489 4490 FENeighbors 4491 table of known neighbors 4492 4493 4494 FEConfiguredNeighborType 4495 4496 4497 4498 4499 4500 ModifiableLFBTopology 4501 4502 Whether Modifiable LFB is supported 4503 4504 4505 boolean 4506 4507 4508 SupportedLFBs 4509 List of all supported LFBs 4510 4511 4512 SupportedLFBType 4513 4514 4515 4516 4517 4518 4520 5.2. FE Capabilities 4522 The FE Capability information is contained in the capabilities 4523 element of the class definition. As described elsewhere, capability 4524 information is always considered to be read-only. 4526 The currently defined capabilities are ModifiableLFBTopology and 4527 SupportedLFBs. Information as to which components of the FEObject 4528 LFB are supported is accessed by the properties information for those 4529 components. 4531 5.2.1. ModifiableLFBTopology 4533 This component has a boolean value that indicates whether the LFB 4534 topology of the FE may be changed by the CE. If the component is 4535 absent, the default value is assumed to be true, and the CE presumes 4536 the LFB topology may be changed. If the value is present and set to 4537 false, the LFB topology of the FE is fixed. If the topology is 4538 fixed, the SupportedLFBs element may be omitted, and the list of 4539 supported LFBs is inferred by the CE from the LFB topology 4540 information. If the list of supported LFBs is provided when 4541 ModifiableLFBTopology is false, the CanOccurBefore and CanOccurAfter 4542 information should be omitted. 4544 5.2.2. SupportedLFBs and SupportedLFBType 4546 One capability that the FE should include is the list of supported 4547 LFB classes. The SupportedLFBs component, is an array that contains 4548 the information about each supported LFB Class. The array structure 4549 type is defined as the SupportedLFBType dataTypeDef. 4551 Each entry in the SupportedLFBs array describes an LFB class that the 4552 FE supports. In addition to indicating that the FE supports the 4553 class, FEs with modifiable LFB topology SHOULD include information 4554 about how LFBs of the specified class may be connected to other LFBs. 4555 This information SHOULD describe which LFB classes the specified LFB 4556 class may succeed or precede in the LFB topology. The FE SHOULD 4557 include information as to which port groups may be connected to the 4558 given adjacent LFB class. If port group information is omitted, it 4559 is assumed that all port groups may be used. This capability 4560 information on the acceptable ordering and connection of LFBs MAY be 4561 omitted if the implementor concludes that the actual constraints are 4562 such that the information would be misleading for the CE. 4564 5.2.2.1. LFBName 4566 This component has as its value the name of the LFB Class being 4567 described. 4569 5.2.2.2. LFBClassID 4571 The numeric ID of the LFB Class being described. While conceptually 4572 redundant with the LFB Name, both are included for clarity and to 4573 allow consistency checking. 4575 5.2.2.3. LFBVersion 4577 The version string specifying the LFB Class version supported by this 4578 FE. As described above in versioning, an FE can support only a 4579 single version of a given LFB Class. 4581 5.2.2.4. LFBOccurrenceLimit 4583 This component, if present, indicates the largest number of instances 4584 of this LFB class the FE can support. For FEs that do not have the 4585 capability to create or destroy LFB instances, this can either be 4586 omitted or be the same as the number of LFB instances of this class 4587 contained in the LFB list attribute. 4589 5.2.2.5. PortGroupLimits and PortGroupLimitType 4591 The PortGroupLimits component is an array of information about the 4592 port groups supported by the LFB class. The structure of the port 4593 group limit information is defined by the PortGroupLimitType 4594 dataTypeDef. 4596 Each PortGroupLimits array entry contains information describing a 4597 single port group of the LFB class. Each array entry contains the 4598 name of the port group in the PortGroupName component, the fewest 4599 number of ports that can exist in the group in the MinPortCount 4600 component, and the largest number of ports that can exist in the 4601 group in the MaxPortCount component. 4603 5.2.2.6. CanOccurAfters and LFBAdjacencyLimitType 4605 The CanOccurAfters component is an array that contains the list of 4606 LFBs the described class can occur after. The array entries are 4607 defined in the LFBAdjacencyLimitType dataTypeDef. 4609 The array entries describe a permissible positioning of the described 4610 LFB class, referred to here as the SupportedLFB. Specifically, each 4611 array entry names an LFB that can topologically precede that LFB 4612 class. That is, the SupportedLFB can have an input port connected to 4613 an output port of an LFB that appears in the CanOccurAfters array. 4614 The LFB class that the SupportedLFB can follow is identified by the 4615 NeighborLFB component (of the LFBAdjacencyLimitType dataTypeDef) of 4616 the CanOccurAfters array entry. If this neighbor can only be 4617 connected to a specific set of input port groups, then the viaPort 4618 component is included. This component is an array, with one entry 4619 for each input port group of the SupportedLFB that can be connected 4620 to an output port of the NeighborLFB. 4622 [e.g., Within a SupportedLFBs entry, each array entry of the 4623 CanOccurAfters array must have a unique NeighborLFB, and within each 4624 such array entry each viaPort must represent a distinct and valid 4625 input port group of the SupportedLFB. The LFB Class definition 4626 schema does not yet support these uniqueness constraints.] 4628 5.2.2.7. CanOccurBefores and LFBAdjacencyLimitType 4630 The CanOccurBefores array holds the information about which LFB 4631 classes can follow the described class. Structurally this element 4632 parallels CanOccurAfters, and uses the same type definition for the 4633 array entries. 4635 The array entries list those LFB classes that the SupportedLFB may 4636 precede in the topology. In this component, the entries in the 4637 viaPort component of the array value represent the output port groups 4638 of the SupportedLFB that may be connected to the NeighborLFB. As 4639 with CanOccurAfters, viaPort may have multiple entries if multiple 4640 output ports may legitimately connect to the given NeighborLFB class. 4642 [And a similar set of uniqueness constraints apply to the 4643 CanOccurBefore clauses, even though an LFB may occur both in 4644 CanOccurAfter and CanOccurBefore.] 4646 5.2.2.8. LFBClassCapabilities 4648 While it would be desirable to include class capability level 4649 information, this is not included in the model. While such 4650 information belongs in the FE Object in the supported class table, 4651 the contents of that information would be class specific. The 4652 currently expected encoding structures for transferring information 4653 between the CE and FE are such that allowing completely unspecified 4654 information would be likely to induce parse errors. We could specify 4655 that the information is encoded in an octetstring, but then we would 4656 have to define the internal format of that octet string. 4658 As there also are not currently any defined LFB Class level 4659 Capabilities that the FE needs to report, this information is not 4660 present now, but may be added in a future version of the FE Object. 4661 (This is an example of a case where versioning, rather than 4662 inheritance, would be needed, since the FE Object must have class ID 4663 1 and instance ID 1 so that the protocol behavior can start by 4664 finding this object.) 4666 5.3. FE Components 4668 The element is included if the class definition contains 4669 the definition of the components of the FE Object that are not 4670 considered "capabilities". Some of these components are writeable, 4671 and some are read-only, which is determinable by examining the 4672 property information of the components. 4674 5.3.1. FEState 4676 This component carries the overall state of the FE. For now, it is 4677 restricted to the strings AdminDisable, OperDisable and OperEnable. 4679 5.3.2. LFBSelectors and LFBSelectorType 4681 The LFBSelectors component is an array of information about the LFBs 4682 currently accessible via ForCES in the FE. The structure of the LFB 4683 information is defined by the LFBSelectorType dataTypeDef. 4685 Each entry in the array describes a single LFB instance in the FE. 4686 The array entry contains the numeric class ID of the class of the LFB 4687 instance and the numeric instance ID for this instance. 4689 5.3.3. LFBTopology and LFBLinkType 4691 The optional LFBTopology component contains information about each 4692 inter-LFB link inside the FE, where each link is described in an 4693 LFBLinkType dataTypeDef. The LFBLinkType component contains 4694 sufficient information to identify precisely the end points of a 4695 link. The FromLFBID and ToLFBID components specify the LFB instances 4696 at each end of the link, and MUST reference LFBs in the LFB instance 4697 table. The FromPortGroup and ToPortGroup MUST identify output and 4698 input port groups defined in the LFB classes of the LFB instances 4699 identified by FromLFBID and ToLFBID. The FromPortIndex and 4700 ToPortIndex components select the entries from the port groups that 4701 this link connects. All links are uniquely identified by the 4702 FromLFBID, FromPortGroup, and FromPortIndex fields. Multiple links 4703 may have the same ToLFBID, ToPortGroup, and ToPortIndex as this model 4704 supports fan in of inter- LFB links but not fan out. 4706 5.3.4. FENeighbors and FEConfiguredNeighborType 4708 The FENeighbors component is an array of information about manually 4709 configured adjacencies between this FE and other FEs. The content of 4710 the array is defined by the FEConfiguredNeighborType dataTypeDef. 4712 This array is intended to capture information that may be configured 4713 on the FE and is needed by the CE, where one array entry corresponds 4714 to each configured neighbor. Note that this array is not intended to 4715 represent the results of any discovery protocols, as those will have 4716 their own LFBs. This component is optional. 4718 While there may be many ways to configure neighbors, the FE-ID is the 4719 best way for the CE to correlate entities. And the interface 4720 identifier (name string) is the best correlator. The CE will be able 4721 to determine the IP address and media level information about the 4722 neighbor from the neighbor directly. Omitting that information from 4723 this table avoids the risk of incorrect double configuration. 4725 Information about the intended forms of exchange with a given 4726 neighbor is not captured here, only the adjacency information is 4727 included. 4729 5.3.4.1. NeighborID 4731 This is the ID in some space meaningful to the CE for the neighbor. 4733 5.3.4.2. InterfaceToNeighbor 4735 This identifies the interface through which the neighbor is reached. 4737 5.3.4.3. NeighborInterface 4739 This identifies the interface on the neighbor through which the 4740 neighbor is reached. The interface identification is needed when 4741 either only one side of the adjacency has configuration information, 4742 or the two FEs are adjacent on more than one interface. 4744 6. Satisfying the Requirements on FE Model 4746 This section describes how the proposed FE model meets the 4747 requirements outlined in Section 5 of RFC3654 [4]. The requirements 4748 can be separated into general requirements (Section 5, 5.1 - 5.4) and 4749 the specification of the minimal set of logical functions that the FE 4750 model must support (Section 5.5). 4752 The general requirement on the FE model is that it be able to express 4753 the logical packet processing capability of the FE, through both a 4754 capability and a state model. In addition, the FE model is expected 4755 to allow flexible implementations and be extensible to allow defining 4756 new logical functions. 4758 A major component of the proposed FE model is the Logical Function 4759 Block (LFB) model. Each distinct logical function in an FE is 4760 modeled as an LFB. Operational parameters of the LFB that must be 4761 visible to the CE are conceptualized as LFB components. These 4762 components express the capability of the FE and support flexible 4763 implementations by allowing an FE to specify which optional features 4764 are supported. The components also indicate whether they are 4765 configurable by the CE for an LFB class. Configurable components 4766 provide the CE some flexibility in specifying the behavior of an LFB. 4767 When multiple LFBs belonging to the same LFB class are instantiated 4768 on an FE, each of those LFBs could be configured with different 4769 component settings. By querying the settings of the components for 4770 an instantiated LFB, the CE can determine the state of that LFB. 4772 Instantiated LFBs are interconnected in a directed graph that 4773 describes the ordering of the functions within an FE. This directed 4774 graph is described by the topology model. The combination of the 4775 components of the instantiated LFBs and the topology describe the 4776 packet processing functions available on the FE (current state). 4778 Another key component of the FE model is the FE components. The FE 4779 components are used mainly to describe the capabilities of the FE, 4780 but they also convey information about the FE state. 4782 The FE model includes only the definition of the FE Object LFB 4783 itself. Meeting the full set of working group requirements requires 4784 other LFBs. The class definitions for those LFBs will be provided in 4785 other documents. 4787 7. Using the FE model in the ForCES Protocol 4789 The actual model of the forwarding plane in a given NE is something 4790 the CE must learn and control by communicating with the FEs (or by 4791 other means). Most of this communication will happen in the post- 4792 association phase using the ForCES protocol. The following types of 4793 information must be exchanged between CEs and FEs via the ForCES 4794 Protocol [2]: 4796 1. FE topology query; 4798 2. FE capability declaration; 4800 3. LFB topology (per FE) and configuration capabilities query; 4802 4. LFB capability declaration; 4804 5. State query of LFB components; 4806 6. Manipulation of LFB components; 4808 7. LFB topology reconfiguration. 4810 Items 1) through 5) are query exchanges, where the main flow of 4811 information is from the FEs to the CEs. Items 1) through 4) are 4812 typically queried by the CE(s) in the beginning of the post- 4813 association (PA) phase, though they may be repeatedly queried at any 4814 time in the PA phase. Item 5) (state query) will be used at the 4815 beginning of the PA phase, and often frequently during the PA phase 4816 (especially for the query of statistical counters). 4818 Items 6) and 7) are "command" types of exchanges, where the main flow 4819 of information is from the CEs to the FEs. Messages in Item 6) (the 4820 LFB re-configuration commands) are expected to be used frequently. 4822 Item 7) (LFB topology re-configuration) is needed only if dynamic LFB 4823 topologies are supported by the FEs and it is expected to be used 4824 infrequently. 4826 The inter-FE topology (item 1 above) can be determined by the CE in 4827 many ways. Neither this document nor the ForCES Protocol [2] 4828 document mandates a specific mechanism. The LFB Class definition 4829 does include the capability for an FE to be configured with, and 4830 provides to the CE in response to a query, the identity of its 4831 neighbors. There may also be defined specific LFB classes and 4832 protocols for neighbor discovery. Routing protocols may be used by 4833 the CE for adjacency determination. The CE may be configured with 4834 the relevant information. 4836 The relationship between the FE model and the seven post-association 4837 messages are visualized in Figure 12: 4839 +--------+ 4840 ..........-->| CE | 4841 /----\ . +--------+ 4842 \____/ FE Model . ^ | 4843 | |................ (1),2 | | 6, 7 4844 | | (off-line) . 3, 4, 5 | | 4845 \____/ . | v 4846 . +--------+ 4847 e.g. RFCs ..........-->| FE | 4848 +--------+ 4850 Figure 12: Relationship between the FE model and the ForCES protocol 4851 messages, where (1) is part of the ForCES base protocol, and the 4852 rest are defined by the FE model. 4854 The actual encoding of these messages is defined by the ForCES 4855 Protocol [2] document and is beyond the scope of the FE model. Their 4856 discussion is nevertheless important here for the following reasons: 4858 o These PA model components have considerable impact on the FE 4859 model. For example, some of the above information can be 4860 represented as components of the LFBs, in which case such 4861 components must be defined in the LFB classes. 4863 o The understanding of the type of information that must be 4864 exchanged between the FEs and CEs can help to select the 4865 appropriate protocol format and the actual encoding method (such 4866 as XML, TLVs). 4868 o Understanding the frequency of these types of messages should 4869 influence the selection of the protocol format (efficiency 4870 considerations). 4872 An important part of the FE model is the port the FE uses for its 4873 message exchanges to and from the CE. In the case that a dedicated 4874 port is used for CE-FE communication, we propose to use a special 4875 port LFB, called the CE-FE Port LFB (a subclass of the general Port 4876 LFB in Section 6.1), to model this dedicated CE-FE port. The CE-FE 4877 Port LFB acts as both a source and sink for the traffic from and to 4878 the CE. Sometimes the CE-FE traffic does not have its own dedicated 4879 port, instead the data fabric is shared for the data plane traffic 4880 and the CE-FE traffic. A special processing LFB can be used to model 4881 the ForCES packet encapsulation and decapsulation in such cases. 4883 The remaining sub-sections of this section address each of the seven 4884 message types. 4886 7.1. FE Topology Query 4888 An FE may contain zero, one or more external ingress ports. 4889 Similarly, an FE may contain zero, one or more external egress ports. 4890 In other words, not every FE has to contain any external ingress or 4891 egress interfaces. For example, Figure 13 shows two cascading FEs. 4892 FE #1 contains one external ingress interface but no external egress 4893 interface, while FE #2 contains one external egress interface but no 4894 ingress interface. It is possible to connect these two FEs together 4895 via their internal interfaces to achieve the complete ingress-to- 4896 egress packet processing function. This provides the flexibility to 4897 spread the functions across multiple FEs and interconnect them 4898 together later for certain applications. 4900 While the inter-FE communication protocol is out of scope for ForCES, 4901 it is up to the CE to query and understand how multiple FEs are 4902 inter-connected to perform a complete ingress-egress packet 4903 processing function, such as the one described in Figure 13. The 4904 inter-FE topology information may be provided by FEs, may be hard- 4905 coded into CE, or may be provided by some other entity (e.g., a bus 4906 manager) independent of the FEs. So while the ForCES Protocol [2] 4907 supports FE topology query from FEs, it is optional for the CE to use 4908 it, assuming the CE has other means to gather such topology 4909 information. 4911 +-----------------------------------------------------+ 4912 | +---------+ +------------+ +---------+ | 4913 input| | | | | | output | 4914 ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ 4915 | | port | |Decompressor| |Forwarder| FE | | 4916 | +---------+ +------------+ +---------+ #1 | | 4917 +-----------------------------------------------------+ V 4918 | 4919 +-----------------------<-----------------------------+ 4920 | 4921 | +----------------------------------------+ 4922 V | +------------+ +----------+ | 4923 | input | | | | output | 4924 +->--+->|Header |-->| Egress |---------+--> 4925 | |Compressor | | port | FE | 4926 | +------------+ +----------+ #2 | 4927 +----------------------------------------+ 4929 Figure 13: An example of two FEs connected together 4931 Once the inter-FE topology is discovered by the CE after this query, 4932 it is assumed that the inter-FE topology remains static. However, it 4933 is possible that an FE may go down during the NE operation, or a 4934 board may be inserted and a new FE activated, so the inter-FE 4935 topology will be affected. It is up to the ForCES protocol to 4936 provide a mechanism for the CE to detect such events and deal with 4937 the change in FE topology. FE topology is outside the scope of the 4938 FE model. 4940 7.2. FE Capability Declarations 4942 FEs will have many types of limitations. Some of the limitations 4943 must be expressed to the CEs as part of the capability model. The 4944 CEs must be able to query these capabilities on a per-FE basis. 4945 Examples: 4947 o Metadata passing capabilities of the FE. Understanding these 4948 capabilities will help the CE to evaluate the feasibility of LFB 4949 topologies, and hence to determine the availability of certain 4950 services. 4952 o Global resource query limitations (applicable to all LFBs of the 4953 FE). 4955 o LFB supported by the FE. 4957 o LFB class instantiation limit. 4959 o LFB topological limitations (linkage constraint, ordering etc.) 4961 7.3. LFB Topology and Topology Configurability Query 4963 The ForCES protocol must provide the means for the CEs to discover 4964 the current set of LFB instances in an FE and the interconnections 4965 between the LFBs within the FE. In addition, sufficient information 4966 should be available to determine whether the FE supports any CE- 4967 initiated (dynamic) changes to the LFB topology, and if so, determine 4968 the allowed topologies. Topology configurability can also be 4969 considered as part of the FE capability query as described in Section 4970 9.3. 4972 7.4. LFB Capability Declarations 4974 LFB class specifications define a generic set of capabilities. When 4975 an LFB instance is implemented (instantiated) on a vendor's FE, some 4976 additional limitations may be introduced. Note that we discuss only 4977 those limitations that are within the flexibility of the LFB class 4978 specification. That is, the LFB instance will remain compliant with 4979 the LFB class specification despite these limitations. For example, 4980 certain features of an LFB class may be optional, in which case it 4981 must be possible for the CE to determine if an optional feature is 4982 supported by a given LFB instance or not. Also, the LFB class 4983 definitions will probably contain very few quantitative limits (e.g., 4984 size of tables), since these limits are typically imposed by the 4985 implementation. Therefore, quantitative limitations should always be 4986 expressed by capability arguments. 4988 LFB instances in the model of a particular FE implementation will 4989 possess limitations on the capabilities defined in the corresponding 4990 LFB class. The LFB class specifications must define a set of 4991 capability arguments, and the CE must be able to query the actual 4992 capabilities of the LFB instance via querying the value of such 4993 arguments. The capability query will typically happen when the LFB 4994 is first detected by the CE. Capabilities need not be re-queried in 4995 case of static limitations. In some cases, however, some 4996 capabilities may change in time (e.g., as a result of adding/removing 4997 other LFBs, or configuring certain components of some other LFB when 4998 the LFBs share physical resources), in which case additional 4999 mechanisms must be implemented to inform the CE about the changes. 5001 The following two broad types of limitations will exist: 5003 o Qualitative restrictions. For example, a standardized multi- 5004 field classifier LFB class may define a large number of 5005 classification fields, but a given FE may support only a subset of 5006 those fields. 5008 o Quantitative restrictions, such as the maximum size of tables, 5009 etc. 5011 The capability parameters that can be queried on a given LFB class 5012 will be part of the LFB class specification. The capability 5013 parameters should be regarded as special components of the LFB. The 5014 actual values of these components may be, therefore, obtained using 5015 the same component query mechanisms as used for other LFB components. 5017 Capability components are read-only arguments. In cases where some 5018 implementations may allow CE modification of the value, the 5019 information must be represented as an operational component, not a 5020 capability component. 5022 Assuming that capabilities will not change frequently, the efficiency 5023 of the protocol/schema/encoding is of secondary concern. 5025 Much of this restrictive information is captured by the component 5026 property information, and so can be access uniformly for all 5027 information within the model. 5029 7.5. State Query of LFB Components 5031 This feature must be provided by all FEs. The ForCES protocol and 5032 the data schema/encoding conveyed by the protocol must together 5033 satisfy the following requirements to facilitate state query of the 5034 LFB components: 5036 o Must permit FE selection. This is primarily to refer to a single 5037 FE, but referring to a group of (or all) FEs may optionally be 5038 supported. 5040 o Must permit LFB instance selection. This is primarily to refer to 5041 a single LFB instance of an FE, but optionally addressing of a 5042 group of LFBs (or all) may be supported. 5044 o Must support addressing of individual components of an LFB. 5046 o Must provide efficient encoding and decoding of the addressing 5047 info and the configured data. 5049 o Must provide efficient data transmission of the component state 5050 over the wire (to minimize communication load on the CE-FE link). 5052 7.6. LFB Component Manipulation 5054 The FE Model provides for the definition of LFB Classes. Each class 5055 has a globally unique identifier. Information within the class is 5056 represented as components and assigned identifiers within the scope 5057 of that class. This model also specifies that instances of LFB 5058 Classes have identifiers. The combination of class identifiers, 5059 instance identifiers, and component identifiers are used by the 5060 protocol to reference the LFB information in the protocol operations. 5062 7.7. LFB Topology Re-configuration 5064 Operations that will be needed to reconfigure LFB topology: 5066 o Create a new instance of a given LFB class on a given FE. 5068 o Connect a given output of LFB x to the given input of LFB y. 5070 o Disconnect: remove a link between a given output of an LFB and a 5071 given input of another LFB. 5073 o Delete a given LFB (automatically removing all interconnects to/ 5074 from the LFB). 5076 8. Example LFB Definition 5078 This section contains an example LFB definition. While some 5079 properties of LFBs are shown by the FE Object LFB, this endeavors to 5080 show how a data plane LFB might be build. This example is a 5081 fictional case of an interface supporting a coarse WDM optical 5082 interface that carries Frame Relay traffic. The statistical 5083 information (including error statistics) is omitted. 5085 Later portions of this example include references to protocol 5086 operations. The operations described are operations the protocol 5087 needs to support. The exact format and fields are purely 5088 informational here, as the ForCES Protocol [2] document defines the 5089 precise syntax and symantics of its operations. 5091 5092 5095 5096 5097 FRFrame 5098 5099 A frame relay frame, with DLCI without 5100 stuffing) 5101 5102 5103 5104 IPFrame 5105 An IP Packet 5106 5107 5108 5109 5110 frequencyInformationType 5111 5112 Information about a single CWDM frequency 5113 5114 5115 5116 LaserFrequency 5117 encoded frequency(channel) 5118 uint32 5119 5120 5121 FrequencyState 5122 state of this frequency 5123 PortStatusValues 5124 5125 5126 LaserPower 5127 current observed power 5128 uint32 5129 5130 5131 FrameRelayCircuits 5132 5133 Information about circuits on this Frequency 5134 5135 5136 frameCircuitsType 5137 5138 5139 5140 5141 5142 frameCircuitsType 5143 5144 Information about a single Frame Relay circuit 5145 5146 5147 5148 DLCI 5149 DLCI of the circuit 5150 uint32 5151 5152 5153 CircuitStatus 5154 state of the circuit 5155 PortStatusValues 5156 5157 5158 isLMI 5159 is this the LMI circuit 5160 boolean 5161 5162 5163 associatedPort 5164 5165 which input / output port is associated 5166 with this circuit 5167 5168 uint32 5169 5170 5171 5172 5173 PortStatusValues 5174 5175 The possible values of status. Used for both 5176 administrative and operational status 5177 5178 5179 uchar 5180 5181 5182 Disabled 5183 the component is disabled 5184 5185 5186 Enabled 5187 FE is operatively enabled 5188 5189 5190 5191 5192 5193 5194 5195 DLCI 5196 The DLCI the frame arrived on 5197 12 5198 uint32 5199 5200 5201 LaserChannel 5202 The index of the laser channel 5203 34 5204 uint32 5205 5206 5207 5208 5209 5210 FrameLaserLFB 5211 Fictional LFB for Demonstrations 5212 1.0 5213 5214 5215 LMIfromFE 5216 5217 Ports for LMI traffic, for transmission 5218 5219 5220 5221 FRFrame 5222 5223 5224 DLCI 5225 LaserChannel 5226 5227 5228 5229 5230 DatafromFE 5231 5232 Ports for data to be sent on circuits 5233 5234 5235 5236 IPFrame 5237 5238 5239 DLCI 5240 LaserChannel 5241 5242 5244 5245 5246 5247 5248 LMItoFE 5249 5250 Ports for LMI traffic for processing 5251 5252 5253 5254 FRFrame 5255 5256 5257 DLCI 5258 LaserChannel 5259 5260 5261 5262 5263 DatatoFE 5264 5265 Ports for Data traffic for processing 5266 5267 5268 5269 IPFrame 5270 5271 5272 DLCI 5273 LaserChannel 5274 5275 5276 5277 5278 5279 5280 AdminPortState 5281 is this port allowed to function 5282 PortStatusValues 5283 5284 5285 FrequencyInformation 5286 5287 table of information per CWDM frequency 5288 5289 5290 frequencyInformationType 5291 5293 5294 5295 5296 5297 OperationalState 5298 5299 whether the port over all is operational 5300 5301 PortStatusValues 5302 5303 5304 MaximumFrequencies 5305 5306 how many laser frequencies are there 5307 5308 uint16 5309 5310 5311 MaxTotalCircuits 5312 5313 Total supportable Frame Relay Circuits, across 5314 all laser frequencies 5315 5316 5317 uint32 5318 5319 5320 5321 5322 FrequencyState 5323 5324 The state of a frequency has changed 5325 5326 5327 FrequencyInformation 5328 _FrequencyIndex_ 5329 FrequencyState 5330 5331 5332 5333 5334 5335 FrequencyInformation 5336 _FrequencyIndex_ 5337 FrequencyState 5338 5339 5340 5341 5342 CreatedFrequency 5343 A new frequency has appeared 5344 5345 FrequencyInformation> 5346 _FrequencyIndex_ 5347 5348 5349 5350 5351 FrequencyInformation 5352 _FrequencyIndex_ 5353 LaserFrequency 5354 5355 5356 5357 5358 DeletedFrequency 5359 5360 A frequency Table entry has been deleted 5361 5362 5363 FrequencyInformation 5364 _FrequencyIndex_ 5365 5366 5367 5368 5369 PowerProblem 5370 5371 there are problems with the laser power level 5372 5373 5374 FrequencyInformation 5375 _FrequencyIndex_ 5376 LaserPower 5377 5378 5379 5380 5381 FrequencyInformation 5382 _FrequencyIndex_ 5383 LaserPower 5384 5385 5386 FrequencyInformation 5387 _FrequencyIndex_ 5388 LaserFrequency 5390 5391 5392 5393 5394 FrameCircuitChanged 5395 5396 the state of an Fr circuit on a frequency 5397 has changed 5398 5399 5400 FrequencyInformation 5401 _FrequencyIndex_ 5402 FrameRelayCircuits 5403 FrameCircuitIndex 5404 CircuitStatus 5405 5406 5407 5408 5409 FrequencyInformation 5410 _FrequencyIndex_ 5411 FrameRelayCircuits 5412 FrameCircuitIndex 5413 CircuitStatus 5414 5415 5416 FrequencyInformation 5417 _FrequencyIndex_ 5418 FrameRelayCircuits 5419 FrameCircuitIndex 5420 DLCI 5421 5422 5423 5424 5425 5426 5427 5429 8.1. Data Handling 5431 This LFB is designed to handle data packets coming in from or going 5432 out to the external world. It is not a full port, and it lacks many 5433 useful statistics, but it serves to show many of the relevant 5434 behaviors. 5436 Packets arriving without error from the physical interface come in on 5437 a Frame Relay DLCI on a laser channel. These two values are used by 5438 the LFB to look up the handling for the packet. If the handling 5439 indicates that the packet is LMI, then the output index is used to 5440 select an LFB port from the LMItoFE port group. The packet is sent 5441 as a full Frame Relay frame (without any bit or byte stuffing) on the 5442 selected port. The laser channel and DLCI are sent as meta-data, 5443 even though the DLCI is also still in the packet. 5445 Good packets that arrive and are not LMI and have a frame relay type 5446 indicator of IP are sent as IP packets on the port in the DatatoFE 5447 port group, using the same index field from the table based on the 5448 laser channel and DLCI. The channel and DLCI are attached as meta- 5449 data for other use (classifiers, for example.) 5451 The current definition does not specify what to do if the Frame Relay 5452 type information is not IP. 5454 Packets arriving on input ports arrive with the Laser Channel and 5455 Frame Relay DLCI as meta-data. As such, a single input port could 5456 have been used. With the structure that is defined (which parallels 5457 the output structure), the selection of channel and DLCI could be 5458 restricted by the arriving input port group (LMI vs. data) and port 5459 index. As an alternative LFB design, the structures could require a 5460 1-1 relationship between DLCI and LFB port, in which case no meta- 5461 data would be needed. This would however be quite complex and noisy. 5462 The intermediate level of structure here allows parallelism between 5463 input and output, without requiring excessive ports. 5465 8.1.1. Setting up a DLCI 5467 When a CE chooses to establish a DLCI on a specific laser channel, it 5468 sends a SET request directed to this LFB. The request might look 5469 like 5471 T = SET 5472 T = PATH-DATA 5473 Path: flags = none, length = 4, path = 2, channel, 4, entryIdx 5474 DataRaw: DLCI, Enabled(1), false, out-idx 5476 Which would establish the DLCI as enabled, with traffic going to a 5477 specific entry of the output port group DatatoFE. (The CE would 5478 ensure that output port is connected to the right place before 5479 issuing this request.) 5481 The response would confirm the creation of the specified entry. This 5482 table is structured to use separate internal indices and DLCIs. An 5483 alternative design could have used the DLCI as index, trading off 5484 complexities. 5486 One could also imagine that the FE has an LMI LFB. Such an LFB would 5487 be connected to the LMItoFE and LMIfromFE port groups. It would 5488 process LMI information. It might be the LFBs job to set up the 5489 frame relay circuits. The LMI LFB would have an alias entry that 5490 points to the Frame Relay circuits table it manages, so that it can 5491 manipulate those entities. 5493 8.1.2. Error Handling 5495 The LFB will receive invalid packets over the wire. Many of these 5496 will simply result in incrementing counters. The LFB designer might 5497 also specify some error rate measures. This puts more work on the 5498 FE, but allows for more meaningful alarms. 5500 There may be some error conditions that should cause parts of the 5501 packet to be sent to the CE. The error itself is not something that 5502 can cause an event in the LFB. There are two ways this can be 5503 handled. 5505 One way is to define a specific component to count the error, and a 5506 component in the LFB to hold the required portion of the packet. The 5507 component could be defined to hold the portion of the packet from the 5508 most recent error. One could then define an event that occurs 5509 whenever the error count changes, and declare that reporting the 5510 event includes the LFB field with the packet portion. For rare but 5511 extremely critical errors, this is an effective solution. It ensures 5512 reliable delivery of the notification. And it allows the CE to 5513 control if it wants the notification. 5515 Another approach is for the LFB to have a port that connects to a 5516 redirect sink. The LFB would attach the laser channel, the DLCI, and 5517 the error indication as meta-data, and ship the packet to the CE. 5519 Other aspects of error handling are discussed under events below. 5521 8.2. LFB Components 5523 This LFB is defined to have two top level components. One reflects 5524 the administrative state of the LFB. This allows the CE to disable 5525 the LFB completely. 5527 The other component is the table of information about the laser 5528 channels. It is a variable sized array. Each array entry contains 5529 an identifier for what laser frequency this entry is associated with, 5530 whether that frequency is operational, the power of the laser at that 5531 frequency, and a table of information about frame relay circuits on 5532 this frequency. There is no administrative status since a CE can 5533 disable an entry simply by removing it. (Frequency and laser power 5534 of a non-operational channel are not particularly useful. Knowledge 5535 about what frequencies can be supported would be a table in the 5536 capabilities section.) 5538 The Frame Relay circuit information contains the DLCI, the 5539 operational circuit status, whether this circuit is to be treated as 5540 carrying LMI information, and which port in the output port group of 5541 the LFB traffic is to be sent to. As mentioned above, the circuit 5542 index could, in some designs, be combined with the DLCI. 5544 8.3. Capabilities 5546 The capability information for this LFB includes whether the 5547 underlying interface is operational, how many frequencies are 5548 supported, and how many total circuits, across all channels, are 5549 permitted. The maximum number for a given laser channel can be 5550 determined from the properties of the FrameRelayCircuits table. A 5551 GET-PROP on path 2.channel.4 will give the CE the properties of the 5552 array which include the number of entries used, the first available 5553 entry, and the maximum number of entries permitted. 5555 8.4. Events 5557 This LFB is defined to be able to generate several events that the CE 5558 may be interested in. There are events to report changes in 5559 operational state of frequencies, and the creation and deletion of 5560 frequency entries. There is an event for changes in status of 5561 individual frame relay circuits. So an event notification of 5562 61.5.3.11 would indicate that there had been a circuit status change 5563 on subscript 11 of the circuit table in subscript 3 of the frequency 5564 table. The event report would include the new status of the circuit 5565 and the DLCI of the circuit. Arguably, the DLCI is redundant, since 5566 the CE presumably knows the DLCI based on the circuit index. It is 5567 included here to show including two pieces of information in an event 5568 report. 5570 As described above, the event declaration defines the event target, 5571 the event condition, and the event report content. The event 5572 properties indicate whether the CE is subscribed to the event, the 5573 specific threshold for the event, and any filter conditions for the 5574 event. 5576 Another event shown is a laser power problem. This event is 5577 generated whenever the laser falls below the specified threshold. 5578 Thus, a CE can register for the event of laser power loss on all 5579 circuits. It would do this by: 5581 T = SET-PROP 5582 Path-TLV: flags=0, length = 2, path = 61.4 5583 Path-TLV: flags = property-field, length = 1, path = 2 5584 Content = 1 (register) 5585 Path-TLV: flags = property-field, length = 1, path = 3 5586 Content = 15 (threshold) 5588 This would set the registration for the event on all entries in the 5589 table. It would also set the threshold for the event, causing 5590 reporting if the power falls below 15. (Presumably, the CE knows 5591 what the scale is for power, and has chosen 15 as a meaningful 5592 problem level.) 5594 If a laser oscillates in power near the 15 mark, one could get a lot 5595 of notifications. (If it flips back and forth between 14 and 15, 5596 each flip down will generate an event.) Suppose that the CE decides 5597 to suppress this oscillation somewhat on laser channel 5. It can do 5598 this by setting the variance property on that event. The request 5599 would look like: 5601 T = SET-PROP 5602 Path-TLV: flags=0, length = 3, path = 61.4.5 5603 Path-TLV: flags = property-field, length = 1, path = 4 5604 Content = 2 (hysteresis) 5606 Setting the hysteresis to 2 suppress a lot of spurious notifications. 5607 When the level first falls below 10, a notification is generated. If 5608 the power level increases to 10 or 11, and then falls back below 10, 5609 an event will not be generated. The power has to recover to at least 5610 12 and fall back below 10 to generate another event. One common 5611 cause of this form of oscillation is when the actual value is right 5612 near the border. If it is really 9.5, tiny changes might flip it 5613 back and forth between 9 and 10. A variance level of 1 will suppress 5614 this sort of condition. Many other events have oscillations that are 5615 somewhat wider, so larger variance settings can be used with those. 5617 9. IANA Considerations 5619 The ForCES model creates the need for a unique XML namespace for 5620 ForCES library definition usage, and unique class names and numeric 5621 class identifiers. 5623 9.1. URN Namespace Registration 5625 IANA is requested to register a new XML namespace, as per the 5626 guidelines in RFC3688 [3]. 5628 URI: The URI for this namespace is 5629 urn:ietf:params:xml:ns:forces:lfbmodel:1.0 5631 Registrant Contact: IESG 5633 XML: none, this is an XML namespace 5635 9.2. LFB Class Names and LFB Class Identifiers 5637 In order to have well defined ForCES LFB Classes, and well defined 5638 identifiers for those classes, a registry of LFB Class names, 5639 corresponding class identifiers, and the document which defines the 5640 LFB Class is needed. The registry policy is simply first come first 5641 served(FCFS) with regard to LFB Class names. With regard to LFB 5642 Class identifiers, identifiers less than 65536 are reserved for 5643 assignment by IETF Standards Track RFCs. Identifiers above 65536 are 5644 available for assignment on a first come, first served basis. All 5645 Registry entries must be documented in a stable, publicly available 5646 form. 5648 Since this registry provides for FCFS allocation of a portion of the 5649 class identifier space, it is necessary to define rules for naming 5650 classes that are using that space. As these can be defined by 5651 anyone, the needed rule is to keep the FCFS class names from 5652 colliding with IETF defined class names. Therefore, all FCFS class 5653 names MUST start with the string "Ext-". 5655 Table 1 tabulates the above information. 5657 IANA is requested to create a register of ForCES LFB Class Names and 5658 the corresponding ForCES LFB Class Identifiers, with the location of 5659 the definition of the ForCES LFB Class, in accordance with the rules 5660 in the following table. 5662 +----------------+------------+---------------+---------------------+ 5663 | LFB Class Name | LFB Class | Place Defined | Description | 5664 | | Identifier | | | 5665 +----------------+------------+---------------+---------------------+ 5666 | Reserved | 0 | RFCxxxx | Reserved | 5667 | | | | -------- | 5668 | FE Object | 1 | RFXxxxx | Defines ForCES | 5669 | | | | Forwarding Element | 5670 | | | | information | 5671 | FE Protocol | 2 | [2] | Defines parameters | 5672 | Object | | | for the ForCES | 5673 | | | | protocol operation | 5674 | | | | -------- | 5675 | IETF defined | 3-65535 | Standards | Reserved for IETF | 5676 | LFBs | | Track RFCs | defined RFCs | 5677 | | | | -------- | 5678 | Forces LFB | >65535 | Any Publicly | First Come, First | 5679 | Class names | | Available | Served for any use | 5680 | beginning EXT- | | Document | | 5681 +----------------+------------+---------------+---------------------+ 5683 Table 1 5685 [Note to RFC Editor, RFCxxxx above is to be changed to the RFC number 5686 assigned to this document for publication.] 5688 10. Authors Emeritus 5690 The following are the authors who were instrumental in the creation 5691 of earlier releases of this document. 5693 Lily Yang, Intel Corp. 5694 Ram Gopal, Nokia Research Center 5695 Alan DeKok, Infoblox, Inc. 5696 Zsolt Haraszti, Clovis Solutions 5698 11. Acknowledgments 5700 Many of the colleagues in our companies and participants in the 5701 ForCES mailing list have provided invaluable input into this work. 5702 Particular thanks to Evangelos Haleplidis for held getting the XML 5703 right. 5705 12. Security Considerations 5707 The FE model describes the representation and organization of data 5708 sets and components in the FEs. The ForCES framework document [2] 5709 provides a comprehensive security analysis for the overall ForCES 5710 architecture. For example, the ForCES protocol entities must be 5711 authenticated per the ForCES requirements before they can access the 5712 information elements described in this document via ForCES. Access 5713 to the information contained in the FE model is accomplished via the 5714 ForCES protocol, which will be defined in separate documents, and 5715 thus the security issues will be addressed there. 5717 13. References 5719 13.1. Normative References 5721 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5722 Levels", BCP 14, RFC 2119, March 1997. 5724 [2] Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. Wang, 5725 "ForCES Protocol Specification", work in progress, draft-ietf - 5726 forces-protocol-11.txt, December 2007. 5728 [3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5729 January 2004. 5731 13.2. Informative References 5733 [4] Khosravi, H. and T. Anderson, "Requirements for Separation of 5734 IP Control and Forwarding", RFC 3654, November 2003. 5736 [5] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding 5737 and Control Element Separation (ForCES) Framework", RFC 3746, 5738 April 2004. 5740 [6] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, 5741 "Differentiated Services Quality of Service Policy Information 5742 Base", RFC 3317, March 2003. 5744 [7] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework 5745 Policy Information Base", RFC 3318, March 2003. 5747 [8] Pras, A. and J. Schoenwaelder, "On the Difference between 5748 Information Models and Data Models", RFC 3444, January 2003. 5750 [9] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the 5751 Use of Extensible Markup Language (XML) within IETF Protocols", 5752 BCP 70, RFC 3470, January 2003. 5754 [10] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML 5755 Schema Part 1: Structures", W3C REC-xmlschema-1, 5756 http://www.w3.org/TR/ xmlschema-1/, May 2001. 5758 [11] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", 5759 W3C REC-xmlschema-2, http://www.w3.org/TR /xmlschema-2/, 5760 May 2001. 5762 [12] Davis, M. and M. Suignard, "UNICODE Security Considerations", 5763 http://www.unicode.org/ reports/tr36/tr36-3.html, July 2005. 5765 Authors' Addresses 5767 Joel Halpern 5768 Self 5769 P.O. Box 6049 5770 Leesburg,, VA 20178 5772 Phone: +1 703 371 3043 5773 Email: jmh@joelhalpern.com 5775 Ellen Deleganes 5776 Intel Corp. 5777 Mail Stop: CO5-156 15400 NW Greenbrier Parkway 5778 Beaverton,, OR 97006 5780 Phone: +1 503 677-4996 5781 Email: ellen.m.deleganes@intel.com 5783 Jamal Hadi Salim 5784 Znyx Networks 5785 Ottawa, Ontario 5786 Canada 5788 Email: hadi@znyx.com 5790 Full Copyright Statement 5792 Copyright (C) The IETF Trust (2008). 5794 This document is subject to the rights, licenses and restrictions 5795 contained in BCP 78, and except as set forth therein, the authors 5796 retain all their rights. 5798 This document and the information contained herein are provided on an 5799 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5800 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5801 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5802 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5803 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5804 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5806 Intellectual Property 5808 The IETF takes no position regarding the validity or scope of any 5809 Intellectual Property Rights or other rights that might be claimed to 5810 pertain to the implementation or use of the technology described in 5811 this document or the extent to which any license under such rights 5812 might or might not be available; nor does it represent that it has 5813 made any independent effort to identify any such rights. Information 5814 on the procedures with respect to rights in RFC documents can be 5815 found in BCP 78 and BCP 79. 5817 Copies of IPR disclosures made to the IETF Secretariat and any 5818 assurances of licenses to be made available, or the result of an 5819 attempt made to obtain a general license or permission for the use of 5820 such proprietary rights by implementers or users of this 5821 specification can be obtained from the IETF on-line IPR repository at 5822 http://www.ietf.org/ipr. 5824 The IETF invites any interested party to bring to its attention any 5825 copyrights, patents or patent applications, or other proprietary 5826 rights that may cover technology that may be required to implement 5827 this standard. Please address the information to the IETF at 5828 ietf-ipr@ietf.org. 5830 Acknowledgment 5832 Funding for the RFC Editor function is provided by the IETF 5833 Administrative Support Activity (IASA).