tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6956

Proposed STD
Pages: 111
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: FORCES

Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library

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

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                           W. Wang
Request for Comments: 6956                 Zhejiang Gongshang University
Category: Standards Track                                  E. Haleplidis
ISSN: 2070-1721                                     University of Patras
                                                                K. Ogawa
                                                         NTT Corporation
                                                                   C. Li
                                                         Hangzhou DPtech
                                                              J. Halpern
                                                                Ericsson
                                                               June 2013


           Forwarding and Control Element Separation (ForCES)
                  Logical Function Block (LFB) Library

Abstract

   This document defines basic classes of Logical Function Blocks (LFBs)
   used in Forwarding and Control Element Separation (ForCES).  The
   basic LFB classes are defined according to the ForCES Forwarding
   Element (FE) model and ForCES protocol specifications; they are
   scoped to meet requirements of typical router functions and are
   considered the basic LFB library for ForCES.  The library includes
   the descriptions of the LFBs and the XML definitions.

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/rfc6956.

Page 2 
Copyright Notice

   Copyright (c) 2013 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 ....................................................3
   2. Terminology and Conventions .....................................4
      2.1. Requirements Language ......................................4
      2.2. Definitions ................................................4
   3. Overview ........................................................6
      3.1. Scope of the Library .......................................6
      3.2. Overview of LFB Classes in the Library .....................8
           3.2.1. LFB Design Choices ..................................8
           3.2.2. LFB Class Groupings .................................9
           3.2.3. Sample LFB Class Application .......................10
      3.3. Document Structure ........................................11
   4. Base Types .....................................................11
      4.1. Data Types ................................................13
           4.1.1. Atomic .............................................13
           4.1.2. Compound Struct ....................................13
           4.1.3. Compound Array .....................................14
      4.2. Frame Types ...............................................14
      4.3. Metadata Types ............................................15
      4.4. XML for Base Type Library .................................16
   5. LFB Class Descriptions .........................................41
      5.1. Ethernet-Processing LFBs ..................................42
           5.1.1. EtherPHYCop ........................................42
           5.1.2. EtherMACIn .........................................44
           5.1.3. EtherClassifier ....................................46
           5.1.4. EtherEncap .........................................48
           5.1.5. EtherMACOut ........................................50
      5.2. IP Packet Validation LFBs .................................52
           5.2.1. IPv4Validator ......................................52
           5.2.2. IPv6Validator ......................................54

Top      ToC       Page 3 
      5.3. IP Forwarding LFBs ........................................55
           5.3.1. IPv4UcastLPM .......................................56
           5.3.2. IPv4NextHop ........................................58
           5.3.3. IPv6UcastLPM .......................................60
           5.3.4. IPv6NextHop ........................................62
      5.4. Redirect LFBs .............................................64
           5.4.1. RedirectIn .........................................64
           5.4.2. RedirectOut ........................................65
      5.5. General Purpose LFBs ......................................66
           5.5.1. BasicMetadataDispatch ..............................66
           5.5.2. GenericScheduler ...................................68
   6. XML for LFB Library ............................................69
   7. LFB Class Use Cases ............................................97
      7.1. IPv4 Forwarding ...........................................98
      7.2. ARP Processing ...........................................101
   8. IANA Considerations ...........................................102
      8.1. LFB Class Names and LFB Class Identifiers ................103
      8.2. Metadata ID ..............................................105
      8.3. Exception ID .............................................106
      8.4. Validate Error ID ........................................107
   9. Security Considerations .......................................108
   10. References ...................................................108
      10.1. Normative References ....................................108
      10.2. Informative References ..................................108
   Appendix A.  Acknowledgements ....................................110
   Appendix B.  Contributors ........................................110

1.  Introduction

   [RFC3746] specifies the Forwarding and Control Element Separation
   (ForCES) framework.  In the framework, Control Elements (CEs)
   configure and manage one or more separate Forwarding Elements (FEs)
   within a Network Element (NE) by use of a ForCES protocol.  [RFC5810]
   specifies the ForCES protocol.  [RFC5812] specifies the Forwarding
   Element (FE) model.  In the model, resources in FEs are described by
   classes of Logical Function Blocks (LFBs).  The FE model defines the
   structure and abstract semantics of LFBs and provides XML schema for
   the definitions of LFBs.

   This document conforms to the specifications of the FE model
   [RFC5812] and specifies detailed definitions of classes of LFBs,
   including detailed XML definitions of LFBs.  These LFBs form a base
   LFB library for ForCES.  LFBs in the base library are expected to be
   combined to form an LFB topology for a typical router to implement IP
   forwarding.  It should be emphasized that an LFB is an abstraction of
   functions rather than implementation details.  The purpose of the LFB
   definitions is to represent functions so as to provide
   interoperability between separate CEs and FEs.

Top      ToC       Page 4 
   More LFB classes with more functions may be developed in the future
   and documented by the IETF.  Vendors may also develop proprietary LFB
   classes as described in the FE model [RFC5812].

2.  Terminology and Conventions

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  Definitions

   This document follows the terminology defined by the ForCES protocol
   in [RFC5810] and by the ForCES FE model in [RFC5812].  The
   definitions below are repeated for clarity.

      Control Element (CE) - A logical entity that implements the ForCES
      protocol and uses it to instruct one or more FEs on how to process
      packets.  CEs handle functionality such as the execution of
      control and signaling protocols.

      Forwarding Element (FE) - A logical entity that implements the
      ForCES protocol.  FEs use the underlying hardware to provide per-
      packet processing and handling as directed/controlled by one or
      more CEs via the ForCES protocol.

      ForCES Network Element (NE) - An entity composed of one or more
      CEs and one or more FEs.  To entities outside an NE, the NE
      represents a single point of management.  Similarly, an NE usually
      hides its internal organization from external entities.

      Logical Function Block (LFB) - The basic building block that is
      operated on by the ForCES protocol.  The LFB is a well-defined,
      logically separable functional block that resides in an FE and is
      controlled by the CE via the ForCES protocol.  The LFB may reside
      at the FE's data path and process packets or may be purely an FE
      control or configuration entity that is operated on by the CE.
      Note that the LFB is a functionally accurate abstraction of the
      FE's processing capabilities but not a hardware-accurate
      representation of the FE implementation.

      FE Model - The FE model is designed to model the logical
      processing functions of an FE, which is defined by the ForCES FE
      model document [RFC5812].  The FE model proposed in this document
      includes three components: the LFB modeling of individual Logical
      Functional Blocks (LFB model), the logical interconnection between

Top      ToC       Page 5 
      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].

      FE Topology - A representation of how the multiple FEs within a
      single NE are interconnected.  Sometimes this is called inter-FE
      topology, to be distinguished from intra-FE topology (i.e., LFB
      topology).

      LFB Class and LFB Instance - LFBs are categorized by LFB classes.
      An LFB instance represents an LFB class (or type) existence.
      There may be multiple instances of the same LFB class (or type) in
      an FE.  An LFB class is represented by an LFB class ID, and an LFB
      instance is represented by an LFB instance ID.  As a result, an
      LFB class ID associated with an LFB instance ID uniquely specifies
      an LFB existence.

      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.  It defines the functionality but not how
      metadata is encoded within an implementation.

      LFB Component - Operational parameters of the LFBs that must be
      visible to the CEs are conceptualized in the FE model as the LFB
      components.  The LFB components include, for example, flags,
      single parameter arguments, complex arguments, and tables that the
      CE can read and/or write via the ForCES protocol (see below).

      LFB Topology - Representation of how the LFB instances are
      logically interconnected and placed along the data path within one
      FE.  Sometimes it is also called intra-FE topology, to be
      distinguished from inter-FE topology.

      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.

      ForCES Protocol - While there may be multiple protocols used
      within the overall ForCES architecture, the term "ForCES protocol"
      and "protocol" refer to the Fp reference points in the ForCES
      framework in [RFC3746].  This protocol does not apply to CE-to-CE
      communication, FE-to-FE communication, or to communication between
      FE and CE managers.  Basically, the ForCES protocol works in a
      master-slave mode in which FEs are slaves and CEs are masters.

Top      ToC       Page 6 
      Physical Port - A port refers to a physical media input port or
      output port of an FE.  A physical port is usually assigned with a
      physical port ID, abbreviated with a PHYPortID.  This document
      mainly deals with physical ports with Ethernet media.

      Logical Port - A conceptually virtual port at the data link layer
      (L2) or network layer (L3).  A logical port is usually assigned
      with a logical port ID, abbreviated with a LogicalPortID.  The
      logical ports can be further categorized with an L2 logical port
      or an L3 logical port.  An L2 logical port can be assigned with an
      L2 logical port ID, abbreviated with an L2PortID.  An L3 logical
      port can be assigned with an L3 logical port ID, abbreviated with
      an L3PortID.  MAC-layer VLAN ports belong to logical ports, and
      they belong to L2 logical ports.

      LFB Port - The connection points where one LFB can be connected to
      another within an FE.  As described in [RFC5812], the CE can
      connect LFBs together by establishing connections between an
      output port of one LFB instance and an input port of another LFB
      instance.  Also see Section 3.2 of [RFC5812] for more details.

      Singleton Port - A named input or output port of an LFB.  This
      port is referred to by a name.  When the context is clear, the
      term "singleton" by itself is used to refer to a singleton port.

      Group Port - A named collection of input or output ports of an
      LFB.  A group port is referred to by a name.  A group port
      consists of a number of port instances, which are referred to by a
      combination of a name and an index.

      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.  The LFB class library is defined by this document.

3.  Overview

3.1.  Scope of the Library

   It is intended that the LFB classes described in this document are
   designed to provide the functions of a typical router.  [RFC1812]
   specifies that a typical router is expected to provide functions to:

Top      ToC       Page 7 
   (1)  Interface to packet networks and implement the functions
        required by that network.  These functions typically include:

        *  Encapsulating and decapsulating the IP datagrams with the
           connected network framing (e.g., an Ethernet header and
           checksum),

        *  Sending and receiving IP datagrams up to the maximum size
           supported by that network (this size is the network's Maximum
           Transmission Unit or MTU),

        *  Translating the IP destination address into an appropriate
           network-level address for the connected network (e.g., an
           Ethernet hardware address), if needed, and

        *  Responding to network flow control and error indications, if
           any.

   (2)  Conform to specific Internet protocols including the Internet
        Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
        (ICMP), and others as necessary.

   (3)  Receive and forward Internet datagrams.  Important issues in
        this process are buffer management, congestion control, and
        fairness.

        *  Recognize error conditions and generate ICMP error and
           information messages as required.

        *  Drop datagrams whose time-to-live fields have reached zero.

        *  Fragment datagrams when necessary to fit into the MTU of the
           next link or interface.

   (4)  Choose a next-hop destination for each IP datagram, based on the
        information in its routing database.

   (5)  Usually support an interior gateway protocol (IGP) to carry out
        distributed routing and reachability algorithms with the other
        routers in the same autonomous system.  In addition, some
        routers will need to support an exterior gateway protocol (EGP)
        to exchange topological information with other autonomous
        systems.  For all routers, it is essential to provide the
        ability to manage static routing items.

   (6)  Provide network management and system support facilities,
        including loading, debugging, status reporting, statistics
        query, exception reporting, and control.

Top      ToC       Page 8 
   The classical IP router utilizing the ForCES framework constitutes a
   CE running some controlling IGP and/or EGP function or static route
   setup and FEs implemented by use of Logical Function Blocks (LFBs)
   conforming to the FE model [RFC5812] specification.  The CE, in
   conformance to the ForCES protocol [RFC5810] and the FE model
   [RFC5812] specifications, instructs the LFBs on the FE how to treat
   received/sent packets.

   Packets in an IP router are received and transmitted on physical
   media typically referred to as "ports".  Different physical media
   will have different ways for encapsulating outgoing frames and
   decapsulating incoming frames.  The different physical media will
   also have different attributes that influence its behavior and how
   frames get encapsulated or decapsulated.  This document will only
   deal with Ethernet physical media.  Future documents may deal with
   other types of media.  This document will also interchangeably refer
   to a port as an abstraction that constitutes a physical layer (PHY)
   and a Media Access Control (MAC) layer, as described by LFBs like
   EtherPHYCop, EtherMACIn, and EtherMACOut.

   IP packets emanating from port LFBs are then processed by a
   validation LFB before being further forwarded to the next LFB.  After
   the validation process, the packet is passed to an LFB where an IP
   forwarding decision is made.  In the IP Forwarding LFBs, a Longest
   Prefix Match LFB is used to look up the destination information in a
   packet and select a next-hop index for sending the packet onward.  A
   next-hop LFB uses the next-hop index metadata to apply the proper
   headers to the IP packets and direct them to the proper egress.  Note
   that in the process of IP packet processing, in this document, we are
   adhering to the weak-host model [RFC1122] since that is the most
   usable model for a packet processing a Network Element.

3.2.  Overview of LFB Classes in the Library

   It is critical to classify functional requirements into various
   classes of LFBs and construct a typical but also flexible enough base
   LFB library for various IP forwarding equipments.

3.2.1.  LFB Design Choices

   A few design principles were factored into choosing what the base
   LFBs look like:

   o  If a function can be designed by either one LFB or two or more
      LFBs with the same cost, the choice is to go with two or more LFBs
      so as to provide more flexibility for implementers.

Top      ToC       Page 9 
   o  An LFB should take advantage of its independence as much as
      possible and have minimal coupling with other LFBs.  The coupling
      may be from LFB attributes definitions as well as physical
      implementations.

   o  Unless there is a clear difference in functionality, similar
      packet processing in the base LFB library should not be
      represented simultaneously as two or more LFBs.  For instance, it
      should not be simultaneously defined with two different LFBs for
      the same next-hop processing.  Otherwise, it may add extra burden
      on implementation to achieve interoperability.

3.2.2.  LFB Class Groupings

   This document defines groups of LFBs for typical router function
   requirements:

   (1)  A group of Ethernet-processing LFBs are defined to abstract the
        packet processing for Ethernet as the port media type.  As
        Ethernet is the most popular media type with rich processing
        features, Ethernet media processing LFBs were a natural choice.
        Definitions for processing of other port media types like Packet
        over SONET (POS) or Asynchronous Transfer Mode (ATM) may be
        incorporated in the library in future versions of this document
        or in a separate document.  The following LFBs are defined for
        Ethernet processing:

        *  EtherPHYCop (Section 5.1.1)

        *  EtherMACIn (Section 5.1.2)

        *  EtherClassifier (Section 5.1.3)

        *  EtherEncap (Section 5.1.4)

        *  EtherMACOut (Section 5.1.5)

   (2)  A group of LFBs are defined for IP packet validation process.
        The following LFBs are defined for IP validation processing:

        *  IPv4Validator (Section 5.2.1)

        *  IPv6Validator (Section 5.2.2)

   (3)  A group of LFBs are defined to abstract IP forwarding process.
        The following LFBs are defined for IP forwarding processing:

        *  IPv4UcastLPM (Section 5.3.1)

Top      ToC       Page 10 
        *  IPv4NextHop (Section 5.3.2)

        *  IPv6UcastLPM (Section 5.3.3)

        *  IPv6NextHop (Section 5.3.4)

   (4)  A group of LFBs are defined to abstract the process for redirect
        operation, i.e., data packet transmission between CE and FEs.
        The following LFBs are defined for redirect processing:

        *  RedirectIn (Section 5.4.1)

        *  RedirectOut (Section 5.4.2)

   (5)  A group of LFBs are defined for abstracting some general purpose
        packet processing.  These processing processes are usually
        general to many processing locations in an FE LFB topology.  The
        following LFBs are defined for redirect processing:

        *  BasicMetadataDispatch (Section 5.5.1)

        *  GenericScheduler (Section 5.5.2)

3.2.3.  Sample LFB Class Application

   Although Section 7 will present use cases for the LFBs defined in
   this document, this section shows a simple sample LFB class
   application in advance so that readers can get a quick overlook of
   the LFB classes with the usage.

   Figure 1 shows a simple LFB processing path for Ethernet packets
   entered from Ethernet physical ports.

   +-----+                +------+
   |     |EtherPHYIn      |      |            from some LFB(s) that
   |     |<---------------|Ether |<---------- generate Ethernet
   |     |                |MACOut|            packets
   |     |                | LFB  |
   |Ether|                +------+
   |PHY  |                +------+
   |Cop  |                |      |
   |LFB  |EtherPHYOut     | Ether|            to some LFB(s) that
   |     |--------------->| MACIn|----------> may classify Ethernet
   |     |                |  LFB |            packets and do IP-layer
   |     |                |      |            processing
   +-----+                +------+

                  Figure 1:  A Simple Sample LFB Use Case

Top      ToC       Page 11 
   In the figure, Ethernet packets from outer networks enter via the
   EtherPHYCop LFB (Section 5.1.1), which describes Ethernet copper
   interface properties (like the link speed) at the physical layer.
   After physical-layer processing, Ethernet packets are delivered to
   the EtherMACIn LFB (Section 5.1.2) to describe its MAC-layer
   processing functions (like locality check).  The packets after the
   EtherMACIn LFB may require further processing to implement various
   functions (like IP-layer forwarding); therefore, some LFBs may follow
   the EtherMACIn LFB in topology to describe followed processing
   functions.

   Meanwhile, packets generated by some LFB(s) may need to be submitted
   to outer physical networks.  The process is described in the figure
   by an EtherMACOut LFB (Section 5.1.5) at the MAC layer and the
   EtherPHYCop LFB at the physical layer.

3.3.  Document Structure

   Base type definitions, including data types, packet frame types, and
   metadata types, are presented in advance for definitions of various
   LFB classes.  Section 4 ("Base Types") provides a description on the
   base types used by this LFB library.  To enable extensive use of
   these base types by other LFB class definitions, the base type
   definitions are provided as a separate library.

   Within every group of LFB classes, a set of LFBs are defined for
   individual function purposes.  Section 5 ("LFB Class Descriptions")
   provides text descriptions on the individual LFBs.  Note that for a
   complete definition of an LFB, a text description and an XML
   definition are required.

   LFB classes are finally defined by XML with specifications and schema
   defined in the ForCES FE model [RFC5812].  Section 6 ("XML for LFB
   Library") provides the complete XML definitions of the base LFB
   classes library.

   Section 7 provides several use cases on how some typical router
   functions can be implemented using the base LFB library defined in
   this document.



(page 11 continued on part 2)

Next RFC Part