draft-ietf-forces-netlink-04.txt   rfc3549.txt 
ForCES Working Group Jamal Hadi Salim Network Working Group J. Salim
Internet Draft Znyx Networks Request for Comments: 3549 Znyx Networks
Expiration: June 2003 Hormuzd Khosravi Category: Informational H. Khosravi
Intel Intel
Andi Kleen A. Kleen
Suse Suse
Alexey Kuznetsov A. Kuznetsov
INR/Swsoft INR/Swsoft
December 2002 July 2003
Netlink as an IP Services Protocol Linux Netlink as an IP Services Protocol
draft-ietf-forces-netlink-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. Internet-Drafts are working not specify an Internet standard of any kind. Distribution of this
documents of the Internet Engineering Task Force (IETF), its areas, memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes Linux Netlink, which is used in Linux both This document describes Linux Netlink, which is used in Linux both as
as an intra-kernel messaging system as well as between kernel and an intra-kernel messaging system as well as between kernel and user
user space. This document is intended as informational in the space. The focus of this document is to describe Netlink's
context of prior art for the ForCES IETF working group. The focus functionality as a protocol between a Forwarding Engine Component
of this (FEC) and a Control Plane Component (CPC), the two components that
document is to describe Netlink from a perspective of a protocol define an IP service. As a result of this focus, this document
between a Forwarding Engine Component (FEC) and a Control Plane ignores other uses of Netlink, including its use as a intra-kernel
Component (CPC), the two components that define an IP service.
The document ignores the ability of Netlink as a intra-kernel
messaging system, as an inter-process communication scheme (IPC), or messaging system, as an inter-process communication scheme (IPC), or
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
as a configuration tool for other non-networking or non-IP network as a configuration tool for other non-networking or non-IP network
services (such as decnet, etc.). services (such as decnet, etc.).
This document is intended as informational in the context of prior
art for the ForCES IETF working group.
Table of Contents Table of Contents
1. Introduction ................................................. 2 1. Introduction ............................................... 2
1.1. Definitions ............................................ 3 1.1. Definitions ........................................... 3
1.1.1. Control Plane Components (CPCs)................... 3 1.1.1. Control Plane Components (CPCs)................ 3
1.1.2. Forwarding Engine Components (FECs)............... 4 1.1.2. Forwarding Engine Components (FECs)............ 3
1.1.2.1. Linux IP Forwarding Engine Model............ 4 1.1.3. IP Services ................................... 5
1.1.3. IP Services ...................................... 5 2. Netlink Architecture ....................................... 7
2. Netlink Architecture ......................................... 7 2.1. Netlink Logical Model ................................. 8
2.1. Netlink Logical Model .................................. 8 2.2. Message Format......................................... 9
2.2. Message Format.......................................... 9 2.3. Protocol Model......................................... 9
2.3. Protocol Model.......................................... 9 2.3.1. Service Addressing............................. 10
2.3.1. Service Addressing................................ 10 2.3.2. Netlink Message Header......................... 10
2.3.2. Netlink Message Header............................ 10 2.3.3. FE System Services' Templates.................. 13
2.3.2.1. Mechanisms for Creating Protocols........... 12 3. Currently Defined Netlink IP Services....................... 16
2.3.2.2. The ACK Netlink Message..................... 12 3.1. IP Service NETLINK_ROUTE............................... 16
2.3.3. FE System Services' Templates..................... 13 3.1.1. Network Route Service Module................... 16
2.3.3.1. Network Interface Service Module............. 13 3.1.2. Neighbor Setup Service Module.................. 20
2.3.3.2. IP Address Service Module................... 15 3.1.3. Traffic Control Service........................ 21
3. Currently Defined Netlink IP Services......................... 16 3.2. IP Service NETLINK_FIREWALL............................ 23
3.1. IP Service NETLINK_ROUTE................................ 16 3.3. IP Service NETLINK_ARPD................................ 27
3.1.1. Network Route Service Module...................... 17 4. References.................................................. 27
3.1.2. Neighbour Setup Service Module.................... 19 4.1. Normative References................................... 27
3.1.3. Traffic Control Service........................... 21 4.2. Informative References................................. 28
3.2. IP Service NETLINK_FIREWALL............................. 23 5. Security Considerations..................................... 28
3.3. IP Service NETLINK_ARPD................................. 27 6. Acknowledgements............................................ 28
4. References.................................................... 27 Appendix 1: Sample Service Hierarchy .......................... 29
4.1. Normative References.................................... 27 Appendix 2: Sample Protocol for the Foo IP Service............. 30
4.2. Informative References.................................. 28 Appendix 2a: Interacting with Other IP services................. 30
5. Security Considerations....................................... 28 Appendix 3: Examples........................................... 31
6. Acknowledgements.............................................. 29 Authors' Addresses.............................................. 32
7. Author's Address............................................. 29 Full Copyright Statement........................................ 33
8. Appendix 1: Sample Service Hierachy .......................... 30
9. Appendix 2: Sample Protocol for the Foo IP Service............ 31
9.1. Interacting with Other IP services...................... 31
10. Appendix 3: Examples......................................... 32
1. Introduction 1. 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 sockets introduced in the early 1990s by the BSD 4.4 routing sockets [9].
[9]. The focus at that time was a simple IP(v4) forwarding The focus at that time was a simple IP(v4) forwarding service and how
service and how the CPC, either via a command line configuration the CPC, either via a command line configuration tool or a dynamic
route daemon, could control forwarding tables for that IPv4
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt forwarding service.
tool or a dynamic route daemon, could control forwarding tables for
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 and management Netlink, when observed from a service provisioning and management
point of view, takes routing sockets one step further by breaking point of view, takes routing sockets one step further by breaking the
the barrier of focus around IPv4 forwarding. Since the Linux 2.1 barrier of focus around IPv4 forwarding. Since the Linux 2.1 kernel,
kernel, Netlink has been providing the IP service abstraction to a Netlink has been providing the IP service abstraction to a few
few services other than the classical RFC 1812 IPv4 forwarding. services other than the classical RFC 1812 IPv4 forwarding.
The motivation for this document is not to list every possible The motivation for this document is not to list every possible
service for which Netlink is applied. In fact, we leave out a lot service for which Netlink is applied. In fact, we leave out a lot of
of services (multicast routing, tunnelling, policy routing, etc). services (multicast routing, tunneling, policy routing, etc). Neither
Neither is this document intended to be a tutorial on Netlink. The is this document intended to be a tutorial on Netlink. The idea is
idea is to explain the overall Netlink view with a special focus on to explain the overall Netlink view with a special focus on the
the mandatory building blocks within the ForCES charter (i.e., IPv4 mandatory building blocks within the ForCES charter (i.e., IPv4 and
and QoS). This document also serves to capture prior art to many QoS). This document also serves to capture prior art to many
mechanisms that are useful within the context of ForCES. The text mechanisms that are useful within the context of ForCES. The text is
is limited to a subset of what is available in kernel 2.4.6, the limited to a subset of what is available in kernel 2.4.6, the newest
newest kernel when this document was first written. It is also kernel when this document was first written. It is also limited to
limited to IPv4 functionality. IPv4 functionality.
We first give some concept definitions and then describe how We first give some concept definitions and then describe how Netlink
Netlink fits in. fits in.
1.1. Definitions 1.1. Definitions
A Control Plane (CP) is an execution environment that may have A Control Plane (CP) is an execution environment that may have
several sub-components, which we refer to as CPCs. Each CPC several sub-components, which we refer to as CPCs. Each CPC provides
provides control for a different IP service being executed by a control for a different IP service being executed by a Forwarding
Forwarding Engine (FE) component. This relationship means that Engine (FE) component. This relationship means that there might be
there might be several CPCs on a physical CP, if it is controlling several CPCs on a physical CP, if it is controlling several IP
several IP services. In essence, the cohesion between a CP services. In essence, the cohesion between a CP component and an FE
component and an FE component is the service abstraction. component is the service abstraction.
1.1.1. Control Plane Components (CPCs) 1.1.1. Control Plane Components (CPCs)
Control Plane Components encompass signalling protocols, with Control Plane Components encompass signalling protocols, with
diversity ranging from dynamic routing protocols, such as OSPF diversity ranging from dynamic routing protocols, such as OSPF [5],
[5], to tag distribution protocols, such as CR-LDP [7]. to tag distribution protocols, such as CR-LDP [7]. Classical
Classical management protocols and activities also fall under this management protocols and activities also fall under this category.
category. These include SNMP [6], COPS [4], and proprietary These include SNMP [6], COPS [4], and proprietary CLI/GUI
CLI/GUI configuration mechanisms. configuration mechanisms. The purpose of the control plane is to
The purpose of the control plane is to provide an execution provide an execution environment for the above-mentioned activities
environment for the above-mentioned activities with the ultimate with the ultimate goal being to configure and manage the second
goal being to configure and manage the second Network Element (NE) Network Element (NE) component: the FE. The result of the
component: the FE. The result of the configuration defines the way configuration defines the way that packets traversing the FE are
that packets traversing the FE are treated. treated.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
1.1.2. Forwarding Engine Components (FECs) 1.1.2. Forwarding Engine Components (FECs)
The FE is the entity of the NE that incoming packets (from the The FE is the entity of the NE that incoming packets (from the
network into the NE) first encounter. network into the NE) first encounter.
The FE's service-specific component massages the packet to provide The FE's service-specific component massages the packet to provide it
it with a treatment to achieve an IP service, as defined by the with a treatment to achieve an IP service, as defined by the Control
Control Plane Components for that IP service. Different services Plane Components for that IP service. Different services will
will utilize different FECs. Service modules may be chained to utilize different FECs. Service modules may be chained to achieve a
achieve a more complex service (refer to the Linux FE model, more complex service (refer to the Linux FE model, described later).
described later). When built for providing a specific service, the When built for providing a specific service, the FE service component
FE service component will adhere to a forwarding model. will adhere to a forwarding model.
1.1.2.1. Linux IP Forwarding Engine Model 1.1.2.1. Linux IP Forwarding Engine Model
____ +---------------+ ____ +---------------+
+->-| FW |---> | TCP, UDP, ... | +->-| FW |---> | TCP, UDP, ... |
| +----+ +---------------+ | +----+ +---------------+
| | | |
^ v ^ v
| _|_ | _|_
+----<----+ | FW | +----<----+ | FW |
skipping to change at page 4, line 43 skipping to change at page 4, line 31
stack stack stack stack
^ | ^ |
|_____ | |_____ |
Ingress ^ Y Ingress ^ Y
device ____ +-------+ +|---|--+ ____ +--------+ Egress device ____ +-------+ +|---|--+ ____ +--------+ Egress
->----->| FW |-->|Ingress|-->---->| Forw- |->| FW |->| Egress | device ->----->| FW |-->|Ingress|-->---->| Forw- |->| FW |->| Egress | device
+----+ | TC | | ard | +----+ | TC |--> +----+ | TC | | ard | +----+ | TC |-->
+-------+ +-------+ +--------+ +-------+ +-------+ +--------+
The figure above shows the Linux FE model per device. The only The figure above shows the Linux FE model per device. The only
mandatory part of the datapath is the Forwarding module, which is mandatory part of the datapath is the Forwarding module, which is RFC
RFC 1812 conformant. The different Firewall (FW), Ingress Traffic 1812 conformant. The different Firewall (FW), Ingress Traffic
Control, and Egress Traffic Control building blocks are not Control, and Egress Traffic Control building blocks are not mandatory
mandatory in the datapath and may even be used to bypass the RFC in the datapath and may even be used to bypass the RFC 1812 module.
1812 module. These modules are shown as simple blocks in the These modules are shown as simple blocks in the datapath but, in
datapath but, in fact, could be multiple cascaded, independent fact, could be multiple cascaded, independent submodules within the
indicated blocks. More information can be found at [10] and [11].
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
submodules within the indicated blocks. More information can be
found at [10] and [11].
Packets arriving at the ingress device first pass through a Packets arriving at the ingress device first pass through a firewall
firewall module. Packets may be dropped, munged, etc., by the module. Packets may be dropped, munged, etc., by the firewall
firewall module. The incoming packet, depending on set policy, module. The incoming packet, depending on set policy, may then be
may then be passed via an Ingress Traffic Control module. passed via an Ingress Traffic Control module. Metering and policing
Metering and policing activities are contained within the activities are contained within the Ingress TC module. Packets may
Ingress TC module. Packets may be dropped, depending on be dropped, depending on metering results and policing policies, at
metering results and policing policies, at this module. this module. Next, the packet is subjected to the only non-optional
Next, the packet is subjected to the only non-optional module, module, the RFC 1812-conformant Forwarding module. The packet may be
the RFC 1812-conformant Forwarding module. dropped if it is nonconformant (to the many RFCs complementing 1812
The packet may be dropped if it is nonconformant (to the many RFCs and 1122). This module is a juncture point at which packets destined
complementing 1812 and 1122). This module is a juncture point at to the forwarding NE may be sent up to the host stack.
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 Packets that are not for the NE may further traverse a policy routing
routing submodule (within the forwarding module), if so submodule (within the forwarding module), if so provisioned. Another
provisioned. firewall module is walked next. The firewall module can drop or
Another firewall module is walked next. The firewall module can munge/transform packets, depending on the configured sub-modules
drop or munge/transform packets, depending on the configured encountered and their policies. If all goes well, the Egress TC
sub-modules encountered and their policies. If all goes well, module is accessed next.
the Egress TC module is accessed next.
The Egress TC may drop packets for policing, scheduling, congestion The Egress TC may drop packets for policing, scheduling, congestion
control, or rate control reasons. Egress queues exist at this control, or rate control reasons. Egress queues exist at this point
point and any of the drops or delays may happen before or after the and any of the drops or delays may happen before or after the packet
packet is queued. All is dependent on configured module algorithms is queued. All is dependent on configured module algorithms and
and policies. policies.
1.1.3. IP Services 1.1.3. IP Services
An IP service is the treatment of an IP packet within the NE. This 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. 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 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 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 service in this context is a Per-Hop Behavior. CP components running
running on NEs define the end-to-end path control for a service by on NEs define the end-to-end path control for a service by running
running control/signaling protocol/management-applications. These control/signaling protocol/management-applications. These
distributed CPCs unify the end-to-end view of the IP service. As 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 noted above, these CP components then define the behavior of the FE
(and therefore the NE) for a described packet. (and therefore the NE) for a described packet.
A simple example of an IP service is the classical IPv4 Forwarding. A simple example of an IP service is the classical IPv4 Forwarding.
In this case, control components, such as routing protocols (OSPF, In this case, control components, such as routing protocols (OSPF,
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
RIP, etc.) and proprietary CLI/GUI configurations, modify the FE's RIP, etc.) and proprietary CLI/GUI configurations, modify the FE's
forwarding tables in order to offer the simple service of forwarding tables in order to offer the simple service of forwarding
forwarding packets to the next hop. Traditionally, NEs offering packets to the next hop. Traditionally, NEs offering this simple
this simple service are known as routers. In the diagram below, service are known as routers.
we show a simple FE<->CP setup to provide an example of the
classical IPv4 service with an extension to do some basic QoS In the diagram below, we show a simple FE<->CP setup to provide an
egress scheduling and illustrate how the setup fits in this 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. described model.
Control Plane (CP) Control Plane (CP)
.------------------------------------ .------------------------------------
| /^^^^^^\ /^^^^^^\ | | /^^^^^^\ /^^^^^^\ |
| | | | COPS |-\ | | | | | COPS |-\ |
| | ospfd | | PEP | \ | | | ospfd | | PEP | \ |
| \ / \_____/ | | | \ / \_____/ | |
/------\_____/ | / | /------\_____/ | / |
| | | | / | | | | | / |
skipping to change at page 6, line 37 skipping to change at page 6, line 31
Forwarding ************* Netlink layer ************ Forwarding ************* Netlink layer ************
Engine (FE) ***************************************** Engine (FE) *****************************************
.-------------|-----------|----------|---|------------- .-------------|-----------|----------|---|-------------
| IPv4 forwarding | | | | IPv4 forwarding | | |
| FE Service / / | | FE Service / / |
| Component / / | | Component / / |
| ---------------/---------------/--------- | | ---------------/---------------/--------- |
| | | / | | | | | / | |
packet | | --------|-- ----|----- | packet packet | | --------|-- ----|----- | packet
in | | | IPv4 | | Egress | | out in | | | IPv4 | | Egress | | out
-->--->|------>|---->|Forwading |----->| QoS |--->| ---->|-> -->--->|------>|---->|Forwarding|----->| QoS |--->| ---->|->
| | | | | Scheduler| | | | | | | | Scheduler| | |
| | ----------- ---------- | | | | ----------- ---------- | |
| | | | | | | |
| --------------------------------------- | | --------------------------------------- |
| | | |
------------------------------------------------------- -------------------------------------------------------
The above diagram illustrates ospfd, an OSPF protocol control The above diagram illustrates ospfd, an OSPF protocol control daemon,
daemon, and a COPS Policy Enforcement Point (PEP) as distinct CPCs. and a COPS Policy Enforcement Point (PEP) as distinct CPCs. The IPv4
The IPv4 FE component includes the IPv4 Forwarding service module FE component includes the IPv4 Forwarding service module as well as
as well as the Egress Scheduling service module. Another service the Egress Scheduling service module. Another service might add a
might add a policy forwarder between the IPv4 forwarder and the QoS policy forwarder between the IPv4 forwarder and the QoS egress
egress scheduler. A simpler classical service would have scheduler. A simpler classical service would have constituted only
constituted only the IPv4 forwarder. the IPv4 forwarder.
Over the years, it has become important to add aditional services
to routers to meet emerging requirements. More complex services
extending classical forwarding have been added and standardized.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
Over the years, it has become important to add additional services to
routers to meet emerging requirements. More complex services
extending classical forwarding have been added and standardized.
These newer services might go beyond the layer 3 contents of the These newer services might go beyond the layer 3 contents of the
packet header. However, the name "router," although a misnomer, is packet header. However, the name "router", although a misnomer, is
still used to describe these NEs. Services (which may look beyond still used to describe these NEs. Services (which may look beyond
the classical L3 service headers) include firewalling, QoS in the classical L3 service headers) include firewalling, QoS in
Diffserv and RSVP, NAT, policy based routing, etc. Newer control Diffserv and RSVP, NAT, policy based routing, etc. Newer control
protocols or management activities are introduced with these new protocols or management activities are introduced with these new
services. services.
One extreme definition of a IP service is something for which a One extreme definition of a IP service is something for which a
service provider would be able to charge. service provider would be able to charge.
2. Netlink Architecture 2. Netlink Architecture
Control of IP service components 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 The FEC and CPC participate to deliver the IP service by
communicating using these templates. The FEC might continously get communicating using these templates. The FEC might continuously get
updates from the Control Plane Component on how to operate the updates from the Control Plane Component on how to operate the
service (e.g., for v4 forwarding or for route additions or service (e.g., for v4 forwarding or for route additions or
deletions). deletions).
The interaction between the FEC and the CPC, in the Netlink The interaction between the FEC and the CPC, in the Netlink context,
context, defines a protocol. Netlink provides mechanisms for the defines a protocol. Netlink provides mechanisms for the CPC
CPC (residing in user space) and the 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 is normally provided is needed to communicate. The wire protocol is normally provided by
by some privileged service that is able to copy between multiple some privileged service that is able to copy between multiple
protection domains. We will refer to this service as the Netlink protection domains. We will refer to this service as the Netlink
service. The Netlink service can also be encapsulated in a service. The Netlink service can also be encapsulated in a different
different transport layer, if the CPC executes on a different node transport layer, if the CPC executes on a different node than the
than the FEC. The FEC and CPC, using Netlink mechanisms, may FEC. The FEC and CPC, using Netlink mechanisms, may choose to define
choose to define a reliable protocol between each other. By a reliable protocol between each other. By default, however, Netlink
default, however, Netlink provides an unreliable communication. provides an unreliable communication.
Note that the FEC and CPC can both live in the same memory Note that the FEC and CPC can both live in the same memory protection
protection domain and use the connect() system call to create a domain and use the connect() system call to create a path to the peer
path to the peer and talk to each other. We will not discuss this and talk to each other. We will not discuss this mechanism further
mechanism further other than to say that it is available. other than to say that it is available. Throughout this document, we
Throughout this document, we will refer interchangebly to the FEC will refer interchangeably to the FEC to mean kernel space and the
to mean kernel space and the CPC to mean user space. This CPC to mean user space. This denomination is not meant, however, to
denomination is not meant, however, to restrict the two components restrict the two components to these protection domains or to the
to these protection domains or to the same compute node. 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.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
2.1. Netlink Logical Model 2.1. Netlink Logical Model
In the diagram below we show a simple FEC<->CPC logical In the diagram below we show a simple FEC<->CPC logical relationship.
relationship. We use the IPv4 forwarding FEC (NETLINK_ROUTE, We use the IPv4 forwarding FEC (NETLINK_ROUTE, which is discussed
which is discussed further below) as an example. 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 | |
| | / \____ _/ | | | / \____ _/ |
| \____/ | | | \____/ | |
| | | | | | | |
skipping to change at page 8, line 45 skipping to change at page 8, line 43
| | | |
----------------------------------------------------- -----------------------------------------------------
Netlink logically models FECs and CPCs in the form of nodes Netlink logically models FECs and CPCs in the form of nodes
interconnected to each other via a broadcast wire. interconnected 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.
Nodes (CPCs or FECs as illustrated above) connect to the wire and Nodes (CPCs or FECs as illustrated above) connect to the wire and
register to receive specific messages. CPCs may connect to register to receive specific messages. CPCs may connect to multiple
multiple wires if it helps them to control the service better. All wires if it helps them to control the service better. All nodes
nodes (CPCs and FECs) dump packets on the broadcast wire. Packets (CPCs and FECs) dump packets on the broadcast wire. Packets can be
can be discarded by the wire if they are malformed or not discarded by the wire if they are malformed or not specifically
specifically formatted for the wire. Dropped packets are not seen formatted for the wire. Dropped packets are not seen by any of the
by any of the nodes. The Netlink service may signal an error to nodes. The Netlink service may signal an error to the sender if it
the sender if it detects a malformatted Netlink packet. detects a malformatted Netlink packet.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
Packets sent on the wire can be broadcast, multicast, or unicast. Packets sent on the wire can be broadcast, multicast, or unicast.
FECs or CPCs register for specific messages of interest for FECs or CPCs register for specific messages of interest for
processing or just monitoring purposes. processing or just monitoring purposes.
Appendices 1 and 2 have a high level overview of this interaction. Appendices 1 and 2 have a high level overview of this interaction.
2.2. Message Format 2.2. Message Format
There are three levels to a Netlink message: The general Netlink There are three levels to a Netlink message: The general Netlink
message header, the IP service specific template, and the IP message header, the IP service specific template, and the IP service
service specific data. 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 parameterization of the FECs, asynchronous event notification of
of FEC events to the CPCs, and statistics querying/gathering FEC events to the CPCs, and statistics querying/gathering (typically
(typically by a CPC). by a CPC).
The Netlink message header is generic for all services, whereas the The Netlink message header is generic for all services, whereas the
IP Service Template header is specific to a service. Each IP IP Service Template header is specific to a service. Each IP Service
Service then carries parametrization data (CPC->FEC direction) or then carries parameterization data (CPC->FEC direction) or response
response (FEC->CPC direction). These parametrizations are in TLV (FEC->CPC direction). These parameterizations are in TLV (Type-
(Type-Length-Value) format and are unique to the service. Length-Value) format and are unique to the service.
The different parts of the netlink message are discussed in the The different parts of the netlink message are discussed in the
following sections. following sections.
2.3. Protocol Model 2.3. Protocol Model
This section expands on how Netlink provides the mechanism for This section expands on how Netlink provides the mechanism for
service-oriented FEC and CPC interaction. service-oriented FEC and CPC interaction.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
2.3.1. Service Addressing 2.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. The
The connection is achieved by making a socket() system call to the connection is achieved by making a socket() system call to the
PF_NETLINK domain. Each FEC is identified by a protocol number. PF_NETLINK domain. Each FEC is identified by a protocol number. One
One may open either SOCK_RAW or SOCK_DGRAM type sockets, although may open either SOCK_RAW or SOCK_DGRAM type sockets, although Netlink
Netlink does not distinguish between the two. The socket does not distinguish between the two. The socket connection provides
connection provides the basis for the FE<->CP addressing. 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
of the connection) by either issuing a service-specific command the connection) by either issuing a service-specific command (from
(from the CPC to the FEC, mostly for configuration purposes), the CPC to the FEC, mostly for configuration purposes), issuing a
issuing a statistics-collection command, or statistics-collection command, or subscribing/unsubscribing to
subscribing/unsubscribing to service events. Closing the socket service events. Closing the socket terminates the transaction.
terminates the transaction.
Refer to Appendices 1 and 2 for examples. Refer to Appendices 1 and 2 for examples.
2.3.2. Netlink Message Header 2.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 an associated payload. If the payload is too Netlink headers and an associated payload. If the payload is too big
big to fit into a single message it, can be split over multiple to fit into a single message it, can be split over multiple Netlink
Netlink messages, collectively called a multipart message. For messages, collectively called a multipart message. For multipart
multipart messages, the first and all following headers have the messages, the first and all following headers have the NLM_F_MULTI
NLM_F_MULTI Netlink header flag set, except for the last header Netlink header flag set, except for the last header which has the
which has the Netlink header type NLMSG_DONE. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | | Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 47 skipping to change at page 11, line 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | | Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Process ID (PID) | | Process ID (PID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the header are: The fields in the header are:
J. Hadi Salim et al draft-ietf-forces-netlink-04.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.
skipping to change at page 11, line 44 skipping to change at page 11, line 43
request is from user space (CPC) to kernel request is from user space (CPC) to kernel
space (FEC). 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 entries 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
because it has the potential to interrupt privileges because it has the potential to
service in the FE for a longer time. interrupt 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
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
exists. 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
skipping to change at page 12, line 44 skipping to change at page 13, line 9
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.
2.3.2.2. The ACK Netlink Message 2.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 FEC to CPC (in response to an ACK Typically, the direction is from FEC to CPC (in response to an ACK
request message). However, the CPC should be able to send ACKs request message). However, the CPC should be able to send ACKs back
back to FEC when requested. The semantics for this are IP to FEC when requested. The semantics for this are IP service
service specific. specific.
J. Hadi Salim et al draft-ietf-forces-netlink-04.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
An error code of zero indicates that the message is an ACK An error code of zero indicates that the message is an ACK response.
response. An ACK response message contains the original Netlink An ACK response message contains the original Netlink message header,
message header, which can be used to compare against (sent sequence which can be used to compare against (sent sequence numbers, etc).
numbers, etc).
A non-zero error code message is equivalent to a Negative ACK A non-zero error code message is equivalent to a Negative ACK (NACK).
(NACK). In such a situation, the Netlink data that was sent down In such a situation, the Netlink data that was sent down to the
to the kernel is returned appended to the original Netlink message kernel is returned appended to the original Netlink message header.
header. An error code printable via the perror() is also set (not An error code printable via the perror() is also set (not in the
in the message header, rather in the executing environment state message header, rather in the executing environment state variable).
variable).
2.3.3. FE System Services' Templates 2.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
by other services. They include the ability to configure, gather 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 create this section for management, link events, etc. fit here. We create this section for
these services for logical separation, despite the fact that they these services for logical separation, despite the fact that they are
are accessed via the NETLINK_ROUTE FEC. The reason that they exist accessed via the NETLINK_ROUTE FEC. The reason that they exist
within NETLINK_ROUTE is due to historical cruft: the BSD 4.4 Route within NETLINK_ROUTE is due to historical cruft: the BSD 4.4 Route
Sockets implemented them as part of the IPv4 forwarding sockets. Sockets implemented them as part of the IPv4 forwarding sockets.
2.3.3.1. Network Interface Service Module 2.3.3.1. Network Interface Service Module
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
This service provides the ability to create, remove, or get This service provides the ability to create, remove, or get
information about a specific network interface. The network information about a specific network interface. The network
interface can be either physical or virtual and is network protocol interface can be either physical or virtual and is network protocol
independent (e.g., an x.25 interface can be defined via this independent (e.g., an x.25 interface can be defined via this
message). The Interface service message template is shown below. message). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved | Device Type | | Family | Reserved | Device Type |
skipping to change at page 14, line 38 skipping to change at page 14, line 38
Device Type: 16 bits Device Type: 16 bits
This defines the type of the link. The link could be Ethernet, a 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 tunnel, etc. We are interested only in IPv4, although the link type
is L3 protocol-independent. is L3 protocol-independent.
Interface Index: 32 bits Interface Index: 32 bits
Uniquely identifies interface. Uniquely identifies interface.
Device Flags: 32 bits Device Flags: 32 bits
IFF_UP Interface is administrativel up. IFF_UP Interface is administratively 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 Interface is operationally up. IFF_RUNNING Interface is operationally up.
IFF_NOARP No ARP protocol needed for this interface. 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 was dynamically created. IFF_DYNAMIC Interface was dynamically created.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
Change Mask: 32 bits Change Mask: 32 bits
Reserved for future use. Must be set to 0xFFFFFFFF. 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 ifindex of link to which this device IFLA_LINK ifindex of link to which this device
is bound. is bound.
IFLA_QDISC ASCII string defining egress root IFLA_QDISC ASCII string defining egress root
queueing discipline. queuing discipline.
IFLA_STATS Interface statistics. IFLA_STATS Interface statistics.
Netlink message types specific to this service: Netlink message types specific to this service:
RTM_NEWLINK, RTM_DELLINK, and RTM_GETLINK RTM_NEWLINK, RTM_DELLINK, and RTM_GETLINK
2.3.3.2. IP Address Service Module 2.3.3.2. IP Address Service Module
This service provides the ability to add, remove, or receive information This service provides the ability to add, remove, or receive
about an IP address associated with an interface. The address information about an IP address associated with an interface. The
provisioning service message template is shown below. address provisioning 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Length | Flags | Scope | | Family | Length | Flags | Scope |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | | Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: 8 bits Family: 8 bits
Address Family: AF_INET for IPv4; and AF_INET6 for IPV6. Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
Length: 8 bits Length: 8 bits
The length of the address mask. The length of the address mask.
Flags: 8 bits Flags: 8 bits
IFA_F_SECONDARY For secondary address (alias interface). IFA_F_SECONDARY For secondary address (alias interface).
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
IFA_F_PERMANENT For a permanent address set by the user. IFA_F_PERMANENT For a permanent address set by the user.
When this is not set, it means the address When this is not set, it means the address
was dynamically created (e.g., by stateless was dynamically created (e.g., by stateless
autoconfiguration). autoconfiguration).
IFA_F_DEPRECATED Defines deprecated (IPV4) address. IFA_F_DEPRECATED Defines deprecated (IPV4) address.
IFA_F_TENTATIVE Defines tentative (IPV4) address (duplicate IFA_F_TENTATIVE Defines tentative (IPV4) address (duplicate
address detection is still in progress). address detection is still in progress).
Scope: 8 bits Scope: 8 bits
The address scope in which the address stays valid. The address scope in which the address stays valid.
SCOPE_UNIVERSE: Global scope. SCOPE_UNIVERSE: Global scope.
SCOPE_SITE (IPv6 only): Only valid within this site. SCOPE_SITE (IPv6 only): Only valid within this site.
SCOPE_LINK: Valid only on this device. SCOPE_LINK: Valid only on this device.
SCOPE_HOST: Valid only on this host. SCOPE_HOST: Valid only on this host.
Applicable attributes: le attributes:
Attribute Description Attribute Description
.........................................................
IFA_UNSPEC Unspecified. IFA_UNSPEC Unspecified.
IFA_ADDRESS Raw protocol address of interface. IFA_ADDRESS Raw protocol address of interface.
IFA_LOCAL Raw protocol local address. IFA_LOCAL Raw protocol local address.
IFA_LABEL ASCII string name of the interface. IFA_LABEL ASCII string name of the interface.
IFA_BROADCAST Raw protocol broadcast address. IFA_BROADCAST Raw protocol broadcast address.
IFA_ANYCAST Raw protocol anycast address. IFA_ANYCAST Raw protocol anycast address.
IFA_CACHEINFO Cache address information. IFA_CACHEINFO Cache address information.
Netlink messages specific to this service: RTM_NEWADDR, Netlink messages specific to this service: RTM_NEWADDR,
RTM_DELADDR, and RTM_GETADDR. RTM_DELADDR, and RTM_GETADDR.
skipping to change at page 16, line 41 skipping to change at page 16, line 38
IFA_CACHEINFO Cache address information. IFA_CACHEINFO Cache address information.
Netlink messages specific to this service: RTM_NEWADDR, Netlink messages specific to this service: RTM_NEWADDR,
RTM_DELADDR, and RTM_GETADDR. RTM_DELADDR, and RTM_GETADDR.
3. Currently Defined Netlink IP Services 3. Currently Defined Netlink IP Services
Although there are many other IP services defined that are using Although there are many other IP services defined that are using
Netlink, as mentioned earlier, we will talk only about a handful of Netlink, as mentioned earlier, we will talk only about a handful of
those integrated into kernel version 2.4.6. These are: those integrated into kernel version 2.4.6. These are:
NETLINK_ROUTE, NETLINK_FIREWALL, and NETLINK_ARPD. NETLINK_ROUTE, NETLINK_FIREWALL, and NETLINK_ARPD.
3.1. IP Service NETLINK_ROUTE 3.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 to collect statistics. updates, as well as to collect statistics.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
3.1.1. Network Route Service Module 3.1.1. Network Route Service Module
This service provides the ability to create, remove or receive This service provides the ability to create, remove or receive
information about a network route. The service message template is information about a network route. The service message template is
shown below. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Src length | Dest length | TOS | | Family | Src length | Dest length | TOS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Table ID | Protocol | Scope | Type | | Table ID | Protocol | Scope | Type |
skipping to change at page 17, line 40 skipping to change at page 17, line 33
TOS: 8 bits TOS: 8 bits
The 8-bit TOS (should be deprecated to make room for DSCP). The 8-bit TOS (should be deprecated to make room for DSCP).
Table ID: 8 bits Table ID: 8 bits
Table identifier. Up to 255 route tables are supported. Table identifier. Up to 255 route tables are supported.
RT_TABLE_UNSPEC An unspecified routing table. RT_TABLE_UNSPEC An unspecified routing table.
RT_TABLE_DEFAULT The default table. RT_TABLE_DEFAULT The default table.
RT_TABLE_MAIN The main table. RT_TABLE_MAIN The main table.
RT_TABLE_LOCAL The local table. RT_TABLE_LOCAL The local table.
The user may assign arbitary values between The user may assign arbitrary values between
RT_TABLE_UNSPEC(0) and RT_TABLE_DEFAULT(253). RT_TABLE_UNSPEC(0) and RT_TABLE_DEFAULT(253).
Protocol: 8 bits Protocol: 8 bits
Identifies what/who added the route. 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.
RTPROT_KERNEL By the kernel. RTPROT_KERNEL By the kernel.
RTPROT_BOOT During bootup. RTPROT_BOOT During bootup.
RTPROT_STATIC By the administrator. RTPROT_STATIC By the administrator.
Values larger than RTPROT_STATIC(4) are not interpreted by the Values larger than RTPROT_STATIC(4) are not interpreted by the
kernel, they are just for user information. They may be used to kernel, they are just for user information. They may be used to
tag the source of a routing information or to distinguish between
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
tag the source of a routing information or to distingush between
multiple routing daemons. See <linux/rtnetlink.h> for the multiple routing daemons. See <linux/rtnetlink.h> for the
routing daemon identifiers that are already assigned. routing daemon identifiers that are already assigned.
Scope: 8 bits Scope: 8 bits
Route scope (valid distance to destination). Route scope (valid distance to destination).
RT_SCOPE_UNIVERSE Global route. RT_SCOPE_UNIVERSE Global route.
RT_SCOPE_SITE Interior route in the RT_SCOPE_SITE Interior route in the
local autonomous system. local autonomous system.
RT_SCOPE_LINK Route on this link. RT_SCOPE_LINK Route on this link.
RT_SCOPE_HOST Route on the local host. RT_SCOPE_HOST Route on the local host.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
continue routing lookup in another continue routing lookup in another
table. Under normal routing, table. Under normal routing,
packets are dropped and net packets are dropped and net
unreachable ICMPs are sent to the unreachable ICMPs are sent to the
originator. originator.
RTN_NAT A network address translation RTN_NAT A network address translation
rule. rule.
RTN_XRESOLVE Refer to an external resolver (not RTN_XRESOLVE Refer to an external resolver (not
implemented). implemented).
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
Flags: 32 bits Flags: 32 bits
Further qualify the route. Further qualify the route.
RTM_F_NOTIFY If the route changes, notify the RTM_F_NOTIFY If the route changes, notify the
user. user.
RTM_F_CLONED Route is cloned from another route. RTM_F_CLONED Route is cloned from another route.
RTM_F_EQUALIZE Allow randomization of next hop RTM_F_EQUALIZE Allow randomization of next hop
path in multi-path routing path in multi-path routing
(currently not implemented). (currently not implemented).
Attributes applicable to this service: Attributes applicable to this service:
skipping to change at page 19, line 45 skipping to change at page 20, line 5
RTA_MULTIPATH Multipath route next hop's RTA_MULTIPATH Multipath route next hop's
attributes. attributes.
RTA_PROTOINFO Firewall based policy routing RTA_PROTOINFO Firewall based policy routing
attribute. attribute.
RTA_FLOW Route realm. RTA_FLOW Route realm.
RTA_CACHEINFO Cached route information. RTA_CACHEINFO Cached route information.
Additional Netlink message types applicable to this service: Additional Netlink message types applicable to this service:
RTM_NEWROUTE, RTM_DELROUTE, and RTM_GETROUTE RTM_NEWROUTE, RTM_DELROUTE, and RTM_GETROUTE
3.1.2. Neighbour Setup Service Module 3.1.2. Neighbor Setup Service Module
This service provides the ability to add, remove, or receive This service provides the ability to add, remove, or receive
information about a neighbour table entry (e.g., an ARP entry or information about a neighbor table entry (e.g., an ARP entry or an
an IPv4 neighbour solicitation, etc.). The service message IPv4 neighbor solicitation, etc.). The service message template is
template is shown below. shown below.
J. Hadi Salim et al draft-ietf-forces-netlink-04.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved1 | Reserved2 | | Family | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | | Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | Flags | Type | | State | Flags | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 28 skipping to change at page 20, line 33
Address Family: AF_INET for IPv4; and AF_INET6 for IPV6. Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
Interface Index: 32 bits Interface Index: 32 bits
The unique interface index. The unique interface index.
State: 16 bits State: 16 bits
A bitmask of the following states: A bitmask of the following states:
NUD_INCOMPLETE Still attempting to resolve. NUD_INCOMPLETE Still attempting to resolve.
NUD_REACHABLE A confirmed working cache entry NUD_REACHABLE A confirmed working cache entry
NUD_STALE an expired cache entry. NUD_STALE an expired cache entry.
NUD_DELAY Neighbour no longer reachable. NUD_DELAY Neighbor no longer reachable.
Traffic sent, waiting for Traffic sent, waiting for
confirmation. confirmation.
NUD_PROBE A cache entry that is currently NUD_PROBE A cache entry that is currently
being re-solicited. being re-solicited.
NUD_FAILED An invalid cache entry. NUD_FAILED An invalid cache entry.
NUD_NOARP A device which does not do neighbor NUD_NOARP A device which does not do neighbor
discovery (ARP). discovery (ARP).
NUD_PERMANENT A static entry. NUD_PERMANENT A static entry.
Flags: 8 bits 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 neighbor cache link layer
address. address.
NDA_CACHEINFO Cache statistics. NDA_CACHEINFO Cache statistics.
Additional Netlink message types applicable to this service: Additional Netlink message types applicable to this service:
RTM_NEWNEIGH, RTM_DELNEIGH, and RTM_GETNEIGH. RTM_NEWNEIGH, RTM_DELNEIGH, and RTM_GETNEIGH.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
3.1.3. Traffic Control Service 3.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 events under the auspices of traffic control. These include queuing
queueing disciplines, (schedulers and queue treatment disciplines, (schedulers and queue treatment algorithms -- e.g.,
algorithms--e.g., priority-based scheduler or the RED algorithm) priority-based scheduler or the RED algorithm) and classifiers.
and classifiers. Linux Traffic Control Service is very flexible Linux Traffic Control Service is very flexible and allows for
and allows for hierachical cascading of the different blocks for hierarchical cascading of the different blocks for traffic resource
traffic resource sharing. sharing.
++ ++ +-----+ +-------+ ++ ++ .++ ++ ++ +-----+ +-------+ ++ ++ .++
|| . || +------+ | |-->| Qdisc |-->|| || || || . || +------+ | |-->| Qdisc |-->|| || ||
|| ||---->|Filter|--->|Class| +-------+ ||-+ || || || ||---->|Filter|--->|Class| +-------+ ||-+ || ||
|| || | +------+ | +---------------+| | || || || || | +------+ | +---------------+| | || ||
|| . || | +----------------------+ | || .|| || . || | +----------------------+ | || .||
|| . || | +------+ | || || || . || | +------+ | || ||
|| || +->|Filter|-_ +-----+ +-------+ ++ | || .|| || || +->|Filter|-_ +-----+ +-------+ ++ | || .||
|| -->|| | +------+ ->| |-->| Qdisc |-->|| | ||->|| || -->|| | +------+ ->| |-->| Qdisc |-->|| | ||->||
|| . || | |Class| +-------+ ||-+-->|| .|| || . || | |Class| +-------+ ||-+-->|| .||
skipping to change at page 21, line 38 skipping to change at page 21, line 49
|| || +------+ || .|| || || +------+ || .||
|| . |+----------------------------------------------+| || || . |+----------------------------------------------+| ||
|| | Parent Queuing discipline | .|| || | Parent Queuing discipline | .||
|| . +------------------------------------------------+ .|| || . +------------------------------------------------+ .||
|| . . .. . . .. . . . .. .. .. . .. || || . . .. . . .. . . . .. .. .. . .. ||
|+--------------------------------------------------------+| |+--------------------------------------------------------+|
| Parent Queuing discipline | | Parent Queuing discipline |
| (attached to egress device) | | (attached to egress device) |
+----------------------------------------------------------+ +----------------------------------------------------------+
The above diagram shows an example of the Egress TC block. We try The above diagram shows an example of the Egress TC block. We try to
to be very brief here. For more information, please refer to be very brief here. For more information, please refer to [11]. A
[11]. A packet first goes through a filter that is used to packet first goes through a filter that is used to identify a class
identify a class to which the packet may belong. A class is to which the packet may belong. A class is essentially a terminal
essentially a terminal queueing discipline and has a queue queuing discipline and has a queue associated with it. The queue may
associated with it. The queue may be subject to a simple be subject to a simple algorithm, like FIFO, or a more complex one,
algorithm, like FIFO, or a more complex one, like RED or a token like RED or a token bucket. The outermost queuing discipline, which
bucket. The outermost queueing discipline, which is refered to as is referred to as the parent is typically associated with a
the parent is typically associated with a scheduler. Within this scheduler. Within this scheduler hierarchy, however, may be other
scheduler hierarchy, however, may be other scheduling algorithms, scheduling algorithms, making the Linux Egress TC very flexible.
making the Linux Egress TC very flexible.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
The service message template that makes this possible is shown The service message template that makes this possible is shown below.
below. This template is used in both the ingress and the egress This template is used in both the ingress and the egress queuing
queueing disciplines (refer to the egress traffic control model disciplines (refer to the egress traffic control model in the FE
in the FE model section). Each of the specific components of the model section). Each of the specific components of the model has
model has unique attributes that describe it best. The common unique attributes that describe it best. The common attributes are
attributes are described below. described 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved1 | Reserved2 | | Family | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | | Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qdisc handle | | Qdisc handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 35 skipping to change at page 22, line 39
| TCM Info | | TCM Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: 8 bits Family: 8 bits
Address Family: AF_INET for IPv4; and AF_INET6 for IPV6. Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
Interface Index: 32 bits Interface Index: 32 bits
The unique interface index. The unique interface index.
Qdisc handle: 32 bits Qdisc handle: 32 bits
Unique identifier for instance of queueing discipline. Typically, Unique identifier for instance of queuing discipline. Typically,
this is split into major:minor of 16 bits each. The major number 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. would also be the major number of the parent of this instance.
Parent Qdisc: 32 bits Parent Qdisc: 32 bits
Used in hierarchical layering of queueing disciplines. If this Used in hierarchical layering of queuing disciplines. If this value
value and the Qdisc handle are the same and equal to TC_H_ROOT, and the Qdisc handle are the same and equal to TC_H_ROOT, then the
then the defined qdisc is the top most layer known as the root defined qdisc is the top most layer known as the root qdisc.
qdisc.
TCM Info: 32 bits TCM Info: 32 bits
Set by the FE to 1 typically, except when the Qdisc instance is in 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 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 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 except when used in the context of filters. In that case, this 32-
32-bit field is split into a 16-bit priority field and 16-bit bit field is split into a 16-bit priority field and 16-bit protocol
protocol field. The protocol is defined in kernel source field. The protocol is defined in kernel source
<include/linux/if_ether.h>, however, the most commonly used one <include/linux/if_ether.h>, however, the most commonly used one is
is ETH_P_IP (the IP protocol). ETH_P_IP (the IP protocol).
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
The priority is used for conflict resolution when filters The priority is used for conflict resolution when filters intersect
intersect in their expressions. in their expressions.
Generic attributes applicable to this service: Generic attributes applicable to this service:
Attribute Description 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.
skipping to change at page 23, line 32 skipping to change at page 23, line 35
Qdisc. Qdisc.
Additional Netlink message types applicable to this service: Additional Netlink message types applicable to this service:
RTM_NEWQDISC, RTM_DELQDISC, RTM_GETQDISC, RTM_NEWTCLASS, RTM_NEWQDISC, RTM_DELQDISC, RTM_GETQDISC, RTM_NEWTCLASS,
RTM_DELTCLASS, RTM_GETTCLASS, RTM_NEWTFILTER, RTM_DELTFILTER, and RTM_DELTCLASS, RTM_GETTCLASS, RTM_NEWTFILTER, RTM_DELTFILTER, and
RTM_GETTFILTER. RTM_GETTFILTER.
3.2. IP Service NETLINK_FIREWALL 3.2. IP Service NETLINK_FIREWALL
This service allows CPCs to receive, manipulate, and re-inject This service allows CPCs to receive, manipulate, and re-inject
packets via the IPv4 firewall service modules in the FE. A fire- packets via the IPv4 firewall service modules in the FE. A firewall
wall rule is first inserted to activate packet redirection. The rule is first inserted to activate packet redirection. The CPC
CPC informs the FEC whether it would like to receive just the meta- informs the FEC whether it would like to receive just the metadata on
data on the packet or the actual data and, if the metadata is the packet or the actual data and, if the metadata is desired, what
desired, what is the maximum data length to be redirected. The is the maximum data length to be redirected. The redirected packets
redirected packets are still stored in the FEC, waiting a verdict are still stored in the FEC, waiting a verdict from the CPC. The
from the CPC. The verdict could constitute a simple accept or drop verdict could constitute a simple accept or drop decision of the
decision of the packet, in which case the verdict is imposed on the packet, in which case the verdict is imposed on the packet still
packet still sitting on the FEC. The verdict may also include a sitting on the FEC. The verdict may also include a modified packet
modified packet to be sent on as a replacement. to be sent on as a replacement.
Two types of messages exist that can be sent from CPC to FEC. Two types of messages exist that can be sent from CPC to FEC. These
These are: Mode messages and Verdict messages. Mode messages are are: Mode messages and Verdict messages. Mode messages are sent
sent immediately to the FEC to describe what the CPC would like to immediately to the FEC to describe what the CPC would like to
receive. Verdict messages are sent to the FEC after a decision has receive. Verdict messages are sent to the FEC after a decision has
been made on the fate of a received packet. The formats are been made on the fate of a received packet. The formats are
described below. described below.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
The mode message is described first. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | Reserved1 | Reserved2 | | Mode | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 5 skipping to change at page 25, line 5
Control information on the packet to be sent to the CPC. The Control information on the packet to be sent to the CPC. The
different types are: different types are:
IPQ_COPY_META Copy only packet metadata to CPC. IPQ_COPY_META Copy only packet metadata to CPC.
IPQ_COPY_PACKET Copy packet metadata and packet payloads IPQ_COPY_PACKET Copy packet metadata and packet payloads
to CPC. to CPC.
Range: 32 bits Range: 32 bits
If IPQ_COPY_PACKET, this defines the maximum length to copy. If IPQ_COPY_PACKET, this defines the maximum length to copy.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
A packet and associated metadata received from user space looks A packet and associated metadata received from user space looks
as follows. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet ID | | Packet ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mark | | Mark |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 4 skipping to change at page 25, line 51
the packet was picked. the packet was picked.
timestamp_m: 32 bits timestamp_m: 32 bits
Packet arrival time (seconds) Packet arrival time (seconds)
timestamp_u: 32 bits timestamp_u: 32 bits
Packet arrival time (useconds in addition to the seconds in Packet arrival time (useconds in addition to the seconds in
timestamp_m) timestamp_m)
hook: 32 bits hook: 32 bits
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
The firewall module from which the packet was picked. The firewall module from which the packet was picked.
indev_name: 128 bits indev_name: 128 bits
ASCII name of incoming interface. ASCII name of incoming interface.
outdev_name: 128 bits outdev_name: 128 bits
ASCII name of outgoing interface. ASCII name of outgoing interface.
hw_protocol: 16 bits hw_protocol: 16 bits
Hardware protocol, in network order. Hardware protocol, in network order.
skipping to change at page 26, line 48 skipping to change at page 26, line 44
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet ID | | Packet ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length | | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload . . . | | Payload . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value: 32 bits Value: 32 bits
This is the verdict to be imposed on the packet still sitting This is the verdict to be imposed on the packet still sitting
in the FEC. Verdicts could be: in the FEC. Verdicts could be:
NF_ACCEPT Accept the packet and let it continue its NF_ACCEPT Accept the packet and let it continue its
traversal. traversal.
NF_DROP Drop the packet. NF_DROP Drop the packet.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
Packet ID: 32 bits Packet ID: 32 bits
The packet identifier as passed to the CPC by the FEC. The packet identifier as passed to the CPC by the FEC.
Data Length: 32 bits Data Length: 32 bits
The data length of the modified packet (in bytes). If you dont The data length of the modified packet (in bytes). If you don't
modify the packet just set it to 0. modify the packet just set it to 0.
Payload: Payload:
Size as defined by the Data Length field. Size as defined by the Data Length field.
3.3. IP Service NETLINK_ARPD 3.3. IP Service NETLINK_ARPD
This service is used by CPCs for managing the neighbor table in the 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 FE. The message format used between the FEC and CPC is described in
in the section on the Neighbour Setup Service Module. the section on the Neighbor Setup Service Module.
The CPC service is expected to participate in neighbor solicitation The CPC service is expected to participate in neighbor solicitation
protocol(s). protocol(s).
A neighbor message of type RTM_NEWNEIGH is sent towards the CPC by 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 the FE to inform the CPC of changes that might have happened on that
that neighbour's entry (e.g., a neighbor being perceived as neighbor's entry (e.g., a neighbor being perceived as unreachable).
unreachable).
RTM_GETNEIGH is used to solicit the CPC for information on a RTM_GETNEIGH is used to solicit the CPC for information on a specific
specific neighbor. neighbor.
4. References 4. References
4.1. Normative References 4.1. Normative References
[1] R. Braden, D. Clark, and S. Shenker, "Integrated [1] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
Services in the Internet Architecture: an Overview", RFC 1633, the Internet Architecture: an Overview", RFC 1633, June 1994.
ISI, MIT, and PARC, June 1994.
[2] F. Baker, "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt [2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[3] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. [3] Blake, S., Black, D., Carlson, M., Davies, E, Wang, Z. and W.
Black, and E. Davies, "An Architecture for Differentiated Weiss, "An Architecture for Differentiated Services", RFC 2475,
Services", RFC 2475, December 1998. December 1998.
[4] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. [4] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
Rajan, A. Sastry, "The COPS (Common Open Policy Service) Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
Protocol", RFC 2748, January 2000. 2748, January 2000.
[5] J. Moy, "OSPF Version 2", RFC 2328, April 1998. [5] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[6] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin, [6] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple
"Simple Network Management Protocol (SNMP)", RFC 1157, May Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
1990.
[7] L. Andersson, P. Doolan, N. Feldman, A. Fredette, [7] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
B. Thomas "LDP Specification", RFC 3036, January 2001. Thomas, "LDP Specification", RFC 3036, January 2001.
[8] Y. Bernet, S. Blake, D. Grossman, A. Smith, [8] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal
"An Informal Management Model for DiffServ Routers", Management Model for DiffServ Routers", RFC 3290, May 2002.
RFC 3290, May 2002.
4.2. Informative References 4.2. Informative References
[9] G.R Wright, W. Richard Stevens. "TCP/IP Illus- [9] G. R. Wright, W. Richard Stevens. "TCP/IP Illustrated Volume 2,
trated Volume 2, Chapter 20", June 1995 Chapter 20", June 1995.
[10] http://www.netfilter.org [10] http://www.netfilter.org
[11] http://diffserv.sourceforge.net [11] http://diffserv.sourceforge.net
5. Security Considerations 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
by kernel and user space. Linux capabilities ensure that only kernel and user space. Linux capabilities ensure that only someone
someone with CAP_NET_ADMIN capability (typically, the root user) is with CAP_NET_ADMIN capability (typically, the root user) is allowed
allowed to open sockets. to open sockets.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
6. Acknowledgements 6. Acknowledgements
1) Andi Kleen, for man pages on netlink and rtnetlink. 1) Andi Kleen, for man pages on netlink and rtnetlink.
2) Alexey Kuznetsov is credited for extending Netlink to the IP 2) Alexey Kuznetsov is credited for extending Netlink to the IP
service delivery model. The original Netlink character device was service delivery model. The original Netlink character device was
written by Alan Cox. written by Alan Cox.
3) Jeremy Ethridge for taking the role of someone who did not 3) Jeremy Ethridge for taking the role of someone who did not
understand Netlink and reviewing the document to make sure that it understand Netlink and reviewing the document to make sure that it
made sense. made sense.
7. Author's Address: Appendix 1: Sample Service Hierarchy
Jamal Hadi Salim
Znyx Networks
Ottawa, Ontario
Canada
hadi@znyx.com
Hormuzd M Khosravi
Intel
2111 N.E. 25th Avenue JF3-206
Hillsboro OR 97124-5961
USA
1 503 264 0334
hormuzd.m.khosravi@intel.com
Andi Kleen
SuSE
Stahlgruberring 28
81829 Muenchen
Germany
ak@suse.de
Alexey Kuznetsov
INR/Swsoft
Moscow
Russia
kuznet@ms2.inr.ac.ru
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
8. Appendix 1: Sample Service Hierachy
In the diagram below we show a simple IP service, foo, and the In the diagram below we show a simple IP service, foo, and the
interaction it has between CP and FE components for the service interaction it has between CP and FE components for the service
(labels 1-3). (labels 1-3).
The diagram is also used to demonstrate CP<->FE addressing. In The diagram is also used to demonstrate CP<->FE addressing. In this
this section, we illustrate only the addressing semantics. In section, we illustrate only the addressing semantics. In Appendix 2,
Apendix 2, the diagram is referenced again to define the protocol the diagram is referenced again to define the protocol interaction
interaction between service foo's CPC and FEC (labels 4-10). between service foo's CPC and FEC (labels 4-10).
CP CP
[--------------------------------------------------------. [--------------------------------------------------------.
| .-----. | | .-----. |
| | . -------. | | | . -------. |
| | CLI | / \ | | | CLI | / \ |
| | | | CP protocol | | | | | | CP protocol | |
| /->> -. | component | <-. | | /->> -. | component | <-. |
| __ _/ | | For | | | | __ _/ | | For | | |
| | | IP service | ^ | | | | IP service | ^ |
skipping to change at page 31, line 4 skipping to change at page 29, line 48
| |FE component/module|/ | | |FE component/module|/ |
| | for IP Service | | | | for IP Service | |
--->---|------>---| foo |----->-----|------>-- --->---|------>---| foo |----->-----|------>--
| ------------------- | | ------------------- |
| | | |
| | | |
------------------------------------------ ------------------------------------------
The control plane protocol for IP service foo does the following to The control plane protocol for IP service foo does the following to
connect to its FE counterpart. The steps below are also numbered connect to its FE counterpart. The steps below are also numbered
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt
above in the diagram. above in the diagram.
1) Connect to the IP service foo through a socket connect. A typical 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, connection would be via a call to: socket(AF_NETLINK, SOCK_RAW,
NETLINK_FOO). NETLINK_FOO).
2) Bind to listen to specific asynchronous events for service foo. 2) Bind to listen to specific asynchronous events for service foo.
3) Bind to listen to specific asynchronous FE events. 3) Bind to listen to specific asynchronous FE events.
9. Appendix 2: Sample Protocol for the Foo IP Service Appendix 2: Sample Protocol for the Foo IP Service
Our example IP service foo is used again to demonstrate how one can Our example IP service foo is used again to demonstrate how one can
deploy a simple IP service control using Netlink. deploy a simple IP service control using Netlink.
These steps are continued from Appendix 1 (hence the numbering). These steps are continued from Appendix 1 (hence the numbering).
4) Query for current config of FE component. 4) Query for current config of FE component.
5) Receive response to (4) via channel on (3). 5) Receive response to (4) via channel on (3).
6) Query for current state of IP service foo. 6) Query for current state of IP service foo.
7) Receive response to (6) via channel on (2). 7) Receive response to (6) via channel on (2).
9) Register the protocol-specific packets you would like the FE to 8) Register the protocol-specific packets you would like the FE to
forward to you. forward to you.
10) Send service-specific foo commands and receive responses for them, 9) Send service-specific foo commands and receive responses for them,
if needed. if needed.
9.1. Interacting with Other IP services Appendix 2a: Interacting with Other IP services
The diagram in Appendix 1 shows another control component
configuring the same service. In this case, it is a proprietary
Command Line Interface. The CLI may or may not be using the
Netlink protocol to communicate to the foo component. If the CLI
issues 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. 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.
J. Hadi Salim et al draft-ietf-forces-netlink-04.txt The diagram in Appendix 1 shows another control component configuring
the same service. In this case, it is a proprietary Command Line
Interface. The CLI may or may not be using the Netlink protocol to
communicate to the foo component. If the CLI issues 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. 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.
10. Appendix 3: Examples Appendix 3: Examples
In this example, we show a simple configuration Netlink message In this example, we show a simple configuration Netlink message sent
sent from a TC CPC to an egress TC FIFO queue. This queue from a TC CPC to an egress TC FIFO queue. This queue algorithm is
algorithm is based on packet counting and drops packets when the based on packet counting and drops packets when the limit exceeds 100
limit exceeds 100 packets. We assume that the queue is in a packets. We assume that the queue is in a hierarchical setup with a
hierachical setup with a parent 100:0 and a classid of 100:1 and parent 100:0 and a classid of 100:1 and that it is to be installed on
that it is to be installed on a device with an ifindex of 4. a device with an ifindex of 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (52) | | Length (52) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (RTM_NEWQDISC) | Flags (NLM_F_EXCL | | | Type (RTM_NEWQDISC) | Flags (NLM_F_EXCL | |
| |NLM_F_CREATE | NLM_F_REQUEST)| | |NLM_F_CREATE | NLM_F_REQUEST)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number(arbitrary number) | | Sequence Number(arbitrary number) |
skipping to change at line 1473 skipping to change at page 32, line 4
| TCM Info (0) | | TCM Info (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TCA_KIND) | Length(4) | | Type (TCA_KIND) | Length(4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ("pfifo") | | Value ("pfifo") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TCA_OPTIONS) | Length(4) | | Type (TCA_OPTIONS) | Length(4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (limit=100) | | Value (limit=100) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authors' Addresses
Jamal Hadi Salim
Znyx Networks
Ottawa, Ontario
Canada
EMail: hadi@znyx.com
Hormuzd M Khosravi
Intel
2111 N.E. 25th Avenue JF3-206
Hillsboro OR 97124-5961
USA
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com
Andi Kleen
SuSE
Stahlgruberring 28
81829 Muenchen
Germany
EMail: ak@suse.de
Alexey Kuznetsov
INR/Swsoft
Moscow
Russia
EMail: kuznet@ms2.inr.ac.ru
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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