15 Apr 2004 00:15
Revised LFB input/output text
Zsolt Haraszti <zsolt.haraszti <at> ERICSSON.COM>
2004-04-14 22:15:39 GMT
2004-04-14 22:15:39 GMT
After the dissemination of the last model draft in February (draft-ietf-forces-model-02.txt), we got many very useful comments. Thanks. One topic that generated lots of questions was the concept of LFB inputs and outputs. It became obvious to us that in 02 we did not do a good job explaining the proposed LFB input/output model. Attached is a fully revised version of the relevant subsections of 02 (3.2.1 and 3.2.2). Hopefully this text conveys the design intent much better. Comments are welcome! -- Zsolt Haraszti, Ph.D. Tel: +1 919 472 9949 Ericsson IP Infrastructure Fax: +1 919 472 9999 Raleigh NC USA Email: zsolt.haraszti <at> ericsson.com
3.2.1. LFB Outputs
A LFB output is a conceptual port on a LFB that can send information
to some other LFB. The information is typically a packet and
associated metadata, although in some cases it might consist of only
metadata, i.e., with no packet data.
A single LFB output can be connected to only one LFB input. This is
required to make the packet flow through the LFB topology
unambiguous.
Some LFBs will have a single output, as depicted in Figure 3.a.
+---------------+ +-----------------+
| | | |
| | | OUT +-->
... OUT +--> ... |
| | | EXCEPTIONOUT +-->
| | | |
+---------------+ +-----------------+
a. One output b. Two distinct outputs
+---------------+ +-----------------+
| | | EXCEPTIONOUT +-->
| OUT:1 +--> | |
... OUT:2 +--> ... OUT:1 +-->
| ... +... | OUT:2 +-->
| OUT:n +--> | ... +...
+---------------+ | OUT:n +-->
+-----------------+
c. One output group d. One output and one output group
Figure 3. Examples of LFBs with various output combinations.
To accommodate any non-trivial LFB topology, multiple LFB outputs must
be allowed so that a LFB class can fork the datapath. Two mechanisms
are provided for forking: multiple singleton outputs and output groups
(the two concepts can be also combined in the same LFB class).
Multiple separate singleton outputs are defined in a LFB class to
model a pre-determined number of semantically different outputs.
Pre-determined here means that the number of outputs are known at the
time when the LFB class is defined. Additional singleton outputs
cannot be created at LFB instantiation time, neither can they be
created on the fly after the LFB is instantiated.
For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one
output (OUT) to send those packets for which LPM look-up was
successful (passing a META_ROUTEID as metadata); and have another
output (EXCEPTIONOUT) for sending exception packets for which the LPM
look-up failed. This example is depicted in Figure 3.b. Packets
emitted by these two outputs not only require very different
downstream treatment, but they are a result of two very different
conditions in the LFB, and they also carry different metadata. This
concept assumes that the number of distinct outputs are known at the
time of LFB class definition. For each singleton output the LFB class
definition defines what types of frames and metadata the output emits.
An output group, on the other hand, is used to model the case where a
flow of seemingly similar packets with an identical set of metadata
need to be split into multiple paths, and where the number of such
paths is not known when the LFB class if defined (i.e., because it is
not an inherent property of the LFB class). An output group consists
of a number of outputs (called the output instances of the group), all
sharing the same frame and metadata emission definitions (see Figure
3.c). Each output instance can connect to a different downstream LFB,
just as if they were separate singleton outputs. But, in contrast with
the singleton outputs, the number of output instances can be different
from one instance of the LFB class to another. The class definition
may include a lower and/or an upper limit on the number of output
instances. In addition, for configurable FEs, the FE capability
information may include further limits on the number of instances in
specific output groups of certain LFBs. The actual number of output
instances in a group is an attribute of the LFB instance, which is
read-only for static topologies, and read-write for dynamic
topologies. The output instances in a group are numbered sequentially,
from 0 to N-1, and are addressable from within the LFB. The LFB has a
built-in mechanism to select one specific output instance for each
packet. This mechanism is well described in the textual definition of
the class and it is typically configurable via some attributes of the
LFB.
For example, consider a re-director LFB, whose sole purpose is to
direct packets to one of N downstream paths based on one of the
metadata associated with each arriving packet. Such a LFB is fairly
versatile and can be used in many different places in a topology, for
example to divide the data path into an IPv4 and an IPv6 path based on
a FRAMETYPE metadata (N=2), or to fork into color specific paths after
metering using the COLOR metadata (red, yellow, green; N=3), etc.
Using an output group in the above LFB class provides the desired
flexibility to adapt each instance of this class to the required
operation. The metadata which is to be used as a selector for the
output instance is a property of the LFB. For each packet, the value
of the specified metadata may be used as a direct index to the output
instance. Alternatively, the LFB may have a configurable selector
table that maps a metadata value to output instance.
Note that other LFBs may also use the concept of output group to build
in similar adaptive forking capability. For example, a classifier LFB
with one input and N outputs can be defined easily by using the output
group concept. Alternatively, a classifier LFB with one singleton
output in combination with an explciit N-output re-director LFB to
model the same processing behavior. The decision of whether to use the
output group model for a certain LFB class is left to the LFB class
designers.
The model allows the output group be combined with other singleton
output(s) in the same class, as it is demonstrated in Figure 3.d. The
LFB here has two types of outputs, OUT for normal packet output, and
EXCEPTIONOUT for packets that triggered some exception. The normal OUT
has multiple instances, i.e., it is an output group.
In summary, the LFB class may define one output, multiple singleton
outputs, one or more output groups, or a combination of the latter
two. Multiple singleton outputs are to be used when the LFB must
provide for forking the datapath, and at least one of the following
conditions hold:
- the number of downstream directions are inherent from the definition
of the class (and hence fixed);
- the frame type and set of metadata emitted on any of the outputs are
substantially different from what is emitted on the other outputs
(i.e., they cannot share frame-type and metadata definitions);
An output group is appropriate when the LFB must provide for forking
the datapath, and at least one of the following conditions hold:
- the number of downstream directions is not known when the LFB class
is defined (i.e., because it is not an inherent property of the
class);
- the frame type and set of metadata emitted on these outputs are
sufficiently similar or identical, so they can share the same output
definition.
3.2.2. LFB Inputs
A LFB input is a conceptual port on a LFB where the LFB can receive
information from other LFBs. The information is typically a packet and
associated metadata, although in some cases it might consist of only
metadata, i.e., with no packet data.
It is nevertheless inevitable that there will be LFB instances that
will receive packets from more than one other LFB instance (fan-in).
There are three ways of modeling the fan-in, all supported in the LFB
model:
- Implicit multiplexing via a single input
- Explicit multiplexing via multiple singleton inputs
- Explicit multiplexing via a group of inputs (input group)
The above modes can be combined in the same LFB.
The simplest form of multiplexing uses a singleton input (Figure 4.a).
It is in fact expected that most LFBs will have only one singleton
input. Multiplexing into a single input is possible because the model
allows for more than one LFB output to connect to the same input of an
LFB. This property applies to any LFB input without any special
provisioning in the LFB class. Multiplexing into a single input is
applicable when the packets from the upstream LFBs are similar (in
frame-type and accompanying metadata) and require similar processing.
Note that this model does not address how potential contention is
handled when multiple packets arrive simultaneously. If this needs to
be explicitly modeled, one of the other two modeling solutions must be
used.
The second method to model fan-in uses separately defined singleton
inputs (Figure 4.b). This model is meant for situations where the LFB
needs to handle distinct types of packet streams, requiring
input-specific handling inside the LFB, and where the number of such
distinct cases is an inherent property of the LFB class (and hence is
known when the LFB class is defined). For example, a Layer 2
Decapsulation/Encapsulation LFB may have two inputs, one for receiving
Layer 2 frames for decapsulation, and one for receiving Layer 3 frames
for encapsulation. Such a LFB would expect very different frames (L2
vs. L3) at its inputs, each with different sets of metadata, and would
obviously apply different processing on frames arriving at these
inputs. This model is capable of explicitly addressing packet
contention, i.e., by defining how the LFB class handles the contending
packets.
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ | | |
| | |
+--------------+ v | |
| LFB Y +---+-->|input Meter LFB |
+--------------+ ^ | |
| | |
+--------------+ | | |
| LFB Z |---+ | |
+--------------+ +------------------------+
(a) A LFB connects with multiple upstream LFBs via a single input.
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ +-->|layer2 |
+--------------+ | |
| LFB Y +------>|layer3 LFB |
+--------------+ +------------------------+
(b) A LFB connects with multiple upstream LFBs via two separate
singleton inputs.
+--------------+ +------------------------+
| Queue LFB #1 +---+ | |
+--------------+ | | |
| | |
+--------------+ +-->|in:0 \ |
| Queue LFB #2 +------>|in:1 | input group |
+--------------+ |... | |
+-->|in:N-1 / |
... | | |
+--------------+ | | |
| Queue LFB #N |---+ | Scheduler LFB |
+--------------+ +------------------------+
(c) A Scheduler LFB uses an input group to differentiate which queue
LFB packets are coming from.
Figure 3. Input modeling concepts (examples).
The third method to model fan-in uses the concept of an input group.
The concept is similar to the output group introduced in the previous
section, and is depicted in Figure 4.c. An input group consists of a
number of input instances, all sharing the properties (same frame and
metadata expectations). The input instances are numbered from 0 to
N-1. From the outside these inputs appear as normal inputs, i.e., any
compatible upstream LFB can connect its output to one of these inputs.
When a packet is presented to the LFB at a particular input instance,
the index of the input where the packet arrived will be known to the
LFB and this information may be used in the internal processing. For
example, the input index can be used as a table selector, or as an
explicit precedence selector to resolve contentions. As with output
groups, the number of input instances in an input group is not defined
in the LFB class, though the class definition may include restrictions
on the range of possible values. In addition, if a FE supports
configurable topologies, it may impose further limitations on the
number of instances for a particular port group(s) of a particular LFB
class. Within these limitations, different instances of the same class
may have a different number of input instances. The number of actual
input instances in the group is an attribute of the LFB class, which
is read-only for static topologies, and it is read-write for
configurable topologies.
As an example for the input group, consider the Scheduler LFB depicted
in Figure 3.c. Such an LFB receives packets from a number of Queue
LFBs via a number of input instances, and uses the input index
information to control contention resolution and scheduling.
In summary, the LFB class may define one input, multiple singleton
inputs, one or more input groups, or a combination thereof. Any input
allows for implicit multiplexing of similar packet streams via
connecting multiple outputs to the same input. Explicit multiple
singleton inputs are useful when either the contention handling must
be handled explicitly, or when the LFB class must receive and process
a known number of very distinct types of packet streams. An input
group is suitable when the contention handling must be modeled
explicitly, but the number of inputs are not inherent from the class
(and hence not known when the class is defined), or when it is
critical for LFB operation to know exactly which input the packet was
received.
RSS Feed