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