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