idnits 2.17.1 draft-ietf-forces-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 106 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 101 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7377 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 158 -- Looks like a reference, but probably isn't: 'N' on line 2520 -- Looks like a reference, but probably isn't: '1-9' on line 2659 -- Looks like a reference, but probably isn't: '0-9' on line 2659 -- Looks like a reference, but probably isn't: 'DiffServ' on line 3682 -- Looks like a reference, but probably isn't: 'RFC3168' on line 3968 == Unused Reference: '3' is defined on line 4522, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 4531, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 4534, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3654 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft L. Yang 3 Expiration: July 2004 Intel Corp. 4 File: draft-ietf-forces-model-02.txt J. Halpern 5 Working Group: ForCES Megisto Systems 6 R. Gopal 7 Nokia 8 A. DeKok 9 IDT Inc. 10 Z. Haraszti 11 S. Blake 12 Ericsson 13 E. Deleganes 14 Intel Corp. 15 February 2004 17 ForCES Forwarding Element Model 19 draft-ietf-forces-model-02.txt 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. Internet-Drafts are 25 working documents of the Internet Engineering Task Force (IETF), 26 its areas, and its working groups. Note that other groups may also 27 distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as ``work in 33 progress.'' 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This document defines the forwarding element (FE) model used in the 44 Forwarding and Control Plane Separation (ForCES) protocol. The 45 model represents the capabilities, state and configuration of 46 forwarding elements within the context of the ForCES protocol, so 47 that control elements (CEs) can control the FEs accordingly. More 48 specifically, the model describes the logical functions that are 49 present in an FE, what capabilities these functions support, and 50 how these functions are or can be interconnected. This FE model is 51 intended to satisfy the model requirements specified in the ForCES 52 requirements draft [1]. A list of the basic logical functional 53 blocks (LFBs) is also defined in the LFB class library to aid the 54 effort in defining individual LFBs. 56 Table of Contents 58 Abstract.........................................................1 59 1. Definitions...................................................4 60 2. Introduction..................................................6 61 2.1. Requirements on the FE model.............................6 62 2.2. The FE Model in Relation to FE Implementations...........6 63 2.3. The FE Model in Relation to the ForCES Protocol..........7 64 2.4. Modeling Language for FE Model...........................8 65 2.5. Document Structure.......................................8 66 3. FE Model Concepts.............................................8 67 3.1. State Model and Capability Model.........................9 68 3.2. LFB (Logical Functional Block) Modeling.................11 69 3.2.1. LFB Input and Input Group..........................14 70 3.2.2. LFB Output and Output Group........................15 71 3.2.3. Packet Type........................................16 72 3.2.4. Metadata...........................................16 73 3.2.5. LFB Versioning.....................................22 74 3.2.6. LFB Inheritance....................................23 75 3.3. FE Datapath Modeling....................................24 76 3.3.1. Alternative Approaches for Modeling FE Datapaths...24 77 3.3.2. Configuring the LFB Topology.......................29 78 4. Model and Schema for LFB Classes.............................33 79 4.1. Namespace...............................................33 80 4.2. Element....................................33 81 4.3. Element..........................................35 82 4.4. Element for Frame Type Declarations.........35 83 4.5. Element for Data Type Definitions........36 84 4.5.1. Element for Aliasing Existing Data Types.38 85 4.5.2. Element for Deriving New Atomic Types.....39 86 4.5.3. Element to Define Arrays...................39 87 4.5.4. Element to Define Structures..............41 88 4.5.5. Element to Define Union Types..............42 89 4.5.6. Augmentations......................................42 90 4.6. Element for Metadata Definitions.........43 91 4.7. Element for LFB Class Definitions........44 92 4.7.1. Element to Express LFB Inheritance...45 93 4.7.2. Element to Define LFB Inputs..........46 94 4.7.3. Element to Define LFB Outputs........48 95 4.7.4. Element to Define LFB Operational 96 Attributes................................................50 97 4.7.5. Element to Define LFB Capability 98 Attributes................................................53 99 4.7.6. Element for LFB Operational 100 Specification.............................................54 101 4.8. XML Schema for LFB Class Library Documents..............54 102 5. FE Attributes and Capabilities...............................63 103 5.1. XML Schema for FE Attribute Documents...................64 104 5.2. FEDocument..............................................68 105 5.2.1. FECapabilities.....................................68 106 5.2.2. FEAttributes.......................................71 107 5.3. Sample FE Attribute Document............................73 108 6. LFB Class Library............................................76 109 6.1. Port LFB................................................76 110 6.2. L2 Interface LFB........................................77 111 6.3. IP interface LFB........................................79 112 6.4. Classifier LFB..........................................80 113 6.5. Next Hop LFB............................................81 114 6.6. Rate Meter LFB..........................................83 115 6.7. Redirector (de-MUX) LFB.................................84 116 6.8. Packet Header Rewriter LFB..............................84 117 6.9. Counter LFB.............................................85 118 6.10. Dropper LFB............................................85 119 6.11. IPv4 Fragmenter LFB....................................86 120 6.12. L2 Address Resolution LFB..............................86 121 6.13. Queue LFB..............................................86 122 6.14. Scheduler LFB..........................................87 123 6.15. MPLS ILM/Decapsulation LFB.............................88 124 6.16. MPLS Encapsulation LFB.................................88 125 6.17. Tunnel Encapsulation/Decapsulation LFB.................88 126 6.18. Replicator LFB.........................................89 127 7. Satisfying the Requirements on FE Model......................89 128 7.1. Port Functions..........................................90 129 7.2. Forwarding Functions....................................90 130 7.3. QoS Functions...........................................91 131 7.4. Generic Filtering Functions.............................91 132 7.5. Vendor Specific Functions...............................91 133 7.6. High-Touch Functions....................................91 134 7.7. Security Functions......................................91 135 7.8. Off-loaded Functions....................................92 136 7.9. IPFLOW/PSAMP Functions..................................92 137 8. Using the FE model in the ForCES Protocol....................92 138 8.1. FE Topology Query.......................................94 139 8.2. FE Capability Declarations..............................96 140 8.3. LFB Topology and Topology Configurability Query.........96 141 8.4. LFB Capability Declarations.............................96 142 8.5. State Query of LFB Attributes...........................97 143 8.6. LFB Attribute Manipulation..............................98 144 8.7. LFB Topology Re-configuration...........................98 145 9. Acknowledgments..............................................98 146 10. Security Considerations.....................................99 147 11. Normative References........................................99 148 12. Informative References......................................99 149 13. Authors' Addresses.........................................100 150 14. Intellectual Property Right................................101 151 15. IANA consideration.........................................101 153 Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 157 this document are to be interpreted as described in [RFC-2119]. 159 1. Definitions 161 A set of terminology associated with the ForCES requirements is 162 defined in [1] and is not copied here. The following list of 163 terminology is relevant to the FE model defined in this document. 165 FE Model -- The FE model is designed to model the logical 166 processing functions of an FE. The FE model proposed in this 167 document includes three components: the modeling of individual 168 logical functional blocks (LFB model), the logical interconnection 169 between LFBs (LFB topology) and the FE level attributes, including 170 FE capabilities. The FE model provides the basis to define the 171 information elements exchanged between the CE and the FE in the 172 ForCES protocol. 174 Datapath -- A conceptual path taken by packets within the 175 forwarding plane inside an FE. Note that more than one datapath 176 can exist within an FE. 178 LFB (Logical Function Block) class (or type) -- A template 179 representing a fine-grained, logically separable and well-defined 180 packet processing operation in the datapath. LFB classes are the 181 basic building blocks of the FE model. 183 LFB (Logical Function Block) Instance -- As a packet flows through 184 an FE along a datapath, it flows through one or multiple LFB 185 instances, with each implementing an instance of a certain LFB 186 class. There may be multiple instances of the same LFB in an FE's 187 datapath. Note that we often refer to LFBs without distinguishing 188 between LFB class and LFB instance when we believe the implied 189 reference is obvious for the given context. 191 LFB Model -- The LFB model describes the content and structures in 192 an LFB, plus the associated data definition. There are four types 193 of information defined in the LFB model. The core part of the LFB 194 model is the LFB class definitions; the other three types define 195 the associated data including common data types, supported frame 196 formats and metadata. 198 LFB Metadata -- Metadata is used to communicate per-packet state 199 from one LFB to another, but is not sent across the network. The 200 FE model defines how such metadata is identified, produced and 201 consumed by the LFBs, but not how metadata is encoded within an 202 implementation. 204 LFB Attribute -- Operational parameters of the LFBs that must be 205 visible to the CEs are conceptualized in the FE model as the LFB 206 attributes. The LFB attributes include, for example, flags, single 207 parameter arguments, complex arguments, and tables that the CE can 208 read or/and write via the ForCES protocol. 210 LFB Topology -- Representation of how the LFB instances are 211 logically interconnected and placed along the datapath within one 212 FE. Sometimes it is also called intra-FE topology, to be 213 distinguished from inter-FE topology. LFB topology is outside of 214 the LFB model, but is part of the FE model. 216 FE Topology -- A representation of how the multiple FEs within a 217 single NE are interconnected. Sometimes this is called inter-FE 218 topology, to be distinguished from intra-FE topology (i.e., LFB 219 topology). An individual FE might not have the global knowledge of 220 the full FE topology, but the local view of its connectivity with 221 other FEs is considered to be part of the FE model. The FE 222 topology is discovered by the ForCES base protocol or some other 223 means. 225 Inter-FE Topology -- See FE Topology. 227 Intra-FE Topology -- See LFB Topology. 229 LFB class library -- A set of LFB classes that is identified as the 230 most common functions found in most FEs and hence should be defined 231 first by the ForCES Working Group. 233 2. Introduction 235 [2] specifies a framework by which control elements (CEs) can 236 configure and manage one or more separate forwarding elements (FEs) 237 within a networking element (NE) using the ForCES protocol. The 238 ForCES architecture allows Forwarding Elements of varying 239 functionality to participate in a ForCES network element. The 240 implication of this varying functionality is that CEs can make only 241 minimal assumptions about the functionality provided by FEs in an 242 NE. Before CEs can configure and control the forwarding behavior 243 of FEs, CEs need to query and discover the capabilities and states 244 of their FEs. [1] mandates that the capabilities, states and 245 configuration information be expressed in the form of an FE model. 247 RFC 3444 [11] made the observation that information models (IMs) 248 and data models (DMs) are different because they serve different 249 purposes. "The main purpose of an IM is to model managed objects 250 at a conceptual level, independent of any specific implementations 251 or protocols used". "DMs, conversely, are defined at a lower level 252 of abstraction and include many details. They are intended for 253 implementors and include protocol-specific constructs." Sometimes 254 it is difficult to draw a clear line between the two. The FE model 255 described in this document is first and foremost an information 256 model, but it also includes some aspects of a data model, such as 257 explicit definitions of the LFB class schema and FE schema. It is 258 expected that this FE model will be used as the basis to define the 259 payload for information exchange between the CE and FE in the 260 ForCES protocol. 262 2.1. Requirements on the FE model 264 [1] defines requirements, which must be satisfied by a ForCES FE 265 model. To summarize, an FE model must define: 266 . Logically separable and distinct packet forwarding operations 267 in an FE datapath (logical functional blocks or LFBs); 268 . The possible topological relationships (and hence the sequence 269 of packet forwarding operations) between the various LFBs; 270 . The possible operational capabilities (e.g., capacity limits, 271 constraints, optional features, granularity of configuration) 272 of each type of LFB; 273 . The possible configurable parameters (i.e., attributes) of 274 each type of LFB; 275 . Metadata that may be exchanged between LFBs. 277 2.2. The FE Model in Relation to FE Implementations 279 The FE model proposed here is based on an abstraction of distinct 280 logical functional blocks (LFBs), which are interconnected in a 281 directed graph, and receive, process, modify, and transmit packets 282 along with metadata. Note that a real forwarding datapath 283 implementation should not be constrained by the model. On the 284 contrary, the FE model should be designed such that different 285 implementations of the forwarding datapath can all be logically 286 mapped onto the model with the functionality and sequence of 287 operations correctly captured. However, the model itself does not 288 directly address the issue of how a particular implementation maps 289 to an LFB topology. It is left to the forwarding plane vendors to 290 define how the FE functionality is represented using the FE model. 291 Nevertheless, we do strive to design the FE model such that it is 292 flexible enough to accommodate most common implementations. 294 The LFB topology model for a particular datapath implementation 295 MUST correctly capture the sequence of operations on the packet. 296 Metadata generation (by certain LFBs) must always precede any use 297 of that metadata (by subsequent LFBs in the topology graph); this 298 is required for logically consistent operation. Further, 299 modifications of packet fields that are subsequently used as inputs 300 for further processing must occur in the order specified in the 301 model for that particular implementation to ensure correctness. 303 2.3. The FE Model in Relation to the ForCES Protocol 305 The ForCES base protocol is used by the CEs and FEs to maintain the 306 communication channel between the CEs and FEs. The ForCES protocol 307 may be used to query and discover the inter-FE topology. The 308 details of a particular datapath implementation inside an FE, 309 including the LFB topology, along with the operational capabilities 310 and attributes of each individual LFB, are conveyed to the CE 311 within information elements in the ForCES protocol. The model of 312 an LFB class should define all of the information that would need 313 to be exchanged between an FE and a CE for the proper configuration 314 and management of that LFB. 316 Definition of the various payloads of ForCES messages (irrespective 317 of the transport protocol ultimately selected) cannot proceed in a 318 systematic fashion until a formal definition of the objects being 319 configured and managed (the FE and the LFBs within) is undertaken. 320 The FE Model document defines a set of classes and attributes for 321 describing and manipulating the state of the LFBs of an FE. These 322 class definitions themselves will generally not appear in the 323 ForCES protocol. Rather, ForCES protocol operations will reference 324 classes defined in this model, including relevant attributes (and 325 operations if such are defined). 327 Section 8 provides more detailed discussion on how the FE model 328 should be used by the ForCES protocol. 330 2.4. Modeling Language for FE Model 332 Even though not absolutely required, it is beneficial to use a 333 formal data modeling language to represent the conceptual FE model 334 described in this document and a full specification will be written 335 using such a data modeling language. Using a formal language can 336 help to enforce consistency and logical compatibility among LFBs. 337 In addition, the formal definition of the LFB classes has the 338 potential to facilitate the eventual automation of some part of the 339 code generation process and the functional validation of arbitrary 340 LFB topologies. 342 Human readability was the most important factor considered when 343 selecting the specification language. Encoding, decoding and 344 transmission performance was not a selection factor for the 345 language because the encoding method for over the wire transport is 346 an issue independent of the specification language chosen. It is 347 outside the scope of this document and up to the ForCES protocol to 348 define. 350 XML was chosen as the specification language in this document, 351 because XML has the advantage of being both human and machine 352 readable with widely available tools support. 354 2.5. Document Structure 356 Section 3 provides a conceptual overview of the FE model, laying 357 the foundation for the more detailed discussion and specifications 358 in the sections that follow. Section 4 and 5 constitute the core of 359 the FE model, detailing the two major components in the FE model: 360 LFB model and FE level attributes including capability and LFB 361 topology. Section 6 presents a list of LFB classes in the LFB 362 class library that will be further specified in separate documents 363 according to the FE model presented in Sections 4 and 5. Section 7 364 directly addresses the model requirements imposed by the ForCES 365 requirement draft [1] while Section 8 explains how the FE model 366 should be used in the ForCES protocol. 368 3. FE Model Concepts 370 Some of the important concepts used throughout this document are 371 introduced in this section. Section 3.1 explains the difference 372 between a state model and a capability model, and how the two can 373 be combined in the FE model. Section 3.2 introduces the concept of 374 LFBs (Logical Functional Blocks) as the basic functional building 375 blocks in the FE model. Section 3.3 discusses the logical inter- 376 connection and ordering between LFB instances within an FE, that 377 is, the LFB topology. 379 The FE model proposed in this document is comprised of two major 380 components: LFB model, and FE level attributes including FE 381 capabilities and LFB topology. The LFB model provides the content 382 and data structures to define each individual LFB class. FE 383 attributes provide information at the FE level and the capabilities 384 about what the FE can or cannot do at a coarse level. Part of the 385 FE level information is the LFB topology which expresses the 386 logical inter-connection between the LFB instances along the 387 datapath(s) within the FE. Details on these components are 388 described in Section 4 and 5. The intention of this section is to 389 discuss these concepts at the high level and lay the foundation for 390 the detailed description in the following sections. 392 3.1. State Model and Capability Model 394 The FE capability model describes the capabilities and capacities 395 of an FE in terms of variations of functions supported or 396 limitations contained. Conceptually, the FE capability model 397 presents the many possible states allowed on an FE with capacity 398 information indicating certain quantitative limits or constraints. 399 For example, an FE capability model may describe the FE at a coarse 400 level such as: 401 . this FE can handle IPv4 and IPv6 forwarding; 402 . this FE can perform classification on the following fields: 403 source IP address, destination IP address, source port number, 404 destination port number, etc; 405 . this FE can perform metering; 406 . this FE can handle up to N queues (capacity); 407 . this FE can add and remove encapsulating headers of types 408 including IPSec, GRE, L2TP. 410 On the other hand, an FE state model describes the current state of 411 the FE, that is, the instantaneous values or operational behavior 412 of the FE. The FE state model presents the snapshot view of the FE 413 to the CE. For example, using an FE state model, an FE may be 414 described to its CE as the following: 415 . on a given port the packets are classified using a given 416 classification filter; 417 . the given classifier results in packets being metered in a 418 certain way, and then marked in a certain way; 420 . the packets coming from specific markers are delivered into a 421 shared queue for handling, while other packets are delivered 422 to a different queue; 423 . a specific scheduler with specific behavior and parameters 424 will service these collected queues. 426 The information on the capabilities and capacities of the FE helps 427 the CE understand the flexibility and limitations of the FE 428 functions, so that the CE knows at a coarse level which 429 configurations are applicable to the FEs and which ones are not. 430 It gets more complicated for the capability model to cope with the 431 detailed limits, such as the maximum number of the following items: 432 classifiers, queues, buffer pools, and meters the FE can provide. 434 While one could try to build an object model to fully represent the 435 FE capabilities, other efforts have found this to be a significant 436 undertaking. A middle of the road approach is to define coarse- 437 grained capabilities and simple capacity measures. Then, if the CE 438 attempts to instruct the FE to set up some specific behavior it is 439 not capable of, the FE will return an error indicating the problem. 440 Examples of this approach include Framework Policy Information Base 441 (PIB) [RFC3318) and Differentiated Services QoS Policy Information 442 Base [4]. The capability reporting classes in the DiffServ and 443 Framework PIBs are all meant to allow the device to indicate some 444 general guidelines about what it can or cannot do, but do not 445 necessarily allow it to indicate every possible configuration that 446 it can or cannot support. If a device receives a configuration 447 that it cannot implement, it can reject that configuration by 448 responding with a failure report. 450 Figure 1 shows the concepts of FE state, capabilities and 451 configuration in the context of CE-FE communication via the ForCES 452 protocol. 454 +-------+ +-------+ 455 | | FE capabilities: what it can/cannot do. | | 456 | |<-----------------------------------------| | 457 | | | | 458 | CE | FE state: what it is now. | FE | 459 | |<-----------------------------------------| | 460 | | | | 461 | | FE configuration: what it should be. | | 462 | |----------------------------------------->| | 463 +-------+ +-------+ 465 Figure 1. Illustration of FE state, capabilities and configuration 466 exchange in the context of CE-FE communication via ForCES. 468 The ForCES FE model must include both a state model and a 469 capability model. We believe that a good balance between 470 simplicity and flexibility can be achieved for the FE model by 471 combining the coarse level capability reporting with the error 472 reporting mechanism. Examples of similar approaches include 473 DiffServ PIB [4] and Framework PIB [5]. 475 The concepts of LFB and LFB topology will be discussed in the rest 476 of this section. It will become clear that a capability model is 477 needed at both the FE level and LFB level. 479 Capability information at the LFB level is an integral part of the 480 LFB model, and is modeled the same way as the other operational 481 parameters inside an LFB. For example, certain features of an LFB 482 class may be optional, in which case it must be possible for the CE 483 to determine whether or not an optional feature is supported by a 484 given LFB instance. Such capability information can be modeled as 485 a read-only attribute in the LFB instance, see Section 4.7.5 for 486 details. 488 Capability information at the FE level may describe the LFB classes 489 the FE can instantiate; the number of instances of each can be 490 created; the topological (i.e., linkage) limitations between these 491 LFB instances, etc. Section 5 defines the FE level attributes 492 including capability information. 494 Once the FE capability is described to the CE, the FE state 495 information can be represented by two levels. The first level is 496 the logically separable and distinctive packet processing 497 functions, and we call these individual functions Logical 498 Functional Blocks (LFBs). The second level of information is about 499 how these individual LFBs are ordered and placed along the datapath 500 to deliver a complete forwarding plane service. The 501 interconnection and ordering of the LFBs is called LFB Topology. 502 Section 3.2 discuss high level concepts around LFBs while Section 503 3.3 discuss issues around LFB topology. 505 3.2. LFB (Logical Functional Block) Modeling 507 Each LFB performs a well-defined action or computation on the 508 packets passing through it. Upon completion of such a function, 509 either the packets are modified in certain ways (e.g., 510 decapsulator, marker), or some results are generated and stored, 511 probably in the form of metadata (like a classifier). Each LFB 512 typically does one thing and one thing only. Classifiers, shapers, 513 meters are all examples of LFBs. Modeling LFBs at such a fine 514 granularity allows us to use a small number of LFBs to create the 515 higher-order FE functions (such as an IPv4 forwarder) precisely, 516 which in turn can describe more complex networking functions and 517 vendor implementations of software and hardware. Section 6 provides 518 a list of useful LFBs with such granularity. 520 An LFB has one or more inputs, each of which takes a packet P, and 521 optionally metadata M; and produces one or more outputs, each of 522 which carries a packet P', and optionally metadata M'. Metadata is 523 data associated with the packet in the network processing device 524 (router, switch, etc.) and passed from one LFB to the next, but not 525 sent across the network. It is most likely that there are multiple 526 LFBs within one FE, as shown in Figure 2, and all the LFBs share 527 the same ForCES protocol termination point that implements the 528 ForCES protocol logic and maintains the communication channel to 529 and from the CE. 531 +-----------+ 532 | CE | 533 +-----------+ 534 ^ 535 | Fp reference point 536 | 537 +--------------------------|-----------------------------------+ 538 | FE | | 539 | v | 540 | +----------------------------------------------------------+ | 541 | | ForCES protocol | | 542 | | termination point | | 543 | +----------------------------------------------------------+ | 544 | ^ ^ | 545 | : : Internal control | 546 | : : | 547 | +---:----------+ +---:----------| | 548 | | :LFB1 | | : LFB2 | | 549 | =====>| v |============>| v |======>...| 550 | Inputs| +----------+ |Outputs | +----------+ | | 551 | (P,M) | |Attributes| |(P',M') | |Attributes| |(P",M") | 552 | | +----------+ | | +----------+ | | 553 | +--------------+ +--------------+ | 554 | | 555 +--------------------------------------------------------------+ 557 Figure 2. Generic LFB Diagram 559 An LFB, as shown in Figure 2, has inputs, outputs and attributes 560 that can be queried and manipulated by the CE indirectly via Fp 561 reference point (defined in [2]) and the ForCES protocol 562 termination point. The horizontal axis is in the forwarding plane 563 for connecting the inputs and outputs of LFBs within the same FE. 564 The vertical axis between the CE and the FE denotes the Fp 565 reference point where bidirectional communication between the CE 566 and FE happens: the CE to FE communication is for configuration, 567 control and packet injection while FE to CE communication is used 568 for packet re-direction to the control plane, monitoring and 569 accounting information, errors, etc. Note that the interaction 570 between the CE and the LFB is only abstract and indirect. The 571 result of such interaction is for the CE to indirectly manipulate 572 the attributes of the LFB instances. 574 A namespace is used to associate a unique name or ID with each LFB 575 class. The namespace must be extensible so that new LFB class can 576 also be added later to accommodate future innovation in the 577 forwarding plane. 579 LFB operation must be specified in the model to allow the CE to 580 understand the behavior of the forwarding datapath. For instance, 581 the CE must understand at what point in the datapath the IPv4 582 header TTL is decremented (i.e., it needs to know if a control 583 packet could be delivered to the CE either before or after this 584 point in the datapath). In addition, the CE must understand where 585 and what type of header modifications (e.g., tunnel header append 586 or strip) are performed by the FEs. Further, the CE must verify 587 that various LFBs along a datapath within an FE are compatible to 588 link together. 590 There is value to vendors if the operation of LFB classes can be 591 expressed in sufficient detail so that physical devices 592 implementing different LFB functions can be integrated easily into 593 an FE design. Therefore, a semi-formal specification is needed; 594 that is, a text description of the LFB operation (human readable), 595 but sufficiently specific and unambiguous to allow conformance 596 testing and efficient design (i.e., eliminate guess-work), so that 597 interoperability between different CEs and FEs can be achieved. 599 The LFB class model specifies information like: 600 . number of inputs and outputs (and whether they are 601 configurable) 602 . metadata read/consumed from inputs; 603 . metadata produced at the outputs; 604 . packet type(s) accepted at the inputs and emitted at the 605 outputs; 607 . packet content modifications (including encapsulation or 608 decapsulation); 609 . packet routing criteria (when multiple outputs on an LFB are 610 present); 611 . packet timing modifications; 612 . packet flow ordering modifications; 613 . LFB capability information; 614 . LFB operational attributes, etc. 616 Section 4 of this document provides a detailed discussion of the 617 LFB model with a formal specification of LFB class schema. The 618 rest of Section 3.2 only intends to provide a conceptual overview 619 of some important issues in LFB modeling, without covering all the 620 specific details. 622 3.2.1. LFB Input and Input Group 624 An LFB input is a conceptual port of the LFB where the LFB can 625 receive information from other LFBs. The information is typically a 626 packet (or frame in general) and associated metadata, although in 627 some cases it might consist of only metadata, i.e., with a Null- 628 packet. 630 It is inevitable that there will be LFB instances that will receive 631 packets from more than one other LFB instances (fan-in). If these 632 fan-in links all carry the same type of information (packet type 633 and set of metadata) and require the same processing within the 634 LFB, then one input should be sufficient. If, however, the LFB 635 class can receive two or more very different types of input, and 636 the processing of these inputs are also very distinct, then that 637 may justify the definition of multiple inputs. But in these cases 638 splitting the LFB class into two LFB classes should always be 639 considered as an alternative. In intermediate cases, e.g., where 640 the inputs are somewhat different but they require very similar 641 processing, the shared input solution should be preferred. For 642 example, if an Ethernet framer LFB is capable of receiving IPv4 and 643 IPv6 packets, these can be served by the same LFB input. 645 Note that we assume the model allows for connecting more than one 646 LFB output to a single LFB input directly. There is no restriction 647 on the number of up-stream LFBs connecting their outputs to the 648 same input of a single LFB instance. Note that the behavior of the 649 system when multiple packets arrive at such an input simultaneously 650 is not defined by the model. If such behavior needs to be 651 described, it can be done either by separating the single input to 652 become multiple inputs (one per output), or by inserting other 653 appropriate LFBs (such as Queues and possibly Schedulers) between 654 the multiple outputs and the single input. 656 If there are multiple inputs with the same input type, we model 657 them as an input group, that is, multiple instances of the same 658 input type. In general, an input group is useful to allow an LFB 659 to differentiate packet treatment based on where the packet came 660 from. 662 +----+ +----+ 663 |LFB1+---+ |LFB1+---+ 664 +----+ | +---------+ +----+ | +-----------+ 665 +--->|in LFB3 | input / +--->|in:1 LFB3 | 666 +----+ | +---------+ group \ +--->|in:2 | 667 |LFB2+---+ +----+ | +-----------+ 668 +----+ |LFB2+---+ 669 +----+ 671 (a) without input group (b) with input group 673 Figure 3. An example of using input group. 675 Consider the following two cases in Figure 3(a) and (b). In Figure 676 3(a), the output from two LFBs are directly connected into one 677 input of LFB3, assuming that it can be guaranteed that no two 678 packets arrive at the same time instance. If LFB3 must do 679 something different based on the source of the packet (LFB1 or 680 LFB2), the only way to model that is to make LFB1 and LFB2 pass 681 some metadata with different values so that LFB3 can make the 682 differentiation based on that metadata. In Figure 3(b), that 683 differentiation can be elegantly expressed within LFB3 using the 684 input group concept where the instance id can server as the 685 differentiating key. For example, a scheduler LFB can potentially 686 use an input group consisting of a variable number of inputs to 687 differentiate the queues from which the packets are coming. 689 3.2.2. LFB Output and Output Group 691 An LFB output is a conceptual port of the LFB that can send 692 information to some other LFBs. The information is typically a 693 packet (or frame in general) and associated metadata, although in 694 some cases it might emit only metadata, i.e., with a Null-packet. 696 We assume that a single LFB output can be connected to only one LFB 697 input (this is required to make the packet flow through the LFB 698 topology unambiguous). Therefore, to allow any non-trivial 699 topology, multiple outputs must be allowed for an LFB class. If 700 there are multiple outputs with the same output type, we model them 701 as output group, that is, multiple instances of the same output 702 type. For illustration of output group, consider the hypothetical 703 LFB in Figure 4. The LFB has two types of outputs, one of which 704 can be instantiated to form an output group. 706 +------------------+ 707 | UNPROC +--> 708 | | 709 | PKTOUT:1 +--> \ 710 --> PKTIN PKTOUT:2 +--> | 711 | . + . | Output group 712 | . + . | 713 | PKTOUT:N +--> / 714 +------------------+ 716 Figure 4. An example of an LFB with output group. 718 Multiple outputs should mainly be used for functional separation 719 where the outputs are connected to very different types of LFBs. 720 For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one 721 default output to send those packets for which look-up was 722 successful (passing a META_ROUTEID as metadata); and have another 723 output for sending packets for which the look-up failed. The 724 former output may be connected to a route handler LFB, while the 725 latter can be connected to an ICMP response generator LFB or to a 726 packet handler LFB that passes the packet up to the CE. 728 3.2.3. Packet Type 730 When LFB classes are defined, the input and output packet formats 731 (e.g., IPv4, IPv6, Ethernet, etc.) must be specified: these are the 732 types of packets a given LFB input is capable of receiving and 733 processing, or a given LFB output is capable of producing. This 734 requires that distinct frame types be uniquely labeled with a 735 symbolic name and/or ID. 737 Note that each LFB has a set of packet types that it operates on, 738 but it does not care about whether the underlying implementation is 739 passing a greater portion of the packets. For example, an IPv4 LFB 740 might only operate on IPv4 packets, but the underlying 741 implementation may or may not be stripping the L2 header before 742 handing it over -- whether that is happening or not is opaque to 743 the CE. 745 3.2.4. Metadata 746 Metadata is the per-packet state that is passed from one LFB to 747 another. The metadata is passed with the packet to assist with 748 further processing of that packet. The ForCES model must capture 749 how the per-packet state information is propagated from one LFB to 750 other LFBs. Practically, such metadata propagation can happen 751 within one FE, or cross the FE boundary between two interconnected 752 FEs. We believe that the same metadata model can be used for both 753 situations, however, our focus here is for intra-FE metadata. 755 Each metadata can be conveniently modeled as a pair, 756 where the label identifies the type of information, (e.g., 757 "color"), and its value holds the actual information (e.g., "red"). 758 The tag here is shown as a textual label, but it can be replaced or 759 associated with a unique numeric value (identifier). 760 The metadata life-cycle is defined in this model using three types 761 of events: "write", "read" and "consume". The first "write" 762 initializes the value of the metadata (implicitly creating and/or 763 initializing the metadata), and hence starts the life-cycle. The 764 explicit "consume" event terminates the life-cycle. Within the 765 life-cycle, that is, after a "write" event, but before the next 766 "consume" event, there can be an arbitrary number of "write" and 767 "read" events. These "read" and "write" events can be mixed in an 768 arbitrary order within the life-cycle. Outside of the life-cycle of 769 the metadata, that is, before the first "write" event, or between a 770 "consume" event and the next "write" event, the metadata should be 771 regarded non-existent or non-initialized. Thus, reading a metadata 772 outside of its life-cycle is considered an error. 774 To ensure inter-operability between LFBs, the LFB class 775 specification must define what metadata the LFB class "reads" or 776 "consumes" on its input(s) and what metadata it "produces" on its 777 output(s). For maximum extensibility, this definition should not 778 specify which LFBs the metadata is expected to come from for a 779 consumer LFB, or which LFBs are expected to consume metadata for a 780 producer LFB. 782 While it is important to define the metadata types passing between 783 LFBs, it is not necessary to define the exact encoding mechanism 784 used by LFBs for that metadata. Different implementations are 785 allowed to use different encoding mechanisms for metadata. For 786 example, one implementation may store metadata in registers or 787 shared memory, while another implementation may encode metadata in- 788 band as a preamble in the packets. 790 At any link between two LFBs, the packet is marked with a finite 791 set of active metadata, where active means the metadata is within 792 its life-cycle. (i.e., the metadata has been properly initialized 793 and has not been consumed yet.) There are two corollaries of this 794 model: 796 1. No uninitialized metadata exists in the model. 798 2. No more than one occurrence of each metadata tag can be 799 associated with a packet at any given time. 801 3.2.4.1. LFB Operations on Metadata 803 When the packet is processed by an LFB (i.e., between the time it 804 is received and forwarded by the LFB), the LFB may perform read, 805 write and/or consume operations on any active metadata associated 806 with the packet. If the LFB is considered to be a black box, one of 807 the following operations is performed on each active metadata. 809 - IGNORE: ignores and forwards the metadata 810 - READ: reads and forwards the metadata 811 - READ/RE-WRITE: reads, over-writes and forwards the metadata 812 - WRITE: writes and forwards the metadata 813 (can also be used to create new metadata) 814 - READ-AND-CONSUME: reads and consumes the metadata 815 - CONSUME consumes metadata without reading 817 The last two operations terminate the life-cycle of the metadata, 818 meaning that the metadata is not forwarded with the packet when the 819 packet is sent to the next LFB. 821 In our model, a new metadata is generated by an LFB when the LFB 822 applies a WRITE operation into a metadata type that was not present 823 when the packet was received by the LFB. Such implicit creation may 824 be unintentional by the LFB, that is, the LFB may apply the WRITE 825 operation without knowing or caring if the given metadata existed 826 or not. If it existed, the metadata gets over-written; if it did 827 not exist, the metadata gets created. 829 For source-type LFBs (i.e., an LFB that inserts packets into the 830 model), WRITE is the only meaningful metadata operation. 832 Sink-type LFBs (i.e., an LFB that removes the packet from the 833 model), may either READ-AND-CONSUME (read) or CONSUME (ignore) each 834 active metadata associated with the packet. 836 3.2.4.2. Metadata Production and Consumption 837 For a given metadata on a given packet path, there must be at least 838 one producer LFB that creates that metadata and should be at least 839 one consumer LFB that needs the metadata. In this model, the 840 producer and consumer LFBs of a metadata are not required to be 841 adjacent. There may be multiple consumers for the same metadata and 842 there may be multiple producers of the same metadata. When a packet 843 path involves multiple producers of the same metadata, then the 844 second, third, etc. producers overwrite that metadata value. 846 The metadata that is produced by an LFB is specified by the LFB 847 class definition on a per output port group basis. A producer may 848 always generate the metadata on the port group, or may generate it 849 only under certain conditions. We call the former an 850 "unconditional" metadata, whereas the latter is a "conditional" 851 metadata. In the case of conditional metadata, it should be 852 possible to determine from the definition of the LFB when a 853 "conditional" metadata is produced. 855 The consumer behavior of an LFB, that is, the metadata that the LFB 856 needs for its operation, is defined in the LFB class definition on 857 a per input port group basis. An input port group may "require" a 858 given metadata, or may treat it as "optional" information. In the 859 latter case, the LFB class definition must explicitly define what 860 happens if an optional metadata is not provided. One approach is to 861 specify a default value for each optional metadata, and assume that 862 the default value is used if the metadata is not provided with the 863 packet. 865 When a consumer requires a given metadata, it has dependencies on 866 its up-stream LFBs. That is, the consumer LFB can only function if 867 there is at least one producer of that metadata and no intermediate 868 LFB consumes the metadata. 870 The model should expose this inter-dependency. Furthermore, it 871 should be possible to take this inter-dependency into consideration 872 when constructing LFB topologies, and also that the dependency can 873 be verified when validating topologies. 875 For extensibility reasons, the LFB specification should define what 876 metadata the LFB requires without specifying which LFB(s) it expect 877 a certain metadata to come from. Similarly, LFBs should specify 878 what metadata they produce without specifying which LFBs the 879 metadata is meant for. 881 When specifying the metadata tags, some harmonization effort must 882 be made so that the producer LFB class uses the same tag as its 883 intended consumer(s), or vice versa. 885 3.2.4.3. Fixed, Variable and Configurable Tag 887 When the produced metadata is defined for a given LFB class, most 888 metadata will be specified with a fixed tag. For example, a Rate 889 Meter LFB will always produce the "Color" metadata. 891 A small subset of LFBs need to have the capability to produce one 892 or more of their metadata with tags that are not fixed in the LFB 893 class definition, but instead can be selected per LFB instance. An 894 example of such an LFB class is a Generic Classifier LFB. We call 895 this variable tag metadata production. If an LFB produces metadata 896 with variable tag, a corresponding LFB attribute--called the tag 897 selector--specifies the tag for each such metadata. This mechanism 898 is to improve the versatility of certain multi-purpose LFB classes, 899 since it allows the same LFB class be used in different topologies, 900 producing the right metadata tags according to the needs of the 901 topology. 903 Depending on the capability of the FE, the tag selector can be a 904 read-only or a read-write attribute. In the former case, the tag 905 cannot be modified by the CE. In the latter case the tag can be 906 configured by the CE, hence we call this "configurable tag metadata 907 production." (Note that in this definition configurable tag 908 metadata production is a subset of variable tag metadata 909 production.) 911 Similar concepts can be introduced for the consumer LFBs to satisfy 912 the different metadata needs. Most LFB classes will specify their 913 metadata needs using fixed metadata tags. For example, a Next Hop 914 LFB may always require a "NextHopId" metadata; but the Redirector 915 LFB may need to use a "ClassID" metadata in one instance, and a 916 "ProtocolType" metadata in another instance as a basis for 917 selecting the right output port. In this case, an LFB attribute is 918 used to provide the required metadata tag at run-time. This 919 metadata tag selector attribute may be read-only or read-write, 920 depending on the capabilities of the LFB instance and the FE. 922 3.2.4.4. Metadata Usage Categories 924 Depending on the role and usage of a metadata, various amount of 925 encoding information must be provided when the metadata is defined, 926 and some cases offer less flexibility in the value selection than 927 others. 929 As far as usage of a metadata is concerned, three types of metadata 930 exist: 931 - Relational (or binding) metadata 932 - Enumerated metadata 933 - Explicit/external value metadata 935 The purpose of the relational metadata is to refer in one LFB 936 instance (producer LFB) to a "thing" in another downstream LFB 937 instance (consumer LFB), where the "thing" is typically an entry in 938 a table attribute of the consumer LFB. 940 For example, the Prefix Lookup LFB executes an LPM search using its 941 prefix table and resolves to a next-hop reference. This reference 942 needs to be passed as metadata by the Prefix Lookup LFB (producer) 943 to the Next Hop LFB (consumer), and must refer to a specific entry 944 in the next-hop table within the consumer. 946 Expressing and propagating such binding relationship is probably 947 the most common usage of metadata. One or more objects in the 948 producer LFB are related (bound) to a specific object in the 949 consumer LFB. Such a relation is established by the CE very 950 explicitly, i.e., by properly configuring the attributes in both 951 LFBs. Available methods include the following: 953 The binding may be expressed by tagging the involved objects in 954 both LFBs with the same unique (but otherwise arbitrary) 955 identifier. The value of the tag is explicitly configured (written 956 by the CE) into both LFBs, and this value is also the value that 957 the metadata carries between the LFBs. 959 Another way of setting up binding relations is to use a naturally 960 occurring unique identifier of the consumer's object (for example, 961 the array index of a table entry) as a reference (and as a value of 962 the metadata. In this case, the index is obtained (read) or 963 inferred by the CE by communicating with the consumer LFB. Once the 964 CE obtains the index, it needs to plug (write) it into the producer 965 LFB to establish the binding. 967 Important characteristics of the binding usage of metadata are: 969 - The value of the metadata shows up in the CE-FE communication for 970 BOTH the consumer and the producer. That is, the metadata value 971 must be carried over the ForCES protocol. Using the tagging 972 technique, the value is WRITTEN to both LFBs. Using the other 973 technique, the value is WRITTEN to only the producer LFB and may be 974 READ from the consumer LFB. 976 - The actual value is irrelevant for the CE, the binding is simply 977 expressed by using the SAME value at the consumer and producer 978 LFBs. 980 - Hence the definition of the metadata does not have to include 981 value assignments. The only exception is when some special value(s) 982 of the metadata must be reserved to convey special events. Even 983 though these special cases must be defined with the metadata 984 specification, their encoded values can be selected arbitrarily. 985 For example, for the Prefix Lookup LFB example, a special value may 986 be reserved to signal the NO-MATCH case, and the value of zero may 987 be assigned for this purpose. 989 The second class of metadata is the enumerated type. An example is 990 the "Color" metadata that is produced by a Meter LFB and consumed 991 by some other LFBs. As the name suggests, enumerated metadata has a 992 relatively small number of possible values, each with a very 993 specific meaning. All of the possible cases must be enumerated when 994 defining this class of metadata. Although a value encoding must be 995 included in the specification, the actual values can be selected 996 arbitrarily (e.g., and would be both valid encodings, what is important is that 998 an encoding is specified). 1000 The value of the enumerated metadata may or may not be conveyed via 1001 the ForCES protocol between the CE and FE. 1003 The third class of metadata is the explicit type. This refers to 1004 cases where the value of the metadata is explicitly used by the 1005 consumer LFB to change some packet header fields. In other words, 1006 its value has a direct and explicit impact on some field and will 1007 be visible externally when the packet leaves the NE. Examples are: 1008 TTL increment given to a Header Modifier LFB, and DSCP value for a 1009 Remarker LFB. For explicit metadata, the value encoding must be 1010 explicitly provided in the metadata definition, where the values 1011 cannot be selected arbitrarily, but rather they should conform to 1012 what is commonly expected. For example, a TTL increment metadata 1013 should encode with zero for the no increment case, by one for the 1014 single increment case, etc. A DSCP metadata should use 0 to encode 1015 DSCP=0, 1 to encode DSCP=1, etc. 1017 3.2.5. LFB Versioning 1018 LFB class versioning is a method to enable incremental evolution of 1019 LFB classes. Unlike inheritance (discussed next in Section 3.2.6), 1020 where it assumed that an FE datapath model containing an LFB 1021 instance of a particular class C could also simultaneously contain 1022 an LFB instance of a class C' inherited from class C; with 1023 versioning, an FE would not be allowed to contain an LFB instance 1024 for more than one version of a particular class. 1026 LFB class versioning is supported by requiring a version string in 1027 the class definition. CEs may support backwards compatibility 1028 between multiple versions of a particular LFB class, but FEs are 1029 not allowed to support more than one single version of a particular 1030 class. 1032 3.2.6. LFB Inheritance 1034 LFB class inheritance is supported in the FE model as a means of 1035 defining new LFB classes. This also allows FE vendors to add 1036 vendor-specific extensions to standardized LFBs. An LFB class 1037 specification MUST specify the base class (with version number) it 1038 inherits from (with the default being the base LFB class). 1039 Multiple-inheritance is not allowed, though, to avoid the 1040 unnecessary complexity. 1042 Inheritance should be used only when there is significant reuse of 1043 the base LFB class definition. A separate LFB class should be 1044 defined if there is not enough reuse between the derived and the 1045 base LFB class. 1047 An interesting issue related to class inheritance is backward 1048 compatibility (between a descendant and an ancestor class). 1049 Consider the following hypothetical scenario where there exists a 1050 standardized LFB class "L1". Vendor A builds an FE that implements 1051 LFB "L1" and vendors B builds a CE that can recognize and operate 1052 on LFB "L1". Suppose that a new LFB class, "L2", is defined based 1053 on the existing "L1" class (for example, by extending its 1054 capabilities in some incremental way). Lets first examine the FE 1055 backward compatibility issue by considering what would happen if 1056 vendor B upgrades its FE from "L1" to "L2" while vendor C's CE is 1057 not changed. The old L1-based CE can interoperate with the new L2- 1058 based FE if the derived LFB class "L2" is indeed backward 1059 compatible with the base class "L1". 1061 The reverse scenario is a much less problematic case, i.e., when CE 1062 vendor B upgrades to the new LFB class "L2", but the FE is not 1063 upgraded. Note that as long as the CE is capable of working with 1064 older LFB classes, this problem does not affect the model; hence we 1065 will use the term "backward compatibility" to refer to the first 1066 scenario concerning FE backward compatibility. 1068 Inheritance can be designed into the model with backward 1069 compatibility support by constraining the LFB inheritance such that 1070 the derived class is always a functional superset of the base 1071 class, i.e., the derived class can only grow on top of the base 1072 class, but not shrink from it. Additionally, the following 1073 mechanisms are required to support FE backward compatibility: 1074 1) When detecting an LFB instance of an LFB type that is 1075 unknown to the CE, the CE MUST be able to query the base 1076 class of such an LFB from the FE. 1077 2) The LFB instance on the FE SHOULD support a backward 1078 compatibility mode (meaning the LFB instance reverts itself 1079 back to the base class instance), and the CE SHOULD be able 1080 to configure the LFB to run in such mode. 1082 3.3. FE Datapath Modeling 1084 Packets coming into the FE from ingress ports generally flow 1085 through multiple LFBs before leaving out of the egress ports. How 1086 an FE treats a packet depends on many factors, such as type of the 1087 packet (e.g., IPv4, IPv6 or MPLS), actual header values, time of 1088 arrival, etc. The result of the operation of an LFB may have an 1089 impact on how the packet is to be treated in further (downstream) 1090 LFBs and this differentiation of packet treatment downstream can be 1091 conceptualized as having alternative datapaths in the FE. For 1092 example, the result of a 6-tuple classification (performed by a 1093 classifier LFB) controls what rate meter is applied to the packet 1094 (by a rate meter LFB) in a later stage in the datapath. 1096 LFB topology is a directed graph representation of the logical 1097 datapaths within an FE, with the nodes representing the LFB 1098 instances and the directed link the packet flow direction from one 1099 LFB to the next. Section 3.3.1 discusses how the FE datapaths can 1100 be modeled as LFB topology; while Section 3.3.2 focuses on issues 1101 around LFB topology reconfiguration. 1103 3.3.1. Alternative Approaches for Modeling FE Datapaths 1105 There are two basic ways to express the differentiation in packet 1106 treatment within an FE, one representing the datapath directly and 1107 graphically (topological approach) and the other utilizing metadata 1108 (the encoded state approach). 1110 . Topological Approach 1111 Using this approach, differential packet treatment is expressed 1112 via actually splitting the LFB topology into alternative paths. 1113 In other words, if the result of an LFB must control how the 1114 packet is further processed, then such an LFB will have separate 1115 output ports (one for each alternative treatment) connected to 1116 separate sub-graphs (each expressing the respective treatment 1117 downstream). 1119 . Encoded State Approach 1121 An alternative way of expressing differential treatment is using 1122 metadata. The result of the operation of an LFB can be encoded 1123 in a metadata which is passed along with the packet to 1124 downstream LFBs. A downstream LFB, in turn, can use the 1125 metadata (and its value, e.g., as an index into some table) to 1126 decide how to treat the packet. 1128 Theoretically, the two approaches can substitute for each other, so 1129 one may consider using purely one (or the other) approach to 1130 describe all datapaths in an FE. However, neither model by itself 1131 is very useful for practically relevant cases. For a given FE with 1132 certain logical datapaths, applying the two different modeling 1133 approaches would result in very different looking LFB topology 1134 graphs. A model using purely the topological approach may require 1135 a very large graph with many links (i.e., paths) and nodes (i.e., 1136 LFB instances) to express all alternative datapaths. On the other 1137 hand, a model using purely the encoded state model would be 1138 restricted to a string of LFBs, which would make it very 1139 unintuitive to describe very different datapaths (such as MPLS and 1140 IPv4). Therefore, a mix of these two approaches will likely be 1141 used for a practical model. In fact, as we illustrate it below, 1142 the two approaches can be mixed even within the same LFB. 1144 Using a simple example of a classifier with N classification 1145 outputs followed by some other LFBs, Figure 5(a) shows what the LFB 1146 topology looks like by using the purely topological approach. Each 1147 output from the classifier goes to one of the N LFBs followed and 1148 no metadata is needed here. The topological approach is simple, 1149 straightforward and graphically intuitive. However, if N is large 1150 and the N nodes followed the classifier (LFB#1, LFB#2, ..., LFB#N) 1151 all belong to the same LFB type (for example, meter) but each with 1152 its own independent attributes, the encoded state approach gives a 1153 much simpler topology representation, as shown in Figure 5(b). The 1154 encoded state approach requires that a table of N rows of meter 1155 attributes is provided in the Meter node itself, with each row 1156 representing the attributes for one meter instance. A metadata M 1157 is also needed to pass along with the packet P from the classifier 1158 to the meter, so that the meter can use M as a look-up key (index) 1159 to find the corresponding row of the attributes that should be used 1160 for any particular packet P. 1162 Now what if all the N nodes (LFB#1, LFB#2, ..., LFB#N) are not of 1163 the same type? For example, if LFB#1 is a queue while the rest are 1164 all meters, what is the best way to represent such datapaths? 1165 While it is still possible to use either the pure topological 1166 approach or the pure encoded state approach, the natural 1167 combination of the two seems the best by representing the two 1168 different functional datapaths using topological approach while 1169 leaving the N-1 meter instances distinguished by metadata only, as 1170 shown in Figure 5(c). 1171 +----------+ 1172 P | LFB#1 | 1173 +--------->|(Attrib-1)| 1174 +-------------+ | +----------+ 1175 | 1|------+ P +----------+ 1176 | 2|---------------->| LFB#2 | 1177 | classifier 3| |(Attrib-2)| 1178 | ...|... +----------+ 1179 | N|------+ ... 1180 +-------------+ | P +----------+ 1181 +--------->| LFB#N | 1182 |(Attrib-N)| 1183 +----------+ 1185 5(a) Using pure topological approach 1187 +-------------+ +-------------+ 1188 | 1| | Meter | 1189 | 2| (P, M) | (Attrib-1) | 1190 | 3|---------------->| (Attrib-2) | 1191 | ...| | ... | 1192 | N| | (Attrib-N) | 1193 +-------------+ +-------------+ 1195 5(b) Using pure encoded state approach to represent the LFB 1196 topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the 1197 same type (e.g., meter). 1199 +-------------+ 1200 +-------------+ (P, M) | queue | 1201 | 1|------------->| (Attrib-1) | 1202 | 2| +-------------+ 1203 | 3| (P, M) +-------------+ 1204 | ...|------------->| Meter | 1205 | N| | (Attrib-2) | 1206 +-------------+ | ... | 1207 | (Attrib-N) | 1208 +-------------+ 1210 5(c) Using a combination of the two, if LFB#1, LFB#2, ..., and 1211 LFB#N are of different types (e.g., queue and meter). 1213 Figure 5. An example of how to model FE datapaths 1215 From this example, we demonstrate that each approach has distinct 1216 advantage for different situations. Using the encoded state 1217 approach, fewer connections are typically needed between a fan-out 1218 node and its next LFB instances of the same type, because each 1219 packet carries metadata with it so that the following nodes can 1220 interpret and hence invoke a different packet treatment. For those 1221 cases, a pure topological approach forces one to build elaborate 1222 graphs with a lot more connections and often results in an unwieldy 1223 graph. On the other hand, a topological approach is intuitive and 1224 most useful for representing functionally very different datapaths. 1226 For complex topologies, a combination of the two is the most useful 1227 and flexible. Here we provide a general design guideline as to 1228 what approach is best used for what situation. The topological 1229 approach should primarily be used when the packet datapath forks 1230 into areas with distinct LFB classes (not just distinct 1231 parameterizations of the same LFB classes), and when the fan-outs 1232 do not require changes (adding/removing LFB outputs) at all or 1233 require only very infrequent changes. Configuration information 1234 that needs to change frequently should preferably be expressed by 1235 the internal attributes of one or more LFBs (and hence using the 1236 encoded state approach). 1238 +---------------------------------------------+ 1239 | | 1240 +----------+ V +----------+ +------+ | 1241 | | | | |if IP-in-IP| | | 1242 ---->| ingress |->+----->|classifier|---------->|Decap.|---->---+ 1243 | ports | | |----+ | | 1244 +----------+ +----------+ |others+------+ 1245 | 1246 V 1247 (a) The LFB topology with a logical loop 1249 +-------+ +-----------+ +------+ +-----------+ 1250 | | | |if IP-in-IP | | | | 1251 --->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|-> 1252 | ports | | |----+ | | | | 1253 +-------+ +-----------+ |others +------+ +-----------+ 1254 | 1255 V 1256 (b) The LFB topology without the loop utilizing two 1257 independent classifier instances. 1259 Figure 6. An LFB topology example. 1261 It is important to point out that the LFB topology here is the 1262 logical topology that the packets flow through, not the physical 1263 topology as determined by how the FE hardware is laid out. 1264 Nevertheless, the actual implementation may still influence how the 1265 functionality should be mapped into the LFB topology. Figure 6 1266 shows one simple FE example. In this example, an IP-in-IP packet 1267 from an IPSec application like VPN may go to the classifier first 1268 and have the classification done based on the outer IP header; upon 1269 being classified as an IP-in-IP packet, the packet is then sent to 1270 a decapsulator to strip off the outer IP header, followed by a 1271 classifier again to perform classification on the inner IP header. 1272 If the same classifier hardware or software is used for both outer 1273 and inner IP header classification with the same set of filtering 1274 rules, a logical loop is naturally present in the LFB topology, as 1275 shown in Figure 6(a). However, if the classification is 1276 implemented by two different pieces of hardware or software with 1277 different filters (i.e., one set of filters for outer IP header 1278 while another set for inner IP header), then it is more natural to 1279 model them as two different instances of classifier LFB, as shown 1280 in Figure 6(b). 1282 To distinguish multiple instances of the same LFB class, each LFB 1283 instance has its own LFB instance ID. One way to encode the LFB 1284 instance ID is to encode it as x.y where x is the LFB class ID 1285 while y is the instance ID within each LFB class. 1287 3.3.2. Configuring the LFB Topology 1289 While there is little doubt that the individual LFB must be 1290 configurable, the configurability question is more complicated for 1291 LFB topology. Since LFB topology is really the graphic 1292 representation of the datapaths within FE, configuring the LFB 1293 topology means dynamically changing the datapaths including changes 1294 to the LFBs along the datapaths on an FE, e.g., creating (i.e., 1295 instantiating) or deleting LFBs, setting up or deleting 1296 interconnections between outputs of upstream LFBs to inputs of 1297 downstream LFBs. 1299 Why would the datapaths on an FE ever change dynamically? The 1300 datapaths on an FE is set up by the CE to provide certain data 1301 plane services (e.g., DiffServ, VPN, etc.) to the NE's customers. 1302 The purpose of reconfiguring the datapaths is to enable the CE to 1303 customize the services the NE is delivering at run time. The CE 1304 needs to change the datapaths when the service requirements change, 1305 e.g., when adding a new customer, or when an existing customer 1306 changes their service. However, note that not all datapath changes 1307 result in changes in the LFB topology graph, and that is determined 1308 by the approach we use to map the datapaths into LFB topology. As 1309 discussed in 3.3.1, the topological approach and encoded state 1310 approach can result in very different looking LFB topologies for 1311 the same datapaths. In general, an LFB topology based on a pure 1312 topological approach is likely to experience more frequent topology 1313 reconfiguration than one based on an encoded state approach. 1314 However, even an LFB topology based entirely on an encoded state 1315 approach may have to change the topology at times, for example, to 1316 totally bypass some LFBs or insert new LFBs. Since a mix of these 1317 two approaches is used to model the datapaths, LFB topology 1318 reconfiguration is considered an important aspect of the FE model. 1320 We want to point out that allowing a configurable LFB topology in 1321 the FE model does not mandate that all FEs must have such 1322 capability. Even if an FE supports configurable LFB topology, it 1323 is expected that there will be FE-specific limitations on what can 1324 actually be configured. Performance-optimized hardware 1325 implementation may have zero or very limited configurability, while 1326 FE implementations running on network processors may provide more 1327 flexibility and configurability. It is entirely up to the FE 1328 designers to decide whether or not the FE actually implements such 1329 reconfiguration and how much. Whether it is a simple runtime 1330 switch to enable or disable (i.e., bypass) certain LFBs, or more 1331 flexible software reconfiguration is all implementation detail 1332 internal to the FE and outside of the scope of FE model. In either 1333 case, the CE(s) must be able to learn the FE's configuration 1334 capabilities. Therefore, the FE model must provide a mechanism for 1335 describing the LFB topology configuration capabilities of an FE. 1336 These capabilities may include (see Section 5 for full details): 1337 . What LFB classes can the FE instantiate? 1338 . How many instances of the same LFB class can be created? 1339 . What are the topological limitations? For example: 1340 o How many instances of the same class or any class can be 1341 created on any given branch of the graph? 1342 o Ordering restrictions on LFBs (e.g., any instance of LFB 1343 class A must be always downstream of any instance of LFB 1344 class B). 1346 Even if the CE is allowed to configure LFB topology for an FE, how 1347 can the CE interpret an arbitrary LFB topology (presented to the CE 1348 by the FE) and know what to do with it? In other words, how does 1349 the CE know the mapping between an LFB topology and a particular NE 1350 service or application (e.g., VPN, DiffServ, etc.)? We argue that 1351 first of all, it is unlikely that an FE can support any arbitrary 1352 LFB topology; secondly, once the CE understands the coarse 1353 capability of an FE, it is up to the CE to configure the LFB 1354 topology according to the network service the NE is supposed to 1355 provide. So the more important mapping that the CE has to 1356 understand is from the high level NE service to a specific LFB 1357 topology, not the other way around. Do we expect the CE has the 1358 ultimate intelligence to translate any high level service policy 1359 into the configuration data for the FEs? No, but it is conceivable 1360 that within a given network service domain (like DiffServ), a 1361 certain amount of intelligence can be programmed into the CE such 1362 that the CE has a general understanding of the LFBs involved and so 1363 the translation from a high level service policy to the low level 1364 FE configuration can be done automatically. In any event, this is 1365 considered an implementation issue internal to the control plane 1366 and outside the scope of the FE model. Therefore, it is not 1367 discussed any further in this draft. 1369 +----------+ +-----------+ 1370 ---->| Ingress |---->|classifier |--------------+ 1371 | | |chip | | 1372 +----------+ +-----------+ | 1373 v 1374 +-------------------------------------------+ 1375 +--------+ | Network Processor | 1376 <----| Egress | | +------+ +------+ +-------+ | 1377 +--------+ | |Meter | |Marker| |Dropper| | 1378 ^ | +------+ +------+ +-------+ | 1379 | | | 1380 +----------+-------+ | 1381 | | | 1382 | +---------+ +---------+ +------+ +---------+ | 1383 | |Forwarder|<------|Scheduler|<--|Queue | |Counter | | 1384 | +---------+ +---------+ +------+ +---------+ | 1385 |--------------------------------------------------------------+ 1387 (a) The Capability of the FE, reported to the CE 1389 +-----+ +-------+ +---+ 1390 | A|--->|Queue1 |--------------------->| | 1391 ------>| | +-------+ | | +---+ 1392 | | | | | | 1393 | | +-------+ +-------+ | | | | 1394 | B|--->|Meter1 |----->|Queue2 |------>| |->| | 1395 | | | | +-------+ | | | | 1396 | | | |--+ | | | | 1397 +-----+ +-------+ | +-------+ | | +---+ 1398 classifier +-->|Dropper| | | IPv4 1399 +-------+ +---+ Fwd. 1400 Scheduler 1401 (b) One LFB topology as configured by the CE and 1402 accepted by the FE 1403 Queue1 1404 +---+ +--+ 1405 | A|------------------->| |--+ 1406 +->| | | | | 1407 | | B|--+ +--+ +--+ +--+ | 1408 | +---+ | | | | | | 1409 | Meter1 +->| |-->| | | 1410 | | | | | | 1411 | +--+ +--+ | Ipv4 1412 | Counter1 Dropper1 Queue2| +--+ Fwd. 1413 +---+ | +--+ +--->|A | +-+ 1414 | A|---+ | |------>|B | | | 1415 ------>| B|------------------------------>| | +--->|C |->| |-> 1416 | C|---+ +--+ | +->|D | | | 1417 | D|-+ | | | +--+ +-+ 1418 +---+ | | +---+ Queue3| | Scheduler 1419 Classifier1 | | | A|------------> +--+ | | 1420 | +->| | | |--+ | 1421 | | B|--+ +--+ +-------->| | | 1422 | +---+ | | | | +--+ | 1423 | Meter2 +->| |-+ | 1424 | | | | 1425 | +--+ Queue4 | 1426 | Marker1 +--+ | 1427 +---------------------------->| |----+ 1428 | | 1429 +--+ 1430 (c) Another LFB topology as configured by the CE and 1431 accepted by the FE 1433 Figure 7. An example of configuring LFB topology. 1435 Figure 7 shows an example where a QoS-enabled router has several 1436 line cards that have a few ingress ports and egress ports, a 1437 specialized classification chip, a network processor containing 1438 codes for FE blocks like meter, marker, dropper, counter, queue, 1439 scheduler and Ipv4 forwarder. Some of the LFB topology is already 1440 fixed and has to remain static due to the physical layout of the 1441 line cards. For example, all the ingress ports might be already 1442 hard wired into the classification chip and so all packets must 1443 follow from the ingress port into the classification engine. On 1444 the other hand, the LFBs on the network processor and their 1445 execution order are programmable, even though there might exist 1446 certain capacity limits and linkage constraints between these LFBs. 1447 Examples of the capacity limits might be: there can be no more than 1448 8 meters; there can be no more than 16 queues in one FE; the 1449 scheduler can handle at most up to 16 queues; etc. The linkage 1450 constraints might dictate that classification engine may be 1451 followed by a meter, marker, dropper, counter, queue or IPv4 1452 forwarder, but not scheduler; queues can only be followed by a 1453 scheduler; a scheduler must be followed by the IPv4 forwarder; the 1454 last LFB in the datapath before going into the egress ports must be 1455 the IPv4 forwarder, etc. 1457 Once the FE reports such capability and capacity to the CE, it is 1458 now up to the CE to translate the QoS policy into the desirable 1459 configuration for the FE. Figure 7(a) depicts the FE capability 1460 while 7(b) and 7(c) depict two different topologies that the FE 1461 might be asked to configure to. Note that both the ingress and 1462 egress are omitted in (b) and (c) for simple representation. The 1463 topology in 7(c) is considerably more complex than 7(b) but both 1464 are feasible within the FE capabilities, and so the FE should 1465 accept either configuration request from the CE. 1467 4. Model and Schema for LFB Classes 1469 The main goal of the FE model is to provide an abstract, generic, 1470 modular, implementation-independent representation of the FEs. This 1471 is facilitated using the concept of LFBs which are instantiated 1472 from LFB classes. LFB classes and associated definitions will be 1473 provided in a collection of XML documents. The collection of these 1474 XML documents is called a LFB class library, and each document is 1475 called an LFB class library document (or library document, for 1476 short). Each of the library documents will conform to the schema 1477 presented in this section. The root element of the library document 1478 is the element. 1480 It is not expected that library documents will be exchanged between 1481 FEs and CEs "over-the-wire". But the model will serve as an 1482 important reference for the design and development of the CEs 1483 (software) and FEs (mostly the software part). It will also serve 1484 as a design input when specifying the ForCES protocol elements for 1485 CE-FE communication. 1487 4.1. Namespace 1489 The LFBLibrary element and all of its sub-elements are defined in 1490 the following namespace: 1492 http://ietf.org/forces/1.0/lfbmodel 1494 4.2. Element 1496 The element serves as a root element of all library 1497 documents. It contains one or more of the following main blocks: 1499 . for the frame declarations; 1500 . for defining common data types; 1501 . for defining metadata, and 1502 . for defining LFB classes. 1504 Each block is optional, that is, one library may contain only 1505 metadata defintions, another may contain only LFB class 1506 definitions, yet another may contain all of the above. 1508 In addition to the above main blocks, a library document can import 1509 other library documents if it needs to refer to definitions 1510 contained in the included document. This concept is similar to the 1511 "#include" directive in C. Importing is expressed by the 1512 elements, which must precede all the above elements in the 1513 document. For unique referencing, each LFBLibrary instance document 1514 has a unique label defined in the "provide" attribute of the 1515 LFBLibrary element. 1517 The element also includes an optional 1518 element, which can be used to provide textual description about the 1519 library. 1521 Following is a skeleton of a library document: 1523 1524 1527 1528 ... 1529 1531 1532 1533 ... 1535 1536 1537 ... 1538 1540 1541 1542 ... 1544 1546 1547 1548 ... 1549 1551 1552 1553 ... 1554 1555 1557 4.3. Element 1559 This element is used to refer to another LFB library document. 1560 Similar to the "include" directive in C, this makes the objects 1561 (metadata types, data types, etc.) defined in the referred library 1562 available for referencing in the current document. 1564 The load element must contain the label of the library to be 1565 included and may contain a URL to specify where the library can be 1566 retrieved. The load element can be repeated unlimited times. Three 1567 examples for the elements: 1569 1570 1571 1574 4.4. Element for Frame Type Declarations 1576 Frame names are used in the LFB definition to define what types of 1577 frames the LFB expects at its input port(s) and emits at its output 1578 port(s). The optional element in the library document 1579 contains one or more elements, each declaring one frame 1580 type. 1582 Each frame definition contains a unique name (NMTOKEN) and a brief 1583 synopsis. In addition, an optional detailed description may be 1584 provided. 1586 Uniqueness of frame types must be ensured among frame types defined 1587 in the same library document and in all directly or indirectly 1588 included library documents. 1590 The following example defines two frame types: 1592 1593 1594 ipv4 1595 IPv4 packet 1596 1597 This frame type refers to an IPv4 packet. 1598 1599 1600 1601 ipv6 1602 IPv6 packet 1603 1604 This frame type refers to an IPv6 packet. 1605 1606 1607 ... 1608 1610 4.5. Element for Data Type Definitions 1612 The (optional) element can be used to define 1613 commonly used data types. It contains one or more 1614 elements, each defining a data type with a unique name. Such data 1615 types can be used in several places in the library documents, 1616 including: 1618 . Defining other data types 1619 . Defining metadata 1620 . Defining attributes of LFB classes 1622 This is similar to the concept of having a common header file for 1623 shared data types. 1625 Each element contains a unique name (NMTOKEN), a 1626 brief 1627 synopsis, an optional longer description, and a type definition 1628 element. The name must be unique among all data types defined in 1629 the same library document and in any directly or indirectly 1630 included library documents. For example: 1632 1633 1634 ieeemacaddr 1635 48-bit IEEE MAC address 1636 ... type definition ... 1637 1638 1639 ipv4addr 1640 IPv4 address 1641 ... type definition ... 1642 1643 ... 1644 1646 There are two kinds of data types: atomic and compound. Atomic 1647 data types are appropriate for single-value variables (e.g. 1648 integer, ASCII string, byte array). 1650 The following built-in atomic data types are provided, but 1651 additional atomic data types can be defined with the and 1652 elements: 1654 Meaning 1655 ---- ------- 1656 char 8-bit signed integer 1657 uchar 8-bit unsigned integer 1658 int16 16-bit signed integer 1659 uint16 16-bit unsigned integer 1660 int32 32-bit signed integer 1661 uint32 32-bit unsigned integer 1662 int64 64-bit signed integer 1663 uint64 64-bit unisgned integer 1664 string[N] ASCII null-terminated string with 1665 buffer of N characters (string max 1666 length is N-1) 1667 byte[N] A byte array of N bytes 1668 float16 16-bit floating point number 1669 float32 32-bit IEEE floating point number 1670 float64 64-bit IEEE floating point number 1672 These built-in data types can be readily used to define metadata or 1673 LFB attributes, but can also be used as building blocks when 1674 defining new data types. 1676 Compound data types can build on atomic data types and other 1677 compound data types. There are four ways that compound data types 1678 can be defined. They may be defined as an array of elements of 1679 some compound or atomic data type. They may be a structure of 1680 named elements of compound or atomic data types (ala C structures). 1681 They may be a union of named elements of compound or atomic data 1682 types (ala C unions). They may also be defined as augmentations 1683 (explained below in 4.5.6) of existing compound data types. 1685 Given that the FORCES protocol will be getting and setting 1686 attribute values, all atomic data types used here must be able to 1687 be conveyed in the FORCES protocol. Further, the FORCES protocol 1688 will need a mechanism to convey compound data types. However, the 1689 details of such representations are for the protocol document, not 1690 the model documents. 1692 For the definition of the actual type in the element, 1693 the following elements are available: , , , 1694 , and . 1696 [EDITOR: How to support augmentation is for further study.] 1698 4.5.1. Element for Aliasing Existing Data Types 1700 The element refers to an existing data type by its name. 1701 The referred data type must be defined either in the same library 1702 document, or in one of the included library documents. If the 1703 referred data type is an atomic data type, the newly defined type 1704 will also be regarded as atomic. If the referred data type is a 1705 compound type, the new type will also be a compound. Some usage 1706 examples: 1708 1709 short 1710 Alias to int16 1711 int16 1712 1713 1714 ieeemacaddr 1715 48-bit IEEE MAC address 1716 byte[6] 1717 1719 4.5.2. Element for Deriving New Atomic Types 1721 The element allows the definition of a new atomic type 1722 from an existing atomic type, applying range restrictions and/or 1723 providing special enumerated values. Note that the 1724 element can only use atomic types as base types, and its result is 1725 always another atomic type. 1727 For example, the following snippet defines a new "dscp" data type: 1729 1730 dscp 1731 Diffserv code point. 1732 1733 uchar 1734 1735 1736 1737 1738 1739 DSCP-BE 1740 Best Effort 1741 1742 ... 1743 1744 1745 1747 4.5.3. Element to Define Arrays 1749 The element can be used to create a new compound data type 1750 as an array of a compound or an atomic data type. The type of the 1751 array entry can be specified either by referring to an existing 1752 type (using the element) or defining an unnamed type 1753 inside the element using any of the , , 1754 , or elements. 1756 The array can be "fixed-size" or "variable-size", which is 1757 specified by the "type" attribute of the element. The 1758 default is "variable-size". For variable size arrays an optional 1759 "max-length" attribute can specify the maximum allowed length. This 1760 attribute should be used to encode semantic limitations, and not 1761 implementation limitations. The latter should be handled by 1762 capability attributes of LFB classes, and should never be included 1763 in data type definitions. If the "max-length" attribute is not 1764 provided, the array is regarded as of unlimited-size. 1766 For fixed-size arrays a "length" attribute must be provided which 1767 specifies the constant size of the array. 1769 The result of this construct is always a compound type, even if the 1770 array has a fixed size of 1. 1772 Arrays can only be subscripted by integers, and will be presumed to 1773 start with index 0. 1775 The following example shows the definition of a fixed size array 1776 with pre-defined data type as array elements: 1778 1779 dscp-mapping-table 1780 1781 A table of 64 DSCP values, used to re-map code space. 1782 1783 1784 dscp 1785 1786 1788 The following example defines a variable size array with an upper 1789 limit on its size: 1791 1792 mac-alias-table 1793 A table with up to 8 IEEE MAC addresses 1794 1795 ieeemacaddr 1796 1797 1799 The following example shows the definition of an array with local 1800 (unnamed) type definition: 1802 1803 classification-table 1804 1805 A table of classification rules and result opcodes. 1806 1807 1808 1809 1810 rule 1811 The rule to match 1812 classrule 1813 1814 1815 opcode 1816 The result code 1817 opcode 1818 1819 1820 1821 1823 In the above example each entry of the array is a of two 1824 fileds ("rule" and "opcode"). 1826 4.5.4. Element to Define Structures 1828 A structure is comprised of a collection of data elements. Each 1829 data element has a data type (either an atomic type or an existing 1830 compound type) and is assigned a name unique within the scope of 1831 the compound data type being defined. These serve the same function 1832 as "struct" in C, etc. 1834 The actual type of the field can be defined by referring to an 1835 existing type (using the element), or can be a locally 1836 defined (unnamed) type created by any of the , , 1837 , or elements. 1839 The result of this construct is always regarded a compound type, 1840 even if the contains only one field. 1842 An example: 1844 1845 ipv4prefix 1846 1847 IPv4 prefix defined by an address and a prefix length 1848 1849 1850 1851 address 1852 Address part 1853 ipv4addr 1854 1855 1856 prefixlen 1857 Prefix length part 1858 1859 uchar 1860 1861 1862 1863 1864 1865 1866 1868 4.5.5. Element to Define Union Types 1870 Similar to the union declaration in C, this construct allows the 1871 definition of overlay types. Its format is identical to the 1872 element. 1874 The result of this construct is always regarded a compound type, 1875 even if the union contains only one element. 1877 4.5.6. Augmentations 1879 Compound types can also be defined as augmentations of existing 1880 compound types. If the existing compound type is a structure, 1881 augmentation may add new elements to the type. They may replace 1882 the type of an existing element with an augmentation derived from 1883 the current type. They may not delete an existing element, nor may 1884 they replace the type of an existing element with one that is not 1885 an augmentation of the type that the element has in the basis for 1886 the augmentation. If the existing compound type is an array, 1887 augmentation means augmentation of the array element type. 1889 One consequence of this is that augmentations are compatible with 1890 the compound type from which they are derived. As such, 1891 augmentations are useful in defining attributes for LFB subclasses 1892 with backward compatibility. In addition to adding new attributes 1893 to a class, the data type of an existing attribute may be replaced 1894 by an augmentation of that attribute, and still meet the 1895 compatibility rules for subclasses. 1897 For example, consider a simple base LFB class A that has only one 1898 attribute (attr1) of type X. One way to derive class A1 from A can 1899 be by simply adding a second attribute (of any type). Another way 1900 to derive a class A2 from A can be by replacing the original 1901 attribute (attr1) in A of type X with one of type Y, where Y is an 1902 augmentation of X. Both classes A1 and A2 are backward compatible 1903 with class A. 1905 [EDITOR: How to support the concept of augmentation in the XML 1906 schema is for further study.] 1908 4.6. Element for Metadata Definitions 1910 The (optional) element in the library document 1911 contains one or more elements. Each 1912 element defines a metadata. 1914 Each element contains a unique name (NMTOKEN). 1915 Uniqueness is defined over all metadata defined in this library 1916 document and in all directly or indirectly included library 1917 documents. The element also contains a brief 1918 synopsis, an optional detailed description, and a compulsory type 1919 definition information. Only atomic data types can be used as value 1920 types for metadata. 1922 Two forms of type definitions are allowed. The first form uses the 1923 element to refer to an existing atomic data type defined 1924 in the element of the same library document or in 1925 one of the included library documents. The usage of the 1926 element is identical to how it is used in the 1927 elements, except here it can only refer to atomic types. 1929 [EDITOR: The latter restriction is not yet enforced by the XML 1930 schema.] 1932 The second form is an explicit type definition using the 1933 element. This element is used here in the same way as in the 1934 elements. 1936 The following example shows both usages: 1938 1939 1940 NEXTHOPID 1941 Refers to a Next Hop entry in NH LFB 1942 int32 1943 1944 1945 CLASSID 1946 1947 Result of classification (0 means no match). 1949 1950 1951 int32 1952 1953 1954 NOMATCH 1955 1956 Classification didn�t result in match. 1957 1958 1959 1960 1961 1962 1964 4.7. Element for LFB Class Definitions 1966 The (optional) element can be used to define one or 1967 more LFB classes using elements. Each 1968 element defines an LFB class and includes the following elements: 1969 . provides the symbolic name of the LFB class. Example: 1970 "ipv4lpm" 1971 . provides a short synopsis of the LFB class. 1972 Example: "IPv4 Longest Prefix Match Lookup LFB" 1973 . is the version indicator 1974 . is the inheritance indicator 1975 . lists the input ports and their specifications 1976 . lists the output ports and their specifications 1977 . defines the operational attributes of the LFB 1978 . defines the capability attributes of the LFB 1979 . contains the operational specification of the 1980 LFB 1982 [EDITOR: LFB class names should be unique not only among classes 1983 defined in this document and in all included documents, but also 1984 unique across a large collection of libraries. Obviously some 1985 global control is needed to ensure such uniqueness. This subject 1986 requires further study.] 1988 Here is a skeleton of an example LFB class definition: 1990 1991 1992 ipv4lpm 1993 IPv4 Longest Prefix Match Lookup LFB 1994 1.0 1995 baseclass 1997 1998 ... 1999 2001 2002 ... 2003 2005 2006 ... 2007 2009 2010 ... 2011 2013 2014 This LFB represents the IPv4 longest prefix match lookup 2015 operation. 2016 The modeled behavior is as follows: 2017 Blah-blah-blah. 2018 2020 2021 ... 2022 2024 Except the , , and elements, all other 2025 elements are optional in , though when they are 2026 present, they must occur in the above order. 2028 4.7.1. Element to Express LFB Inheritance 2030 The optional element can be used to indicate that 2031 this class is a derivative of some other class. The content of this 2032 element must be the unique name () of another LFB class. The 2033 referred LFB class must be defined in the same library document or 2034 in one of the included library documents. 2036 [EDITOR: The element will likely need to specify the 2037 version of the ancestor, which is not included in the schema yet. 2038 The process and rules of class derivation are still being studied.] 2040 It is assumed that the derived class is backwards compatible with 2041 the base class. 2043 4.7.2. Element to Define LFB Inputs 2045 The optional element is used to define input ports. An 2046 LFB class may have zero, one, or more inputs. If the LFB class has 2047 no input ports, the elements must be omitted. The 2048 element can contain one or more elements, 2049 one for each port or port-group. We assume that most LFBs will have 2050 exactly one input. Multiple inputs with the same input type are 2051 modeled as one input group. Input groups are defined the same way 2052 as input ports by the element, differentiated only by 2053 an optional "group" attribute. 2055 Multiple inputs with different input types should be avoided if 2056 possible (see discussion in Section 3.2.1). Some special LFBs will 2057 have no inputs at all. For example, a packet generator LFB does not 2058 need an input. 2060 Single input ports and input port groups are both defined by the 2061 element, they are differentiated by only an optional 2062 "group" attribute. 2064 The element contains the following elements: 2065 . provides the symbolic name of the input. Example: "in". 2066 Note that this symbolic name must be unique only within the 2067 scope of the LFB class. 2068 . contains a brief description of the input. Example: 2069 "Normal packet input". 2070 . lists all allowed frame formats. Example: {"ipv4" 2071 and "ipv6"}. Note that this list should refer to names 2072 specified in the element of the same library 2073 document or in any included library documents. The 2074 element can also provide a list of required metadata. Example: 2075 {"classid", "vifid"}. This list should refer to names of 2076 metadata defined in the element in the same 2077 library document or in any included library documents. For each 2078 metadata it must be specified whether the metadata is required 2079 or optional. For each optional metadata a default value must be 2080 specified, which is used by the LFB if the metadata is not 2081 provided with a packet. 2083 In addition, the optional "group" attribute of the 2084 element can specify if the port can behave as a port group, i.e., 2085 it is allowed to be instantiated. This is indicated by a "yes" 2086 value (the default value is "no"). 2088 An example element, defining two input ports, the 2089 second one being an input port group: 2091 2092 2093 in 2094 Normal input 2095 2096 2097 ipv4 2098 ipv6 2099 2100 2101 classid 2102 vifid 2103 vrfid 2104 2105 2106 2107 2108 ... another input port ... 2109 2110 2112 For each , the frame type expectations are defined by 2113 the element using one or more elements (see 2114 example above). When multiple frame types are listed, it means that 2115 "one of these" frame types are expected. A packet of any other 2116 frame type is regarded as incompatible with this input port of the 2117 LFB class. The above example list two frames as expected frame 2118 types: "ipv4" and "ipv6". 2120 Metadata expectations are specified by the 2121 element. In its simplest form this element can contain a list of 2122 elements, each referring to a metadata. When multiple 2123 instances of metadata are listed by elements, it means that 2124 "all of these" metadata must be received with each packet (except 2125 metadata that are marked as "optional" by the "dependency" 2126 attribute of the corresponding element). For a metadata that 2127 is specified "optional", a default value must be provided using the 2128 "defaultValue" attribute. The above example lists three metadata as 2129 expected metadata, two of which are mandatory ("classid" and 2130 "vifid"), and one being optional ("vrfid"). 2132 [EDITOR: How to express default values for byte[N] atomic types is 2133 yet to be defined.] 2134 The schema also allows for more complex definitions of metadata 2135 expectations. For example, using the element, a list of 2136 metadata can be specified to express that at least one of the 2137 specified metadata must be present with any packet. For example: 2139 2140 2141 prefixmask 2142 prefixlen 2143 2144 2146 The above example specifies that either the "prefixmask" or the 2147 "prefixlen" metadata must be provided with any packet. 2149 The two forms can also be combined, as it is shown in the following 2150 example: 2152 2153 classid 2154 vifid 2155 vrfid 2156 2157 prefixmask 2158 prefixlen 2159 2160 2162 Although the schema is constructed to allow even more complex 2163 definition of metadata expectations, we do not discuss these here. 2165 4.7.3. Element to Define LFB Outputs 2167 The optional element is used to define output ports. 2168 An LFB class may have zero, one, or more outputs. If the LFB class 2169 has no output ports, the element must be omitted. The 2170 element can contain one or more 2171 elements, one for each port or port-group. If there are multiple 2172 outputs with the same output type, we model them as an output port 2173 group. Some special LFBs may have no outputs at all (e.g., 2174 Dropper). 2176 Single output ports and output port groups are both defined by the 2177 element, they are differentiated by only an optional 2178 "group" attribute. 2180 The element contains the following elements: 2181 . provides the symbolic name of the output. Example: "out". 2182 Note that the symbolic name must be unique only within the scope 2183 of the LFB class. 2184 . contains a brief description of the output port. 2185 Example: "Normal packet output". 2186 . lists the allowed frame formats. Example: {"ipv4", 2187 "ipv6"}. Note that this list should refer to symbols specified 2188 in the element in the same library document or in 2189 any included library documents. The element may also 2190 contain the list of emitted (generated) metadata. Example: 2191 {"classid", "color"}. This list should refer to names of 2192 metadata specified in the element in the same 2193 library document or in any included library documents. For each 2194 generated metadata, it should be specified whether the metadata 2195 is always generated or generated only in certain conditions. 2196 This information is important when assessing compatibility 2197 between LFBs. 2199 In addition, the optional "group" attribute of the 2200 element can specify if the port can behave as a port group, i.e., 2201 it is allowed to be instantiated. This is indicated by a "yes" 2202 value (the default value is "no"). 2204 The following example specifies two output ports, the second being 2205 an output port group: 2207 2208 2209 out 2210 Normal output 2211 2212 2213 ipv4 2214 ipv4bis 2215 2216 2217 nhid 2218 nhtabid 2219 2220 2221 2222 2223 exc 2224 Exception output port group 2225 2226 2227 ipv4 2228 ipv4bis 2229 2230 2231 errorid 2232 2233 2234 2235 2237 What types of frames and metadata the port produces are defined 2238 inside the element in each . Within the 2239 element, the list of frame types the port produces is 2240 listed in the element. When more than one frame is 2241 listed, it means that "one of" these frames will be produced. 2243 The list of metadata that is produced with each packet is listed in 2244 the optional element of the . In its 2245 simplest form, this element can contain a list of elements, 2246 each referring to a metadata type. The meaning of such a list is 2247 that "all of" these metadata are provided with each packet, except 2248 those that are listed with the optional "availability" attribute 2249 set to "conditional." Similar to the element of 2250 the , the element supports more 2251 complex forms, which we do not discuss here further. 2253 4.7.4. Element to Define LFB Operational Attributes 2255 Operational parameters of the LFBs that must be visible to the CEs 2256 are conceptualized in the model as the LFB attributes. These 2257 include, for example, flags, single parameter arguments, complex 2258 arguments, and tables. Note that the attributes here refer to only 2259 those operational parameters of the LFBs that must be visible to 2260 the CEs. Other variables that are internal to LFB implementation 2261 are not regarded as LFB attributes and hence are not covered. 2263 Some examples for LFB attributes are: 2264 . Configurable flags and switches selecting between operational 2265 modes of the LFB 2266 . Number of inputs or ouputs in a port group 2267 . Metadata CONSUME vs. PROPAGATE mode selectors 2268 . Various configurable lookup tables, including interface 2269 tables, prefix tables, classification tables, DSCP mapping 2270 tables, MAC address tables, etc. 2271 . Packet and byte counters 2272 . Various event counters 2273 . Number of current inputs or outputs for each input or output 2274 group 2275 . Metadata CONSUME/PROPAGATE mode selector 2277 There may be various access permission restrictions on what the CE 2278 can do with an LFB attribute. The following categories may be 2279 supported: 2280 . No-access attributes. This is useful when multiple access 2281 modes maybe defined for a given attribute to allow some 2282 flexibility for different implementations. 2283 . Read-only attributes. 2284 . Read-write attributes. 2285 . Write-only attributes. This could be any configurable data 2286 for which read capability is not provided to the CEs. (e.g., 2287 the security key information) 2288 . Read-reset attributes. The CE can read and reset this 2289 resource, but cannot set it to an arbitrary value. Example: 2290 Counters. 2291 . Firing-only attributes. A write attempt to this resource will 2292 trigger some specific actions in the LFB, but the actual value 2293 written is ignored. 2295 The LFB class may define more than one possible access mode for a 2296 given attribute (for example, "write-only" and "read-write"), in 2297 which case it is left to the actual implementation to pick one of 2298 the modes. In such cases a corresponding capability attribute must 2299 inform the CE about the access mode the actual LFB instance 2300 supports (see next subsection on capability attributes). 2302 The attributes of the LFB class are listed in the 2303 element. Each attribute is defined by an element. An 2304 element contains the following elements: 2305 . defines the name of the attribute. This name must be 2306 unique among the attributes of the LFB class. Example: 2307 "version". 2308 . should provide a brief description of the purpose 2309 of the attribute. 2310 . The data type of the attribute can be defined either via a 2311 reference to a predefined data type or providing a local 2312 definition of the type. The former is provided by using the 2313 element, which must refer to the unique name of an 2314 existing data type defined in the element in 2315 the same library document or in any of the included library 2316 documents. When the data type is defined locally (unnamed 2317 type), one of the following elements can be used: , 2318 , , and . Their usage is identical to 2319 how they are used inside elements (see Section 2320 4.5). 2321 . The optional element can specify a default 2322 value for the attribute, which is applied when the LFB is 2323 initialized or reset. [EDITOR: A convention to define default 2324 values for compound data types and byte[N] atomic types is yet 2325 to be defined.] 2327 In addition to the above elements, the element includes 2328 an optional "access" attribute, which can take any of the following 2329 values or even a list of these values: "read-only", "read-write", 2330 "write-only", "read-reset", and "trigger-only". The default access 2331 mode is "read-write". 2333 The following example defines two attributes for an LFB: 2335 2336 2337 foo 2338 number of things 2339 uint32 2340 2341 2342 bar 2343 number of this other thing 2344 2345 uint32 2346 2347 2348 2349 2350 10 2351 2352 2354 The first attribute ("foo") is a read-only 32-bit unsigned integer, 2355 defined by referring to the built-in "uint32" atomic type. The 2356 second attribute ("bar") is also an integer, but uses the 2357 element to provide additional range restrictions. This attribute 2358 has two possible access modes, "read-write" or "write-only". A 2359 default value of 10 is provided. 2361 Note that not all attributes are likely to exist at all times in a 2362 particular implementation. While the capabilities will frequently 2363 indicate this non-existence, CEs may attempt to reference non- 2364 existent or non-permitted attributes anyway. The FORCES protocol 2365 mechanisms should include appropriate error indicators for this 2366 case. 2368 The mechanism defined above for non-supported attributes can also 2369 apply to attempts to reference non-existent array elements or to 2370 set read-only elements. 2372 4.7.5. Element to Define LFB Capability Attributes 2374 The LFB class specification will provide some flexibility for the 2375 FE implementation regarding how the LFB class is implemented. For 2376 example the class may define some features optional, in which case 2377 the actual implementation may or may not provide the given feature. 2378 In these cases the CE must be able to query the LFB instance about 2379 the availability of the feature. In addition, the instance may have 2380 some limitations that are not inherent from the class definition, 2381 but rather the result of some implementation limitations. For 2382 example, an array attribute may be defined in the class definition 2383 as "unlimited" size, but the physical implementation may impose a 2384 hard limit on the size of the array. 2386 Such capability related information is expressed by the capability 2387 attributes of the LFB class. The capability attributes are always 2388 read-only attributes, and they are listed in a separate 2389 element in the . The 2390 element contains one or more elements, each defining 2391 one capability attribute. The format of the element is 2392 almost the same as the element, it differs in two 2393 aspects: it lacks the access mode attribute (because it is always 2394 read-only), and it lacks the element (because 2395 default value is not applicable to read-only attributes). 2397 Some examples of capability attributes: 2398 . The version of the LFB class that this LFB instance complies 2399 with; 2400 . Supported optional features of the LFB class; 2401 . Maximum number of configurable outputs for an output group; 2402 . Metadata pass-through limitations of the LFB; 2403 . Maximum size of configurable attribute tables; 2404 . Additional range restriction on operational attributes; 2405 . Supported access modes of certain attributes (if the access 2406 mode of an operational attribute is specified as a list of two 2407 or mode modes). 2409 The following example lists two capability attributes: 2411 2412 2413 version 2414 2415 LFB class version this instance is compliant with. 2416 2417 version 2418 2419 2420 limitBar 2421 2422 Maximum value of the "bar" attribute. 2423 2424 uint16 2425 2426 2428 4.7.6. Element for LFB Operational Specification 2430 The element of the provides unstructured 2431 text (in XML sense) to verbally describe what the LFB does. 2433 4.8. XML Schema for LFB Class Library Documents 2435 2436 2442 2443 2444 Schema for Defining LFB Classes and associated types (frames, 2445 data types for LFB attributes, and metadata). 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2457 2459 2461 2463 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2544 2546 2547 2548 2549 2550 2551 2552 2554 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2579 2580 2581 2582 2583 2584 2585 2586 2587 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2631 2633 2635 2637 2640 2641 2642 2643 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2677 2678 2679 2680 2681 2682 2683 2684 2686 2687 2688 2689 2690 2691 2692 2693 2694 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2721 2722 2723 2724 2725 2726 2727 2728 2730 2731 2732 2733 2734 2735 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2748 2749 2750 2751 2752 2753 2754 2755 2757 2758 2759 2760 2761 2762 2763 2764 2765 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2813 2814 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2855 5. FE Attributes and Capabilities 2857 A ForCES forwarding element handles traffic on behalf of a ForCES 2858 control element. While the standards will describe the protocol 2859 and mechanisms for this control, different implementations and 2860 different instances will have different capabilities. The CE needs 2861 to be able to determine what each instance it is responsible for is 2862 actually capable of doing. As stated previously, this is an 2863 approximation. The CE is expected to be prepared to cope with 2864 errors in requests and variations in detail not captured by the 2865 capabilities information about an FE. 2867 In addition to its capabilities, an FE will have some information 2868 (attributes) that can be used in understanding and controlling the 2869 forwarding operations. Some of the attributes will be read only, 2870 while others will also be writeable. 2872 The ForCES protocol will define the actual mechanism for getting 2873 and setting attribute information. This model defines the starting 2874 set of information that will be available. This definition 2875 includes the semantics and the structuring of the information. It 2876 also provides for extensions to this information. 2878 In order to crisply define the attribute information and structure, 2879 this document describes the attributes as information in an 2880 abstract XML document. Conceptually, each FE contains such a 2881 document. The document structure is defined by the XML Schema 2882 contained in this model. Operationally, the ForCES protocol refers 2883 to information contained in that document in order to read or write 2884 FE attributes and capabilities. This document is an abstract 2885 representation of the information. There is no requirement that 2886 such a document actually exist in memory. Unless the ForCES 2887 protocol calls for transfer of the information in XML, the 2888 information is not required to ever be represented in the FE in 2889 XML. The XML schema serves only to identify the elements and 2890 structure of the information. 2892 The subsections in this part of the document provide the details on 2893 this aspect of the FE model. 5.1 gives the XML schema for the 2894 abstract FE attribute document. 5.2 elaborates on each of the 2895 defined attributes of the FE, following the hierarchy of the 2896 schema. 5.3 provides an example XML FE attribute document to 2897 clarify the meaning of 5.1 and 5.2. 2899 5.1. XML Schema for FE Attribute Documents 2901 2902 2904 2905 2906 Schema for the Abstract FE Attributes and Capabilities Document 2907 2908 2910 2911 2912 2913 2915 2917 2918 2919 2921 2922 2923 2925 2926 2927 2928 2930 2931 2932 2933 2936 2937 2939 2940 2941 2942 2943 2944 2946 2947 2948 2949 2950 2952 2953 2954 2955 2958 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2974 2976 2977 2979 2980 2981 2982 2983 2986 2987 2988 2989 2990 2992 2993 2995 2996 2997 2998 3000 3001 3003 3004 3005 3007 3008 3009 3010 3011 3012 3013 3014 3015 3017 3018 3019 3020 3021 3022 3023 3024 3025 3027 3028 3029 "> 3030 "> 3031 3032 3033 3034 3035 3036 3037 3039 3041 3042 3043 3046 3047 3048 3049 3050 3052 3053 3054 3055 3056 3057 3058 3059 3061 3062 3063 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3076 3078 3079 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3092 3094 5.2. FEDocument 3096 An instance of this document captures the capabilities and FE level 3097 attribute / state information about a given FE. Currently, two 3098 elements are allowed in the FEDocument, FECapabilities and 3099 FEAttributes. 3101 At the moment, all capability and attribute information in this 3102 abstract document is defined as optional. We may wish to mandate 3103 support for some capability and/or attribute information. 3105 If a protocol using binary encoding of this information is adopted 3106 by the ForCES working group, then each relevant element defined in 3107 the schema will have a "ProtocolEncoding" attribute added, with a 3108 "Fixed" value providing the value that is used in the protocol for 3109 that element, so that the XML and the on the wire protocol can be 3110 correlated. 3112 5.2.1. FECapabilities 3113 This element, which if it occurs must occur only once, contains all 3114 the capability related information about the FE. Capability 3115 information is always considered to be read-only. 3117 The currently defined elements allowed within the FECapabilities 3118 element are ModifiableLFBTopology, LFBsSupported, 3119 WriteableAttributes and ReadableAttributes. 3121 5.2.1.1. ModifiableLFBTopology 3123 This element has a boolean value. This element indicates whether 3124 the LFB topology of the FE may be changed by the CE. If the 3125 element is absent, the default value is assumed to be true, and the 3126 CE presumes the LFB topology may be changed. If the value is 3127 present and set to false, the LFB topology of the FE is fixed. In 3128 that case, the LFBs supported clause may be omitted, and the list 3129 of supported LFBs is inferred by the CE from the LFB topology 3130 information. If the list of supported LFBs is provided when 3131 ModifiableLFBTopology is false, the CanOccurBefore and 3132 CanOccurAfter information should be omitted. 3134 5.2.1.2. SupportedLFBs and SupportedLFB 3136 One capability that the FE should include is the list of supported 3137 LFB classes. The SupportedLFBs element, which occurs at most once, 3138 serves as a wrapper for the list of LFB classes supported. Each 3139 class is described in a SupportedLFB element. 3141 Each occurrence of the SupportedLFB element describes an LFB class 3142 that the FE supports. In addition to indicating that the FE 3143 supports the class, FEs with modifiable LFB topology should include 3144 information about how LFBs of the specified class may be connected 3145 to other LFBs. This information should describe which LFB classes 3146 the specified LFB class may succeed or precede in the LFB topology. 3147 The FE should include information as to which port groups may be 3148 connected to the given adjacent LFB class. If port group 3149 information is omitted, it is assumed that all port groups may be 3150 used. 3152 5.2.1.2.1. LFBName 3154 This element has as its value the name of the LFB being described. 3156 5.2.1.2.2. LFBOccurrenceLimit 3158 This element, if present, indicates the largest number of instances 3159 of this LFB class the FE can support. For FEs that do not have the 3160 capability to create or destroy LFB instances, this can either be 3161 omitted or be the same as the number of LFB instances of this class 3162 contained in the LFB list attribute. 3164 5.2.1.2.3. PortGroupLimits and PortGroupLimit 3166 The PortGroupLimits element is the wrapper to hold information 3167 about the port groups supported by the LFB class. It holds multiple 3168 occurrences of the PortGroupLimit element. 3170 Each occurrence of the PortGroupLimit element contains the port 3171 occurrence information for a single port group of the LFB class. 3172 Each occurrence has the name of the port group in the PortGroupName 3173 element, the fewest number of ports that can exist in the group in 3174 the MinPortCount element, and the largest number of ports that can 3175 exist in the group in the MaxPortCount element. 3177 5.2.1.2.4.CanOccurAfters and CanOccurAfter 3179 The CanOccurAfters element is a wrapper to hold the multiple 3180 occurrences of the CanOccurAfter permissible placement information. 3182 The CanOccurAfter element describes a permissible positioning of 3183 the SupportedLFB. Specifically, it names an LFB that can 3184 topologically precede the SupportedLFB. That is, the SupportedLFB 3185 can have an input port connected to an output port of the LFB that 3186 it CanOccurAfter. The LFB class that the SupportedLFB can follow is 3187 identified by the NeighborLFB element of the CanOccurAfter element. 3188 If this neighbor can only be connected to a specific set of input 3189 port groups, then the viaPort element is included. This element 3190 occurs once for each input port group of the SupportedLFB that can 3191 be connected to an output port of the NeighborLFB. 3193 [e.g., Within a SupportedLFB element, each CanOccurAfter element 3194 must have a unique NeighborLFB, and within each CanOccurAfter 3195 element each viaPort must represent a unique and valid input port 3196 group of the SupportedLFB. The "unique" clauses for this have not 3197 yet been added to the schema.] 3199 5.2.1.2.5. CanOccurBefores and CanOccurBefore 3201 The CanOccurBefores element is a wrapper to hold the multiple 3202 occurrences of the CanOccurBefore permissible placement 3203 information. 3205 The CanOccurBefore element similarly lists those LFB classes that 3206 the SupportedLFB may precede in the topology. In this element, the 3207 viaPort element represents the output port group of the 3208 SupportedLFB that may be connected to the NeighborLFB. As with 3209 CanOccurAfter, viaPort may occur multiple times if multiple output 3210 ports may legitimately connect to the given NeighborLFB class. 3212 [And a similar set of uniqueness constraints apply to the 3213 CanOccurBefore clauses, even though an LFB may occur both in 3214 CanOccurAfter and CanOccurBefore.] 3216 5.2.1.2.6. LFBClassCapabilities 3218 This element contains capability information about the subject LFB 3219 class whose structure and semantics are defined by the LFB class 3220 definition. 3222 5.2.1.3. SupportedAttributes 3224 This element serves as a wrapper to hold the information about 3225 attributed related capabilities. Specifically, attributes should be 3226 described in this element if: 3227 a) they are optional elements in the standard and are supported 3228 by the FE, or 3229 b) the standard allows for a range of access permissions (for 3230 example, read-only or read-write). 3232 Each attribute so described is contained in the SupportedAttributes 3233 element. That element contains an AttributeName element whose value 3234 is the name of the element being described and an AccessModes 3235 element, whose value is the list of permissions. 3237 5.2.2. FEAttributes 3239 The FEAttributes element contains the attributes of the FE that are 3240 not considered "capabilities". Some of these attributes are 3241 writeable, and some are read-only, which should be indicated by the 3242 capability information. At the moment, the set of attributes is 3243 woefully incomplete. Each attribute is identified by a unique 3244 element tag, and the value of the element is the value of the 3245 attribute. 3247 5.2.2.1. FEStatus 3249 This attribute carries the overall state of the FE. For now, it is 3250 restricted to the strings AdminDisable, OperDisable and OperEnable. 3252 5.2.2.2.LFBInstances and LFBInstance 3253 The LFBInstances element serves as a wrapper to hold the multiple 3254 occurrences of the LFBInstance information about individual LFB 3255 instances on the FE. 3257 Each occurrence of the LFBInstance element describes a single LFB 3258 instance. Each element contains an LFBClassName indicating what 3259 class this instance has, and an LFBInstanceID indicating the ID 3260 used for referring to this instance. For now, the ID uses the 3261 NMTOKEN construction. Further protocol work is likely to replace 3262 this with a range restricted integer. 3264 5.2.2.3. LFBTopology and LFBLink 3266 This optional element contains the information about each inter-LFB 3267 link inside the FE. Each link is described in an LFBLink element. 3268 This element contains sufficient information to identify precisely 3269 the end points of a link. The FromLFBID and ToLFBID fields indicate 3270 the LFB instances at each end of the link, and must reference LFBs 3271 in the LFB instance table. The FromPortGroup and ToPortGroup must 3272 identify output and input port groups defined in the LFB classes of 3273 the LFB instances identified by the FromLFBID and ToLFBID. The 3274 FromPortIndex and ToPortIndex fields select the elements from the 3275 port groups that this link connects. All links are uniquely 3276 identified by the FromLFBID, FromPortGroup, and FromPortIndex 3277 fields. Multiple links may have the same ToLFBID, ToPortGroup, and 3278 ToPortIndex as this model supports fan in of inter-LFB links but 3279 not fan out. 3281 5.2.2.4. FEConfiguredNeighbors an FEConfiguredNeighbor 3283 The FEConfiguredNeighbors element is a wrapper to hold the 3284 configuration information that one or more FEConfiguredNeighbor 3285 elements convey about the configured FE topology. 3287 The FEConfiguredNeighbor element occurs once for each configured FE 3288 neighbor the FE knows about. It should not be filled in based on 3289 FE level protocol operations. In general, neighbor discovery 3290 operation on the FE should be represented and manipulated as an 3291 LFB. However, for FEs that include neighbor discovery and do not 3292 have such an LFB, it is permitted to fill in the information in 3293 this table based on such protocols. 3295 Similarly, the MAC address information in the table is intended to 3296 be used in situations where neighbors are configured by MAC 3297 address. Resolution of network layer to MAC address information 3298 should be captured in ARP LFBs, not duplicated in this table. Note 3299 that the same neighbor may be reached through multiple interfaces 3300 or at multiple addresses. There is no uniqueness requirement of 3301 any sort on occurrences of the FEConfiguredNeighbor element. 3303 Information about the intended forms of exchange with a given 3304 neighbor is not captured here, only the adjacency information is 3305 included. 3307 5.2.2.4.1.NeighborID 3309 This is the ID in some space meaningful to the CE for the neighbor. 3310 If this table remains, we probably should add an FEID from the same 3311 space as an attribute of the FE. 3313 5.2.2.4.2.NeighborInterface 3315 This identifies the interface through which the neighbor is 3316 reached. 3318 [Editors note: As the port structures become better defined, the 3319 type for this should be filled in with the types necessary to 3320 reference the various possible neighbor interfaces, include 3321 physical interfaces, logical tunnels, virtual circuits, etc.] 3323 5.2.2.4.3. NeighborNetworkAddress 3325 Neighbor configuration is frequently done on the basis of a network 3326 layer address. For neighbors configured in that fashion, this is 3327 where that address is stored. 3329 5.2.2.4.4.NeighborMacAddress 3331 Neighbors are sometimes configured using MAC level addresses 3332 (Ethernet MAC address, circuit identifiers, etc.) If such 3333 addresses are used to configure the adjacency, then that 3334 information is stored here. Note that over some ports such as 3335 physical point to point links or virtual circuits considered as 3336 individual interfaces, there is no need for either form of address. 3338 5.3. Sample FE Attribute Document 3340 3341 3343 3345 true 3346 3347 3348 3349 Classifier 3350 3 3352 3353 3354 3355 InputPortGroup 3356 1 3357 1 3358 3359 3360 3361 OutputPortGroup 3362 0 3363 32 3364 3365 3366 3367 ErrorPortGroup 3368 0 3369 1 3370 3371 3372 3373 3374 Port 3375 3376 3377 InternalSource 3379 3380 3381 3382 3383 3384 Marker 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 FEStatus 3395 read write 3396 3397 3398 Vendor 3399 read 3400 3402 Model 3403 read 3404 3405 3406 3408 3409 World Wide Widgets 3410 Foo Forward Model 6 3411 OperEnable 3412 3413 3414 Classifier 3415 Inst5 3416 3417 3418 Interface 3419 Inst11 3420 3421 3422 Meter 3423 Inst17 3424 3425 3426 3427 3428 Inst11 3429 IFOnwardGroup 3430 1 3431 Inst5 3432 InputPortGroup 3433 1 3434 3435 3436 Inst5 3437 OutputGroup 3438 1 3439 Inst17 3440 InMeterGroup 3441 1 3442 3443 3444 3445 3447 6. LFB Class Library 3449 A set of initial LFB classes are identified here in the LFB class 3450 library as necessary to build common FE functions. Some of the LFB 3451 classes described here are abstract base classes from which 3452 specific LFB sub-classes will be derived. Hence, the base classes 3453 may not be used directly in a particular FE's model, but the sub- 3454 classes (yet to be defined) could be. This initial list attempts 3455 to describe LFB classes at the expected level of granularity. This 3456 list is neither exhaustive nor sufficiently detailed. 3458 Several working groups in the IETF have already done some relevant 3459 work in modeling the provisioning policy data for some of the 3460 functions we are interested in, for example, the DiffServ 3461 (Differentiated Services) PIB [4] and IPSec PIB [8]. Whenever 3462 possible, we have tried to reuse the work done elsewhere instead of 3463 reinventing the wheel. 3465 6.1. Port LFB 3467 A Port LFB is used to model physical I/O ports on the FE. It is 3468 both a source of data "received" by the FE and a sink of data 3469 "transmitted" by the FE. The Port LFB contains a number of static 3470 attributes, which may include, but are not limited to, the 3471 following items: 3472 . the number of physical ports on this LFB 3473 . physical port type 3474 . physical port link speed (may be variable; e.g., 10/100/1000 3475 Ethernet). 3477 In addition, the Port LFB contains a number of configurable 3478 attributes, including: 3479 . physical port current status (up or down) 3480 . physical port loopback 3481 . physical port mapping to L2 interface. 3483 The Port LFB can be sub-classed into technology specific LFB 3484 classes, with additional static and configurable attributes. 3485 Examples of possible sub-classes include: 3486 . Ethernet 3487 . Packet-over-SONET OC-N 3488 . ATM-over-SONET/SDN OC-N 3489 . T3 3490 . E3 3491 . T1 3492 . E1 3493 . CSIX-L1 switching fabric port (Fi interface) 3494 . CE-FE port (for Fp interface). 3496 LFB class inheritance can be used to sub-class derived LFB classes 3497 with additional properties, such as TDM channelization. 3499 The Port LFB "receives" (sources) and "transmits" (sinks) frames in 3500 technology specific formats (described in the respective LFB class 3501 definition but not otherwise modeled) into/out of the FE. Packets 3502 "received" from a physical port are sourced on (one of) the LFB's 3503 output port(s), while packets to be "transmitted" on a physical 3504 port are sinked on (one of) the LFB's input port(s). The Port LFB 3505 is unique among LFB classes in that packets accepted on a LFB input 3506 port are not emitted back out on an LFB output port (except in the 3507 case of physical port loopback operation). 3509 The Port LFB transmits technology specific L2 frames to 3510 topologically adjacent LFB instances (i.e., no frame 3511 decapsulation/encapsulation is modeled in this LFB class). When 3512 transmitting a frame to an adjacent downstream LFB, the Port LFB 3513 provides two items of metadata: the frame length and the L2 3514 interface identifier. When receiving frames from an adjacent 3515 upstream LFB, the frame is accompanied by two items of metadata: 3516 frame length and outgoing port identifier. 3518 Statistics are not maintained by the Port LFB; statistics 3519 associated with a particular port may be maintained by an L2 3520 interface LFB (see Section 6.2). 3522 6.2. L2 Interface LFB 3524 The L2 Interface LFB models an L2 protocol termination. The L2 3525 Interface LFB performs two sets of functions: decapsulation and 3526 demultiplexing as needed on the receive side of an FE, and 3527 encapsulation and multiplexing as needed on the transmit side. 3528 Hence the LFB has two distinct sets of inputs and outputs tailored 3529 for these separate functions. The L2 Interface LFB is not modeled 3530 as two separate (receive/transmit) LFBs because there are shared 3531 attributes between the decapsulation and encapsulation functions. 3533 On the decapsulation input(s), the LFB accepts an L2 protocol 3534 specific frame, along with frame length and L2 interface metadata. 3535 The LFB decapsulates the L2 frame by removing any L2 3536 header/trailers (while simultaneously applying any checksum/CRC 3537 functions), determines the L2 or L3 protocol type of the next-layer 3538 packet (based on a PID or Ethertype within the L2 frame header), 3539 adjusts the frame length metadata, and uses the L2 interface 3540 metadata to select an L2 interface attribute. The L2 interface 3541 attribute supports a number of additional attributes, including: 3542 . L2 MTU 3543 . supported next-layer L2 or L3 protocols 3544 . L2-specific receive counters (byte, packet) 3545 . counting mode 3546 . L2 or L3 interface metadata for next-layer packet 3547 . LFB output port. 3548 The LFB may support multiple decapsulation output ports within two 3549 output groups; one for normal forwarding, and one for exception 3550 packets. The LFB emits the decapsulated packet along with the 3551 modified frame length metadata, an L2 or L3 protocol type metadata, 3552 and an L2 or L3 interface metadata. 3554 On the encapsulation input(s), the LFB accepts a packet along with 3555 frame length, protocol type, and L2 interface metadata. The L2 3556 interface metadata is used to select an L2 interface attribute 3557 which supports a number of additional attributes, including: 3558 . L2-specific transmit counters (byte, packet) 3559 . counting mode (may be taken from receive counters mode) 3560 . L2 or L3 interface metadata for next-layer frame (we assume 3561 that L2 3562 . protocols could be layered on top of an L3 protocol; e.g., 3563 L2TP or 3564 . PWE3), or port metadata. 3565 . LFB output port. 3566 The LFB encapsulates the packet using the appropriate L2 3567 header/trailer and protocol type information (calculating 3568 checksums/CRCs as necessary), and provides the frame to the next 3569 LFB along with incremented frame length metadata, updated protocol 3570 type metadata, and updated interface (or port) metadata, on a 3571 configurable LFB encapsulation output. 3573 As in the case of the Port LFB, technology specific variants of the 3574 L2 interface LFB will be sub-classes of the L2 Interface LFB. 3575 Example sub-classes include: 3576 . Ethernet/802.1Q 3577 . PPP 3578 . ATM AAL5. 3580 Each sub-class will likely support static and configurable 3581 attributes specific to the L2 technology; for example the 3582 Ethernet/802.1Q Interface LFB will support a per-interface MAC 3583 address attribute. Note that each technology specific sub-class 3584 may require additional metadata. For example, the Ethernet/802.1Q 3585 Interface LFB requires an outgoing MAC destination address to 3586 generate an outgoing Ethernet header. 3588 The L2 interface management function is separated into a distinct 3589 LFB from the Port LFB because L2 encapsulations can be nested 3590 within frames; e.g., PPP-over-Ethernet-over-ATM AAL5 (PPPoEoA). 3592 6.3. IP interface LFB 3594 The IP Interface LFB models a container for IP interface-specific 3595 attributes. These may include: 3596 . IP protocols supported (IPv4 and/or IPv6) 3597 . IP MTU 3598 . interface MIB counters 3599 . table metadata for associated forwarding tables (LPM, 3600 multicast) 3601 . table metadata for associated classification tables. 3602 The IP Interface LFB also performs basic protocol-specific packet 3603 heade validation functions (e.g., IP version, IPv4 header length, 3604 IPv4 header checksum, MTU, TTL=0, etc.). The IP Interface LFB 3605 class supports three different L3 protocols: IPv4, IPv6, and MPLS, 3606 although individual LFB instances might support a subset of these 3607 protocols, configurable on each interface attribute. 3609 As with the L2 Interface LFB, the IP Interface LFB supports two 3610 modes of operation: one needed on the receive side of an FE, and 3611 one on the transmit side, using separate sets of LFB inputs and 3612 outputs. In the first mode of operation (for FE receive 3613 processing), the IP Interface LFB accepts IP packets along with 3614 frame length, L3 protocol type, and interface metadata (possibly 3615 including additional metadata items such as L2-derived class 3616 metadata). The interface metadata is used to select an interface 3617 attribute, and the protocol type is checked against the protocols 3618 supported for this interface. Error checks are applied, including 3619 whether the particular protocol type is supported on this 3620 interface, and if no errors occur, the appropriate counters are 3621 incremented and the protocol type is used to select the outgoing 3622 LFB output from a set dedicated to the first mode of operation. The 3623 IP header protocol type/next header field may also be used to 3624 select an LFB output; for example, IPv4 packets with AH header may 3625 be directed to a particular next LFB, or IPv6 packets with Hop-by- 3626 Hop Options. If errors do occur, the appropriate error counters 3627 are incremented, and the error type is used to select a specific 3628 exception LFB output. 3630 In the second mode of operation (for FE transmit processing), the 3631 IP Interface LFB accepts an IP packet along with frame length, 3632 protocol type, and interface metadata. Again, the interface 3633 metadata is used to select an interface attribute. The interface 3634 attribute stores the outgoing L2 or IP interface (e.g., tunnel) 3635 interface metadata. The IP MTU of the outgoing interface is 3636 checked, along with the protocol type of the packet. If no errors 3637 occur, the appropriate counters are incremented, and the next level 3638 interface metadata may be used to select an IP Interface LFB output 3639 dedicated to the second mode of operation. Otherwise, the 3640 appropriate error counters are incremented, and the error type is 3641 used to select an exception output. 3643 Because the IP Interface LFB is the repository for the interface 3644 MIB counters, two special pairs of inputs are provided for packets 3645 which have been selected to be discarded further downstream (one 3646 each for the receive and transmit counters). Packets arriving on 3647 these LFB inputs must be accompanied by frame length and L3 3648 interface metadata. An exception output on the LFB should be 3649 connected to a dropper LFB. 3651 6.4. Classifier LFB 3653 The function of classification is to logically partition packets 3654 into one of N different classes, based on some sequence of one or 3655 more mathematical operations applied to the packet and its 3656 associated metadata. Various LFBs perform an intrinsic 3657 classification function. Where this function is a well-defined 3658 protocol operation, a separate LFB may be defined (e.g., IP 3659 Interface LFB, which performs header verification). 3661 Several common applications need to classify packets using a 3662 particular mathematical operation (e.g., longest prefix match (LPM) 3663 or ternary match) against a fixed set of fields in a packet's 3664 header plus metadata, or an easily recognized part of the packet 3665 payload. Two example applications are classification for 3666 Differentiated Services or for security processing. Typically the 3667 packet is evaluated against a potentially large set of rules 3668 (called "filters") which are processed in a particular order to 3669 ensure a deterministic result. This sort of classification 3670 functionalit is modeled by the Classifier LFB. 3672 The Classifier LFB accepts an input packet and metadata, and 3673 produces the unmodified packet along with a class metadata, which 3674 may be used to map the packet to a particular LFB output. 3676 The Classifier LFB supports multiple classifier attributes. Each 3677 classifier is parameterized by one or more filters. Classification 3678 is performed by selecting the classifier to use on a particular 3679 packet (e.g., by metadata lookup on a configurable metadata item), 3680 and by evaluating the selected contents of the accepted packet 3681 against that classifier's filters. A filter decides if the input 3682 packet satisfies particular criteria. According to [DiffServ], "a 3683 filter consists of a set of conditions on the component values of a 3684 packet's classification key (the header values, contents, and 3685 attributes relevant for classification)". 3687 Note that other LFBs may perform simple classification on the 3688 packet or its metadata. The purpose of the Classifier LFB is to 3689 model an LFB that "digests" large amounts of input data (packet, 3690 metadata), to produce a "summary" of the classification results, in 3691 the form of additional (or modified) metadata. Other LFBs can then 3692 use this summary information to quickly and simply perform trivial 3693 classification operations. 3695 The Classifier LFB can be sub-classed into several function- 3696 specific LFB classes which perform common classification functions. 3697 These may include: 3698 . Longest Prefix Match (LPM) 3699 . IP Multicast lookup (S,G) 3700 . Multifield Exact Match 3701 . Multifield Ternary Match. 3703 6.5. Next Hop LFB 3705 The Next Hop LFB is used to resolve next hop information following 3706 a forwarding lookup. Next Hop information normally includes the 3707 outgoing interface (or interfaces, in the case of multicast), as 3708 well as the outgoing IP address(es). This next hop information 3709 associated with a forwarding prefix or classification rule is often 3710 separated into a separate data structure in implementations to 3711 allow the two pieces of information to be decoupled, because there 3712 is frequently a fan-in relationship between forwarding prefix/rule 3713 entries and next hop information, and decoupling them can permit 3714 more efficient data structure management. 3716 The Next Hop LFB maintains next hop attributes organized into 3717 multiple next hop tables. The relevant table for a packet is 3718 selected based on next hop table metadata. A set of one or more 3719 next hop attributes is selected based on next hop index metadata. 3720 Each next hop attribute stores the following information: 3721 . a list of one or more outgoing interfaces 3722 . next hop IP addresses, or, an index to a table of this 3723 information 3724 . that is maintained at a downstream LFB 3725 . a list of outgoing MTUs 3726 . TTL decrement value 3728 The Next Hop LFB has two primary operations. The first is to map 3729 the incoming next hop table and next hop index metadata into a 3730 configurable next hop attribute. This mapping may be direct (one 3731 metadata pair to one next hop attribute). If the next hop index 3732 metadata selects a set of next hop attributes, final attribute 3733 resolution depends on a selection algorithm that uses some 3734 additional metadata, or an internal classification operation, to 3735 select among a set of possible next hop attributes. One example is 3736 weighted next hop selection, where individual packets are mapped to 3737 particular next hop attributes in the set according to weights and 3738 to some flow order-preserving function (e.g., such as an address 3739 pair hash). Another alternative is class-based next hop selection, 3740 based on some class metadata. 3742 The second operation is a derivative of the first. The next hop 3743 table and next hop index metadata are used to select a set of one 3744 or more next hop attributes. Then the outgoing interface values 3745 stored in those attributes are compared against the incoming 3746 interface metadata provided to the Next Hop LFB, to determine 3747 whether the incoming interface is in the set. This operation, in 3748 combination with a IP source address forwarding lookup (which 3749 provides the next hop table/index metadata), can be used to perform 3750 a reverse path forwarding (RPF) check. 3752 The Next Hop LFB has two inputs: one for normal next hop 3753 resolution, and one for the incoming interface metadata test (e.g., 3754 RPF). The LFB requires incoming interface, frame length, next hop 3755 table, and next hop index metadata. There are two normal output 3756 groups, one for the normal next hop resolution, and another for the 3757 RPF check. No additional metadata is produced for the latter, but 3758 for the former, the following metadata may be produced: 3759 . outgoing interface(s) 3760 . next hop IP address(es) 3761 . TTL decrement value (if TTL decrement is not performed by the 3762 Next Hop LFB) 3763 An alternative mode of operation produces index metadata instead of 3764 outgoing interface and next hop IP address metadata. This index 3765 metadata is used to access a cache of the outgoing interface and 3766 next hop IP address that may be stored on the egress FE (this 3767 permits more efficient communication across the Fi interface). 3768 This index metadata can also be used as input metadata to a MPLS 3769 Encapsulation LFB. 3771 The Next Hop LFB supports an exception output port group. 3772 Exception conditions include: 3773 . RPF test failed 3774 . No route to host 3775 . No route to network 3776 . Packet too big 3777 . TTL expired 3778 The mapping between exception conditions and exception outputs is 3779 configurable, and an exception code metadata is produced on these 3780 outputs. 3782 6.6. Rate Meter LFB 3784 The Rate Meter LFB is used to meter the packet flow through the LFB 3785 according to a rate- and time-dependent function. Packets are 3786 provided to the Rate Meter LFB along with packet length metadata 3787 (and optional color metadata) and are associated with a meter 3788 attribute either statically (based on LFB input) or via some other 3789 configurable metadata item. The metering algorithm of the 3790 associated meter attribute is applied to the packet, using the 3791 packet length and the current time as inputs, along with previous 3792 state maintained by the attribute. A color metadata is associated 3793 with the packet in accordance with the metering algorithm used. 3794 The color metadata is optionally emitted with the packet, or used 3795 to map the packet to a particular LFB output. Color-aware metering 3796 algorithms use color metadata if provided with the packet (e.g., by 3797 a Classifier LFB), or assume a default color value. 3799 The Rate Meter LFB supports a number of static attributes, 3800 including: 3801 . supported metering algorithms 3802 . maximum number of meter attributes. 3804 The Rate Meter LFB supports a number of configurable attributes, 3805 including: 3806 . number of LFB inputs 3807 . number of LFB outputs 3808 . mapping of LFB input to meter attribute (when mapped 3809 statically) 3810 . metadata item to select for mapping to meter attribute 3811 . mapping of metadata value to meter attribute 3812 . default meter attribute (when not mapped statically or via 3813 correct 3814 . metadata) 3815 . per-attribute metering algorithm 3816 . per-attribute metering paramters, including: 3817 . minimum rate 3818 . maximum rate 3819 . burst size 3820 . color metadata enable 3821 . mapping of packet color to LFB output. 3823 A Rate Meter LFB can be used to implement a policing function, by 3824 connecting a LFB output directly to a Dropper LFB, and mapping non- 3825 conforming (e.g., "red") traffic to that output. 3827 6.7. Redirector (de-MUX) LFB 3829 The Redirector LFB is used to select between alternative datapaths 3830 based on the value of some metadata item. The Redirector LFB 3831 accepts an input packet P, and uses associated metadata item M to 3832 demultiplex that packet onto one of N outputs; e.g., unicast 3833 forwarding, multicast, or broadcast. Configurable attributes 3834 include: 3835 . number of LFB output ports (N) 3836 . metadata item to demultiplex on (M) 3837 . mapping of metadata value to output port 3838 . default output port (for un-matched input metadata values). 3840 Note that other LFBs may include demultiplexing functionality 3841 (i.e., if they have multiple outputs in an output group). The 3842 Redirector LFB is especially useful for demultiplexing based on 3843 metadata items that are not generated or modified by an immediate 3844 upstream LFB. 3846 6.8. Packet Header Rewriter LFB 3848 The Packet Header Rewriter LFB is used to re-write fields in a 3849 packet's header. Function-specific sub-classes of the Packet 3850 Header Rewriter LFB may be specified as sub-classes of the Modifier 3851 LFB. These may include: 3852 . IPv4 TTL/IPv6 Hop Count 3853 . IPv4 header checksum 3854 . DSCP 3855 . IPv4 NAT 3857 The precise means by which the packet header rewriting functions 3858 will be specified is TBD. 3860 6.9. Counter LFB 3862 The Counter LFB is used to maintain packet and/or byte statistics 3863 on the packet flow through the LFB. Packets are provided to the 3864 Counter LFB on an LFB input along with packet length metadata and 3865 are associated with a count attribute either statically (based on 3866 the LFB input) or via some other configurable metadata item. The 3867 Counter LFB modifies neither the packet nor any associated 3868 metadata. 3870 The Counter LFB supports a number of static attributes, including: 3871 . supported counting modes (e.g., byte, packet, both) 3872 . supported logging modes (e.g., last recorded packet time) 3873 . maximum number of count attributes 3875 The Counter LFB supports a number of configurable attributes, 3876 including: 3877 . number of LFB inputs 3878 . mapping of LFB input to count attribute (when mapped 3879 statically) 3880 . metadata item to select for mapping to count attribute 3881 . mapping of metadata value to count attribute 3882 . default count attribute (when not mapped statically or via 3883 correct 3884 . metadata) 3885 . counting mode per-attribute 3886 . logging mode per-attribute. 3888 The Counter LFB does not perform any time-dependent counting. The 3889 time at which a count is made may, however, be logged as part of 3890 the count attribute. 3892 Other LFBs may maintain internal statistics (e.g., interface LFBs). 3893 The Counter LFB is especially useful for maintain counts associated 3894 with QoS policy. 3896 6.10. Dropper LFB 3898 A Dropper LFB has one input, and no outputs. It discards all 3899 packets that it accepts without any modification or examination of 3900 those packets. 3902 The purpose of a Dropper LFB is to allow the description of "sinks" 3903 within the model, where those sinks do not result in the packet 3904 being sent into any object external to the model. 3906 The Dropper LFB has no configurable attributes. 3908 6.11. IPv4 Fragmenter LFB 3910 The IPv4 Fragmenter LFB fragments IPv4 packets according to the MTU 3911 of the outgoing interface. The IPv4 Fragmenter LFB accepts packets 3912 with frame length and MTU metadata, and produces a sequence of one 3913 or more valid IPv4 packets properly fragmented, each along with 3914 corrected frame length metadata. 3916 The source of the outgoing interface MTU is TBD. The IPv4 3917 fragmentation function is not incorporated into the IP Interface 3918 LFB because forwarding implementations may include additional 3919 forwarding functions between fragmentation and final output 3920 interface processing. 3922 6.12. L2 Address Resolution LFB 3924 The L2 Address Resolution LFB is used to map an next hop IP address 3925 into an L2 address. The LFB accepts packets with output L2 3926 interface and next hop IP address metadata, and produces the packet 3927 along with the correct L2 destination address. The L2 Address 3928 Resolution LFB maintains multiple address resolution table 3929 attributes accessed by the output L2 interface metadata. Each 3930 table attribute maintains a set of configurable L2 address 3931 attributes, accessed by the next hop IP address. 3933 The L2 Address Resolution LFB has a normal output group which 3934 produces the L2 destination address metadata, as well as an 3935 exception output. This exception output can be used to divert the 3936 packet to another LFB (e.g., an ARP/ND Protocol LFB, or a Port LFB 3937 used to reach the CE) for address resolution. 3939 6.13. Queue LFB 3941 The Queue LFB is used to represent queueing points in the packet 3942 datapath. It is always used in combination with one or more 3943 Scheduler LFBs. The Queue LFB manages one or more FIFO packet 3944 queues as configurable attributes. The Queue LFB provides one or 3945 more LFB inputs, and packets are mapped from LFB inputs to queues, 3946 either statically, or via queue metadata. Each queue attribute is 3947 mapped one-to-one with a scheduling input on a downstream Scheduler 3948 LFB. The Queue LFB provides one or more LFB outputs, along with 3949 optional scheduling input metadata. 3951 Additional per-queue configurable attributes include the following: 3953 . maximum depth discard behavior (tail drop/head drop/Active 3954 Queue Management (AQM)) 3955 . AQM parameters (specific to the AQM algorithm; e.g., RED) 3956 . Explicit Congestion Notification (ECN) enable. 3958 Packets are provided to the Queue LFB along with a packet length 3959 metadata and an optional queue metadata. Because the Queue LFB can 3960 model sophisticated AQM mechanisms such as per-color marking 3961 thresholds (e.g., Weighted RED), packets may also be accompanied 3962 with color metadata. 3964 If ECN is enabled on a queue serving IP packets, then the IP packet 3965 header is modified if congestion is marked. A protocol type 3966 metadata must accompany the packet to indicate the packet protocol 3967 (e.g., IPv4, IPv6, Ethernet), so that the implementation can 3968 determine the location of the ECN bits in the header [RFC3168]. In 3969 the case of IPv4, if congestion is signaled, the header checksum 3970 must be modified. The Queue LFB supports a capability to indicate 3971 whether it corrects the IPv4 header checksum after marking 3972 congestion experienced. Support for the checksum fixup is not 3973 mandatory since the checksum may be recalculated in another LFB 3974 further downstream. 3976 6.14. Scheduler LFB 3978 The Scheduler LFB is used to perform packet scheduling at queueing 3979 points in the packet datapath, and hence is always used in 3980 combination with one or more upstream Queue or Scheduler LFBs. The 3981 Scheduler LFB supports one or more logical scheduling inputs. A 3982 scheduling input can be mapped one-to-one to a Scheduler LFB input, 3983 or the scheduling input can be selected via metadata (and both 3984 mechanisms may be used in combination). 3986 The Scheduler LFB multiplexes its scheduling inputs onto a single 3987 LFB output, based on its scheduling algorithm along with the per- 3988 input scheduling configuration. The packet is not modified during 3989 the scheduling process. 3991 Packets are provided to the Scheduler LFB along with a packet 3992 length metadata and an optional scheduling input metadata. 3994 Configurable attributes include: 3995 . number of logical scheduler inputs 3996 . number of LFB inputs 3997 . mapping of LFB input to scheduler input 3998 . scheduling algorithm 3999 . per-input scheduling parameters, including: 4001 . priority 4002 . minimum service rate 4003 . maximum service rate 4004 . burst duration (at maximum service rate). 4006 Hierarchical scheduling configurations can be created by cascading 4007 two or more Scheduler LFBs. 4009 6.15. MPLS ILM/Decapsulation LFB 4011 The MPLS Incoming Label Map (ILM)/Decapsulation LFB accepts MPLS- 4012 encapsulated packets, examines (and possibly removes) the top-most 4013 label, and emits the packet on one output within an output group, 4014 along with configurable index and class metadata. The configurable 4015 metadata can be used as input for an IP Interface LFB, a Next Hop 4016 LFB, or the same (or another) MPLS ILM/Decapsulation LFB. This 4017 allows the FE to terminate, forward, or "pop and lookup" on the 4018 value of the top-most label. The LFB maintains a set of ILM table 4019 attributes indexed by incoming IP interface metadata. Each ILM 4020 table entry is an attribute specifying whether to remove the label, 4021 and which output port to emit the packet on. An exception output 4022 is provided for packets with expired TTL. 4024 6.16. MPLS Encapsulation LFB 4026 The MPLS Encapsulation LFB accepts IP or MPLS-encapsulated packets 4027 and appends an MPLS label stack, which is selected by output 4028 interface and configurable index metadata. The TTL of the accepted 4029 packet is copied from the outermost header into the labels in the 4030 label stack, and the S bit is set on the bottom label if the 4031 accepted packet is IP. The MPLS EXP bits are copied (or mapped) 4032 according to per-stack attributes. 4034 The MPLS Encapsulation LFB maintains multiple stack table 4035 attributes indexed by output interface metadata. Entry attributes 4036 within a table are indexed by configurable index metadata. Each 4037 entry attribute maintains a label stack, along with a configurable 4038 attribute for EXP bit handling, and possibly class and/or queue 4039 metadata to emit with the packet. 4041 MPLS ILM/decapsulation and encapsulation functions are modeled in 4042 separate LFBs because some implementations split these operations 4043 across FEs. 4045 6.17. Tunnel Encapsulation/Decapsulation LFB 4046 The Tunnel Encapsulation/Decapsulation LFB models tunnel header 4047 encapsulation and decapsulation/demultiplexing. The LFB maintains 4048 separate encapsulation and decapsulation input and output groups. 4049 The encapsulation input group accepts packets with tunnel metadata, 4050 appends a tunnel header that is stored in a configurable attribute 4051 indexed by the tunnel metadata, and emits the packet on an 4052 encapsulation output. The decapsulation input group accepts 4053 packets encapsulated with a tunnel header along with tunnel 4054 metadata, removes the tunnel header (performing any tunnel- 4055 protocol-specific classification) according to attributes 4056 configured on a per-tunnel basis and accessed via the tunnel 4057 metadata, and emits the packet along with configurable metadata. 4058 For example, the configurable metadata that is output may be used 4059 as input interface metadata by a downstream IP or L2 Interface LFB. 4060 A decapsulation exception output is available and is used in the 4061 event that decapsulation fails. 4063 The Tunnel Encapsulation/Decapsulation LFB may be sub-classed into 4064 tunnel-protocol-specific LFBs, including: 4065 . IP-IP 4066 . GRE 4067 . L2TP 4068 . Generic IPv6 Tunnels 4070 6.18. Replicator LFB 4072 The Replicator LFB is used to replicate accepted packets and emit 4073 them on one or more outputs in an output group. Packets are 4074 accepted along with replicator index metadata. The LFB maintains 4075 an attribute table indexed by this metadata. Each table entry 4076 attribute specifies the number of times the packet must be 4077 replicated, the outputs (within the output group) that each 4078 replicated packet should be emitted on, and configurable metadata 4079 to be associated with each replicated packet. 4081 The Replicator LFB can be used for multicast replication, or for 4082 transparent packet interception. 4084 7. Satisfying the Requirements on FE Model 4086 This section describes how the proposed FE model meets the 4087 requirements outlined in Section 5 of RFC 3654 [1]. The 4088 requirements can be separated into general requirements (Sections 4089 5, 5.1 - 5.4) and the specification of the minimal set of logical 4090 functions that the FE model must support (Section 5.5). 4092 The general requirement on the FE model is that it be able to 4093 express the logical packet processing capability of the FE, 4094 through both a capability and a state model. In addition, the FE 4095 model is expected to allow flexible implementations and be 4096 extensible to allow defining new logical functions. 4098 A major component of the proposed FE model is the Logical Function 4099 Block (LFB) model. Each distinct logical function in an FE is 4100 modeled as an LFB. Operational parameters of the LFB that must be 4101 visible to the CE are conceptualized as LFB attributes. These 4102 attributes support flexible implementations by allowing an FE to 4103 specify supported optional features and to indicate which 4104 attributes are configurable by the CE for an LFB class (e.g., 4105 express the capability of the FE). Configurable attributes also 4106 provide the CE some flexibility in specifying the behavior of a 4107 LFB. When multiple LFBs belonging to the same LFB class are 4108 instantiated on an FE, each of those LFBs could be configured with 4109 different attribute settings. By querying the settings of the 4110 attributes for an instantiated LFB, one can determine the state of 4111 that LFB. 4113 Instantiated LFBs are interconnected in a directed graph that 4114 describes the ordering of the functions within an FE. This 4115 directed graph is described by the topology model. The combination 4116 of the attributes of the instantiated LFBs and the topology 4117 describe the packet processing functions available on the FE 4118 (current state). 4120 Another key component of the FE model is the FE attributes. The FE 4121 attributes are used mainly to describe the capabilities of the FE, 4122 but they also convey information about the FE state. 4124 The FE model also includes a definition of the minimal set of LFBs 4125 that is required by Section 5.5 of [1]. The sections that follow 4126 provide more detail on the specifics of each of those LFBs. 4128 7.1. Port Functions 4130 The FE model can be used to define a Port LFB class and its 4131 technology-specific subclasses (see Section 6.1) to map the 4132 physical port of the device to the LFB model with both static and 4133 configurable attributes. The static attributes model the type of 4134 port, link speed etc. The configurable attributes model the 4135 addressing, administrative status etc. 4137 7.2. Forwarding Functions 4138 Because forwarding function is one of the most common and important 4139 functions in the forwarding plane, it requires special attention in 4140 modeling to allow design flexibility, implementation efficiency, 4141 modeling accuracy and configuration simplicity. Toward that end, 4142 it is recommended that the core forwarding function being modeled 4143 by the combination of two LFBs -- Longest Prefix Match (LPM) 4144 classifier LFB (see Section 6.4) and Next Hop LFB (see Section 4145 6.5). Special header writer LFB (see Section 6.8) is also needed 4146 to take care of TTL decrement and checksum etc. 4148 7.3. QoS Functions 4150 The LFB class library already includes descriptions of the Meter 4151 (Section 6.6.), Queue (Section 6.13), Scheduler (Section 6.14), 4152 Counter (Section 6.9) and Dropper (Section 6.10) LFBs to support 4153 the QoS functions in the forwarding path. FE model can also be 4154 used to define other useful QoS functions as needed. These LFBs 4155 allow the CE to manipulate the attributes to model IntServ or 4156 DiffServ functions. 4158 7.4. Generic Filtering Functions 4160 Various combinations of Classifier (Section 6.4), Redirector 4161 (Section 6.7), Meter (Section 6.6.) and Dropper (Section 6.10) LFBs 4162 can model a complex set of filtering functions. 4164 7.5. Vendor Specific Functions 4166 New LFB classes can be defined according to the LFB model as 4167 described in Section 4 to support vendor specific functions. A new 4168 LFB class can also be derived from an existing LFB class through 4169 inheritance. 4171 7.6.High-Touch Functions 4173 High-touch functions are those that take action on the contents or 4174 headers of a packet based on content other than what is found in 4175 the IP header. Examples of such functions include NAT, ALG, 4176 firewall, tunneling and L7 content recognition. It is not 4177 practical to include all possible high touch functions in the 4178 initial LFB library in Section 6 due to the number and complexity. 4179 However, the flexibility of the LFB model and the power of 4180 interconnection in LFB topology should make it possible to model 4181 any high-touch functions. 4183 7.7. Security Functions 4184 Security functions are not included in the initial LFB class 4185 library. However, the FE model is flexible and powerful enough to 4186 model the types of encryption and/or decryption functions that an 4187 FE supports and the associated attributes for such functions. 4189 The IP Security Policy (IPSP) Working Group in the IETF has started 4190 work in defining the IPSec Policy Information Base [8]. We should 4191 try to reuse the work as much as we can. 4193 7.8. Off-loaded Functions 4195 In addition to the packet processing functions that are typical to 4196 find on the FEs, some logical functions may also be executed 4197 asynchronously by some FEs, according to a certain finite-state 4198 machine, triggered not only by packet events, but by timer events 4199 as well. Examples of such functions include finite-state machine 4200 execution required by TCP termination or OSPF Hello processing off- 4201 loaded from the CE. By defining LFBs for such functions, the FE 4202 model is capable of expressing these asynchronous functions, so 4203 that the CE may take advantage of such off-loaded functions on the 4204 FEs. 4206 7.9. IPFLOW/PSAMP Functions 4208 [9] defines architecture for IP traffic flow monitoring, measuring 4209 and exporting. The LFB model supports statistics collection on the 4210 LFB by including statistical attributes (Section 4.7.4) in the LFB 4211 class definitions; in addition, special statistics collection LFBs 4212 such as meter LFB (Section 7.2.2) and counter LFB (Section 7.2.1) 4213 can also be used to support accounting functions in the FE. 4215 [10] describes a framework to define a standard set of capabilities 4216 for network elements to sample subsets of packets by statistical 4217 and other methods. Time event generation, filter LFB, and 4218 counter/meter LFB are the elements needed to support packet 4219 filtering and sampling functions -- these elements can all be 4220 supported in the FE model. 4222 8. Using the FE model in the ForCES Protocol 4224 The actual model of the forwarding plane in a given NE is something 4225 the CE must learn and control by communicating with the FEs (or by 4226 other means). Most of this communication will happen in the post- 4227 association phase using the ForCES protocol. The following types of 4228 information must be exchanged between CEs and FEs via the ForCES 4229 protocol: 4230 1) FE topology query; 4231 2) FE capability declaration; 4232 3) LFB topology (per FE) and configuration capabilities query; 4233 4) LFB capability declaration; 4234 5) State query of LFB attributes; 4235 6) Manipulation of LFB attributes; 4236 7) LFB topology reconfiguration. 4238 Items 1) through 5) are query exchanges, where the main flow of 4239 information is from the FEs to the CEs. Items 1) through 4) are 4240 typically queried by the CE(s) in the beginning of the post- 4241 association (PA) phase, though they may be repeatedly queried at 4242 any time in the PA phase. Item 5) (state query) will be used at the 4243 beginning of the PA phase, and often frequently during the PA phase 4244 (especially for the query of statistical counters). 4246 Items 6) and 7) are "command" types of exchanges, where the main 4247 flow of information is from the CEs to the FEs. Messages in Item 6) 4248 (the LFB re-configuration commands) are expected to be used 4249 frequently. Item 7) (LFB topology re-configuration) is needed only 4250 if dynamic LFB topologies are supported by the FEs and it is 4251 expected to be used infrequently. 4253 Among the seven types of payload information the ForCES protocol 4254 carries between CEs and FEs, the FE model covers all of them except 4255 item 1), which concerns the inter-FE topology. The FE model 4256 focuses on the LFB and LFB topology within a single FE. Since the 4257 information related to item 1) requires global knowledge about all 4258 of the FEs and their inter-connection with each other, this 4259 exchange is part of the ForCES base protocol instead of the FE 4260 model. 4262 The relationship between the FE model and the seven post- 4263 association messages are visualized in Figure 9: 4265 +--------+ 4266 ..........-->| CE | 4267 /----\ . +--------+ 4268 \____/ FE Model . ^ | 4269 | |................ (1),2 | | 6, 7 4270 | | (off-line) . 3, 4, 5 | | 4271 \____/ . | v 4272 . +--------+ 4273 e.g. RFCs ..........-->| FE | 4274 +--------+ 4276 Figure 9. Relationship between the FE model and the ForCES protocol 4277 messages, where (1) is part of the ForCES base protocol, and the 4278 rest are defined by the FE model. 4280 The actual encoding of these messages is defined by the ForCES 4281 protocol and beyond the scope of the FE model. Their discussion is 4282 nevertheless important here for the following reasons: 4283 . These PA model components have considerable impact on the FE 4284 model. For example, some of the above information can be 4285 represented as attributes of the LFBs, in which case such 4286 attributes must be defined in the LFB classes. 4287 . The understanding of the type of information that must be 4288 exchanged between the FEs and CEs can help to select the 4289 appropriate protocol format and the actual encoding method (such as 4290 XML, TLVs). 4291 . Understanding the frequency of these types of messages should 4292 influence the selection of the protocol format (efficiency 4293 considerations). 4295 An important part of the FE model is the port the FE uses for its 4296 message exchanges to and from the CE. In the case that a dedicated 4297 port is used for CE-FE communication, we propose to use a special 4298 port LFB, called the CE-FE Port LFB (a subclass of the general Port 4299 LFB in Section 6.1), to model this dedicated CE-FE port. The CE-FE 4300 Port LFB acts as both a source and sink for the traffic from and to 4301 the CE. Sometimes the CE-FE traffic does not have its own 4302 dedicated port, instead the data fabric is shared for the data 4303 plane traffic and the CE-FE traffic. A special processing LFB can 4304 be used to model the ForCES packet encapsulation and decapsulation 4305 in such cases. 4307 The remaining sub-sections of this section address each of the 4308 seven message types. 4310 8.1. FE Topology Query 4311 An FE may contain zero, one or more external ingress ports. 4312 Similarly, an FE may contain zero, one or more external egress 4313 ports. In other words, not every FE has to contain any external 4314 ingress or egress interfaces. For example, Figure 10 shows two 4315 cascading FEs. FE #1 contains one external ingress interface but 4316 no external egress interface, while FE #2 contains one external 4317 egress interface but no ingress interface. It is possible to 4318 connect these two FEs together via their internal interfaces to 4319 achieve the complete ingress-to-egress packet processing function. 4320 This provides the flexibility to spread the functions across 4321 multiple FEs and interconnect them together later for certain 4322 applications. 4324 While the inter-FE communication protocol is out of scope for 4325 ForCES, it is up to the CE to query and understand how multiple FEs 4326 are inter-connected to perform a complete ingress-egress packet 4327 processing function, such as the one described in Figure 10. The 4328 inter-FE topology information may be provided by FEs, may be hard- 4329 coded into CE, or may be provided by some other entity (e.g., a bus 4330 manager) independent of the FEs. So while the ForCES protocol 4331 supports FE topology query from FEs, it is optional for the CE to 4332 use it, assuming the CE has other means to gather such topology 4333 information. 4335 +-----------------------------------------------------+ 4336 | +---------+ +------------+ +---------+ | 4337 input| | | | | | output | 4338 ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ 4339 | | port | |Decompressor| |Forwarder| FE | | 4340 | +---------+ +------------+ +---------+ #1 | | 4341 +-----------------------------------------------------+ V 4342 | 4343 +-----------------------<-----------------------------+ 4344 | 4345 | +----------------------------------------+ 4346 V | +------------+ +----------+ | 4347 | input | | | | output | 4348 +->--+->|Header |-->| Egress |---------+--> 4349 | |Compressor | | port | FE | 4350 | +------------+ +----------+ #2 | 4351 +----------------------------------------+ 4353 Figure 10. An example of two FEs connected together. 4355 Once the inter-FE topology is discovered by the CE after this 4356 query, it is assumed that the inter-FE topology remains static. 4357 However, it is possible that an FE may go down during the NE 4358 operation, or a board may be inserted and a new FE activated, so 4359 the inter-FE topology will be affected. It is up to the ForCES 4360 protocol to provide a mechanism for the CE to detect such events 4361 and deal with the change in FE topology. FE topology is outside 4362 the scope of the FE model. 4364 8.2. FE Capability Declarations 4366 FEs will have many types of limitations. Some of the limitations 4367 must be expressed to the CEs as part of the capability model. The 4368 CEs must be able to query these capabilities on a per-FE basis. 4369 Examples: 4370 . Metadata passing capabilities of the FE. Understanding these 4371 capabilities will help the CE to evaluate the feasibility of 4372 LFB topologies, and hence to determine the availability of 4373 certain services. 4374 . Global resource query limitations (applicable to all LFBs of 4375 the FE). 4376 . LFB supported by the FE. 4377 . LFB class instantiation limit. 4378 . LFB topological limitations (linkage constraint, ordering 4379 etc.) 4381 8.3. LFB Topology and Topology Configurability Query 4383 The ForCES protocol must provide the means for the CEs to discover 4384 the current set of LFB instances in an FE and the interconnections 4385 between the LFBs within the FE. In addition, sufficient 4386 information should be available to determine whether the FE 4387 supports any CE-initiated (dynamic) changes to the LFB topology, 4388 and if so, determine the allowed topologies. Topology 4389 configurability can also be considered as part of the FE capability 4390 query as described in Section 9.3. 4392 8.4. LFB Capability Declarations 4394 LFB class specifications define a generic set of capabilities. 4395 When an LFB instance is implemented (instantiated) on a vendor's 4396 FE, some additional limitations may be introduced. Note that we 4397 discuss only those limitations that are within the flexibility of 4398 the LFB class specification. That is, the LFB instance will remain 4399 compliant with the LFB class specification despite these 4400 limitations. For example, certain features of an LFB class may be 4401 optional, in which case it must be possible for the CE to determine 4402 if an optional feature is supported by a given LFB instance or not. 4403 Also, the LFB class definitions will probably contain very few 4404 quantitative limits (e.g., size of tables), since these limits are 4405 typically imposed by the implementation. Therefore, quantitative 4406 limitations should always be expressed by capability arguments. 4408 LFB instances in the model of a particular FE implementation will 4409 possess limitations on the capabilities defined in the 4410 corresponding LFB class. The LFB class specifications must define 4411 a set of capability arguments, and the CE must be able to query the 4412 actual capabilities of the LFB instance via querying the value of 4413 such arguments. The capability query will typically happen when 4414 the LFB is first detected by the CE. Capabilities need not be re- 4415 queried in case of static limitations. In some cases, however, some 4416 capabilities may change in time (e.g., as a result of 4417 adding/removing other LFBs, or configuring certain attributes of 4418 some other LFB when the LFBs share physical resources), in which 4419 case additional mechanisms must be implemented to inform the CE 4420 about the changes. 4422 The following two broad types of limitations will exist: 4423 . Qualitative restrictions. For example, a standardized multi- 4424 field classifier LFB class may define a large number of 4425 classification fields, but a given FE may support only a 4426 subset of those fields. 4427 . Quantitative restrictions, such as the maximum size of tables, 4428 etc. 4430 The capability parameters that can be queried on a given LFB class 4431 will be part of the LFB class specification. The capability 4432 parameters should be regarded as special attributes of the LFB. The 4433 actual values of these arguments may be, therefore, obtained using 4434 the same attribute query mechanisms as used for other LFB 4435 attributes. 4437 Capability attributes will typically be read-only arguments, but in 4438 certain cases they may be configurable. For example, the size of a 4439 lookup table may be limited by the hardware (read-only), in other 4440 cases it may be configurable (read-write, within some hard limits). 4442 Assuming that capabilities will not change frequently, the 4443 efficiency of the protocol/schema/encoding is of secondary concern. 4445 8.5. State Query of LFB Attributes 4447 This feature must be provided by all FEs. The ForCES protocol and 4448 the data schema/encoding conveyed by the protocol must together 4449 satisfy the following requirements to facilitate state query of the 4450 LFB attributes: 4451 . Must permit FE selection. This is primarily to refer to a 4452 single FE, but referring to a group of (or all) FEs may 4453 optional be supported. 4454 . Must permit LFB instance selection. This is primarily to refer 4455 to a single LFB instance of an FE, but optionally addressing 4456 of a group of LFBs (or all) may be supported. 4457 . Must support addressing of individual attribute of an LFB. 4458 . Must provide efficient encoding and decoding of the addressing 4459 info and the configured data. 4460 . Must provide efficient data transmission of the attribute 4461 state over the wire (to minimize communication load on the CE- 4462 FE link). 4464 8.6. LFB Attribute Manipulation 4466 This is a place-holder for all operations that the CE will use to 4467 populate, manipulate, and delete attributes of the LFB instances on 4468 the FEs. This is how the CE configures an individual LFB instance. 4470 The same set of requirements as described in Section 9.5 for 4471 attribute query applies here for attribute manipulation as well. 4473 Support for various levels of feedback from the FE to the CE (e.g., 4474 request received, configuration completed), as well as multi- 4475 attribute configuration transactions with atomic commit and 4476 rollback, may be necessary in some circumstances. 4478 (Editor's note: It remains an open issue as to whether or not other 4479 methods are needed in addition to "get attribute" and "set 4480 attribute" (such as multi-attribute transactions). If the answer 4481 to that question is yes, it is not clear whether such methods 4482 should be supported by the FE model itself or the ForCES protocol.) 4484 8.7. LFB Topology Re-configuration 4486 Operations that will be needed to reconfigure LFB topology: 4487 . Create a new instance of a given LFB class on a given FE. 4488 . Connect a given output of LFB x to the given input of LFB y. 4489 . Disconnect: remove a link between a given output of an LFB and 4490 a given input of another LFB. 4491 . Delete a given LFB (automatically removing all interconnects 4492 to/from the LFB). 4494 9. Acknowledgments 4495 Many of the colleagues in our companies and participants in the 4496 ForCES mailing list have provided invaluable input into this work. 4498 10. Security Considerations 4500 The FE model describes the representation and organization of data 4501 sets and attributes in the FEs. ForCES framework document [2] 4502 provides a comprehensive security analysis for the overall ForCES 4503 architecture. For example, the ForCES protocol entities must be 4504 authenticated per the ForCES requirements before they can access 4505 the information elements described in this document via ForCES. 4506 The access to the information contained in the FE model is 4507 accomplished via the ForCES protocol which will be defined in 4508 separate documents and so the security issues will be addressed 4509 there. 4511 11. Normative References 4513 [1] Khosravi, H. et al., "Requirements for Separation of IP Control 4514 and Forwarding", RFC 3654, November 2003. 4516 [2] Yang, L. et al., "Forwarding and Control Element Separation 4517 (ForCES) Framework", work in progress, November 2003, . 4520 12. Informative References 4522 [3] Bernet, Y. et al., "An Informal Management Model for Diffserv 4523 Routers", RFC 3290, May 2002. 4525 [4] Chan, K. et al., "Differentiated Services Quality of Service 4526 Policy Information Base", RFC 3317, March 2003. 4528 [5] Sahita, R. et al., "Framework Policy Information Base", RFC 4529 3318, March 2003. 4531 [6] Moore, B. et al., "Information Model for Describing Network 4532 Device QoS Datapath Mechanisms", RFC 3670, January 2004. 4534 [7] Snir, Y. et al., "Policy Framework QoS Information Model", RFC 4535 3644, Nov 2003. 4537 [8] Li, M. et al., "IPsec Policy Information Base", work in 4538 progress, January 2003, . 4540 [9] Quittek, J. et Al., "Requirements for IP Flow Information 4541 Export", work in progress, January 2004, . 4544 [10] Duffield, N., "A Framework for Passive Packet Measurement ", 4545 work in progress, December 2003, . 4548 [11] Pras, A. and Schoenwaelder, J., FRC 3444 "On the Difference 4549 between Information Models and Data Models", January 2003. 4551 13. Authors' Addresses 4553 L. Lily Yang 4554 Intel Corp. 4555 Mail Stop: JF3-206 4556 2111 NE 25th Avenue 4557 Hillsboro, OR 97124, USA 4558 Phone: +1 503 264 8813 4559 Email: lily.l.yang@intel.com 4561 Joel M. Halpern 4562 Megisto Systems, Inc. 4563 20251 Century Blvd. 4564 Germantown, MD 20874-1162, USA 4565 Phone: +1 301 444-1783 4566 Email: jhalpern@megisto.com 4568 Ram Gopal 4569 Nokia Research Center 4570 5, Wayside Road, 4571 Burlington, MA 01803, USA 4572 Phone: +1 781 993 3685 4573 Email: ram.gopal@nokia.com 4575 Alan DeKok 4576 IDT Inc. 4577 1575 Carling Ave. 4578 Ottawa, ON K1G 0T3, Canada 4579 Phone: +1 613 724 6004 ext. 231 4580 Email: alan.dekok@idt.com 4582 Zsolt Haraszti 4583 Ericsson 4584 920 Main Campus Dr, St. 500 4585 Raleigh, NC 27606, USA 4586 Phone: +1 919 472 9949 4587 Email: zsolt.haraszti@ericsson.com 4589 Steven Blake 4590 Ericsson 4591 920 Main Campus Dr, St. 500 4592 Raleigh, NC 27606, USA 4593 Phone: +1 919 472 9913 4594 Email: steven.blake@ericsson.com 4596 Ellen Deleganes 4597 Intel Corp. 4598 Mail Stop: JF3-206 4599 2111 NE 25th Avenue 4600 Hillsboro, OR 97124, USA 4601 Phone: +1 503 712 4173 4602 Email: ellen.m.deleganes@intel.com 4604 14. Intellectual Property Right 4606 The authors are not aware of any intellectual property right issues 4607 pertaining to this document. 4609 15. IANA consideration 4611 A namespace is needed to uniquely identify the LFB type in the LFB 4612 class library. 4614 Frame type supported on input and output of LFB must also be 4615 uniquely identified. 4617 A set of metadata supported by the LFB model must also be uniquely 4618 identified with names or IDs.