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.