One document matched: draft-yang-forces-model-02.txt
Differences from draft-yang-forces-model-01.txt
Internet Draft L. Yang
Expiration: Dec 2003 Intel Labs
File: draft-yang-forces-model-02.txt J. Halpern
Working Group: ForCES
R. Gopal
Nokia
A. DeKok
IDT Inc.
June 2003
ForCES Forwarding Element Functional Model
draft-yang-forces-model-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as ``work in
progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines a functional model for forwarding elements
(FEs) used in the Forwarding and Control Plane Separation (ForCES)
protocol. This model is used to describe the capabilities,
capacities, state and configuration of ForCES forwarding elements
within the context of the ForCES protocol, so that ForCES control
elements (CEs) can control the FEs accordingly. The model is to
specify what logical functions are present in the FEs, what
capabilities these functions support, and how these functions are
Internet Draft ForCES FE Functional Model June 2003
or can be interconnected. The forwarding element model defined
herein is intended to satisfy the requirements specified in the
ForCES requirements draft [FORCES-REQ]. Using this model,
predefined or vendor specific logical functions can be expressed
and configured. However, the definition of these individual
functions are not described and defined in this document.
Table of Contents
Abstract.........................................................1
1. Definitions...................................................3
2. Motivation and Requirements of FE model.......................4
3. State Model versus Capability Model...........................4
4. FE Model Concepts: FE Block and FE Block Topology.............7
4.1. FE Blocks................................................7
4.2. FE Block Topology........................................9
4.2.1. Configuring FE Block Topology......................11
4.2.2. Modeling FE Block Topology.........................16
5. Logical FE Block Library.....................................21
5.1. FE Input/Output Block Characterization..................21
5.1.1. Source Block.......................................21
5.1.2. Sink Block.........................................22
5.1.3. Port Block.........................................22
5.1.4. Dropper Block......................................22
5.1.5. MUX Block..........................................23
5.1.6. Redirector (de-MUX) Block..........................23
5.1.7. Shaper Block.......................................23
5.2. FE Processing Blocks....................................23
5.2.1. Counter Block......................................24
5.2.2. Meter Block........................................24
5.2.3. Filter Block.......................................24
5.2.4. Classifier Block...................................24
5.2.5. Redirecting Classifier Block.......................25
5.2.6. Modifier Block.....................................25
5.2.7. Packet Header Rewriter Block.......................26
5.2.8. Packet Compression/Decompression Block.............26
5.2.9. Packet Encryption/Decryption Block.................26
5.2.10. Packet Encapsulation/Decapsulation Block..........26
6. Minimal Set of Logical Functions Required for FE Model.......27
6.1. QoS Functions...........................................27
6.1.1. Classifier.........................................27
6.1.2. Meter..............................................28
6.1.3. Marker.............................................28
6.1.4. Dropper............................................28
6.1.5. Counter............................................28
6.1.6. Queue and Scheduler (?)............................28
6.1.7. Shaper.............................................28
Yang, et al. Expires Dec 2003 [Page 2]
Internet Draft ForCES FE Functional Model June 2003
6.2. Generic Filtering Functions.............................28
6.3. Vendor Specific Functions...............................29
6.4. Port Functions..........................................29
6.5. Forwarding Functions....................................29
6.6. High-Touch Functions....................................30
6.7. Security Functions......................................31
6.8. Off-loaded Functions....................................31
7. Cascading Multiple FEs.......................................31
8. Data Modeling and Representation.............................32
9. Security Considerations......................................33
10. Intellectual Property Right.................................33
11. IANA consideration..........................................34
12. Normative References........................................34
13. Informative References......................................34
14. Acknowledgments.............................................35
15. Authors' Addresses..........................................35
Conventions used in this document
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 [RFC-2119].
1. Definitions
A set of terminology associated with the ForCES requirements is
defined in [FORCES-REQ] and is not copied here. The following list
of terminology is relevant to the FE model defined in this
document.
Datapath -- A conceptual path taken by packets within the
forwarding plane, inside an FE. There might exist more than one
datapath within an FE.
Forwarding Element (FE) Block -- An abstraction of the basic packet
processing logical functions in the datapath. It is the building
block of FE functionality. This concept abstracts away
implementation details from the parameters of interest for
configuration, control and management by CE.
Forwarding Element (FE) Stage -- Representation of an FE block
instance in a FE's datapath. As a packet flows through an FE along
a datapath, it flows through one or multiple distinct stages, with
each stage implementing an instance of a certain logical function
block. There may be multiple instances of the same functional
block in a FE's datapath.
Yang, et al. Expires Dec 2003 [Page 3]
Internet Draft ForCES FE Functional Model June 2003
FE Topology -- Representation of how the multiple FEs in a single
NE are interconnected. Sometimes it is called inter-FE topology,
to be distinguished from intra-FE (block) topology.
FE Block Topology -- Representation of how the FE stages are
interconnected and placed along the datapath within one FE.
Sometimes it is also called intra-FE topology, to be distinguished
from inter-FE topology.
Inter-FE Topology û See FE Topology.
Intra-FE Topology û See FE Block Topology.
2. Motivation and Requirements of FE model
The ForCES architecture allows Forwarding Elements (FEs) of varying
functionality to participate in a ForCES network element (NE). The
implication of this varying functionality is that CEs can make only
minimal assumptions about the functionality provided by its FEs.
Before CEs can configure and control the forwarding behavior of
FEs, CEs need to query and discover the capabilities and states of
their FEs. [FORCES-REQ] mandates that this capabilities and states
information be expressed in the form of an FE model, and this model
will be used as the basis for CEs to control and manipulate FEs'
behavior via ForCES protocol.
[FORCES-REQ] describes all the requirements placed on the FE model
in detail. We provide a brief summary here to highlight some of the
design issues we face.
. The FE model MUST express what logical functions can be
applied to packets as they pass through an FE.
. The FE model MUST be capable of supporting/allowing variations
in the way logical functions are implemented on an FE.
. The model MUST be capable of describing the order in which
these logical functions are applied in a FE.
. The FE model SHOULD be extendable and should have provision to
express new or vendor specific logical functions.
. The FE model SHOULD be able to support minimal set of logical
functions that are already identified, such as port functions,
forwarding functions, QoS functions, filtering functions,
high-touch functions, security functions, vendor-specific
functions and off-loaded functions.
3. State Model versus Capability Model
Since the motivation of an FE model is to allow the CEs later to
control and configure the FEs' behavior via ForCES protocol, it
Yang, et al. Expires Dec 2003 [Page 4]
Internet Draft ForCES FE Functional Model June 2003
becomes essential to examine and understand what kind of control
and configuration the CEs might do to the FEs. It is also equally
essential to understand how configurable or programmable FEs are
today and will be in the near future.
To understand the issue better, it is helpful to make a distinction
between two different kinds of FE models û an FE state model and FE
capability model.
An FE state model describes the current state of the FE, that is,
the instantaneous values or operational behavior of the FE. The FE
state model presents the snapshot view of the FE to the CE. For
example, using an FE state model, an FE may be described to its CE
as the following:
- on a given port the packets are classified using a given
classification filter;
- the given classifier results in packets being metered in a
certain way, and then marked in a certain way;
- the packets coming from specific markers are delivered into a
shared queue for handling, while other packets are delivered to a
different queue;
- a specific scheduler with specific behavior and parameters will
service these collected queues.
On the other hand, the FE capability model describes the
configurable capabilities and capacities of an FE in terms of
variations of functions supported or limitations contained.
Conceptually FE capability model presents the many possible states
allowed on an FE with capacity information indicating certain
quantitative limits or constraints. For example, an FE capability
model may describe the FE at a coarse level such as:
- this FE can handle IPv4 and IPv6 forwarding;
- this FE can perform classification on the following fields:
source IP address, destination IP address, source port number,
destination port number, etc;
- this FE can perform metering;
- this FE can handle up to N queues (capacity);
- this FE can add and remove encapsulating headers of types
including IPSec, GRE, L2TP.
The information on the capabilities and capacities of the FE helps
the CE understand the flexibility of the FE functions. Where it
gets more complicated is for the capability model to cope with the
detailed limits, issues such as how many classifiers the FE can
handle, how many queues, and how many buffer pools the FE can
support, how many meters the FE can provide.
Yang, et al. Expires Dec 2003 [Page 5]
Internet Draft ForCES FE Functional Model June 2003
While one could try to build an object model for representing
capabilities in full, other efforts have found this to be a
significant undertaking. A middle of the road approach is to define
coarse-grained capabilities and simple capacity measures. Then, if
the CE attempts to instruct the FE to set up some specific behavior
it is not capable of, the FE will return an error indicating the
problem. Such an approach is taken by RFC3318 in defining a set of
Provisioning Classes (PRCs) for Framework Policy Information Base
(PIB). For example, in Section 4.1 of RFC3318, a ôComponent
Limitations Tableö is described so that ôthe PEP can report some
limitations of attribute values and/or classes and possibly
guidance values for the attributeö. Similar approach is also taken
in Differentiated Services QoS Policy Information Base [RFC3317].
The DiffServ QoS PIB includes capability reporting classes for
individual devices, like classification capabilities, metering
capabilities, etc. Two additional classes are also defined to allow
specification of the element linkage capabilities of the PEP: the
dsIfElmDepthCaps PRC indicates the maximum number of functional
datapath elements that can be linked consecutively in a datapath;
while the dsIfElmLinkCaps PRC indicates what functional datapath
elements may follow a specific type of element in a datapath. Such
capability reporting classes in the DiffServ and Framework PIB are
all meant to allow the PEP to indicate some general guidelines
about what the device can do. They are intended to be an aid to
the PDP when it constructs policy for the PEP. These classes do
not necessarily allow the PEP to indicate every possible
configuration that it can or cannot support. If a PEP receives a
policy that it cannot implement, it must notify the PDP with a
failure report.
Figure 1 shows the concepts of FE state, capabilities, capacities
and configuration in the context of CE-FE communication via ForCES
protocol.
It is clear to us that in the context of ForCES, a state model is
definitely necessary but not sufficient. A simple state model
without any capability flavor will severely limit ForCESÆs ability
to take advantage of the flexibility offered by programmable FEs.
The question is how much of the capability model is needed in
addition to the state model. As we discussed previously, a
detailed capability model is difficult to develop and may impose
unnecessary overhead for those FEs that donÆt have much flexibility
in their capability. We believe that a good balance between
simplicity and flexibility can be achieved for ForCES FE model by
taking the similar approach as demonstrated by DiffServ
PIB[RFC3317] and Framework PIB[RFC3318] û that is, by combining the
coarse level capability reporting mechanism for both the individual
Yang, et al. Expires Dec 2003 [Page 6]
Internet Draft ForCES FE Functional Model June 2003
FE functions and linkage constraints with the error reporting
mechanism.
+-------+ +-------+
| | FE capabilities/capacity: what it can be.| |
| |<-------------------------------------- --| |
| | | |
| CE | FE state: what it is now. | FE |
| |<-----------------------------------------| |
| | | |
| | FE configuration: what it should be. | |
| |----------------------------------------->| |
+-------+ +-------+
Figure 1. Illustration of FE state, capabilities, capacities and
configuration in the context of CE-FE communication via ForCES.
4. FE Model Concepts: FE Block and FE Block Topology
Conceptually, the FE model presents two levels of information about
the FE. At the first level are the individual FE functions. We
call these individual FE functions FE blocks. The second level of
information that the FE model should present is about how these
individual function are ordered and placed along the datapath to
deliver a complete forwarding plane service. The interconnection
of the FE functions is called ôFE block topologyö.
4.1. FE Blocks
A new terminology ôFE Functional Blockö is used to refer to the
individual FE functions that constitute the very basic units for FE
models. Each FE functional block performs a well-defined action or
computation on the packets passing through it. Upon completion of
such function, either the packets are modified in certain ways
(like decapsulator, marker), or some results are generated and
stored, probably in the form of meta-data (like classifier). Each
FE Block typically does one thing and one thing only. Classifiers,
shapers, meters are all examples of FE blocks. Modeling FE blocks
at such fine granularity allows us to use a small number of FE
blocks to create the higher-order FE functions (like Ipv4
forwarder) precisely, which in turn can describe more complex
networking functions and vendor implementations of software and
hardware.
+----------+
| CE |
Yang, et al. Expires Dec 2003 [Page 7]
Internet Draft ForCES FE Functional Model June 2003
+----------+
| ^
| |
v |
+----------+
Inputs ---> | FE Block | ---> Outputs
(P,M) | | (PÆ,MÆ)
| S |
+----------+
Figure 2. Generic FE Block Layout
An FE Block has inputs, outputs, and a connection to and from the
CE, as shown in Figure 2. The horizontal axis is in the forwarding
plane, and the vertical axis denotes interaction between the
forwarding and control planes. An FE block contains internal state
S, composed of one or both CE->FE configuration; and data created
and managed by the FE itself. An FE Block also has one or more
inputs, each of which takes a packet P, and optionally metadata M;
and produces one or more outputs, each of which carries a packet
PÆ, and optionally metadata MÆ.
Meta-data is data which is associated with the packet in the
network processing device (router, switch, etc), but which is not
sent across the network. CE to FE communication is for
configuration, control and packet injection while FE to CE is for
packet re-direction to the control plane, rmon, accounting
information, errors, etc.
The FE model defines a generic FE block akin to an abstract base
class in object-oriented terminology. The generic FE block contains
basic information like block type and textual description of the
block function. A namespace is used to associate a unique name or
ID with each type of FE block. The namespace must be extensible so
that new logical functions can also be added later to accommodate
future innovation in the forwarding plane.
Based on this generic FE block, each FE logical function is defined
with additional state and capability information pertinent to each
specific function. Typically it is important to specify
information such as:
- how many inputs it takes and what kinds of packets and meta data
it takes for each input;
- how many outputs it produces and what kind of packets and meta
data it emits for each output;
- the packet processing (such as modification) behavior;
Yang, et al. Expires Dec 2003 [Page 8]
Internet Draft ForCES FE Functional Model June 2003
- what information is programmed into it (e.g., LPM list, next hop
list, WRED parameters, etc.) and what parameters among them are
configurable;
- what statistics it keeps (e.g., drop count, CRC error count,
etc.);
- what events it can throw (e.g., table miss, port down, etc.).
These parameters are further described in Section 5, below.
4.2. FE Block Topology
Packets coming into the FE from ingress ports generally flow
through multiple functional blocks before leaving out of the egress
ports. Different packets (or packets from different flows) may take
different datapath inside the same FE and hence perform different
sequences of FE blocks. Such interconnection of the FE blocks as
traversed by the packets is referred to as FE block topology.
It is important to point out that the FE block topology here is the
logical topology that the packets flow through, not the physical
topology as determined by how the FE hardware is laid out. Figure
3(a) shows part of the block topology of one simple FE example.
Three ingress ports are present in the FE and these ports may be of
different type with different characteristics. If we model a
single ingress port function as an FE block, clearly we need a way
to model multiple instances of one FE block with each instance
having separate set of parameters allowed for independent
configuration.
+-------------------------------------------+
| |
+-----------+ | +-----------+ +--------+ |
| | v | |if IP-in-IP | | |
---->| ingress |--------->|classifier |----------->|Decap. |-->+
| ports | | |----+ | |
+-----------+ +-----------+ |others +--------+
|
V
(a) The FE block topology example with a logical loop
instance tables
=================
ingress port classifier Decapsulator
+---+--------+--+ +---+--------+--+ +---+-----------+
|id |IP Addr |à | |id |#filters|à | |id | à |
+---+--------+--+ +---+--------+--+ +---+-----------+
|1 |x.x.x.x |à | |1 |10 |à | |1 | à |
+---+--------+--+ +---+--------+--+ +---+-----------+
Yang, et al. Expires Dec 2003 [Page 9]
Internet Draft ForCES FE Functional Model June 2003
|2 |x.x.x.x |à | |2 |10 |à |
+---+--------+--+ +---+--------+--+
|3 |x.x.x.x |à |
+---+--------+--+
(b) The block instance tables used for such an FE block
topology
+-------+ +-----------+ +------+ +-----------+
| | | |if IP-in-IP | | | |
--->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|->
| ports | | |----+ | | | |
+-------+ +-----------+ |others +------+ +-----------+
|
V
(c) The FE block topology equivalent of (a) without the loop
Figure 3. An FE block topology example with block instance
tables.
Figure 3(a) also shows that it is possible for a packet to flow
through a certain function more than once and hence create a
logical loop in the FE block topology. For example, an IP-in-IP
packet from an IPSec application like VPN may go to the classifier
first and have the classification done based on the outer IP
header; upon being classified as an IP-in-IP packet, the packet is
then sent to a decapsulator to strip off the outer IP header,
followed by the classifier again to perform classification on the
inner IP header. It is clear from Figure 3(a) that such a logical
loop is sometimes necessary and must be properly modeled in the FE
block topology.
To represent the FE block instances, we define an ôFE block
instance tableö associated with each FE block û each row of the
table corresponds to one instance of the block. An instance ID is
needed to distinguish different instances of one block. Multiple
instances of the same block can be configured independently with
different parameters. Figure 3(b) shows the FE block instance
tables for the FE block topology in (a). The instance table of the
ingress ports has 3 rows because there are 3 ingress ports. The
classifier block has two rows, one corresponding to the classifier
instance after the ingress port, while the other row corresponding
to the instance after the decapsulator. The decapsulator has only
one row in its instance table since only one instance of
Yang, et al. Expires Dec 2003 [Page 10]
Internet Draft ForCES FE Functional Model June 2003
decapsulator is used. Each row in the instance table has its own
parameters and so each instance can be configured independently.
A way to model the logical loop to the classifier in Figure 3(a) is
to treat it as if there are two different instances of classifier,
as shown in Figure 3(c).
While there is little doubt that the individual FE blocks must be
configurable, the configurability question becomes complicated and
controversial for FE block topology. To discuss the issue further,
we need to answer the following questions:
1) Is the FE block topology configurable at all? Is that feasible
with todayÆs forwarding plane technology? Even if the CE can
dynamically configure an FE block topology, how can the CE
interpret an arbitrary FE block topology and know what to do
with it?
2) If the FE block topology can be configured by the CE, how do we
model the FE block topology?
LetÆs discuss these questions in the rest of the section.
4.2.1. Configuring FE Block Topology
We believe that the FE block topology should be configurable with
ForCES model because even todayÆs forwarding plane technology can
potentially allow that. As network processors are being used
increasingly in the forwarding plane, much of the packet processing
functions on the FE is implemented in software. As such, the FE
can afford much flexibility and programmability of its
functionality by configuring the software either at runtime or
compile time. It is conceivably feasible for the FE to change its
FE block topology by recompiling the set of the software components
and their chaining order along the datapath. It might be possible
to achieve some of the reconfiguration at runtime. Therefore, we
argue that it is necessary for ForCES to allow FE block topology
configurable in its FE model since it is technically feasible.
For example, a NAT-enabled router may have several line cards (FEs)
that are capable of both NAT (Network Address Translator) functions
and IPv4 Forwarding. Such an FE contain two FE blocks in it: NAT
and IPv4 Forwarder. Depends on where on the network this router is
deployed, the network administrator may decide on different
configuration for the CE to configure the FEs. If the router sits
on the edge of a private address domain, the CE may want to
configure the FEs to perform NAT first and IPv4 Forwarder later so
that the forwarding is done with the correct address space. On the
other hand, if the router sits inside the private address domain,
the CE may want to configure the FEs to perform only the IPv4
Yang, et al. Expires Dec 2003 [Page 11]
Internet Draft ForCES FE Functional Model June 2003
forwarding function and bypass the NAT because the address space is
already translated by the edge router. Therefore, the FEs might be
asked to configure the NAT block as an optional stage in the FE
topologies to accommodate the two deployment scenarios. This is a
very simple example and the switch between these two topologies
could be easily done with a runtime flag in the FE software.
However simple as it is, it does demonstrate the need to allow for
FE block topology configuration.
+-------------+ +--------------+
| | | |
------->| NAT |-------->|IPv4 Forwarder|------>
| | | |
+-------------+ +--------------+
(a) NAT followed by IPv4 Forwarder
+-------------+ +--------------+
| | | |
--->-+ | NAT | +---->|IPv4 Forwarder|------>
| | | | | |
| +-------------+ | +--------------+
| |
+----------->--------+
(b) NAT is skipped and only the forwarder is used
Figure 4. A simple example to configure different FE
topologies.
We want to point out that allowing configurable FE block topology
in FE model does not mandate that all FEs must have such
capability. Even if the FE elects to support block topology
reconfiguration, it is entirely up to the FE designers to decide
how the FE actually implements such reconfiguration. Whether it is
only a simple runtime switch to allow a few choices like in Figure
4, or a much more elaborate reconfiguration as shown later in
Figure 5 possibly supported by recompilation is all implementation
details internal to the FE but outside the scope of FE model. The
purpose of this discussion is to justify the motivation and
necessity of supporting FE block topology configuration in the FE
model, but not to dictate how this should be done inside the FEs.
WeÆve just answered the questions of ôIs it possible to configure
the FE block topology with todayÆs forwarding plane technologyö.
Now it is time to look at the other related question: ôEven if it
is feasible to configure an FE block topology, how can the CE
Yang, et al. Expires Dec 2003 [Page 12]
Internet Draft ForCES FE Functional Model June 2003
interpret an arbitrary FE block topology (presented to it by the
FE) and know what to do with it? Alternatively, how does the CE
know what kind of FE block topology it should use to implement a
particular NE service or application?ö
The example in Figure 4 is too trivial to require much intelligence
at the CE. Figure 5 shows a more comlex example where a QoS-
enabled router has several line cards that have a few ingress ports
and egress ports, a specialized classification chip, a network
processor containing codes for FE blocks like meter, marker,
dropper, counter, mux, queue, scheduler and Ipv4 forwarder. Some of
the FE block topology is already fixed and has to remain static due
to the physical layout of the line cards. For example, all the
ingress ports might be already hard wired into the classification
chip and so all packets must follow from the ingress port into the
classification engine. On the other hand, the blocks on the network
processor are programmable and the order of these blocks can be
changed by recompilation of the codes. There might exist certain
capacity limits and linkage constraints between these blocks.
Examples of the capacity limits might be: there can be no more than
8 meters; there can be no more than 16 queues in one FE; the
scheduler can handle at most up to 16 queues; etc. The linkage
constraints might dictate that classification engine may be
followed by meter, marker, dropper, counter, queue or Ipv4
forwarder, but not scheduler; queues can only be followed by
scheduler; scheduler must be followed by the Ipv4 forwarder; the
last block in the datapath before going into the egress ports must
be the Ipv4 forwarder, etc.
Once the FE reports such capability and capacity to the CE, it is
now up to the CE to translate the QoS policy into the desirable
configuration for the FE. Now the question arises as to whether or
not the CE has the ultimate intelligence to translate high level
QoS policy into the configuration data for the FEs. We argue that
this question is outside of the scope of FE model itself. It is
possible that some human intervention is still necessary. For
example, the network administrator might be called upon to
translate the high level QoS policy into the configurable FE data
(including the block topology) that the CE uses to configure the
line cards. It is also conceivable that within a given network
service domain (like DiffServ), certain amount of intelligence can
be programmed into the CE such that the CE has a general
understanding of the FE blocks involved and so the translation from
high level QoS policy to the low level FE configuration can be done
automatically. In any event, this is considered implementation
issue internal to the control plane only and outside the scope of
Yang, et al. Expires Dec 2003 [Page 13]
Internet Draft ForCES FE Functional Model June 2003
the FE model. Therefore, it is not discussed any further in this
draft.
Figure 5(a) depicts the FE capability while 4(b) and 4(c) depict
two different topologies that the FE might be asked to configure
into. Note that both ingress and egress are omitted in (b) and (c)
for simplicity in the figures. The topology in (b) is considerably
more complex than (c) but both are feasible with the FE
capabilities, and so the FE should accept either configuration
request from the CE.
As demonstrated in the example shown in Figure 5, many variants of
the FE block topology come directly from the configuration of the
individual FE blocks. For example, the number of datapath branches
from the classifier is determined by the number of filters used by
the classifier. Figure 5(b) uses four filters so there are four
main datapath branches fan out from the classifier while 4(c) uses
only two filters resulting two datapath fan-out. Each datapath is
further configured by configuring the FE blocks along the path.
+----------+ +-----------+
| | | |
---->| Ingress |---->|classifier |--------------+
| | |chip | |
+----------+ +-----------+ |
|
v
+-------------------------------------------+
| Network Processor |
+--------+ | |
<----| Egress | | +------+ +------+ +-------+ +---+ |
+--------+ | |Meter | |Marker| |Dropper| |Mux| |
^ | +------+ +------+ +-------+ +---+ |
| | |
+----------+-------+ |
| | |
| +---------+ +---------+ +------+ +---------+ |
| |Forwarder|<------|Scheduler|<--|Queue | |Counter | |
| +---------+ +---------+ +------+ +---------+ |
| |
|--------------------------------------------------------------+
(a) The Capability of the FE, reported to the CE
Queue1
+---+ +--+
| A|------------------->| |--+
Yang, et al. Expires Dec 2003 [Page 14]
Internet Draft ForCES FE Functional Model June 2003
+->| | | | |
| | B|--+ +--+ +--+ +--+ |
| +---+ | | | | | |
| Meter1 +->| |-->| | |
| | | | | |
| +--+ +--+ | Ipv4
| Counter1 Dropper1 Queue2| +--+ Fwd.
+---+ | +--+ +--->|A | +-+
| A|---+ | |------>|B | | |
------>| B|------------------------------>| | +--->|C |->| |->
| C|---+ +--+ | +->|D | | |
| D|-+ | | | +--+ +-+
+---+ | | +---+ +---+ Queue3| | Scheduler
Classifier1 | | | A|------------>|A | +--+ | |
| +->| | | |->| |--+ |
| | B|--+ +--+ +->|B | | | |
| +---+ | | | | +---+ +--+ |
| Meter2 +->| |-+ Mux1 |
| | | |
| +--+ Queue4 |
| Marker1 +--+ |
+---------------------------->| |----+
| |
+--+
(b) One FE block topology as configured by the CE and
accepted by the FE
+-----+ +-------+ +---+
| A|--->|Queue1 |--------------------->| |
------>| | +-------+ | | +---+
| | | | | |
| | +-------+ +-------+ | | | |
| B|--->|Meter1 |----->|Queue2 |------>| |->| |
| | | | +-------+ | | | |
| | | |--+ | | | |
+-----+ +-------+ | +-------+ | | +---+
classifier +-->|Dropper| | | IPv4
+-------+ +---+ Fwd.
scheduler
(c) Another FE block topology as configured by the CE
and accepted by the FE
Figure 5. Another example of configuring FE block topology.
Yang, et al. Expires Dec 2003 [Page 15]
Internet Draft ForCES FE Functional Model June 2003
4.2.2. Modeling FE Block Topology
Now that weÆve seen some examples of how FE block topology can be
configured, we need to focus on the question as how to model the FE
block topology traversed by the packets. As discussed below, there
exist two different approaches in modeling the FE block topology.
. Directed Graph Topological Approach
An FE stage is simply an instance of an FE block within an FE's
datapath. As a packet flows through an FE along a datapath, it
flows through one or multiple distinct stages, with each stage
instantiating a certain FE logical function. So an FE stage is
simply a row in the ôFE block instance tablesö corresponding to the
block type of the stage. Each FE allocates an FE-unique stage ID
to each of its stages. One way to assign the stage ID is to
combine both the block-type namespace and the instance ID in the
instance table.
The FE block topology can then be modeled by a directed graph
interconnecting all the FE stages present in the FE, with each node
in the graph corresponding to an FE stage, and the direction
between two nodes coinciding with the packet flow direction. In
order to represent the directed interconnection between two
consecutive nodes along a datapath, each stage contains a field
called ônumber of downstream stagesö and an array of ôdownstream
stage IDsö that point to the set of downstream nodes following this
stage. Such a modeling approach directly models the datapath
topological graph of the FE stages and so we refer to it as the
directed graph topological approach.
For such a directed graph topological approach, the following
information needs to be specified for each FE stage in the graph:
- stage identifier which uniquely identifies the node within this
FE graph;
- block type which identifies the block function that this stage is
an instance of;
- number of downstream stages which corresponds to the number of
downstream nodes connected to this stage;
- downstream stage identifiers which corresponds to the set of
downstream nodes connected to this stage.
Such information can be combined into the rows of the ôFE block
instance tableö for each FE block type present on the FE. With
Yang, et al. Expires Dec 2003 [Page 16]
Internet Draft ForCES FE Functional Model June 2003
such information defined for each row in the instance table, it is
now possible to traverse the whole graph in a node-by-node fashion
following the linked list, as long as the initial stage(s) are
known. For example, the topology model for Figure 5(c) is shown in
Figure 6. It is assumed that the FE has four ingress ports and two
egress ports. The stage id is assigned to have the format of
ôxx.yyö where xx being the block type name while yy being the
instance id of that stage in the instance table of type xx. The
following shorthand are used for FE block type namespace:
IG=Ingress-port; CL=classifier; EG=egress-port; QU=queue; MT=meter;
DR=dropper; SC=scheduler; and FW=Forwarder.
In Figure 6, by starting from the initial stages of {IG.1; IG.2;
IG.3; IG.4} and using the instance tables, all the datapath in the
FE block topology can be easily traversed. From this example, it is
clear that directed graph topological approach is straightforward
and graphical, and hence easy to understand and implement. DiffServ
[RFC3317] uses this approach in modeling its QoS functions and
their interconnection. However, such approach has certain
limitations. One of the limitations is that there exists an
implicit assumption within such a model that each node affects the
datapath branching only for the next immediate stage. For example,
in Figure 5(c), the classifier directs packets into either queue1
or meter1, but once the packets enter meter1, the classification
results have no impact on which of the two branches leaving meter1
(i.e., queue2 or dropper) is being taken. While this limitation
might be perfectly reasonable for many FE designs, some find it
insufficient. For example, some of the classification engine uses
the classification results to determine the full datapath, i.e.,
not just the immediate stage following the classifier, but
including all the following FE stages the packets should perform.
It is difficult to represent such FE design using the pure directed
graph topological approach. An alternative approach, encoded state
approach, is more suitable in this case because it carries meta-
data between the stages.
Instance tables:
================
IG CL QU
+---+-----+----+ +---+-----+---------+ +---+-----+----+
|id |#next|next| |id |#next|next | |id |#next|next|
+---+-----+----+ +---+-----+---------+ +---+-----+----+
|1 | 1 |CL.1| |1 |2 |QU.1;MT.1| |1 |1 |SC.1|
+---+-----+----+ +---+-----+---------+ +---+-----+----+
|2 | 1 |CL.1| |2 |1 |SC.1|
+---+-----+----+ +---+-----+----+
|3 | 1 |CL.1|
Yang, et al. Expires Dec 2003 [Page 17]
Internet Draft ForCES FE Functional Model June 2003
+---+-----+----+
|4 | 1 |CL.1|
+---+-----+----+
DR MT EG
+---+-----+----+ +---+-----+---------+ +---+-----+----+
|id |#next|next| |id |#next|next | |id |#next|next|
+---+-----+----+ +---+-----+---------+ +---+-----+----+
|1 | 0 | | |1 |2 |QU.2;DR.1| |1 |0 | |
+---+-----+----+ +---+-----+---------+ +---+-----+----+
|2 |0 | |
+---+-----+----+
SC FW
+---+-----+----+ +---+-----+---------+
|id |#next|next| |id |#next|next |
+---+-----+----+ +---+-----+---------+
|1 | 1 |FW.1| |1 |2 |EG.1;EG.2|
+---+-----+----+ +---+-----+---------+
Directed Graph:
===============
Traverse the graph by starting from {IG.1;IG.2;IG.3;IG.4}.
*Notes:
1) The fields shown in the instance tables are only the fields
common to all: id (instance ID); #next (number of immediate next
stages); next (the instance IDs of all the immediate next
stages). The parameters pertinent to each block type are not
shown in the instance tables because they do not affect the
topology modeling.
2) The stage id is assigned to have the format of ôxx.yyö where xx
being the block type name while yy being the instance id of that
stage in the instance table of type xx.
3) The following shorthand are used for FE block type namespace:
IG=Ingress-port; CL=classifier; EG=egress-port; QU=queue;
MT=meter; DR=dropper; SC=scheduler; and FW=Forwarder.
Figure 6. Using the directed graph approach to model the FE
block topology in Figure 5(c).
. Encoded State Approach
In addition to the topological approach, the QDDIM model also
adopts the encoded state approach so that information about the
Yang, et al. Expires Dec 2003 [Page 18]
Internet Draft ForCES FE Functional Model June 2003
treatment that a packet received on an ingress interface is allowed
to be communicated along with the packet to the egress interface
(see [QDDIM] Section 3.8.3). QDDIM model represents this
information transfer in terms of a packet preamble.
+----------------+
| Meter-A |
| |
----->| In -|-----PM-1--->
| |
| Out -|-----PM-2--->
+----------------+
Figure 7: Meter Followed by Two Preamble Markers
Figure 7 shows an example used in [QDDIM] (section 3.8.3) in which
meter results are captured in a packet preamble. ôPreamberMarker
PM-1 adds to the packet preamble an indication that the packet
exited Meter A as conforming traffic. Similarly, PreambleMarker PM-
2 adds to the preambles of packets that come through it indications
that they exited Meter A as nonconforming traffic. A PreambleMarker
appends its information to whatever is already present in a packet
preamble, as opposed to overwriting what is already there.ö ôTo
foster interoperability, the basic format of the information
captured by a PreambleMarker is specified.ö ôOnce a meter result
has been stored in a packet preamble, it is available for any
subsequent Classifier to use.ö
In the example of Figure 5(c), if the results from classifier are
to impact all the following stages, even beyond the immediate next
stage, encoded state approach should be used so that meta-data is
inserted representing the results from classifier and is made
available to all following stages.
+------------+ +------------+ +------------+
input | Ethernet | | | | Ethernet |output
------->| Ingress |-->| IPv4 L3 LPM|-->| Egress |---->
| Port Mgr | | Forwarder | | Port Mgr |
+------------+ +------------+ +------------+
(a) using encoded state approach
Input +------------+ +------------+ output
------->|Ingr-Port #1|-->| |
+------------+ | | +------------+
------->|Ingr-Port #2|-->| |-->|EgressPort#1|----->
Yang, et al. Expires Dec 2003 [Page 19]
Internet Draft ForCES FE Functional Model June 2003
+------------+ | | +------------+
------->|Ingr-Port #3|-->|IPv4 L3 LPM |-->|EgressPort#2|----->
+------------+ |Forwarder | +------------+
------->|Ingr-Port #4|-->| |-->|EgressPort#3|----->
+------------+ | | +------------+
------->|Ingr-Port #5|-->| |-->|EgressPort#4|----->
+------------+ | | +------------+
------->|Ingr-Port #6|-->| |
+------------+ +------------+
(b) using directed graph topological approach
Figure 8. A simple example using two different approaches.
Using the topological approach as exemplified by DiffServ model,
there are N connections between a fan-out node of 1:N (e.g., a
classifier) and its next stages. Using the encoded state approach,
fewer connections are typically needed between the same fan-out
node and its next stages, because each packet carries some state
information as metadata that the next stage nodes can interpret and
invoke different packet treatment. Pure topological approaches can
be overly complex to represent because they force on to build
elaborate topologies with a lot more connections. An encoded state
approach is nicer in that it allows one to simplify the graph and
represent the functional blocks with more clarity. But it does
require extra metadata to be carried along with the packet, like
the preamble in the QDDIM model.
For example in Figure 8(a), IPv4 L3 LPM forwarder generates some
metadata at its output to carry information on which port the
packets should go to, and #3 (Enet-Egress-port-Manager) uses this
meta data to direct the packets to the right egress port. Figure
8(b) shows how the FE graph looks like when using the pure
topological approach instead, assuming six ingress and four egress
ports. It is clear that (b) is unwieldy compared to (a).
Note that the FE graph can represent largely arbitrary topologies
of the stages, regardless which approach (topological or encoded
state) is taken. Clearly the two approaches are not exclusive.
For complex topologies, a combination of the two is most useful and
flexible. Therefore, we recommend that the ForCES FE model adopt
both approaches. More specifically, the directed graph topological
approach should be used as the basic model, while the encoded state
approach can be used as optional, when meta-data is needed between
stages beyond the immediate next neighbors.
Yang, et al. Expires Dec 2003 [Page 20]
Internet Draft ForCES FE Functional Model June 2003
5. Logical FE Block Library
A small set of fine-grained FE blocks can be identified as the very
basic units from which all other FE functions can be built upon.
Such a set of FE blocks can be viewed as a FE block library. This
section defines such a library.
Several working groups in the IETF have already done some relevant
work in modeling the provisioning policy data for some of the
functions we are interested in, for example, DiffServ
(Differentiated Services) PIB [RFC3317], IPSec PIB [IPSEC-PIB].
Whenever possible, we should try to reuse the work done elsewhere
instead of reinventing the wheel.
FE blocks may be characterized into two general classes:
input/output oriented blocks, and processing blocks. Each class is
composed of a number of sub-blocks, and the combination of classes
and sub-blocks can completely characterize FE functions.
The FE input/output blocks are characterized by their inputs and
outputs, and they generally do not modify or further process the
data that they handle. The FE processing blocks are characterized
by the manner in which they modify the packet, metadata, or
internal state, independent of how that information is input into
the block.
5.1. FE Input/Output Block Characterization
The FE input/output blocks are characterized by the following
elements:
- number of inputs
- number of outputs
These blocks do not modify or examine the packet in any way.
5.1.1. Source Block
A source block has no inputs, and one output. It ôsourcesö events
from the external world into the FE model.
The purpose of the source block is to allow the model to explicitly
interact with objects that are outside of the model. That is, an
Ethernert port that injects packets into the FE may be modeled as a
ôsourceö block, as from the point of view of the model, it creates
Yang, et al. Expires Dec 2003 [Page 21]
Internet Draft ForCES FE Functional Model June 2003
packets out of the ôetherö, and outside of the scope of the model.
See also the FE Port block below, in Section 5.1.3.
5.1.2. Sink Block
A sink block has one input, and no outputs. It ôsinksö events from
the FE model into the external world.
The purpose of the sink block is to allow the model to explicitly
interact with objects that are outside of the model. That is, and
Ethernet port that sends packets from an FE may be modeled as a
ôsinkö block, as from the point of view of the model, it sends
packets into the ôetherö, and outside of the scope of the model.
See also the FE Port block below, in Section 5.1.3.
5.1.3. Port Block
An FE Port Block is used to describe specific sinks or sources. An
FE Source Block may source events other than packets, such as TCP
timers. An FE Source block may also not require complex
configuration. In addition, the model should be able to map both
sources and sinks onto one logical block which models a port that
implements those functions. For these reasons, it is useful to
define a Port Block separately from the previously defined Source
and Sink blocks, even though there is some overlap between them.
The FE Port Block contains a number of configurable parameters,
which may include, but are not limited to, the following items:
- the number of ports on the FE;
- the sub-interfaces if any;
- the static attributes of each port (e.g., port type, direction,
link speed);
- the configurable attributes of each port (e.g., IP address,
administrative status);
- the statistics collected on each port (e.g., number of packets
received);
- the current status (up or down).
5.1.4. Dropper Block
A dropper block has one input, and no outputs. It discards all
packets that it receives without any modification or examination of
those packets.
Yang, et al. Expires Dec 2003 [Page 22]
Internet Draft ForCES FE Functional Model June 2003
The purpose of a dropper block is to allow the description of
ôsinksö within the model, where those sinks do not result in the
packet being sent into any object external to the model.
5.1.5. MUX Block
A mux block has N inputs, and one output. It multiplexes packets
from the inputs onto its output.
5.1.6. Redirector (de-MUX) Block
A redirector block has one input, and N outputs. It is the inverse
a MUX block.
The redirector block takes an input packet P, and uses the metadata
M to redirect that packet to one or more of N outputs, e.g. Most
commonly unicast forwarding, multicast, or broadcast.
5.1.7. Shaper Block
A shaper block has one input, and one output. It takes input
packets and metadata at some time t, and outputs the packet and
(possibly updated) metadata at some other time, tÆ. The packet is
not examined or modified during this process.
The meta-data is used to determine how to shape the outgoing
traffic. The packet and metadata are conceptually added to the
internal state S of the block when the packet is received, and are
removed from that internal state when the packet is output from the
block.
5.2. FE Processing Blocks
An FE processing block may be characterized by four parameters:
P û the packet that it is processing
t û the time at which that packet is being processed
M û the metadata that is associated with that packet
S û the internal state of the block
(including any CE->FE configuration, and any internal FE
data)
Yang, et al. Expires Dec 2003 [Page 23]
Internet Draft ForCES FE Functional Model June 2003
We do not model or describe how any of these parameters arrive at
the block. Instead, we characterize the blocks by how they process
those parameters.
5.2.1. Counter Block
A counter block updates its internal state S, by counting packets,
or metadata. The packet is not modified, and the metadata may, or
may not, be modified.
A counter block is independent of time ætÆ, in that it does not
perform any time-dependent counting. The time at which a count is
made may, however, be associated with that count.
5.2.2. Meter Block
A meter block is a counter block that is time dependent. That is,
it meters the rate over time at which packets or metadata flow
through the block.
5.2.3. Filter Block
According to [DiffServ], "a filter consists of a set of conditions
on the component values of a packet's classification key (the
header values, contents, and attributes relevant for
classification)ö.
That is, a filter block examines the packet without modifying it,
and uses its internal state S to make decisions about the packet.
The result of that examination is that the filter block creates new
metadata ômatchö, or ôno matchö to associate with that packet,
depending on whether the packet matched, or did not match, the
conditions of the filter.
A filter block may be viewed as a special case of a classifier
block. Alternately, a classifier block may be viewed as consisting
of multiple filter blocks.
5.2.4. Classifier Block
A classifier block uses its internal state S to classify the packet
into one of N different logical classes. That is, it takes an
input packet and meta-data, and produces the same packet with new
or more meta-data. A classifier is parameterized by filters.
Classification is done by matching the contents of the incoming
packets according to the filters, and the result of classification
is produced in the form of metadata. Note that this classifier is
Yang, et al. Expires Dec 2003 [Page 24]
Internet Draft ForCES FE Functional Model June 2003
modeled solely based on its internal processing, and not on its
inputs and outputs. It is a single-exit classifier that does NOT
physically redirect the packet. In contrast, a DiffServ-like
classifier is a 1:N (fan-out) device: It takes a single traffic
stream as input and generate N logically separate traffic streams
as output. That kind of multi-exit classifier can be modeled by
combining this classifier with a redirector (see Section 5.1.5).
Note that other FE Blocks MAY perform simple classification on the
packet or metadata. The purpose of the FE Classifier Block is to
model a block that ôdigestsö large amounts of input data (packet,
metadata), to produce a ôsummaryö of the classification results, in
the form of additional metadata. Other FE Blocks can then use this
summary information to quickly and simply perform trivial
ôclassificationsö.
The requirement for a unique and separate FE Classifier Block comes
about because it would not make sense to model a classifier block
inside each of every other block. Such a model would be highly
redundant. We therefore specifically model a complex
classification block, and explicitly state that other blocks may
make decisions based on the parameters S, t, and M, but not on P.
5.2.5. Redirecting Classifier Block
This block is logically a combination of the FE Classifier Block in
Section 5.2.4, and the FE Redirector Block in Section 5.1.6. It
uses its internal classification rules to redirect the input packet
P to one or more outputs.
Its purpose is to allow the ôatomicö modeling of classification
with redirection. If this block was described as two blocks, then
the model would be required to describe the format and
interpretation of the metadata. As there is not yet consensus on
the format and interpretation of metadata, it is preferable to
define an additional block which allows us to avoid most of that
contention.
It is expected that once there is experience with using the FE
model and blocks defined here, that we may reach consensus on the
format and interpretation of the metadata. At that time, we may
revisit the definition of this block, and may choose to remove it
due to redundancy with previously defined blocks.
5.2.6. Modifier Block
Yang, et al. Expires Dec 2003 [Page 25]
Internet Draft ForCES FE Functional Model June 2003
A modifier block modifies incoming packets and sends them out. This
is a generic ôcatch-allö block for packet processing which is not
modeled in one of the other blocks. Usually the meta-data is used
to determine how to modify the packet.
This block is defined in a generic manner, and we expect that
specific examples of packet and/or metadata modification will be
described as below, with named sub-classes of the modifier block.
5.2.7. Packet Header Rewriter Block
This block is a sub-class of the Modifier Block. It is used to re-
write fields on the packet header, such as Ipv4 TTL decrementing,
checksum calculation, or TCP/IP NAT.
5.2.8. Packet Compression/Decompression Block
This block is a sub-class of the Modifier Block. It is used to
compress or decompress packet data, such as with Ipv4 Van Jacobson
header compression.
It may be useful to split this block into separate compression and
decompression blocks. This decision should be made after we have
more experience with the model.
5.2.9. Packet Encryption/Decryption Block
This block is a sub-class of the Modifier Block. It is used to
encrypt or decrypt packet data, such as with TLS.
It may be useful to split this block into separate encryption and
decryption blocks. This decision should be made after we have more
experience with the model.
5.2.10. Packet Encapsulation/Decapsulation Block
This block is a sub-class of the Modifier Block. It is used to
encapsulate or decapsulate packet data, such as with IP in IP.
It may be useful to split this block into separate encapsulation
and decapsulation blocks. This decision should be made after we
have more experience with the model.
Yang, et al. Expires Dec 2003 [Page 26]
Internet Draft ForCES FE Functional Model June 2003
6. Minimal Set of Logical Functions Required for FE Model
A minimum set of FE functions is defined in [FORCES-REQ] that must
be supported by any proposed FE model. In this section, we
demonstrate how the small FE block library defined in Section 5 can
be used to model all the logical functions required in [FORCES-
REQ].
6.1. QoS Functions
The IETF community has already done some work in modeling the QoS
functions in the datapath. The IETF DiffServ working group has
defined an informal data model [RFC3290] for QoS-related functions
like classification, metering, marking, actions of marking,
dropping, counting and multiplexing, queueing, etc. The latest work
on DiffServ PIB (Policy Information Base) [RFC3317] defines a set
of provisioning classes to provide policy control of resources
implementing the Diferentiated Services Architecture. DiffServ PIB
also has an element of capability flavor in it. The IETF Policy
Framework working group is also defining an informational model
[QDDIM] to describe the QoS mechanisms inherent in different
network devices, including hosts. This model is intended to be used
with the QoS Policy Information Model [QPIM] to model how policies
can be defined to manage and configure the QoS mechanisms present
in the datapath of devices.
Here is a list of QoS functional blocks that should be supported
directly in the library or indirectly via combination of the FE
blocks in the library:
. Classifier
. Meter
. Marker
. Dropper
. Counter
. Queue and Scheduler
. Shaper
6.1.1. Classifier
There are two ways to define a classifier block: single-exit
classifier or multi-exit classifier.
Yang, et al. Expires Dec 2003 [Page 27]
Internet Draft ForCES FE Functional Model June 2003
A single-exit classifier follows the QDDIM model. It takes an input
packet and meta-data, and produces the same packet, with new/more
meta-data. Such a single-exit classifier does not physically
redirect the packets. It only decides which meta-data to associate
with the packet and such meta-data can be used by later blocks to
physically redirect the packets.
A multi-exit classifier, on the other hand, follows the DiffServ
model. It is equivalent of a single-exit classifier followed by a
redirector. Such a classifier directs packets to different output
paths.
6.1.2. Meter
Meter is directly defined in the FE Block library.
6.1.3. Marker
Marker can be modeled as a special kind of FE Modifier Block.
6.1.4. Dropper
Dropper is directly defined in the FE Block library.
6.1.5. Counter
Counter is directly defined in the FE Block library.
6.1.6. Queue and Scheduler (?)
6.1.7. Shaper
Shaper is directly defined in the FE Block library.
6.2. Generic Filtering Functions
A combination of classifier, redirector, modifier etc. can model
complex set of filtering functions. For example, Figure 9
represents a filtering function that classifies packets into one of
two logical classes: forward, and drop. These logical classes are
represented as meta data M1, and M2. The re-director uses this
meta data to re-direct the packet to one of two outputs. The first
sinks the packet back into the network. The second silently drops
the packets.
classifier -> redirector ---M1--- sink
\
Yang, et al. Expires Dec 2003 [Page 28]
Internet Draft ForCES FE Functional Model June 2003
\-M2--- dropper
Figure 9. A filtering function example.
6.3. Vendor Specific Functions
New and currently unknown FE functionality can be derived (i.e.,
extended) based on the generic FE Block. The name space used to
identify the FE block type must be extensible such that new logical
functions can be defined and added later to accommodate future
innovation in forwarding plane, as long as the new functions are
modeled as an FE block.
6.4. Port Functions
Every FE contains a certain number of interfaces (ports), including
both the inter-NE interfaces and intra-NE interfaces. The inter-NE
interfaces are the external interfaces for the NE to
receive/forward packets from/to the external world. The intra-NE
interfaces are used for FE-FE or FE-CE communications. Same model
should be used for both the inter-FE and intra-FE interfaces, but
it is necessary to make the distinction between the two known to
the CE so that the CE can do different configuration.
Certain types of physical ports have sub-interfaces (frame relay
DLCIs, ATM VCs, Ethernet VLans, etc.) as virtual or logical
interfaces. Some implementations treat tunnels (e.g., GRE, L2TP,
IPSec, MPLS, etc.) as interfaces, while others do not. [FORCES-REQ]
treats tunneling as high-touch functions and so FE model does not
model tunneling as part of the port functions. Instead, tunneling
is covered in Section 6.6.
6.5. Forwarding Functions
Support for IPv4 and IPv6 unicast and multicast forwarding
functions must be provided by the model.
Typically, the control plane maintains the Routing Information Base
(RIB), which contains all the routes discovered by all the routing
protocols with all kinds of attributes relevant to the routes. The
forwarding plane uses a different database, the Forwarding
Information Base (FIB), which contains only the active subset of
those routes (only the best routes chosen for forwarding) with
attributes that are only relevant for forwarding. A component in
the control plane, termed Route Table Manager (RTM), is responsible
to manage the RIB in the CE and maintain the FIB used by the FEs.
Therefore, the most important aspect in modeling the forwarding
Yang, et al. Expires Dec 2003 [Page 29]
Internet Draft ForCES FE Functional Model June 2003
functions is the data model for the FIB. The model also needs to
support the possibility of multiple paths.
At the very minimum, each route in the FIB needs to contain the
following layer-3 information:
- the prefix of the destination IP address;
- the length of the prefix;
- the number of equal-cost multi-path;
- the next hop IP address and the egress interface for each path.
Another aspect of the forwarding functions is the method to resolve
a next hop destination IP address into the associated media
address. There are many ways to resolve Layer 3 to Layer 2 address
mapping depending upon link layer. For example, in case of Ethernet
links, the Address Resolution Protocol (ARP, defined in RFC 826) is
used for IPv4 address resolution.
Assuming a separate table is maintained in the FEs for address
resolution, the following information is necessary for each address
resolution entry:
- the next hop IP address;
- the media address.
Different implementation may have different ways to maintain the
FIB and the resolution table. For example, a FIB may consist of two
separate tables, one to match the prefix to the next hop and the
other to match the next hop to the egress interface. Another
implementation may use one table instead. Our approach of using
the fine-grained FE blocks to model the forwarding functions allow
such flexibility.
For example, a combination of a classifier, followed by a modifier
and a redirector can model the forwarding function.
6.6. High-Touch Functions
High-touch functions are those that take action on the contents or
headers of a packet based on content other than what is found in
the IP header. Examples of such functions include NAT, ALG,
firewall, tunneling and L7 content recognition.
The ForCES working group first needs to agree upon a small set of
common high-touch functions with well-defined behavior to be
included in the initial FE block library. Here is a list of
candidate blocks:
. NAT
. Firewall
Yang, et al. Expires Dec 2003 [Page 30]
Internet Draft ForCES FE Functional Model June 2003
. Encapsulator
. Decapsulator
NAT, Encapsulator, Decapsulator are all different examples of the
modifier FE block; while firewall can be modeled as a filtering
function (Section 6.2).
6.7. Security Functions
The FE model must be able to describe the types of encryption
and/or decryption functions that an FE supports and the associated
attributes for such functions. In general, encyption and decryption
can be modeled by modifier.
IP Security Policy (IPSP) Working Group in the IETF has started
work in defining the IPSec Policy Information Base [IPSEC-PIB].
Further study on this is needed to determine whether it can be
reused here and any other additional work is needed.
6.8. Off-loaded Functions
In addition to the packet processing functions that are typical to
find on the FEs, some logical functions may also be executed
asynchronously by some FEs, according to a certain finite-state
machine, triggered not only by packet events, but by timer events
as well. Examples of such functions include finite-state machine
execution required by TCP termination or OSPF Hello processing off-
loaded from the CE. The FE model must be capable of expressing
these asynchronous functions, so that the CE may take advantage of
such off-loaded functions on the FEs.
The ForCES working group first needs to agree upon a small set of
such off-loaded functions with well-understood behavior and
interactions with the control plane.
7. Cascading Multiple FEs
An FE may contain zero, one or more external ingress ports.
Similarly, an FE may contain zero, one or more external egress
ports. In another word, not every FE has to contain any external
ingress or egress interfaces. For example, Figure 10 shows two
cascading FEs. FE #1 contains one external ingress interface but
no external egress interface, while FE #2 contains one external
egress interface but no ingress interfce. It is possible to
connect these two FEs together via their internal interfaces to
achieve the complete ingress-to-egress packet processing function.
Yang, et al. Expires Dec 2003 [Page 31]
Internet Draft ForCES FE Functional Model June 2003
This provides the flexibility to spread the functions across
multiple FEs and interconnect them together later for certain
applications.
+-----------------------------------------------------+
| +---------+ +------------+ +---------+ |
input| | | | | | output |
---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+
| | port | |Decompressor| |Forwarder| FE | |
| +---------+ +------------+ +---------+ #1 | |
+-----------------------------------------------------+ V
|
+-----------------------<-----------------------------+
|
| +----------------------------------------+
V | +------------+ +----------+ |
| input | | | | output |
+->--+->|Header |-->| Egress |---------+-->
| |Compressor | | port | FE |
| +------------+ +----------+ #2 |
+----------------------------------------+
Figure 10. An example of two different FEs connected together.
While inter-FE communication protocol is out of scope for ForCES,
it is up to the CE to query and understand the FE function and
inter-FE topology for multiple FEs and cascade them together when
necessary to perform a complete ingress-egress packet processing
function, like described in Figure 10.
8. Data Modeling and Representation
A formal data modeling language is needed to represent the
conceptual FE model described in this document and a full
specification will be written using such a data modeling language.
It is also necessary to identify a data representation method for
over-the-wire transport of the FE model data.
The following is a list of some potential candidates for
consideration. For the moment, we intend to leave this as an open
issue and much debate is needed in the ForCES WG before a decision
can be made. Therefore, we only provide the candidate list and some
initial discussion here without drawing a conclusion yet.
- XML (Extensible Markup Language) Schema
- ASN.1 (Abstract Syntax Notation One)
Yang, et al. Expires Dec 2003 [Page 32]
Internet Draft ForCES FE Functional Model June 2003
- SMI (Structure of Management Information) [RFC1155]
- SPPI (Structure of Policy Provisioning Information) [RFC3159]
- UML (Universal Modeling Language)
Most of the candidates here, with the notable exception of UML, are
capable of representing the model in the document and over-the-
wire. Of course, it is also possible to choose one data model
language for specification in the document and later allow several
over-the-wire representations to map the model into different
implementations.
XML has the advantage of being human and machine readable with
widely available tools support. However, it is very verbose and
hence less efficient for over-the-wire transport. It also requires
XML parsing functions in both the CE and FE and hence may impose
large footprint esp. for FEs. Currently XML is not yet widely
deployed and used in network elements. XML for network
configuration in general remains an open area that still requires
substantial investigation and experiment in IETF.
ASN.1 format is human readable and widely used in network
protocols. SMI is based on a subset of ASN.1 and used to define
Management Information Base (MIB) for SNMP. SPPI is the adapted
subset of SMI used to define Policy Information Base (PIB) for
COPS. Substantial investment has been made in SMI/MIBs/SNMP by IETF
and the Internet community collectively has had many years of
design and operation experience with SMI/MIBs/SNMP. However, it is
also well recognized that SMI/MIBs/SNMP is not well suited for
configuration and so SPPI/PIBs/COPS-PR attempts to optimize for
network provisioning and configuration.
UML is the software industryÆs standard language for specifying,
visualizing, constructing and documenting the artifacts of software
systems. It is a powerful tool for data modeling. However, it does
not provide a data representation format for over-the-wire
transport.
9. Security Considerations
The FE model just describes the representation and organization of
data sets and attributes in the forwarding plane. The associated
communication protocol (i.e., ForCES protocol) will be defined in
separate documents and so the security issues will be addressed
there.
10. Intellectual Property Right
Yang, et al. Expires Dec 2003 [Page 33]
Internet Draft ForCES FE Functional Model June 2003
The authors are not aware of any intellectual property right issues
pertaining to this document.
11. IANA consideration
A namespace is needed to uniquely identify the FE block type for
each FE logical function.
12. Normative References
[RFC1812] F. Baker, ôRequirements for IP Version 4 Routers", June
1995.
[RFC1155] M. Rose, et. al., ôStructure and Identification of
Management Informationfor TCP/IP-based Internets", May
1990.
[RFC3084] K. Chan, et. al., ôCOPS Usage for Policy Provisioning,ö
March 2001.
[RFC3159] K. McCloghrie, et. al., ôStructure of Policy Provisioning
Information (SPPI)", August 2001.
[RFC3290] Y. Bernet, et. al., ôAn Informal Management Model for
Diffserv Routersö, May 2002.
[FORCES-REQ] H. Khosravi, et. al., ôRequirements for Separation of
IP Control and Forwarding", work in progress, May 2003,
<draft-ietf-forces-requirements-09.txt>.
13. Informative References
[RFC3317] K. Chan, et. al., ôDifferentiated Services Quality of
Service Policy Information Baseö, March 2003.
[RFC3318] R.Sahita, et. al., ôFramework Policy Information Baseö,
RFC 3318, March 2003.
[QDDIM] B. Moore, et. al., ôInformation Model for Describing
Network Device QoS Datapath Mechanismsö, work in
progress, May 2002, <draft-ietf-policy-qos-device-info-
model-08.txt>.
Yang, et al. Expires Dec 2003 [Page 34]
Internet Draft ForCES FE Functional Model June 2003
[QPIM] Y. Snir, et. al., ôPolicy Framework QoS Information Modelö,
work in progress, Nov 2001, <draft-ietf-policy-qos-
info-model-04.txtö.
[IPSEC-PIB] Man. Li, et. al., öIPsec Policy Information Baseö, work
in progress, January 2003, <draft-ietf-ipsp-ipsecpib-
07.txt>
[IPSEC-MIB] C. Madson, et. al., ôIPsec Flow Monitoring MIBö, work
in progress, March 2003, <draft-ietf-ipsec-flow-
monitoring-mib-02.txt>
14. Acknowledgments
The authors would also like to thank the following individuals for
their invaluable technical input: David Putzolu, Hormuzd Khosravi,
Eric Johnson, David Durham, Andrzej Matejko, T. Sridhar, Jamal
Hadi, Alex Audu.
15. Authors' Addresses
Lily L. Yang
Intel Labs
2111 NE 25th Avenue
Hillsboro, OR 97124, USA
Phone: +1 503 264 8813
Email: lily.l.yang@intel.com
Joel Halpern
P.O.Box 6049
Leesburg, VA 20178, USA
Phone: +1 703 371 3043
Email: jmh@joelhalpern.com
Ram Gopal
Nokia Research Center
5, Wayside Road,
Burlington, MA 01803, USA
Phone: +1 781 993 3685
Email: ram.gopal@nokia.com
Alan DeKok
IDT Inc.
1575 Carling Ave.
Ottawa, ON K1G 0T3, Canada
Yang, et al. Expires Dec 2003 [Page 35]
Internet Draft ForCES FE Functional Model June 2003
Phone: +1 613 724 6004 ext. 231
Email: alan.dekok@idt.com
Yang, et al. Expires Dec 2003 [Page 36]
| PAFTECH AB 2003-2026 | 2026-04-24 01:08:35 |