Internet DRAFT - draft-gopal-forces-femodel
draft-gopal-forces-femodel
Internet Draft Ram Gopal
Expiration: August 2002 Nokia
File: draft-gopal-forces-eemodel-00.txt February 2002
Working Group: ForCES
Forwarding Element Model
draft-gopal-forces-femodel-00.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.
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 [2].
Abstract
This document describes a model for the Forwarding Element (FE)
Forces protocol endpoint. This model represents all the logical
components, which are responsible for providing per-hop behavior
inside a network element. This document also describes the MIB for
the FE model, which can be used to communicate between Forwarding
and Control Elements.
Gopal Expires August 2002 [Page 1]
Internet Draft Forwarding Element Model February 2002
Table of Content
1. Definitions.....................................................2
2. Introduction....................................................4
3. FE Model........................................................4
3.1.1. Functional aspects of Forwarding plane components...........5
3.2. Classification based on the treatment.........................5
3.3. Placement and ordering of logical components in FE............6
3.4. FE Model relationship.........................................8
3.5. Representation................................................9
3.5.1. Logical organization of Table..............................10
3.5.2. Example of Logical Component Description...................12
3.6. FE model MIB Definition (ASN.1)..............................13
4. References.....................................................13
5. Acknowledgments................................................14
6. Authors' Addresses.............................................14
1. Definitions
FE endpoint - Termination of Forces protocol at a FE
CE endpoint - Termination of Forces protocol at a CE
The following definitions are taken from [3]
Classifier - an entity which selects packets based on the content of
packet headers according to defined rules.
Dropper - a device that performs dropping.
Dropping - the process of discarding packets based on specified
rules; policing.
Marker - a device that performs marking.
Marking- the process of setting the DS codepoint in a packet based
on defined rules; pre-marking, re-marking.
Meter - a device that performs metering.
Metering - the process of measuring the temporal properties (e.g.,
rate) of a traffic stream selected by a classifier. The
instantaneous state of this process may be used to affect the
operation of a marker, shaper, or dropper, and/or may be used for
accounting and measurement purposes.
The following definitions are taken from [4]
Gopal Expires August 2002 [Page 2]
Internet Draft Forwarding Element Model February 2002
Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed by a CE via the ForCES
protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs.
Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs how to process
packets. CEs handle functionality such as the execution of control
and signaling protocols. CEs may consist of PCE partitions or whole
PCEs.
Pre-association Phase - The period of time during which a FE Manager
(see below) and a CE Manager (see below) are determining which FE
and CE should be part of the same network element.
Post-association Phase - The period of time during which a FE does
know which CE is to control it and vice versa, including the time
during which the CE and FE are establishing communication with one
another.
ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" refers
only to the ForCES post-association phase protocol (see below).
ForCES Post-Association Phase Protocol - The protocol used for post-
association phase communication between CEs and FEs. This protocol
does not apply to CE-to-CE communication, FE-to-FE communication, or
to communication between FE and CE managers. The ForCES protocol is
a master-slave protocol in which FEs are slaves and CEs are masters.
This protocol includes both the management of the communication
channel (e.g., connection establishment, heartbeats) and the control
messages themselves.
FE Model - A model that describes the logical processing functions
of a FE.
FE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which CE(s) a FE should
communicate. This process is called CE discovery and may involve
the FE manager learning the capabilities of available CEs. A FE
manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which CE(s) to
use. Being a logical entity, a FE manager might be physically
combined with any of the other logical entities mentioned in this
section.
CE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which FE(s) a CE should
Gopal Expires August 2002 [Page 3]
Internet Draft Forwarding Element Model February 2002
communicate. This process is called FE discovery and may involve
the CE manager learning the capabilities of available FEs. A CE
manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which FE to use.
Being a logical entity, a CE manager might be physically combined
with any of the other logical entities mentioned in this section.
Pre-association Phase Protocol - A protocol between FE managers and
CE managers that is used to determine which CEs or FEs to use. A
pre-association phase protocol may include a CE and/or FE capability
discovery mechanism. Note that this capability discovery process is
wholly separate from (and does not replace) that used within the
ForCES protocol (see Section 7, requirement #1). However, the two
capability discovery mechanisms may utilize the same FE model (see
Section 6). Pre-association phase protocols are not discussed
further in this document (see Section 11.3).
ForCES Network Element (NE) - An entity composed of one or more CEs
and one or more FEs. To entities outside a NE, the NE represents a
single point of management. Similarly, a NE usually hides its
internal organization from external entities.
ForCES Protocol Element - A FE or CE.
2. Introduction
Network elements such as routers play an important role in
transporting IP packets in the Internet. QoS aware router, policy
based routing and middle-box functions such as firewall, NAT,
proxies put heavy requirements on per-hop behavior treatment for IP
packets. This complicates network element.
Routers have emerged from simple monolithic software to a
distributed routing complex that interconnects different networks
and distributes the routing and forwarding logic to line cards and
control cards. A line card does basic forwarding function and a
control card runs all the control and management functions.
Forces [4] defines both architectural and protocol requirements for
the communication between CE and FE.
This document describes a FE model. The model comprises of logical
components and the components are organized in sequence in the
forwarding plane of a line card.
3. FE Model
Before describing the organization of the model, let us look at the
Gopal Expires August 2002 [Page 4]
Internet Draft Forwarding Element Model February 2002
functions and basic building blocks of the model.
Forces [4] defines that FE resides in the forwarding data path and
is responsible for communicating with CE. It represents all the
logical components residing in the forwarding plane.
The rest of this section describes how we identify the components
and build FE model.
3.1.1. Functional aspects of Forwarding plane components
When a packet is received by the forwarding blade inside ( say a
line card), it may be modified, metered or unmodified and be
directed towards its destination through the same/different line
card egress port. The components that are responsible for altering,
directing or metering IP packets may be hardware components (like
queue buffer) or software components. These components are the
essential building blocks of the FE. There may be one or more such
components and they are arranged serial or parallel from input port
to output port of the line card.
A FE model represents logical components and their relations. It is
important that each logical component is identified by its unique
behavior.
3.2. Classification based on the treatment
The classification of logical functions based on the capability is
shown in Figure 1. The Horizontal scale describes the logical
component organization based on how they treat IP packets.
Even though this classification is not reflected in the FE model, it
helps to understand the logical components in terms of what they do
on receipt of an IP packet for treatment.
The logical components are classified as follows:
1. Logical components that do not modify IP packets but perform
some parsing or decision-making. Typical function may include a
simple look-up.
2. Logical components that modify the content of the IP packet in
the header or the payload, e.g., encryption or DSCP code points
etc. These components may perform some logical operations or
operations that are based on configured algorithms.
Gopal Expires August 2002 [Page 5]
Internet Draft Forwarding Element Model February 2002
3. Logical components that do not modify but simply act as counter
to compute some statistics. This is a subset of case 1. The
only difference could be these components may generate external
events to the management plane components or to CE itself.
Treatment of IP packet
-------------------------------------------------------->
|Classification of logical components based on packet treatment
|-----------------------------------------------------------------
| IP packets | IP packets | IP not modified
| Not modified | altered | but has some side effects
|----------------+------------------------------------------------
| Classifier | Firewall |
| Filter | Half-NAT | Meter
| Shaper | Dropper | egress port
| Forwarder | Encapsulation | ingress port
| Queue | Decryption |
| Scheduler
|
Figure 1 Classification of logical functions
NOTE:
1. Meter also does not modify the IP packet. It is a special
type of logical function where it can generate external
events which can be either feedback to one of the logical
functions or to be sent to outside the FE for management.
2. Similarly, egress and ingress port status is monitored by
the FE and if a status change is detected by FE, it may
generate an event.
3.3. Placement and ordering of logical components in FE
The third aspect, which gives understanding of the FE model, is the
organization of the logical components. There may be more than one
parallel path in the forwarding plane between an egress port and an
ingress port. The logical components are laid out in sequence in
each parallel data path. When an IP packet passes through these
logical components one after another, the IP packet experiences
different treatments and these treatments are called stage
operations [5].
The following summarizes the logical layout of the FE model. The
logical layout is not contributing to the treatment of IP packet.
Gopal Expires August 2002 [Page 6]
Internet Draft Forwarding Element Model February 2002
1. One or more parallel path to process the IP packets in a
forwarding blade.
2. An IP packet passes through the series of logical components
and gets different packet treatments in each stage of
operation. This organization and placement of logical
components may be different for different path between an
ingress port and an egress port.
3. The treatments of packets in one direction may be different
from the treatments of packets in the reverse direction of the
path.
Gopal Expires August 2002 [Page 7]
Internet Draft Forwarding Element Model February 2002
3.4. FE Model relationship
After describing the concept of a logical function, its behavior and
placement inside a FE, the object model is described in the Figure
2.
+-----------------------+
| FE |
+-----------------------+
|
|1..n
+-----------------------+
| Parallel Path |
+-----------------------+
|1
|
|1 .. n
+-----------------------+
| Logical Component | (Abstract Element)
+-----------------------+
^
|
|
<------------------------------------------------>
| | | |
+-----------+ +-------+ +-------+ +-----------+
| Classifier| |Marker |. . .| Queue | . .| Forwarder |
+-----------+ +-------+ +-------+ +-----------+
^ ^
| |
<---------------------> <----------------->
| | Specific Capabilities | |
+-------------+ +------------+ +---------+ +--------+
| Multifield | | Free-Form | | RFC1812 | . . | Content|
+-------------+ +------------+ +---------+ | Based |
+--------+
Figure 2 Object model of FE
Description of the Model:
1. The FE is the base object that can have one or more parallel
paths to handle IP packets from ingress to egress ports. FE
object describes the attributes and capabilities the FE
supports. This includes whether it can participate 2 phase
command operation, high availability operation etc. [4]
Gopal Expires August 2002 [Page 8]
Internet Draft Forwarding Element Model February 2002
2. On each parallel path, there may be one or more logical
components. The logical component names are unique and can be
referenced uniquely inside a FE. Parallel path object is just
a reference object.
3. Logical component is an abstract entity. Its basic
characteristic is that it contributes to the per-hop behavior
while treating IP packets. Multiple logical components that are
derived from this abstract component. Examples are Forwarder,
Filter, Classifier, etc.
There may be further specialized logical components that are the
classified logical components.
Therefore, this model in principle has 3 levels as follows:
(1) First level is the FE object level which describes the
characteristic of FE , it contains list of CE in the CE
-Table.
(2) Second level is the Parallel path object that is used to
assist the referencing of the FE logical elements
(3) Third and final level is the Logical components
themselves.
Vendor specific logical functions can be added and their attributes
can be either defined or extended from existing logical components.
The next section describes the Table view to show how we can
reference each logical element and how it can be configured and
operated.
3.5. Representation
To represent the FE model in and to provide access to different
logical functions, CE can communicate to FE in one of the following
ways
1. XML representation
2. TLV format
3. MIB (ASN.1) format
XML takes up more bytes and requires parse functions in the CE and
FE. XML is not widely deployed and used in network elements.
ASN.1 format is human readable and most of the logical functions
attributes can be found in other protocols like Diffserv, PIB, IPSec
policy , etc. It will easier to use rather than redefining it
Gopal Expires August 2002 [Page 9]
Internet Draft Forwarding Element Model February 2002
repeatedly. This notation itself serves as some unique
identification to access all the logical components in a FE.
TLV is another alternative to communicate. But it requires some
external table structure to uniquely identifying the logical
components inside the network element.
3.5.1.Logical organization of Table
We provide the table views and describe each tables. Later part of
this section describes the actual MIB itself.
1. Each logical components needs to be accessed from the FE.
2. There may be multiple logical components of the same type in
one parallel path eg., classifier components
Parallel path Table <--------different stage ------------>
+-------------------+ +--------+ +-----------+ +-------+
|Parallel path 1 |o---->|ingress |->| IPFwd | . ->|egress |
+-------------------+ | port | +-----------+ |port |
|Parallel path 2 |o-- +--------+ +-------+
+-------------------+ |
. | +----------+ +-----------+
. +->|ingress |-> |Vendor |
. |port | |Specific |
+----------+ +-----------+
|
|
|
+-----V--+ +-------+
| Meter |. . ->|egress |
+--------+ |port |
+-------+
Figure 3 Organization of FE Table
Figure 3 describes two parallel paths. The parallel path table
contains index to the series of logical components. Logical
components are organized similar to a link list. It preserves the
order placement of logical components and is similar to [5][6]. On
parallel path 1, an IP packet reaches the ingress port. It then
moves on to the second stage and is processed by the Ipforwarder
component. This process continues till the packet reaches the egress
Gopal Expires August 2002 [Page 10]
Internet Draft Forwarding Element Model February 2002
port logical component. This linked list view of the stage reflects
the actual layout of the logical components in the forwarding path.
The following are the operations that can be performed on this
model.
(a) Flexibility
Vendor specific components can be added and be used any
where in the stage operation.
This model is extensible and the uniqueness to identify a
particular element in a FE is by an OID. For example,
FE.ParallelPathTableEntry.LogicalComponent
(b) Ordering of Logical Functions
Order of Logical functions is easily mapped to the linked
list organization of stage row entry. There may be cycles of
operations that may lead to loops etc. However, the sequence
in which a packet is treated is provided in a link list form
(C) Port Functions
As each logical component is identified by a unique number,
it is easy for FE to provide and update the status of the
ports. Either FE can automatically generate notification to
the external CE or the external entity can make a query to
get the status.
(d) Logical component functions
MIBĘs for filters, Classifiers, Queues are defined in other
protocol the configurable attributes and their access
privileges are described in detail.
Gopal Expires August 2002 [Page 11]
Internet Draft Forwarding Element Model February 2002
3.5.2. Example of Logical Component Description
Parallel path Table <--------STAGE ----------------------->
+-------------------+ +--------+ +-----------+ +-------+
|Parallel path 1 |o---->|ingress |->| IPFwd | . ->|egress |
+-------------------+ | port | +-----------+ |port |
|Parallel path 2 |o-- +--------+ +-------+
+-------------------+ |
. |
|
. |
|
+-----------------------+
|
| +----------------------------------------------------------+
| | Meter Table |
| +----------------------------------------------------------+
| |Id | SucceedNext|FailNext | MeterSpecific| Storage|Status |
| +---+------------+---------+--------------+--------+-------+
| | | | | | | |
| +---+------------+---------+--------------+--------+-------+
+->| | O | | | | |
+--------|-------------------------------------------------+
|
+-----------+
| +------------------------------------------------------+
| | Queue Table |
| +------------------------------------------------------+
| |Id | ServQNext |MinRate | MaxRate | QStorage|QStatus |
| +---+------------+---------+--------+---------+--------+
| | | | | | | |
| +---+------------+---------+--------+---------+--------+
+->| | O | | | | |
+---+----|-------+---------+--------+---------+--------+
| | | | | | | |
+---+----|-------+---------+--------+---------+--------+
|
|
+ -> Next logical component function
In this example, we show how each logical component can be accessed
using the data path pointer in the parallel path table. We have
taken the Meter Table and Queue Table attributes as defined in the
[6].
Gopal Expires August 2002 [Page 12]
Internet Draft Forwarding Element Model February 2002
First parallel path table is accessed and the index of the parallel
path table points to the first logical component function. Each
logical function is arranged in the form of a table. After indexing
the parallel path table for the second parallel path the first
logical functions is metering, the data path pointer points to the
attributes that are configured for that logical function. After the
metering process, the next pointer field points to the next logical
component that is a Queue. Hence, the next pointer points to a row
of that Queue table.
Each logical component is organized in a table form. Table lookup is
straightforward. This approach can support any number of parallel
data paths. Indexing is based on the table value.
The FE model needs to add some values like logical component ID ,
and some other additional attributes which are required for the
identification of logical components.
3.6. FE model MIB Definition (ASN.1)
TBW
4. References
1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026,
October 1996.
2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997.
3. S. Blake, et. Al., "An Architecture for Differentiated Service",
RFC2475, December 1998.
4. Anderson, et. al.,"Requirements for Separation of IP Control and
Forwarding", work in progress, February 2002,<draft-ietf-forces-
requirements-02.txt>,IETF.
5. Y. Bernet, et. al., "An Informal Management Model for DiffServ
Routers", work in progress, September 2001, <draft-ietf-diffserv-
model-06.txt>, IETF.
6. F.Baker, et. al., "Management Information Base for the
Differentiated Services Architecture", work in progress, November
2001, <draft-ietf-diffserv-mib-16.txt>, IETF.
Gopal Expires August 2002 [Page 13]
Internet Draft Forwarding Element Model February 2002
5. Acknowledgments
I would like to thank Man Li and Sanjeev verma of Nokia Research
Center for their valuable comments and suggestions.
6. Authors' Addresses
Ram Gopal
Nokia Research Center
5, Wayside Road,
Burlington, MA 01803
Phone: 1-781-993-3685
Email: ram.gopal@nokia.com
Gopal Expires August 2002 [Page 14]
