Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5812

Forwarding and Control Element Separation (ForCES) Forwarding Element Model

Pages: 134
Proposed Standard
Errata
Updated by:  7408
Part 1 of 5 – Pages 1 to 10
None   None   Next

Top   ToC   RFC5812 - Page 1
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 Model

Abstract

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.
Top   ToC   RFC5812 - Page 2
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.
Top   ToC   RFC5812 - Page 3

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
Top   ToC   RFC5812 - Page 4
           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
Top   ToC   RFC5812 - Page 5

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
Top   ToC   RFC5812 - Page 6
   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
Top   ToC   RFC5812 - Page 7
   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.
Top   ToC   RFC5812 - Page 8

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
Top   ToC   RFC5812 - Page 9
      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.
Top   ToC   RFC5812 - Page 10
   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)

Next Section