RFC 6956
Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
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) LibraryAbstract
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.
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
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.
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
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.
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:
(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.
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.
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)
* 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
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)
