draft-ietf-forces-netlink-02.txt   draft-ietf-forces-netlink-03.txt 
ForCES Working Group Jamal Hadi Salim ForCES Working Group Jamal Hadi Salim
Internet Draft Znyx Networks Internet Draft Znyx Networks
Hormuzd Khosravi Hormuzd Khosravi
Intel Intel
Andi Kleen Andi Kleen
Suse Suse
Alexey Kuznetsov Alexey Kuznetsov
INR/Swsoft INR/Swsoft
March 2002 June 2002
Netlink as an IP services protocol Netlink as an IP Services Protocol
draft-ietf-forces-netlink-02.txt draft-ietf-forces-netlink-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
1. Abstract 1. Abstract
This document describes Linux Netlink, which is used in Linux both This document describes Linux Netlink, which is used in Linux both
as an inter-kernel messaging system as well as between kernel and as an intra-kernel messaging system as well as between kernel and
jhs_hk_ak_ank draft-forces-netlink-02.txt jhs_hk_ak_ank draft-forces-Netlink-03.txt
user-space. The purpose of this document is intended as informa- user space. This document is intended as informational in the con-
tional in the context of prior art for the ForCES IETF working text of prior art for the ForCES IETF working group. The focus of
group. The focus of this document is to describe netlink from a this
context of a protocol between a Forwarding Engine Component (FEC) document is to describe Netlink from a perspective of a protocol
and a Control Plane Component(CPC) that define an IP service. between a Forwarding Engine Component (FEC) and a Control Plane
Component (CPC), the two components that define an IP service.
The document ignores the ability of netlink as a inter-kernel mes- The document ignores the ability of Netlink as a intra-kernel mes-
saging system, as a an inter-process communication scheme (IPC) or saging system, as an inter-process communication scheme (IPC), or
its use in configuring other non-network as well as network but as a configuration tool for other non-networking or non-IP network
non-IP services (such as decnet etc). services (such as decnet, etc.).
2. Introduction 2. Introduction
The concept of IP Service control-forwarding separation was first The concept of IP Service control-forwarding separation was first
introduced in the early 1980s by the BSD 4.4 routing sock- introduced in the early 1980s by the BSD 4.4 routing sockets
ets[stevens]. The focus at that time was a simple IP(v4) forward- [Stevens]. The focus at that time was a simple IP(v4) forwarding
ing service and how the CPC, either via a command line configura- service and how the CPC, either via a command line configuration
tion tool or a dynamic route daemon, can control forwarding tables tool or a dynamic route daemon, could control forwarding tables for
for that IPV4 forwarding service. that IPv4 forwarding service.
The IP world has evolved considerably since those days. Linux The IP world has evolved considerably since those days. Linux
netlink, when observed from a service provisioning point of view Netlink, when observed from a service provisioning and management
takes routing sockets one step further by breaking the barrier of point of view, takes routing sockets one step further by breaking
focus around IPV4 forwarding. Since the linux 2.1 kernel, netlink the barrier of focus around IPv4 forwarding. Since the Linux 2.1
has been providing the IP service abstraction to a few services kernel, Netlink has been providing the IP service abstraction to a
other than the classical IPv4 forwarding. few services other than the classical RFC 1812 IPv4 forwarding.
The motivation for this document is not to list every possible ser-
vice for which Netlink is applied. In fact, we leave out a lot of
services (multicast routing, tunnelling, policy routing, etc.).
Neither is this document intended to be a tutorial on Netlink. The
idea is to explain the overall Netlink view with a special focus on
the mandatory building blocks within the ForCES charter (i.e., IPv4
and QoS). This document also serves to capture prior art to many
mechanisms that are useful within the context of ForCES. The text
is limited to a subset of what is available in kernel 2.4.6, the
newest kernel when this document was first written. It is also
limited to IPv4 functionality.
We first give some concept definitions and then describe how We first give some concept definitions and then describe how
netlink fits in. Netlink fits in.
2.1. Some definitions jhs_hk_ak_ank draft-forces-Netlink-03.txt
A Control plane(CP) is an execution environment that may have sev- 2.1. Definitions
eral components which we refer to as CPCs. Each CPC provides con-
trol for a different IP service being executed by a FE component.
This means that there might be several CPCs on a physical CP if it
is controlling several IP services. In essence, the cohesion
between a CP component and a FE component is the service abstrac-
tion.
In the diagram below we show a simple FE<->CP setup to provide an A Control Plane (CP) is an execution environment that may have sev-
example of the classical IPv4 service with an extension to do some eral sub-components, which we refer to as CPCs. Each CPC provides
basic QoS egress scheduling and how it fits in this described control for a different IP service being executed by a Forwarding
Engine (FE) component. This relationship means that there might be
several CPCs on a physical CP, if it is controlling several IP ser-
vices. In essence, the cohesion between a CP component and an FE
component is the service abstraction.
jhs_hk_ak_ank draft-forces-netlink-02.txt 2.1.1. Control Plane Components (CPCs)
model. Control Plane Components encompass signalling protocols, with
diversity ranging from dynamic routing protocols, such as OSPF
[RFC2328], to tag distribution protocols, such as CR-LDP [RFC3036].
Classical management protocols and activities also fall under this
category. These include SNMP [RFC1157], COPS [RFC2748], and pro-
prietary CLI/GUI configuration mechanisms.
The purpose of the control plane is to provide an execution envi-
ronment for the above-mentioned activities with the ultimate goal
being to configure and manage the second Network Element (NE) com-
ponent: the FE. The result of the configuration defines the way
that packets traversing the FE are treated.
2.1.2. Forwarding Engine Components (FECs)
The FE is the entity of the NE that incoming packets (from the net-
work into the NE) first encounter.
The FE's service-specific component massages the packet to provide
it with a treatment to achieve an IP service, as defined by the
Control Plane Components for that IP service. Different services
will utilize different FECs. Service modules may be chained to
achieve a more complex service (refer to the Linux FE model,
described later). When built for providing a specific service, the
FE service component will adhere to a forwarding model.
jhs_hk_ak_ank draft-forces-Netlink-03.txt
2.1.2.1. Linux IP Forwarding Engine Model
____ +---------------+
+->-| FW |---> | TCP, UDP, ... |
| +----+ +---------------+
| |
^ v
| _|_
+----<----+ | FW |
| +----+
^ |
| Y
To host From host
stack stack
^ |
|_____ |
Ingress ^ Y
device ____ +-------+ +|---|--+ ____ +--------+ Egress
->----->| FW |-->|Ingress|-->---->| Forw- |->| FW |->| Egress | device
+----+ | TC | | ard | +----+ | TC |-->
+-------+ +-------+ +--------+
The figure above shows the Linux FE model per device. The only
mandatory part of the datapath is the Forwarding module, which is
RFC 1812 conformant. The different Firewall (FW), Ingress Traffic
Control, and Egress Traffic Control building blocks are not manda-
tory in the datapath and may even be used to bypass the RFC 1812
module. These modules are shown as simple blocks in the datapath
but, in fact, could be multiple cascaded, independent submodules
within the indicated blocks. More information can be found at
[Netfilter] and [Diffserv].
Packets arriving at the ingress device first pass through a fire-
wall module. Packets may be dropped, munged, etc., by the firewall
module. The incoming packet, depending on set policy, may then be
passed via an Ingress Traffic Control module. Metering and polic-
ing activities are contained within the Ingress TC module. Packets
may be dropped, depending on metering results and policing poli-
cies, at this module. Next, the packet is subjected to the only
non-optional module, the RFC 1812-conformant Forwarding module.
The packet may be dropped if it is nonconformant (to the many RFCs
complementing 1812 and 1122). This module is a juncture point at
which packets destined to the forwarding NE may be sent up to the
host stack.
Packets that are not for the NE may further traverse a policy rout-
ing submodule (within the forwarding module), if so provisioned.
jhs_hk_ak_ank draft-forces-Netlink-03.txt
Another firewall module is walked next. The firewall module can
drop or munge/transform packets, depending on the configured sub-
modules encountered and their policies. If all goes well, the
Egress TC module is accessed next.
The Egress TC may drop packets for policing, scheduling, congestion
control, or rate control reasons. Egress queues exist at this
point and any of the drops or delays may happen before or after the
packet is queued. All is dependent on configured module algorithms
and policies.
2.1.3. IP Services
An IP service is the treatment of an IP packet within the NE. This
treatment is provided by a combination of both the CPC and the FEC.
The time span of the service is from the moment when the packet
arrives at the NE to the moment that it departs. In essence, an IP
service in this context is a Per-Hop Behavior. CP components run-
ning on NEs define the end-to-end path control for a service by
running control/signaling protocol/management-applications. These
distributed CPCs unify the end-to-end view of the IP service. As
noted above, these CP components then define the behavior of the FE
(and therefore the NE) for a described packet.
A simple example of an IP service is the classical IPv4 Forwarding.
In this case, control components, such as routing protocols (OSPF,
RIP, etc.) and proprietary CLI/GUI configurations, modify the FE's
forwarding tables in order to offer the simple service of forward-
ing packets to the next hop. Traditionally, NEs offering this sim-
ple service are known as routers. In the diagram below, we show a
simple FE<->CP setup to provide an example of the classical IPv4
service with an extension to do some basic QoS egress scheduling
and illustrate how the setup fits in this described model.
jhs_hk_ak_ank draft-forces-Netlink-03.txt
Control Plane (CP) Control Plane (CP)
.------------------------------------ .------------------------------------
| /^^^^^\ /^^^^^\ | | /^^^^^^\ /^^^^^^\ |
| | | | COPS |-. | | | | | COPS |-\ |
| | ospfd | | PEP | | | | | ospfd | | PEP | \ |
| | / \_____/ | | | \ / \_____/ | |
/--------\_____/ | | | /------\_____/ | / |
| | | | | | | | | | / |
| |______________________|___|_________| | |_________\__________|____|_________|
| | | | | | | |
****************************************** ******************************************
Forwarding ************* Netlink layer ************ Forwarding ************* Netlink layer ************
Engine (FE) ***************************************** Engine (FE) *****************************************
.-------------|-----------|------------|---|----------- .-------------|-----------|----------|---|-------------
| IPv4 forwading | / | | IPv4 forwading | | |
| FE Service / / | | FE Service / / |
| Component / / | | Component / / |
| ---------------/---------------/--------- | | ---------------/---------------/--------- |
| | | / | | | | | / | |
packet | | --------|-- ----|----- | packet packet | | --------|-- ----|----- | packet
in | | | IPV4 | | Egress | | out -->---> |------>|---->|Forwading |----->| QoS |--->| ---->|----> in | | | IPv4 | | Egress | | out
-->--->|------>|---->|Forwading |----->| QoS |--->| ---->|->
| | | | | Scheduler| | | | | | | | Scheduler| | |
| | ----------- ---------- | | | | ----------- ---------- | |
| | | | | | | |
| --------------------------------------- | | --------------------------------------- |
| | | |
------------------------------------------------------- -------------------------------------------------------
2.1.1. Control Plane Components (CPCs) The above diagram illustrates ospfd, an OSPF protocol control dae-
mon, and a COPS Policy Enforcement Point (PEP) as distinct CPCs.
Control plane components would encompass signalling protocols with The IPv4 FE component includes the IPv4 Forwarding service module
diversity ranging from dynamic routing protocols such as OSPF as well as the Egress Scheduling service module. Another service
[RFC2328] to tag distribution protocols such as CR-LDP [RFC3036]. might add a policy forwarder between the IPv4 forwarder and the QoS
Classical Management protocols and activities also fall under this egress scheduler. A simpler classical service would have consti-
category. These include SNMP [RFC1157], COPS [RFC2748] or propri- tuted only the IPv4 forwarder.
etary CLI/GUI configuration mechanisms.
jhs_hk_ak_ank draft-forces-netlink-02.txt
The purpose of the control plane is to provide an execution envi-
ronment for the above mentioned activities with the ultimate goal
being to configure and manage the second NE component: the FE. The
result of the configuration would define the way packets travesing
the FE are treated.
In the above diagram, ospfd and COPS are distinct CPCs.
2.1.2. Forwarding Engine Components
The FE is the entity of the NE that incoming packets (from the net-
work into the NE) first encounter.
The FE's service specific component massages the packet to provide
it with a treatment to achieve a IP service as defined by the con-
trol plane components for that IP service. Different services will
utilize different FEC. Service modules maybe chained to achieve a
more complex service (as shown in the diagram). When built for
providing a specific service, the FE service component will adhere
to a Forwading Model.
In the above diagram, the IPV4 FE component includes both the IPV4
Forwarding service module as well as the Egress Scheduling service
module. Another service might may add a policy forwarder between
the IPV4 forwader and the QoS egress Scheduler. A simpler classi-
cal service would have constituted only the IPV4 forwarder.
2.1.3. IP Services
An IP Service is the treatment of an IP packet within the NE. This
treatment is provided by a combination of both the CPC and FEC
The time span of the service is from the moment when the packet
arrives at the NE to the moment it departs. In essence an IP ser-
vice in this context is a Per-Hop Behavior. A service control/sig-
naling protocol/management-application (CP components running on
NEs defining the end to end path) unifies the end to end view of
the IP service. As noted above, these CP components then define the
behavior of the FE (and therefore the NE) to a described packet.
A simple example of an IP service is the classical IPv4 Forwarding.
In this case, control components such as routing protocols(OSPF,
jhs_hk_ak_ank draft-forces-netlink-02.txt
RIP etc) and proprietary CLI/GUI configurations modify the FE's Over the years, it has become important to add aditional services
forwarding tables in order to offer the simple service of forward- to routers to meet emerging requirements. More complex services
ing packets to the next hop. Traditionally, NEs offering this sim- extending classical forwarding have been added and standardized.
ple service are known as routers. These newer services might go beyond the layer 3 contents of the
packet header. However, the name "router," although a misnomer, is
still used to describe these NEs. Services (which may look beyond
the classical L3 service headers) include firewalling, QoS in Diff-
serv and RSVP, NAT, policy based routing, etc. Newer control pro-
tocols or management activities are introduced with these new ser-
vices.
Over the years it has become important to add aditional services to jhs_hk_ak_ank draft-forces-Netlink-03.txt
the routers to meet emerging requirements. More complex services
extending classical forwarding were added and standardized. These
newer services might go beyond the layer 3 contents of the packet
header. However, the name "router", although a misnomer, is still
used to describe these NEs. Services (which may look beyond the
classical L3 headers) here include firewalling, Qos in Diffserv and
RSVP, NATs, policy based routing etc. Newer control protocols or
management activities are introduced with these new services.
One extreme definition of a IP service is something a service One extreme definition of a IP service is something for which a
provider would be able to charge for. service provider would be able to charge.
3. Netlink Architecture 3. Netlink Architecture
IP services components control is defined by using templates. Control of IP service components is defined by using templates.
The FEC and CPC participate to deliver the IP service by communi- The FEC and CPC participate to deliver the IP service by communi-
cating using these templates. The FEC might continously get cating using these templates. The FEC might continously get
updates from the control plane component on how to operate the ser- updates from the Control Plane Component on how to operate the ser-
vice (example for V4 forwarding, route additions or deletions). vice (e.g., for v4 forwarding or for route additions or deletions).
The interaction between the FEC and the CPC, in the netlink con- The interaction between the FEC and the CPC, in the Netlink con-
text, would define a protocol. Netlink provides the mechanism for text, defines a protocol. Netlink provides mechanisms for the CPC
the CPC (residing in user space) and FEC (residing in kernel space) (residing in user space) and the FEC (residing in kernel space) to
to have their own protocol definition. Kernel space and user space have their own protocol definition--kernel space and user space
just mean different protection domains. Therefore a wire protocol just mean different protection domains. Therefore, a wire protocol
is needed to communicate. The wire protocol would be normally be is needed to communicate. The wire protocol is normally provided
provided by some privileged service that is able to copy between by some privileged service that is able to copy between multiple
multiple protection domains. We will refer to this service as the protection domains. We will refer to this service as the Netlink
netlink service. Netlink service could also be necapsulated to a service. The Netlink service can also be encapsulated in a differ-
different transport layer if the CPC executes on a different node ent transport layer, if the CPC executes on a different node than
than the FEC. The FEC and CPC, using netlink mechanisms, may the FEC. The FEC and CPC, using Netlink mechanisms, may choose to
choose to define a reliable protocol between each other. By define a reliable protocol between each other. By default, how-
default, however, netlink provides an unreliable communication. ever, Netlink provides an unreliable communication.
Note that the FEC and CPC can both live in the same memory protec- Note that the FEC and CPC can both live in the same memory protec-
tion domain and use the connect() system call to create a path to tion domain and use the connect() system call to create a path to
the peer and talk to each other. We will not discuss this further the peer and talk to each other. We will not discuss this mecha-
other than to say it is available as a mechanism. Through out this nism further other than to say that it is available. Throughout
this document, we will refer interchangebly to the FEC to mean ker-
jhs_hk_ak_ank draft-forces-netlink-02.txt nel space and the CPC to mean user space. This denomination is not
meant, however, to restrict the two components to these protection
document we will refer interchangebly to the FEC to mean kernel- domains or to the same compute node.
space and the CPC to mean user-space. This is not meant, however,
to restrict the two components to these protection domains or to
the same compute node.
Note: Netlink allows participation in IP services by both service Note: Netlink allows participation in IP services by both service
components. components.
3.1. Netlink Logical model 3.1. Netlink Logical Model
In the diagram below we show a simple FEC<->CPC logical relation- In the diagram below we show a simple FEC<->CPC logical relation-
ship. We use the example of IPV4 forwarding FEC (NETLINK_ROUTE, ship. We use the IPv4 forwarding FEC (NETLINK_ROUTE, which is
which is discussed further below) as an example.
jhs_hk_ak_ank draft-forces-Netlink-03.txt
discussed further below) as an example.
Control Plane (CP) Control Plane (CP)
.------------------------------------ .------------------------------------
| /^^^^^ /CPC-2 | | /^^^^^\ /^^^^^\ |
| | | / CPC-2 \ |
| | CPC-1 | | COPS | | | | CPC-1 | | COPS | |
| | ospfd | | PEP | | | | ospfd | | PEP | |
| / _____/ | | / _____/ |
| _____/ | | | _____/ | |
| | | | | | | |
****************************************| ****************************************|
************* BROADCAST WIRE ************ ************* BROADCAST WIRE ************
FE---------- *****************************************. FE---------- *****************************************.
| IPv4 forwading | | / | | IPv4 forwading | | | |
| FEC | | | | | FEC | | | |
| --------------/-----|-----------|-------- | | --------------/ ----|-----------|-------- |
| | / | | | | | | / | | | |
| | .-------. .-------. .------. | | | | .-------. .-------. .------. | |
| | |ingress| | IPV4 | |Egress| | | | | |Ingress| | IPv4 | |Egress| | |
| | |police | |Forward| | QoS | | | | | |police | |Forward| | QoS | | |
| | |_______| |_______| |Sched | | | | | |_______| |_______| |Sched | | |
| | ------ | | | | ------ | |
| --------------------------------------- | | --------------------------------------- |
| | | |
----------------------------------------------------- -----------------------------------------------------
Netlink logically models FECs and CPCs in the form of nodes inter- Netlink logically models FECs and CPCs in the form of nodes inter-
connected to each other via a broadcast wire. connected to each other via a broadcast wire.
The wire is specific to a service. The example above shows the The wire is specific to a service. The example above shows the
broadcast wire belonging to the extended IPV4 forwarding service. broadcast wire belonging to the extended IPv4 forwarding service.
jhs_hk_ak_ank draft-forces-netlink-02.txt Nodes (CPCs or FECs as illustrated above) connect to the wire and
register to receive specific messages. CPCs may connect to multi-
ple wires if it helps them to control the service better. All
nodes (CPCs and FECs) dump packets on the broadcast wire. Packets
can be discarded by the wire if they are malformed or not specifi-
cally formatted for the wire. Dropped packets are not seen by any
of the nodes. The Netlink service MAY signal an error to the
sender if it detects a malformatted Netlink packet.
Nodes connect to the wire and register to receive specific mes- Packets sent on the wire can be broadcast, multicast, or unicast.
sages. CPCs may connect to multiple wires if it helps them to con- FECs or CPCs register for specific messages of interest for pro-
trol the service better. All nodes(CPCs and FECs) dump packets on cessing or just monitoring purposes.
the broadcast wire. Packets could be discarded by the wire if mal-
formed or not specifically formated for the wire. Dropped packets
are not seen by any of the nodes. The netlink service MAY signal
an error to the original if it detects an malformatted netlink
packet.
Packets sent on the wire could be broadcast, multicast or unicast. jhs_hk_ak_ank draft-forces-Netlink-03.txt
FECs or CPCs register for and pick specific messages of interest
for processing or just monitoring purposes.
3.2. The message format Appendices 1 and 2 have a high level overview of this interaction.
There are three levels to a netlink message: The general netlink 3.2. Message Format
message header, the IP service specific template, the IP service
specific data. There are three levels to a Netlink message: The general Netlink
message header, the IP service specific template, and the IP ser-
vice specific data.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Netlink message header | | Netlink message header |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Service Template | | IP Service Template |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Service specific data in TLVs | | IP Service specific data in TLVs |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The netlink message is used to communicate between the FEC and CPC The Netlink message is used to communicate between the FEC and CPC
for parametrization of the FECs, asynchoronous event notification for parametrization of the FECs, asynchoronous event notification
of FEC events to the CPCs and statistics querying/gathering (typi- of FEC events to the CPCs, and statistics querying/gathering (typi-
cally by the CPC). The Netlink message header is generic for all cally by a CPC).
services whereas the IP Service Template header is specific to a
service. Each IP Service then carries parameterization
data(CPC->FEC direction) or response (FEC->CPC direction). These
are in TLV format and unique just to the service.
jhs_hk_ak_ank draft-forces-netlink-02.txt The Netlink message header is generic for all services, whereas the
IP Service Template header is specific to a service. Each IP Ser-
vice then carries parametrization data (CPC->FEC direction) or
response (FEC->CPC direction). These parametrizations are in TLV
(Type-Length-Value) format and are unique to the service.
3.3. Protocol Model 3.3. Protocol Model
This section expands on how netlink provides the mechanism for ser- This section expands on how Netlink provides the mechanism for ser-
vice oriented FEC and CPC interaction. vice-oriented FEC and CPC interaction.
jhs_hk_ak_ank draft-forces-Netlink-03.txt
3.3.1. Service Addressing 3.3.1. Service Addressing
Access is provided by first connecting to the service on the FE. Access is provided by first connecting to the service on the FE.
This is done by making a socket() system call to the PF_NETLINK The connection is achieved by making a socket() system call to the
domain. Each FEC is identified by a protocol number. One may open PF_NETLINK domain. Each FEC is identified by a protocol number.
either SOCK_RAW or SOCK_DGRAM type sockets although netlink doesnt One may open either SOCK_RAW or SOCK_DGRAM type sockets, although
distinguish the two. The socket connection provides the basis for Netlink does not distinguish between the two. The socket connec-
the FE<->CP addressing. tion provides the basis for the FE<->CP addressing.
Connecting to a service is followed (at any point during the life Connecting to a service is followed (at any point during the life
of the connection) by issuing either a service specific command of the connection) by either issuing a service-specific command
mostly for configuration purposes (from the CPC to the FEC) or sub- (from the CPC to the FEC, mostly for configuration purposes), issu-
scribing/unsubscribing to service(s') events, or statistics collec- ing a statistics-collection command, or subscribing/unsubscribing
tion. to service events. Closing the socket terminates the transaction.
Refer to Appendices 1 and 2 for examples.
3.3.1.1. Sample Service Hierachy
In the diagram below we show a simple IP service, foo, and the
interaction it has between CP and FE components for the ser-
vice(labels 1-3).
We introduce the diagram below to demonstrate CP<->FE addressing.
In this section we illustrate only the addressing semantics. In
section 4, the diagram is referenced again to define the protocol
interaction between service foo's CPC and FEC (labels 4-10).
jhs_hk_ak_ank draft-forces-netlink-02.txt
CP
[--------------------------------------------------------.
| .-----. |
| | . -------. |
| | CLI | / |
| | | | CP protocol |
| /->> -. | component | <-. |
| __ _/ | | For | | |
| | | IP service | ^ |
| Y | foo | | |
| | ___________/ ^ |
| Y 1,4,6,8,9 / ^ 2,5,10 | 3,7 |
--------------- Y------------/---|----------|-----------
| ^ | ^
**|***********|****|**********|**********
************* Netlink layer ************
**|***********|****|**********|**********
FE | | ^ ^
.-------- Y-----------Y----|--------- |----.
| | / |
| Y / |
| . --------^-------. / |
| |FE component/module|/ |
| | for IP Service | |
--->---|------>---| foo |----->-----|------>--
| ------------------- |
| |
| |
------------------------------------------
The control plane protocol for IP service foo does the following to
connect to its FE counterpart. The steps below are also numbered
above in the diagram.
1) Connect to IP service foo through a socket connect. A typical con-
nection would be via a call to: socket(AF_NETLINK, SOCK_RAW,
NETLINK_FOO)
2) Bind to listen to specific async events for service foo
3) Bind to listen to specific async FE events
jhs_hk_ak_ank draft-forces-netlink-02.txt
3.3.2. Netlink message header 3.3.2. Netlink Message Header
Netlink messages consist of a byte stream with one or multiple Netlink messages consist of a byte stream with one or multiple
Netlink headers and associated payload. If the payload is too big Netlink headers and an associated payload. If the payload is too
to fit into a single message it can be split over multiple netlink big to fit into a single message it, can be split over multiple
messages. This is called a multipart message. For multipart mes- Netlink messages, collectively called a multipart message. For
sages the first and all following headers have the NLM_F_MULTI multipart messages, the first and all following headers have the
netlink header flag set, except for the last header which has the NLM_F_MULTI Netlink header flag set, except for the last header
netlink header type NLMSG_DONE. which has the Netlink header type NLMSG_DONE.
The netlink message header is shown below. The Netlink message header is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | | Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Process PID | | Process ID (PID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the header are: The fields in the header are:
jhs_hk_ak_ank draft-forces-netlink-02.txt jhs_hk_ak_ank draft-forces-Netlink-03.txt
Length: 32 bits Length: 32 bits
The length of the message in bytes including the header. The length of the message in bytes, including the header.
Type: 16 bits Type: 16 bits
This field describes the message content. This field describes the message content.
It can be one of the standard message types: It can be one of the standard message types:
NLMSG_NOOP message is ignored NLMSG_NOOP Message is ignored.
NLMSG_ERROR the message signals an error and the payload NLMSG_ERROR The message signals an error and the payload
contains a nlmsgerr structure. This can be looked contains a nlmsgerr structure. This can be looked
at as a NACK and typically it is from FEC to CPC. at as a NACK and typically it is from FEC to CPC.
NLMSG_DONE message terminates a multipart message NLMSG_DONE Message terminates a multipart message.
Individual IP Services specify more message types, for e.g., Individual IP services specify more message types, e.g.,
NETLINK_ROUTE Service specifies several types such as RTM_NEWLINK, NETLINK_ROUTE service specifies several types, such as RTM_NEWLINK,
RTM_DELLINK, RTM_GETLINK, RTM_NEWADDR, RTM_DELADDR, RTM_NEWROUTE, RTM_DELLINK, RTM_GETLINK, RTM_NEWADDR, RTM_DELADDR, RTM_NEWROUTE,
RTM_DELROUTE, etc. RTM_DELROUTE, etc.
Flags: 16 bits Flags: 16 bits
The standard flag bits used in netlink are The standard flag bits used in Netlink are
NLM_F_REQUEST Must be set on all request messages (typically NLM_F_REQUEST Must be set on all request messages (typically
from user space to kernel space) from user space to kernel space)
NLM_F_MULTI Indicates the message is part of a multipart NLM_F_MULTI Indicates the message is part of a multipart
message terminated by NLMSG_DONE message terminated by NLMSG_DONE
NLM_F_ACK Request for an acknowledgment on success. NLM_F_ACK Request for an acknowledgment on success.
Typical direction of request is from user Typical direction of request is from user
space to kernel space. space (CPC) to kernel space (FEC).
NLM_F_ECHO Echo this request. Typical direction of NLM_F_ECHO Echo this request. Typical direction of
request is from user space to kernel space. request is from user space (CPC) to kernel
space (FEC).
Additional flag bits for GET requests on config information in Additional flag bits for GET requests on config information in
the FEC. the FEC.
NLM_F_ROOT Return the complete table instead of a NLM_F_ROOT Return the complete table instead of a
single entry. single entry.
NLM_F_MATCH Return all matching criteria passed in NLM_F_MATCH Return all entries matching criteria passed in
message content message content.
NLM_F_ATOMIC Return an atomic snapshot of the table being NLM_F_ATOMIC Return an atomic snapshot of the table being
referenced. This may require special privileges referenced. This may require special privileges
because it has the potential to interrupt because it has the potential to interrupt
service in the FE for a longer time. service in the FE for a longer time.
Convenience macros for flag bits: Convenience macros for flag bits:
NLM_F_DUMP This is NLM_F_ROOT or'ed with NLM_F_MATCH NLM_F_DUMP This is NLM_F_ROOT or'ed with NLM_F_MATCH
Additional flag bits for NEW requests Additional flag bits for NEW requests
NLM_F_REPLACE Replace existing matching config object with NLM_F_REPLACE Replace existing matching config object with
this request. this request.
NLM_F_EXCL Don't replace the config object if it already NLM_F_EXCL Don't replace the config object if it already
exists.
jhs_hk_ak_ank draft-forces-netlink-02.txt jhs_hk_ak_ank draft-forces-Netlink-03.txt
exists.
NLM_F_CREATE Create config object if it doesn't already NLM_F_CREATE Create config object if it doesn't already
exist. exist.
NLM_F_APPEND Add to the end of the object list. NLM_F_APPEND Add to the end of the object list.
For those familiar with BSDish use of such operations in route For those familiar with BSDish use of such operations in route
sockets, the equivalent translations are: sockets, the equivalent translations are:
- BSD ADD operation equates to NLM_F_CREATE or-ed - BSD ADD operation equates to NLM_F_CREATE or-ed
with NLM_F_EXCL with NLM_F_EXCL
- BSD CHANGE operation equates to NLM_F_REPLACE - BSD CHANGE operation equates to NLM_F_REPLACE
- BSD Check operation equates to NLM_F_EXCL - BSD Check operation equates to NLM_F_EXCL
- BSD APPEND equivalent is actually mapped to - BSD APPEND equivalent is actually mapped to
NLM_F_CREATE NLM_F_CREATE
Sequence Number: 32 bits Sequence Number: 32 bits
The sequence number of the message. The sequence number of the message.
Process PID: 32 bits Process ID (PID): 32 bits
The PID of the process sending the message. The PID is used by the The PID of the process sending the message. The PID is used by the
kernel to multiplex to the correct sockets. A PID of zero is used kernel to multiplex to the correct sockets. A PID of zero is used
when sending messages to user space from the kernel. netlink service when sending messages to user space from the kernel.
fills in an appropiate value when zero.
3.3.2.1. Mechanisms for creating protocols 3.3.2.1. Mechanisms for Creating Protocols
One could create a reliable protocol between an FEC and a CPC by One could create a reliable protocol between an FEC and a CPC by
using the combination of sequence numbers, ACKs and retransmit using the combination of sequence numbers, ACKs, and retransmit
timers. Both sequence numbers and ACKs are provided by netlink. timers. Both sequence numbers and ACKs are provided by Netlink;
Timers are provided by Linux. timers are provided by Linux.
One could create a heartbeat protocol between the FEC and CPC by One could create a heartbeat protocol between the FEC and CPC by
using the ECHO flags and the NLMSG_NOOP message. using the ECHO flags and the NLMSG_NOOP message.
3.3.2.2. The ACK netlink message 3.3.2.2. The ACK Netlink Message
This message is actually used to denote both an ACK and a NACK. This message is actually used to denote both an ACK and a NACK.
Typically the direction is from kernel to user space (in response Typically, the direction is from FEC to CPC (in response to an ACK
to an ACK request message). However, user space should be able to request message). However, the CPC should be able to send ACKs
send ACKs back to kernel space when requested. This is IP service back to FEC when requested. The semantics for this are IP service-
specific. specific.
jhs_hk_ak_ank draft-forces-netlink-02.txt jhs_hk_ak_ank draft-forces-Netlink-03.txt
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netlink message header | | Netlink message header |
| type = NLMSG_ERROR | | type = NLMSG_ERROR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| error code | | Error code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLD Netlink message header | | OLD Netlink message header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error code: integer (typically 32 bits) Error code: integer (typically 32 bits)
Error code of zero indicates that the message is an ACK response. An error code of zero indicates that the message is an ACK
An ACK response message contains the original netlink message response. An ACK response message contains the original Netlink
header that can be used to compare against (sent sequence numbers message header, which can be used to compare against (sent sequence
etc). numbers, etc).
A non-zero error message is equivalent to a Negative ACK (NACK). A non-zero error code message is equivalent to a Negative ACK
In such a situation, the netlink data that was sent down to the (NACK). In such a situation, the Netlink data that was sent down
kernel is returned appended to the original netlink message header. to the kernel is returned appended to the original Netlink message
An error code printable via the perror() is also set (not in the header. An error code printable via the perror() is also set (not
message header, rather in the executing environment state vari- in the message header, rather in the executing environment state
able). variable).
3.3.3. FE System services' templates 3.3.3. FE System Services' Templates
These are services that are offered by the system for general use These are services that are offered by the system for general use
by other services. They include ability to configure, gather by other services. They include the ability to configure, gather
statistics and listen to changes in shared resources. IP address statistics and listen to changes in shared resources. IP address
management, link events etc fit here. We separate them into this management, link events, etc. fit here. We create this section for
section here for logical purposes despite the fact that they are these services for logical separation, despite the fact that they
accessed via the NETLINK_ROUTE FEC. The reason that they exist are accessed via the NETLINK_ROUTE FEC. The reason that they exist
within NETLINK_ROUTE is due to historical cruft based on the fact within NETLINK_ROUTE is due to historical cruft: the BSD 4.4 Route
that BSD 4.4 rather narrowly focussed Route Sockets implemented Sockets implemented them as part of the IPv4 forwarding sockets.
them as part of the IPV4 forwarding sockets.
3.3.3.1. 3.3.3.1.
Network Interface Service Module Network Interface Service Module
jhs_hk_ak_ank draft-forces-netlink-02.txt jhs_hk_ak_ank draft-forces-Netlink-03.txt
This service provides the ability to create, remove or get informa- This service provides the ability to create, remove, or get infor-
tion about a specific network interface. The network interface mation about a specific network interface. The network interface
could be either physical or virtual and is network protocol inde- can be either physical or virtual and is network protocol indepen-
pendent (example an x.25 interface can be defined via this mes- dent (e.g., an x.25 interface can be defined via this message).
sage). The Interface service message template is shown below. The Interface service message template is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Padding | Device Type | | Family | Reserved | Device Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | | Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Flags | | Device Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Change Mask | | Change Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: This is always set to AF_UNSPEC jhs_hk_ak_ank draft-forces-Netlink-03.txt
Device Type: This defines the type of the link. The link could be Family: 8 bits
ethernet, a tunnel etc. Although we are interested only in IPV4, This is always set to AF_UNSPEC.
the link type is protocol independent.
Interface Index: uniquely identifies interface. Device Type: 16 bits
This defines the type of the link. The link could be Ethernet, a
tunnel, etc. We are interested only in IPv4, although the link type
is L3 protocol-independent.
Device Flags: Interface Index: 32 bits
Uniquely identifies interface.
IFF_UP Interface is running. Device Flags: 32 bits
IFF_UP Interface is administrativel up.
IFF_BROADCAST Valid broadcast address set. IFF_BROADCAST Valid broadcast address set.
IFF_DEBUG Internal debugging flag. IFF_DEBUG Internal debugging flag.
IFF_LOOPBACK Interface is a loopback interface. IFF_LOOPBACK Interface is a loopback interface.
IFF_POINTOPOINT Interface is a point-to-point link. IFF_POINTOPOINT Interface is a point-to-point link.
IFF_RUNNING Resources allocated. IFF_RUNNING Interface is operationally up.
IFF_NOARP No arp protocol IFF_NOARP No ARP protocol needed for this interface.
IFF_PROMISC Interface is in promiscuous mode. IFF_PROMISC Interface is in promiscuous mode.
IFF_NOTRAILERS Avoid use of trailers. IFF_NOTRAILERS Avoid use of trailers.
IFF_ALLMULTI Receive all multicast packets. IFF_ALLMULTI Receive all multicast packets.
IFF_MASTER Master of a load balancing bundle. IFF_MASTER Master of a load balancing bundle.
IFF_SLAVE Slave of a load balancing bundle. IFF_SLAVE Slave of a load balancing bundle.
IFF_MULTICAST Supports multicast IFF_MULTICAST Supports multicast
IFF_PORTSEL Is able to select media type via ifmap. IFF_PORTSEL Is able to select media type via ifmap.
IFF_AUTOMEDIA Auto media selection active. IFF_AUTOMEDIA Auto media selection active.
IFF_DYNAMIC Interface Address is not permanent. IFF_DYNAMIC Interface was dynamically created.
jhs_hk_ak_ank draft-forces-netlink-02.txt
Change Mask: Reserved for future use. Must be set to 0xFFFFFFFF. Change Mask: 32 bits
Reserved for future use. Must be set to 0xFFFFFFFF.
Applicable attributes: Applicable attributes:
attribute description Attribute Description
....................................................... ...........................................................
IFLA_UNSPEC - unspecified. IFLA_UNSPEC Unspecified.
IFLA_ADDRESS hardware address interface L2 address IFLA_ADDRESS Hardware address interface L2 address.
IFLA_BROADCAST hardware address L2 broadcast IFLA_BROADCAST Hardware address L2 broadcast
address. address.
IFLA_IFNAME ascii string device name. IFLA_IFNAME ASCII string device name.
IFLA_MTU MTU of the device. IFLA_MTU MTU of the device.
IFLA_LINK Link type. IFLA_LINK ifindex of link to which this device
IFLA_QDISC ascii string defining Queueing is bound.
discipline. IFLA_QDISC ASCII string defining egress root
IFLA_STATS Interface Statistics. queueing discipline.
IFLA_STATS Interface statistics.
Netlink message types specific to this service: RTM_NEWLINK, jhs_hk_ak_ank draft-forces-Netlink-03.txt
RTM_DELLINK, RTM_GETLINK
3.3.3.2. IP Address Service module Netlink message types specific to this service:
RTM_NEWLINK, RTM_DELLINK, and RTM_GETLINK
This service provides the ability to add, remove or receive information 3.3.3.2. IP Address Service Module
about an IP address associated with an interface. The Address provi-
This service provides the ability to add, remove, or receive information
about an IP address associated with an interface. The address provi-
sioning service message template is shown below. sioning service message template is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Length | Flags | Scope | | Family | Length | Flags | Scope |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | | Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: AF_INET for IPV4 or AF_INET6 for IPV6. Family: 8 bits
Length: the length of the address mask Address Family: AF_INET for IPv4; and AF_INET6 for IPV4.
Flags: IFA_F_SECONDARY for secondary address (alias interface),
IFA_F_PERMANENT for a permanent address set by the user as
opposed to dynamic addresses.
other flags include:
IFA_F_DEPRECATED which defines deprecated (IPV6) address
IFA_F_TENTATIVE which defines tentative (IPV6) address
Scope: the address scope
jhs_hk_ak_ank draft-forces-netlink-02.txt
Applicable attributes:
attribute description
.......................................................
IFA_UNSPEC - unspecified.
IFA_ADDRESS raw protocol address of interface
IFA_LOCAL raw protocol local address
IFA_LABEL ascii string name of the interface
reffered to.
IFA_BROADCAST raw protocol broadcast address.
IFA_ANYCAST raw protocol anycast address
IFA_CACHEINFO cacheinfo address information.
Define cacheinfo here -- JHS
netlink messages specific to this service: RTM_NEWADDR,
RTM_DELADDR, RTM_GETADDR
4. Sample Protocol for The foo IP service
Our proverbial IP service "foo" is used again to demonstrate how
one can deploy a simple IP service control using netlink.
These steps are continued from the "Sample Service Hierachy" sec-
tion.
4) query for current config of FE component
5) receive response to 4) via channel on 3)
6) query for current state of IP service foo Length: 8 bits
The length of the address mask.
7) receive response to 6) via channel on 2) Flags: 8 bits
IFA_F_SECONDARY For secondary address (alias interface).
IFA_F_PERMANENT For a permanent address set by the user.
When this is not set, it means the address
was dynamically created (e.g., by stateless
autoconfiguration).
IFA_F_DEPRECATED Defines deprecated (IPV4) address.
IFA_F_TENTATIVE Defines tentative (IPV4) address (duplicate
address detection is still in progress).
9) register the protocol specific packets you would like the FE to Scope: 8 bits
forward to you The address scope in which the address stays valid.
SCOPE_UNIVERSE: Global scope.
SCOPE_SITE (IPv6 only): Only valid within this site.
SCOPE_LINK: Valid only on this device.
SCOPE_HOST: Valid only on this host.
10) send specific service foo commands and receive responses for them Applicable attributes:
if needed
4.1. Interacting with other IP services jhs_hk_ak_ank draft-forces-Netlink-03.txt
jhs_hk_ak_ank draft-forces-netlink-02.txt Attribute Description
.........................................................
IFA_UNSPEC Unspecified.
IFA_ADDRESS Raw protocol address of interface.
IFA_LOCAL Raw protocol local address.
IFA_LABEL ASCII string name of the interface.
IFA_BROADCAST Raw protocol broadcast address.
IFA_ANYCAST Raw protocol anycast address.
IFA_CACHEINFO Cache address information.
The last diagram shows another control component configuring the Netlink messages specific to this service: RTM_NEWADDR,
same service. In this case, it is a proprietary Command Line Inter- RTM_DELADDR, and RTM_GETADDR.
face. The CLI (may or ) may not be using the netlink protocol to
communicate to the foo component. If the CLI should issue commands
that will affect the policy of the FEC for service "foo" then, then
the "foo" CPC is notified. It could then make algorithmic decisions
based on this input (example if a policy that foo installed was
deleted, there might be need to propagate this to all the peers of
service "foo").
5. Currently Defined netlink IP services 4. Currently Defined Netlink IP Services
Although there are many other IP services defined which are using Although there are many other IP services defined that are using
netlink, we will only mention those integrated into the kernel Netlink, as mentioned earlier, we will talk only about a handful of
today (kernel version 2.4.6). These are: those integrated into kernel version 2.4.6. These are:
NETLINK_ROUTE,NETLINK_FIREWALL,NETLINK_ARPD,NETLINK_ROUTE6, NETLINK_ROUTE, NETLINK_FIREWALL, and NETLINK_ARPD.
NETLINK_IP6_FW
5.1. IP Service NETLINK_ROUTE 4.1. IP Service NETLINK_ROUTE
This service allows CPCs to modify the IPv4 routing table in the This service allows CPCs to modify the IPv4 routing table in the
Forwarding Engine. It can also be used by CPCs to receive routing Forwarding Engine. It can also be used by CPCs to receive routing
updates as well as collecting statistics. updates, as well as to collect statistics.
5.1.1. Network Route Service Module 4.1.1. Network Route Service Module
This service provides the ability to create, remove or receive informa- This service provides the ability to create, remove or receive
tion about a network route. The service message template is shown information about a network route. The service message template is
below. shown below.
jhs_hk_ak_ank draft-forces-netlink-02.txt jhs_hk_ak_ank draft-forces-Netlink-03.txt
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Src length | Dest length | TOS | | Family | Src length | Dest length | TOS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Table ID | Protocol | Scope | Type | | Table ID | Protocol | Scope | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: Address family of route. AF_INET for IPV4 and AF_INET6 for Family: 8 bits
IPV6. Address Family: AF_INET for IPv4; and AF_INET6 for IPV4.
Src length: prefix length of source Src length: 8 bits
Prefix length of source IP address.
Dest length: Prefix length of destination IP address Dest length: 8 bits
Prefix length of destination IP address.
TOS: the 8 bit tos (should be deprecated to make room for DSCP) TOS: 8 bits
The 8-bit TOS (should be deprecated to make room for DSCP).
Table ID: Table identifier. Upto 255 route tables are supported. jhs_hk_ak_ank draft-forces-Netlink-03.txt
RT_TABLE_UNSPEC an unspecified routing table
RT_TABLE_DEFAULT the default table Table ID: 8 bits
RT_TABLE_MAIN the main table Table identifier. Up to 255 route tables are supported.
RT_TABLE_LOCAL the local table RT_TABLE_UNSPEC An unspecified routing table.
RT_TABLE_DEFAULT The default table.
RT_TABLE_MAIN The main table.
RT_TABLE_LOCAL The local table.
The user may assign arbitary values between The user may assign arbitary values between
RT_TABLE_UNSPEC and RT_TABLE_DEFAULT. RT_TABLE_UNSPEC(0) and RT_TABLE_DEFAULT(253).
Protocol: identifies what/who added the route. Described further Protocol: 8 bits
below. Identifies what/who added the route.
protocol Route origin. Protocol Route origin.
.............................................. ..............................................
RTPROT_UNSPEC unknown RTPROT_UNSPEC Unknown.
RTPROT_REDIRECT by an ICMP redirect RTPROT_REDIRECT By an ICMP redirect.
(currently unused) RTPROT_KERNEL By the kernel.
RTPROT_KERNEL by the kernel RTPROT_BOOT During bootup.
RTPROT_BOOT during boot RTPROT_STATIC By the administrator.
RTPROT_STATIC by the administrator
Values larger than RTPROT_STATIC are not interpreted by the ker-
nel, they are just for user information. They may be used to tag
the source of a routing information or to distingush between multiple
routing daemons. See <linux/rtnetlink.h> for the routing daemon
identifiers which are already assigned.
jhs_hk_ak_ank draft-forces-netlink-02.txt Values larger than RTPROT_STATIC(4) are not interpreted by the
kernel, they are just for user information. They may be used to
tag the source of a routing information or to distingush between
multiple routing daemons. See <linux/rtnetlink.h> for the
routing daemon identifiers that are already assigned.
Scope: Route scope (distance to destination). Scope: 8 bits
RT_SCOPE_UNIVERSE global route Route scope (valid distance to destination).
RT_SCOPE_SITE interior route in the RT_SCOPE_UNIVERSE Global route.
local autonomous system RT_SCOPE_SITE Interior route in the
RT_SCOPE_LINK route on this link local autonomous system.
RT_SCOPE_HOST route on the local host RT_SCOPE_LINK Route on this link.
RT_SCOPE_NOWHERE destination doesn't exist RT_SCOPE_HOST Route on the local host.
RT_SCOPE_NOWHERE Destination does not exist.
The values between RT_SCOPE_UNIVERSE and RT_SCOPE_SITE are avail- The values between RT_SCOPE_UNIVERSE(0) and RT_SCOPE_SITE(200)
able to the user. are available to the user.
Type: The type of route. Type: 8 bits
The type of route.
Route type description Route type Description
------------------------------------------------- ----------------------------------------------------
RTN_UNSPEC unknown route RTN_UNSPEC Unknown route.
RTN_UNICAST a gateway or direct route RTN_UNICAST A gateway or direct route.
RTN_LOCAL a local interface route RTN_LOCAL A local interface route.
RTN_BROADCAST a local broadcast route RTN_BROADCAST A local broadcast route
(sent as a broadcast)
RTN_ANYCAST a local broadcast route
(sent as a unicast)
RTN_MULTICAST a multicast route
RTN_BLACKHOLE a packet dropping route
RTN_UNREACHABLE an unreachable destination
RTN_PROHIBIT a packet rejection route
RTN_THROW continue routing lookup in another
table
RTN_NAT a network address translation rule
RTN_XRESOLVE refer to an external resolver (not
implemented)
Flags: further qualify the route. jhs_hk_ak_ank draft-forces-Netlink-03.txt
RTM_F_NOTIFY if the route changes, notify the
user via rtnetlink
RTM_F_CLONED route is cloned from another route
RTM_F_EQUALIZE a multicast equalizer (not yet
implemented)
Attributes applicable to this service: (sent as a broadcast).
RTN_ANYCAST An anycast route.
RTN_MULTICAST A multicast route.
RTN_BLACKHOLE A silent packet dropping route.
RTN_UNREACHABLE An unreachable destination.
Packets dropped and host
unreachable ICMPs are sent to the
originator.
RTN_PROHIBIT A packet rejection route. Packets
are dropped and communication
prohibited ICMPs are sent to the
originator.
RTN_THROW When used with policy routing,
continue routing lookup in another
table. Under normal routing,
packets are dropped and net
unreachable ICMPs are sent to the
originator.
RTN_NAT A network address translation
rule.
RTN_XRESOLVE Refer to an external resolver (not
implemented).
jhs_hk_ak_ank draft-forces-netlink-02.txt Flags: 32 bits
Further qualify the route.
RTM_F_NOTIFY If the route changes, notify the
user.
RTM_F_CLONED Route is cloned from another route.
RTM_F_EQUALIZE Allow randomization of next hop
path in multi-path routing
(currently not implemented).
Attribute description Attributes applicable to this service:
----------------------------------------------- Attribute Description
RTA_UNSPEC ignored. ---------------------------------------------------
RTA_DST protocol address for route RTA_UNSPEC Ignored.
RTA_DST Protocol address for route
destination address. destination address.
RTA_SRC protocol address for route source RTA_SRC Protocol address for route source
address. address.
RTA_IIF Input interface index. RTA_IIF Input interface index.
RTA_OIF Output interface index. RTA_OIF Output interface index.
RTA_GATEWAY protocol address for the gateway of RTA_GATEWAY Protocol address for the gateway of
the route the route
RTA_PRIORITY Priority of route. RTA_PRIORITY Priority of route.
RTA_PREFSRC RTA_PREFSRC Preferred source address in cases
RTA_METRICS Route metric
RTA_MULTIPATH
RTA_PROTOINFO
RTA_FLOW
RTA_CACHEINFO
additional netlink message types applicable to this service: jhs_hk_ak_ank draft-forces-Netlink-03.txt
RTM_NEWROUTE, RTM_DELROUTE, RTM_GETROUTE
5.1.2. Neighbour Setup Service Module where more than one source address
could be used.
RTA_METRICS Route metrics attributed to route
and associated protocols (e.g.,
RTT, initial TCP window, etc.).
RTA_MULTIPATH Multipath route next hop's
attributes.
RTA_PROTOINFO Firewall based policy routing
attribute.
RTA_FLOW Route realm.
RTA_CACHEINFO Cached route information.
This service provides the ability to add, remove or receive infor- Additional Netlink message types applicable to this service:
mation about a neighbour table entry (e.g. an ARP entry). The ser- RTM_NEWROUTE, RTM_DELROUTE, and RTM_GETROUTE
vice message template is shown below.
4.1.2. Neighbour Setup Service Module
This service provides the ability to add, remove, or receive infor-
mation about a neighbour table entry (e.g., an ARP entry or an IPv4
neighbour solicitation, etc.). The service message template is
shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Padding | Padding | | Family | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | | Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | Flags | Type | | State | Flags | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
jhs_hk_ak_ank draft-forces-netlink-02.txt jhs_hk_ak_ank draft-forces-Netlink-03.txt
Family: Address Family Family: 8 bits
Address Family: AF_INET for IPv4; and AF_INET6 for IPV4.
Interface Index: The unique interface index Interface Index: 32 bits
The unique interface index.
State: is a bitmask of the following states: State: 16 bits
NUD_INCOMPLETE a currently resolving cache entry A bitmask of the following states:
NUD_REACHABLE a confirmed working cache entry NUD_INCOMPLETE Still attempting to resolve.
NUD_STALE an expired cache entry NUD_REACHABLE A confirmed working cache entry
NUD_DELAY an entry waiting for a timer NUD_STALE an expired cache entry.
NUD_PROBE a cache entry that is currently NUD_DELAY Neighbour no longer reachable.
reprobed Traffic sent, waiting for
NUD_FAILED an invalid cache entry confirmation.
NUD_NOARP a device with no destination cache NUD_PROBE A cache entry that is currently
NUD_PERMANENT a static entry being re-solicited.
NUD_FAILED An invalid cache entry.
NUD_NOARP A device which does not do neighbor
discovery (ARP).
NUD_PERMANENT A static entry.
Flags: one of: Flags: 8 bits
NTF_PROXY a proxy arp entry NTF_PROXY A proxy ARP entry.
NTF_ROUTER an IPv6 router NTF_ROUTER An IPv6 router.
Attributes applicable to this service: Attributes applicable to this service:
Attributes description Attributes Description
------------------------------------ ------------------------------------
NDA_UNSPEC unknown type NDA_UNSPEC Unknown type.
NDA_DST a neighbour cache network NDA_DST A neighbour cache network.
layer destination address layer destination address
NDA_LLADDR a neighbour cache link layer NDA_LLADDR A neighbour cache link layer
address address.
NDA_CACHEINFO cache statistics. NDA_CACHEINFO Cache statistics.
Describe the NDA_CACHEINFO nda_cacheinfo header later --JHS
additional netlink message types applicable to this service: Additional Netlink message types applicable to this service:
RTM_NEWNEIGH, RTM_DELNEIGH, RTM_GETNEIGH RTM_NEWNEIGH, RTM_DELNEIGH, and RTM_GETNEIGH.
5.1.3. Traffic Control Service 4.1.3. Traffic Control Service
This service provides the ability to provision, query or listen to This service provides the ability to provision, query or listen to
events under the auspicies of traffic control. These include Queueing events under the auspicies of traffic control. These include
disciplines (schedulers and queue treatment algorithms eg Priority based queueing disciplines, (schedulers and queue treatment
scheduler or RED algorithm) and classifiers. Linux Traffic Control Ser-
vice is very flexible and allows for hierachical cascading of the dif-
ferent blocks for traffic sharing. The service message template which
makes this possible is shown below. Each of the specific component of
the model has unique attributes which describe it best. The common
jhs_hk_ak_ank draft-forces-netlink-02.txt jhs_hk_ak_ank draft-forces-Netlink-03.txt
attributes as well which are described below. algorithms--e.g., priority-based scheduler or the RED algorithm)
and classifiers. Linux Traffic Control Service is very flexible
and allows for hierachical cascading of the different blocks for
traffic resource sharing.
++ ++ +-----+ +-------+ ++ ++ .++
|| . || +------+ | |-->| Qdisc |-->|| || ||
|| ||---->|Filter|--->|Class| +-------+ ||-+ || ||
|| || | +------+ | +---------------+| | || ||
|| . || | +----------------------+ | || .||
|| . || | +------+ | || ||
|| || +->|Filter|-_ +-----+ +-------+ ++ | || .||
|| -->|| | +------+ ->| |-->| Qdisc |-->|| | ||->||
|| . || | |Class| +-------+ ||-+-->|| .||
->dev->|| || | +------+ _->| +---------------+| || ||
|| || +->|Filter|- +----------------------+ || .||
|| || +------+ || .||
|| . |+----------------------------------------------+| ||
|| | Parent Queuing discipline | .||
|| . +------------------------------------------------+ .||
|| . . .. . . .. . . . .. .. .. . .. ||
|+--------------------------------------------------------+|
| Parent Queuing discipline |
| (attached to egress device) |
+----------------------------------------------------------+
The above diagram shows an example of the Egress TC block. We try
to be very brief here. For more information, please refer to
[Diffserv]. A packet first goes through a filter that is used to
identify a class to which the packet may belong. A class is essen-
tially a terminal queueing discipline and has a queue associated
with it. The queue may be subject to a simple algorithm, like
FIFO, or a more complex one, like RED or a token bucket. The out-
ermost queueing discipline, which is refered to as the parent is
typically associated with a scheduler. Within this scheduler hier-
archy, however, may be other scheduling algorithms, making the
Linux Egress TC very flexible.
The service message template that makes this possible is shown
below. This template is used in both the ingress and the egress
queueing disciplines (refer to the egress traffic control model in
the FE model section). Each of the specific components of the
model has unique attributes that describe it best. The common
attributes are described below.
jhs_hk_ak_ank draft-forces-Netlink-03.txt
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Padding | Padding | | Family | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | | Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qdisc handle | | Qdisc handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent Qdisc | | Parent Qdisc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCM Info | | TCM Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
jhs_hk_ak_ank draft-forces-netlink-02.txt Family: 8 bits
Address Family: AF_INET for IPv4; and AF_INET6 for IPV4.
Family: Address Family Interface Index: 32 bits
The unique interface index.
Interface Index: The unique interface index Qdisc handle: 32 bits
Unique identifier for instance of queueing discipline. Typically,
this is split into major:minor of 16 bits each. The major number
would also be the major number of the parent of this instance.
Qdisc handle: unique identifier for instance of queueing discipline. Parent Qdisc: 32 bits
Typically this is split into major:minor of 16 bits each. The major Used in hierarchical layering of queueing disciplines. If this
number would also be the major number of the parent of this instance. value and the Qdisc handle are the same and equal to TC_H_ROOT,
then the defined qdisc is the top most layer known as the root
qdisc.
Parent Qdisc: This is used in hierarchical layering of queueing jhs_hk_ak_ank draft-forces-Netlink-03.txt
disciplines.
If this value and the Qdisc handle are the same and equal to TC_H_ROOT
then the defined qdisc is the top most layer known as the root qdisc.
TCM Info: This is set by the FE to 1 typically except when the qdisc TCM Info: 32 bits
instance is in use, in which case it is set to imply a reference count. Set by the FE to 1 typically, except when the Qdisc instance is in
use, in which case it is set to imply a reference count. From the
CPC towards the direction of the FEC, this is typically set to 0
except when used in the context of filters. In that case, this
32-bit field is split into a 16-bit priority field and 16-bit
protocol field. The protocol is defined in kernel source
<include/linux/if_ether.h>, however, the most commonly used one
is ETH_P_IP (the IP protocol).
Attributes applicable to this service: The priority is used for conflict resolution when filters
intersect in their expressions.
Attribute description Generic attributes applicable to this service:
Attribute Description
------------------------------------ ------------------------------------
TCA_KIND canonical name of FE component TCA_KIND Canonical name of FE component.
TCA_STATS generic usage statistics of FEC TCA_STATS Generic usage statistics of FEC
TCA_RATE rate estimator being attached to TCA_RATE rate estimator being attached to
FEC. Takes snapshots of stats to FEC. Takes snapshots of stats to
compute rate compute rate.
TCA_XSTATS specific statistics of FEC TCA_XSTATS Specific statistics of FEC.
TCA_OPTIONS nested FEC-specific attributes TCA_OPTIONS Nested FEC-specific attributes.
[should we define all FEC-specific attributes? Seems like a lot of work Appendix 3 has an example of configuring an FE component for a FIFO
Qdisc.
[We still need to talk about classes and filters; later -- jhs] Additional Netlink message types applicable to this service:
RTM_NEWQDISC, RTM_DELQDISC, RTM_GETQDISC, RTM_NEWTCLASS, RTM_DELT-
CLASS, RTM_GETTCLASS, RTM_NEWTFILTER, RTM_DELTFILTER, and RTM_GET-
TFILTER.
5.2. IP Service NETLINK_FIREWALL 4.2. IP Service NETLINK_FIREWALL
This service allows CPCs to receive packets sent by the IPv4 fire- This service allows CPCs to receive, manipulate, and re-inject
wall service in the FE. packets via the IPv4 firewall service modules in the FE. A fire-
wall rule is first inserted to activate packet redirection. The
CPC informs the FEC whether it would like to receive just the meta-
data on the packet or the actual data and, if the metadata is
desired, what is the maximum data length to be redirected. The
redirected packets are still stored in the FEC, waiting a verdict
Two types of messages exist that can be sent from CPC to FEC. These jhs_hk_ak_ank draft-forces-Netlink-03.txt
are: Mode messages and Verdict messages. The formats are described
below.
jhs_hk_ak_ank draft-forces-netlink-02.txt from the CPC. The verdict could constitute a simple accept or drop
decision of the packet, in which case the verdict is imposed on the
packet still sitting on the FEC. The verdict may also include a
modified packet to be sent on as a replacement.
The Verdict message format is as follows Two types of messages exist that can be sent from CPC to FEC.
These are: Mode messages and Verdict messages. Mode messages are
sent immediately to the FEC to describe what the CPC would like to
receive. Verdict messages are sent to the FEC after a decision has
been made on the fate of a received packet. The formats are
described below.
The mode message is described first.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Mode | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload ... | | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A ipq_packet_msg packet type is sent from the FEC to the CPC. The Mode: 8 bits
format is described below ==> We need to complete this later Control information on the packet to be sent to the CPC. The
different types are:
5.3. IP Service NETLINK_ARPD
This service is used by CPCs for managing the ARP table in FE. IPQ_COPY_META Copy only packet metadata to CPC.
IPQ_COPY_PACKET Copy packet metadata and packet payloads
to CPC.
5.4. IP Service NETLINK_ROUTE6 Range: 32 bits
If IPQ_COPY_PACKET, this defines the maximum length to copy.
This service allows CPCs to modify the IPv6 routing table in the jhs_hk_ak_ank draft-forces-Netlink-03.txt
FE. It can also be used by CPCs to receive routing updates.
jhs_hk_ak_ank draft-forces-netlink-02.txt A packet and associated metadata received from user space looks
as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 dst addr | | Packet ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 dst addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 dst addr | | Mark |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 dst addr | | timestamp_m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 src addr | | timestamp_u |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 src addr | | hook |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 src addr | | indev_name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 src addr | | outdev_name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 gw addr | | hw_protocol | hw_type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 gw addr | | hw_addrlen | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 gw addr | | hw_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 gw addr | | data_len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | | Payload . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dst length | src length |
Packet ID: 32 bits
The unique packet identifier as passed to the CPC by the FEC.
Mark: 32 bits
The internal metadata value set to describe the rule in which
the packet was picked.
timestamp_m: 32 bits
Packet arrival time (seconds)
timestamp_u: 32 bits
Packet arrival time (useconds in addition to the seconds in
timestamp_m)
hook: 32 bits
jhs_hk_ak_ank draft-forces-Netlink-03.txt
The firewall module from which the packet was picked.
indev_name: 128 bits
ASCII name of incoming interface.
outdev_name: 128 bits
ASCII name of outgoing interface.
hw_protocol: 16 bits
Hardware protocol, in network order.
hw_type: 16 bits
Hardware type.
hw_addrlen: 8 bits
Hardware address length.
hw_addr: 64 bits
Hardware address.
data_len: 32 bits
Length of packet data.
Payload: size defined by data_len
The payload of the packet received.
The Verdict message format is as follows
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Info | | Packet ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | | Payload . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. IP Service NETLINK_IP6_FW Value: 32 bits
This is the verdict to be imposed on the packet still sitting
in the FEC. Verdicts could be:
NF_ACCEPT Accept the packet and let it continue its
traversal.
NF_DROP Drop the packet.
This service allows CPCs to receive packets that failed the IPv6 jhs_hk_ak_ank draft-forces-Netlink-03.txt
jhs_hk_ak_ank draft-forces-netlink-02.txt Packet ID: 32 bits
The packet identifier as passed to the CPC by the FEC.
firewall checks by that module in the FE. Data Length: 32 bits
The data length of the modified packet (in bytes). If you dont
modify the packet just set it to 0.
6. Security Considerations Payload:
Size as defined by the Data Length field.
4.3. IP Service NETLINK_ARPD
This service is used by CPCs for managing the neighbor table in the
FE. The message format used between the FEC and CPC is described
in the section on the Neighbour Setup Service Module.
The CPC service is expected to participate in neighbor solicitation
protocol(s).
A neighbor message of type RTM_NEWNEIGH is sent towards the CPC by
the FE to inform the CPC of changes that might have happened on
that neighbour's entry (e.g., a neighbor being perceived as
unreachable).
RTM_GETNEIGH is used to solicit the CPC for information on a spe-
cific neighbor.
5. Security Considerations
Netlink lives in a trusted environment of a single host separated Netlink lives in a trusted environment of a single host separated
by kernel and user space. Linux capabilities ensures that only by kernel and user space. Linux capabilities ensure that only
someone with CAP_NET_ADMIN capability (typically root user) is someone with CAP_NET_ADMIN capability (typically, the root user) is
allowed to open sockets. allowed to open sockets.
7. References 6. References
jhs_hk_ak_ank draft-forces-Netlink-03.txt
[RFC1633] R. Braden, D. Clark, and S. Shenker, "Integrated [RFC1633] R. Braden, D. Clark, and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC 1633, Services in the Internet Architecture: an Overview", RFC 1633,
ISI, MIT, and PARC, June 1994. ISI, MIT, and PARC, June 1994.
[RFC1812] F. Baker, "Requirements for IP Version 4 [RFC1812] F. Baker, "Requirements for IP Version 4
Routers", RFC 1812, June 1995. Routers", RFC 1812, June 1995.
[RFC2475] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. [RFC2475] M. Carlson, W. Weiss, S. Blake, Z. Wang, D.
Black, and E. Davies, "An Architecture for Differentiated Black, and E. Davies, "An Architecture for Differentiated
skipping to change at page 27, line 5 skipping to change at page 30, line 31
[RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998.
[RFC1157] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin, [RFC1157] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin,
"Simple Network Management Protocol (SNMP)", RFC 1157, May "Simple Network Management Protocol (SNMP)", RFC 1157, May
1990. 1990.
[RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette,
B. Thomas "LDP Specification", RFC 3036, January 2001. B. Thomas "LDP Specification", RFC 3036, January 2001.
jhs_hk_ak_ank draft-forces-netlink-02.txt [Stevens] G.R Wright, W. Richard Stevens. "TCP/IP Illus-
[stevens] G.R Wright, W. Richard Stevens. "TCP/IP Illus-
trated Volume 2, Chapter 20", June 1995 trated Volume 2, Chapter 20", June 1995
8. Acknowledgements [Netfilter] http://netfilter.samba.org
1) Andi Kleen for man pages on netlink and rtnetlink. [Diffserv] http://diffserv.sourceforge.net
7. Acknowledgements
1) Andi Kleen, for man pages on netlink and rtnetlink.
2) Alexey Kuznetsov is credited for extending Netlink to the IP ser-
vice delivery model. The original Netlink character device was
jhs_hk_ak_ank draft-forces-Netlink-03.txt
2) Alexey Kuznetsov is credited for extending netlink to the IP ser-
vice delivery model. The original netlink character device was
written by Alan Cox. written by Alan Cox.
9. Author's Address: 3) Jeremy Ethridge for taking the role of someone who did not under-
stand Netlink and reviewing the document to make sure that it made
sense.
8. Author's Address:
Jamal Hadi Salim Jamal Hadi Salim
Znyx Networks Znyx Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
hadi@znyx.com hadi@znyx.com
Hormuzd M Khosravi Hormuzd M Khosravi
Intel Intel
2111 N.E. 25th Avenue JF3-206 2111 N.E. 25th Avenue JF3-206
skipping to change at line 1126 skipping to change at page 31, line 39
Andi Kleen Andi Kleen
SuSE SuSE
Stahlgruberring 28 Stahlgruberring 28
81829 Muenchen 81829 Muenchen
Germany Germany
Alexey Kuznetsov Alexey Kuznetsov
INR/Swsoft INR/Swsoft
Moscow Moscow
Russia Russia
9. Appendix 1: Sample Service Hierachy
In the diagram below we show a simple IP service, foo, and the
interaction it has between CP and FE components for the service
(labels 1-3).
The diagram is also used to demonstrate CP<->FE addressing. In
this section, we illustrate only the addressing semantics. In
Apendix 2, the diagram is referenced again to define the protocol
interaction between service foo's CPC and FEC (labels 4-10).
jhs_hk_ak_ank draft-forces-Netlink-03.txt
CP
[--------------------------------------------------------.
| .-----. |
| | . -------. |
| | CLI | / |
| | | | CP protocol |
| /->> -. | component | <-. |
| __ _/ | | For | | |
| | | IP service | ^ |
| Y | foo | | |
| | ___________/ ^ |
| Y 1,4,6,8,9 / ^ 2,5,10 | 3,7 |
--------------- Y------------/---|----------|-----------
| ^ | ^
**|***********|****|**********|**********
************* Netlink layer ************
**|***********|****|**********|**********
FE | | ^ ^
.-------- Y-----------Y----|--------- |----.
| | / |
| Y / |
| . --------^-------. / |
| |FE component/module|/ |
| | for IP Service | |
--->---|------>---| foo |----->-----|------>--
| ------------------- |
| |
| |
------------------------------------------
The control plane protocol for IP service foo does the following to
connect to its FE counterpart. The steps below are also numbered
above in the diagram.
1) Connect to the IP service foo through a socket connect. A typical
connection would be via a call to: socket(AF_NETLINK, SOCK_RAW,
NETLINK_FOO).
2) Bind to listen to specific asynchronous events for service foo.
3) Bind to listen to specific asynchronous FE events.
jhs_hk_ak_ank draft-forces-Netlink-03.txt
10. Appendix 2: Sample Protocol for the Foo IP Service
Our example IP service foo is used again to demonstrate how one can
deploy a simple IP service control using Netlink.
These steps are continued from Appendix 1 (hence the numbering).
4) Query for current config of FE component.
5) Receive response to (4) via channel on (3).
6) Query for current state of IP service foo.
7) Receive response to (6) via channel on (2).
9) Register the protocol-specific packets you would like the FE to
forward to you.
10) Send service-specific foo commands and receive responses for them,
if needed.
10.1. Interacting with Other IP services
The diagram in Appendix 1 shows another control component configur-
ing the same service. In this case, it is a proprietary Command
Line Interface. The CLI may or may not be using the Netlink proto-
col to communicate to the foo component. If the CLI issues com-
mands that will affect the policy of the FEC for service foo then,
then the foo CPC is notified. It could then make algorithmic deci-
sions based on this input. For example, if an FE allowed another
service to delete policies installed by a different service and a
policy that foo installed was deleted by service bar, there might
be a need to propagate this to all the peers of service foo.
11. Appendix 3: Examples
In this example, we show a simple configuration Netlink message
sent from a TC CPC to an egress TC FIFO queue. This queue algo-
rithm is based on packet counting and drops packets when the limit
exceeds 100 packets. We assume that the queue is in a hierachical
setup with a parent 100:0 and a classid of 100:1 and that it is to
be installed on a device with an ifindex of 4.
jhs_hk_ak_ank draft-forces-Netlink-03.txt
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (52) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (RTM_NEWQDISC) | Flags (NLM_F_EXCL | |
| |NLM_F_CREATE | NLM_F_REQUEST)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number(arbitrary number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Process ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Family(AF_INET)| Reserved1 | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qdisc handle (0x1000001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent Qdisc (0x1000000) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCM Info (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TCA_KIND) | Length(4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ("pfifo") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TCA_OPTIONS) | Length(4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (limit=100) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/