RFC 5812
Forwarding and Control Element Separation (ForCES) Forwarding Element Model
Internet Engineering Task Force (IETF) J. Halpern Request for Comments: 5812 Self Category: Standards Track J. Hadi Salim ISSN: 2070-1721 Znyx Networks March 2010 Forwarding and Control Element Separation (ForCES) Forwarding Element ModelAbstract
This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5812.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................5 1.1. Requirements on the FE Model ...............................5 1.2. The FE Model in Relation to FE Implementations .............6 1.3. The FE Model in Relation to the ForCES Protocol ............6 1.4. Modeling Language for the FE Model .........................7 1.5. Document Structure .........................................8 2. Definitions .....................................................8 3. ForCES Model Concepts ..........................................10 3.1. ForCES Capability Model and State Model ...................12 3.1.1. FE Capability Model and State Model ................12 3.1.2. Relating LFB and FE Capability and State Model .....14 3.2. Logical Functional Block (LFB) Modeling ...................14 3.2.1. LFB Outputs ........................................18 3.2.2. LFB Inputs .........................................21 3.2.3. Packet Type ........................................24 3.2.4. Metadata ...........................................24 3.2.5. LFB Events .........................................27 3.2.6. Component Properties ...............................28 3.2.7. LFB Versioning .....................................29 3.2.8. LFB Inheritance ....................................29 3.3. ForCES Model Addressing ...................................30 3.3.1. Addressing LFB Components: Paths and Keys ..........32 3.4. FE Data Path Modeling .....................................32 3.4.1. Alternative Approaches for Modeling FE Data Paths ..33 3.4.2. Configuring the LFB Topology .......................37 4. Model and Schema for LFB Classes ...............................41 4.1. Namespace .................................................42 4.2. <LFBLibrary> Element ......................................42 4.3. <load> Element ............................................44 4.4. <frameDefs> Element for Frame Type Declarations ...........45 4.5. <dataTypeDefs> Element for Data Type Definitions ..........45 4.5.1. <typeRef> Element for Renaming Existing Data Types .........................................49 4.5.2. <atomic> Element for Deriving New Atomic Types .....49 4.5.3. <array> Element to Define Arrays ...................50 4.5.4. <struct> Element to Define Structures ..............54 4.5.5. <union> Element to Define Union Types ..............56 4.5.6. <alias> Element ....................................56 4.5.7. Augmentations ......................................57 4.6. <metadataDefs> Element for Metadata Definitions ...........58 4.7. <LFBClassDefs> Element for LFB Class Definitions ..........59 4.7.1. <derivedFrom> Element to Express LFB Inheritance ...62 4.7.2. <inputPorts> Element to Define LFB Inputs ..........62 4.7.3. <outputPorts> Element to Define LFB Outputs ........65 4.7.4. <components> Element to Define LFB Operational Components .............................67
4.7.5. <capabilities> Element to Define LFB
Capability Components ..............................70
4.7.6. <events> Element for LFB Notification Generation ...71
4.7.7. <description> Element for LFB Operational
Specification ......................................79
4.8. Properties ................................................79
4.8.1. Basic Properties ...................................79
4.8.2. Array Properties ...................................81
4.8.3. String Properties ..................................81
4.8.4. Octetstring Properties .............................82
4.8.5. Event Properties ...................................83
4.8.6. Alias Properties ...................................87
4.9. XML Schema for LFB Class Library Documents ................88
5. FE Components and Capabilities .................................99
5.1. XML for FEObject Class Definition .........................99
5.2. FE Capabilities ..........................................106
5.2.1. ModifiableLFBTopology .............................106
5.2.2. SupportedLFBs and SupportedLFBType ................106
5.3. FE Components ............................................110
5.3.1. FEState ...........................................110
5.3.2. LFBSelectors and LFBSelectorType ..................110
5.3.3. LFBTopology and LFBLinkType .......................110
5.3.4. FENeighbors and FEConfiguredNeighborType ..........111
6. Satisfying the Requirements on the FE Model ...................111
7. Using the FE Model in the ForCES Protocol .....................112
7.1. FE Topology Query ........................................115
7.2. FE Capability Declarations ...............................116
7.3. LFB Topology and Topology Configurability Query ..........116
7.4. LFB Capability Declarations ..............................116
7.5. State Query of LFB Components ............................118
7.6. LFB Component Manipulation ...............................118
7.7. LFB Topology Reconfiguration .............................118
8. Example LFB Definition ........................................119
8.1. Data Handling ............................................126
8.1.1. Setting Up a DLCI .................................127
8.1.2. Error Handling ....................................127
8.2. LFB Components ...........................................128
8.3. Capabilities .............................................128
8.4. Events ...................................................129
9. IANA Considerations ...........................................130
9.1. URN Namespace Registration ...............................130
9.2. LFB Class Names and LFB Class Identifiers ................130
10. Authors Emeritus .............................................132
11. Acknowledgments ..............................................132
12. Security Considerations ......................................132
13. References ...................................................132
13.1. Normative References ....................................132
13.2. Informative References ..................................133
1. Introduction
RFC 3746 [RFC3746] specifies a framework by which control elements (CEs) can configure and manage one or more separate forwarding elements (FEs) within a network element (NE) using the ForCES protocol. The ForCES architecture allows forwarding elements of varying functionality to participate in a ForCES network element. The implication of this varying functionality is that CEs can make only minimal assumptions about the functionality provided by FEs in an NE. Before CEs can configure and control the forwarding behavior of FEs, CEs need to query and discover the capabilities and states of their FEs. RFC 3654 [RFC3654] mandates that the capabilities, states and configuration information be expressed in the form of an FE model. RFC 3444 [RFC3444] observed that information models (IMs) and data models (DMs) are different because they serve different purposes. "The main purpose of an IM is to model managed objects at a conceptual level, independent of any specific implementations or protocols used". "DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs". Sometimes it is difficult to draw a clear line between the two. The FE model described in this document is primarily an information model, but also includes some aspects of a data model, such as explicit definitions of the LFB (Logical Functional Block) class schema and FE schema. It is expected that this FE model will be used as the basis to define the payload for information exchange between the CE and FE in the ForCES protocol.1.1. Requirements on the FE Model
RFC 3654 [RFC3654] defines requirements that must be satisfied by a ForCES FE model. To summarize, an FE model must define: o Logically separable and distinct packet forwarding operations in an FE data path (Logical Functional Blocks or LFBs); o The possible topological relationships (and hence the sequence of packet forwarding operations) between the various LFBs; o The possible operational capabilities (e.g., capacity limits, constraints, optional features, granularity of configuration) of each type of LFB; o The possible configurable parameters (e.g., components) of each type of LFB; and
o Metadata that may be exchanged between LFBs.1.2. The FE Model in Relation to FE Implementations
The FE model proposed here is based on an abstraction using distinct Logical Functional Blocks (LFBs), which are interconnected in a directed graph, and receive, process, modify, and transmit packets along with metadata. The FE model is designed, and any defined LFB classes should be designed, such that different implementations of the forwarding data path can be logically mapped onto the model with the functionality and sequence of operations correctly captured. However, the model is not intended to directly address how a particular implementation maps to an LFB topology. It is left to the forwarding plane vendors to define how the FE functionality is represented using the FE model. Our goal is to design the FE model such that it is flexible enough to accommodate most common implementations. The LFB topology model for a particular data path implementation must correctly capture the sequence of operations on the packet. Metadata generation by certain LFBs MUST always precede any use of that metadata by subsequent LFBs in the topology graph; this is required for logically consistent operation. Further, modification of packet fields that are subsequently used as inputs for further processing MUST occur in the order specified in the model for that particular implementation to ensure correctness.1.3. The FE Model in Relation to the ForCES Protocol
The ForCES base protocol [RFC5810] is used by the CEs and FEs to maintain the communication channel between the CEs and FEs. The ForCES protocol may be used to query and discover the intra-FE topology. The details of a particular data path implementation inside an FE, including the LFB topology, along with the operational capabilities and attributes of each individual LFB, are conveyed to the CE within information elements in the ForCES protocol. The model of an LFB class should define all of the information that needs to be exchanged between an FE and a CE for the proper configuration and management of that LFB. Specifying the various payloads of the ForCES messages in a systematic fashion is difficult without a formal definition of the objects being configured and managed (the FE and the LFBs within). The FE model document defines a set of classes and components for describing and manipulating the state of the LFBs within an FE. These class definitions themselves will generally not appear in the
ForCES protocol. Rather, ForCES protocol operations will reference classes defined in this model, including relevant components and the defined operations. Section 7 provides more detailed discussion on how the FE model should be used by the ForCES protocol.1.4. Modeling Language for the FE Model
Even though not absolutely required, it is beneficial to use a formal data modeling language to represent the conceptual FE model described in this document. Use of a formal language can help to enforce consistency and logical compatibility among LFBs. A full specification will be written using such a data modeling language. The formal definition of the LFB classes may facilitate the eventual automation of some of the code generation process and the functional validation of arbitrary LFB topologies. These class definitions form the LFB library. Documents that describe LFB classes are therefore referred to as LFB library documents. Human readability was the most important factor considered when selecting the specification language, whereas encoding, decoding, and transmission performance were not a selection factor. The encoding method for over-the-wire transport is not dependent on the specification language chosen and is outside the scope of this document and up to the ForCES protocol to define. XML is chosen as the specification language in this document, because XML has the advantage of being both human and machine readable with widely available tools support. This document uses an XML schema to define the structure of the LFB library documents, as defined in [RFC3470] and [Schema1] and [Schema2]. While these LFB class definitions are not sent in the ForCES protocol, these definitions comply with the recommendations in RFC 3470 [RFC3470] on the use of XML in IETF protocols. By using an XML schema to define the structure for the LFB library documents, we have a very clear set of syntactic restrictions to go with the desired semantic descriptions and restrictions covered in this document. As a corollary to that, if it is determined that a change in the syntax is needed, then a new schema will be required. This would be identified by a different URN to identify the namespace for such a new schema.
1.5. Document Structure
Section 3 provides a conceptual overview of the FE model, laying the foundation for the more detailed discussion and specifications in the sections that follow. Section 4 and Section 5 constitute the core of the FE model, detailing the two major aspects of the FE model: a general LFB model and a definition of the FE Object LFB, with its components, including FE capabilities and LFB topology information. Section 6 directly addresses the model requirements imposed by the ForCES requirements defined in RFC 3654 [RFC3654], while Section 7 explains how the FE model should be used in the ForCES protocol.2. Definitions
The use of compliance terminology (MUST, SHOULD, MAY, MUST NOT) is used in accordance with RFC 2119 [RFC2119]. Such terminology is used in describing the required behavior of ForCES forwarding elements or control elements in supporting or manipulating information described in this model. Terminology associated with the ForCES requirements is defined in RFC 3654 [RFC3654] and is not copied here. The following list of terminology relevant to the FE model is defined in this section. FE Model: The FE model is designed to model the logical processing functions of an FE. The FE model proposed in this document includes three components; the LFB modeling of individual Logical Functional Block (LFB model), the logical interconnection between LFBs (LFB topology), and the FE-level attributes, including FE capabilities. The FE model provides the basis to define the information elements exchanged between the CE and the FE in the ForCES protocol [RFC5810]. Data Path: A conceptual path taken by packets within the forwarding plane inside an FE. Note that more than one data path can exist within an FE. LFB (Logical Functional Block) Class (or type): A template that represents a fine-grained, logically separable aspect of FE processing. Most LFBs relate to packet processing in the data path. LFB classes are the basic building blocks of the FE model. LFB Instance: As a packet flows through an FE along a data path, it flows through one or multiple LFB instances, where each LFB is an instance of a specific LFB class. Multiple instances of the same LFB class can be present in an FE's data path. Note that we often
refer to LFBs without distinguishing between an LFB class and LFB
instance when we believe the implied reference is obvious for the
given context.
LFB Model: The LFB model describes the content and structures in an
LFB, plus the associated data definition. XML is used to provide
a formal definition of the necessary structures for the modeling.
Four types of information are defined in the LFB model. The core
part of the LFB model is the LFB class definitions; the other
three types of information define constructs associated with and
used by the class definition. These are reusable data types,
supported frame (packet) formats, and metadata.
Element: Element is generally used in this document in accordance
with the XML usage of the term. It refers to an XML tagged part
of an XML document. For a precise definition, please see the full
set of XML specifications from the W3C. This term is included in
this list for completeness because the ForCES formal model uses
XML.
Attribute: Attribute is used in the ForCES formal modeling in
accordance with standard XML usage of the term, i.e., to provide
attribute information included in an XML tag.
LFB Metadata: Metadata is used to communicate per-packet state from
one LFB to another, but is not sent across the network. The FE
model defines how such metadata is identified, produced, and
consumed by the LFBs, but not how the per-packet state is
implemented within actual hardware. Metadata is sent between the
FE and the CE on redirect packets.
ForCES Component: A ForCES Component is a well-defined, uniquely
identifiable and addressable ForCES model building block. A
component has a 32-bit ID, name, type, and an optional synopsis
description. These are often referred to simply as components.
LFB Component: An LFB component is a ForCES component that defines
the Operational parameters of the LFBs that must be visible to the
CEs.
Structure Component: A ForCES component that is part of a complex
data structure to be used in LFB data definitions. The individual
parts that make up a structured set of data are referred to as
structure components. These can themselves be of any valid data
type, including tables and structures.
Property: ForCES components have properties associated with them,
such as readability. Other examples include lengths for variable-
sized components. These properties are accessed by the CE for
reading (or, where appropriate, writing.) Details on the ForCES
properties are found in Section 4.8.
LFB Topology: LFB topology is a representation of the logical
interconnection and the placement of LFB instances along the data
path within one FE. Sometimes this representation is called
intra-FE topology, to be distinguished from inter-FE topology.
LFB topology is outside of the LFB model, but is part of the FE
model.
FE Topology: FE topology is a representation of how multiple FEs
within a single network element (NE) are interconnected.
Sometimes this is called inter-FE topology, to be distinguished
from intra-FE topology (i.e., LFB topology). An individual FE
might not have the global knowledge of the full FE topology, but
the local view of its connectivity with other FEs is considered to
be part of the FE model. The FE topology is discovered by the
ForCES base protocol or by some other means.
Inter-FE Topology: See FE Topology.
Intra-FE Topology: See LFB Topology.
LFB Class Library: The LFB class library is a set of LFB classes
that has been identified as the most common functions found in
most FEs and hence should be defined first by the ForCES Working
Group.
(page 10 continued on part 2)
