tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5812

 Errata 
Proposed STD
Pages: 134
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: FORCES

Forwarding and Control Element Separation (ForCES) Forwarding Element Model

Part 1 of 5, p. 1 to 10
None       Next RFC Part

Updated by:    7408


Top       ToC       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.

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       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       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       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       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       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       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       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       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 RFC Part