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