[要約] RFC 3549は、Linux NetlinkをIPサービスプロトコルとして使用するための仕様を提供しています。このRFCの目的は、Linuxシステムでネットワーク関連の情報を効率的に取得および操作するための標準化を促進することです。
Network Working Group J. Salim
Request for Comments: 3549 Znyx Networks
Category: Informational H. Khosravi
Intel
A. Kleen
Suse
A. Kuznetsov
INR/Swsoft
July 2003
Linux Netlink as an IP Services Protocol
IPサービスプロトコルとしてのLinux NetLink
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.).
このドキュメントでは、Linux Netlinkについて説明します。LinuxNetlinkは、Linuxでカーネル内のメッセージングシステムとして、およびカーネルとユーザースペースの間で使用されています。このドキュメントの焦点は、NetLinkの機能性を、IPサービスを定義する2つのコンポーネントである転送エンジンコンポーネント（FEC）とコントロールプレーンコンポーネント（CPC）の間のプロトコルとして説明することです。この焦点の結果として、このドキュメントは、インタープロセス通信スキーム（IPC）として、または他の非ネットワーキングまたは非非作業または非非ネットワーキングの構成ツールとしての使用としての使用を含む、NetLinkの他の使用を無視しています。IPネットワークサービス（Decnetなど）。
This document is intended as informational in the context of prior art for the ForCES IETF working group.
このドキュメントは、IETFワーキンググループのための以前のアートの文脈における情報としての情報として意図されています。
Table of Contents
目次
1. Introduction ............................................... 2
1.1. Definitions ........................................... 3
1.1.1. Control Plane Components (CPCs)................ 3
1.1.2. Forwarding Engine Components (FECs)............ 3
1.1.3. IP Services ................................... 5
2. Netlink Architecture ....................................... 7
2.1. Netlink Logical Model ................................. 8
2.2. Message Format......................................... 9
2.3. Protocol Model......................................... 9
2.3.1. Service Addressing............................. 10
2.3.2. Netlink Message Header......................... 10
2.3.3. FE System Services' Templates.................. 13
3. Currently Defined Netlink IP Services....................... 16
3.1. IP Service NETLINK_ROUTE............................... 16
3.1.1. Network Route Service Module................... 16
3.1.2. Neighbor Setup Service Module.................. 20
3.1.3. Traffic Control Service........................ 21
3.2. IP Service NETLINK_FIREWALL............................ 23
3.3. IP Service NETLINK_ARPD................................ 27
4. References.................................................. 27
4.1. Normative References................................... 27
4.2. Informative References................................. 28
5. Security Considerations..................................... 28
6. Acknowledgements............................................ 28
Appendix 1: Sample Service Hierarchy .......................... 29
Appendix 2: Sample Protocol for the Foo IP Service............. 30
Appendix 2a: Interacting with Other IP services................. 30
Appendix 3: Examples........................................... 31
Authors' Addresses.............................................. 32
Full Copyright Statement........................................ 33
The concept of IP Service control-forwarding separation was first introduced in the early 1990s by the BSD 4.4 routing sockets [9]. The focus at that time was a simple IP(v4) forwarding service and how the CPC, either via a command line configuration tool or a dynamic route daemon, could control forwarding tables for that IPv4 forwarding service.
IPサービスコントロールの分離の概念は、1990年代初頭にBSD 4.4ルーティングソケットによって最初に導入されました[9]。当時の焦点は、単純なIP（V4）転送サービスと、コマンドライン構成ツールまたはダイナミックルートデーモンを介したCPCが、そのIPv4転送サービスの転送テーブルを制御する方法でした。
The IP world has evolved considerably since those days. Linux Netlink, when observed from a service provisioning and management point of view, takes routing sockets one step further by breaking the barrier of focus around IPv4 forwarding. Since the Linux 2.1 kernel, Netlink has been providing the IP service abstraction to a few services other than the classical RFC 1812 IPv4 forwarding.
IPの世界は当時からかなり進化してきました。Linux Netlinkは、サービスのプロビジョニングと管理の観点から観察された場合、IPv4転送に関するフォーカスの障壁を破ることにより、ソケットをさらに一歩進めます。Linux 2.1カーネル以来、NetLinkはIPサービスの抽象化を、古典的なRFC 1812 IPv4転送以外のいくつかのサービスに提供しています。
The motivation for this document is not to list every possible service for which Netlink is applied. In fact, we leave out a lot of services (multicast routing, tunneling, policy routing, etc). Neither is this document intended to be a tutorial on Netlink. The idea is to explain the overall Netlink view with a special focus on the mandatory building blocks within the ForCES charter (i.e., IPv4 and QoS). This document also serves to capture prior art to many mechanisms that are useful within the context of ForCES. The text is limited to a subset of what is available in kernel 2.4.6, the newest kernel when this document was first written. It is also limited to IPv4 functionality.
このドキュメントの動機は、NetLinkが適用されるすべての可能なサービスをリストすることではありません。実際、多くのサービス（マルチキャストルーティング、トンネル、ポリシールーティングなど）を除外しています。このドキュメントは、NetLinkのチュートリアルになることも意図していません。アイデアは、NetLink全体のビューを、Force Charter（つまり、IPv4およびQOS）内の必須のビルディングブロックに特に焦点を当てて説明することです。このドキュメントは、力のコンテキスト内で有用な多くのメカニズムに以前の芸術を捉えるのにも役立ちます。このテキストは、このドキュメントが最初に記述されたときの最新のカーネルであるカーネル2.4.6で利用可能なもののサブセットに限定されています。また、IPv4機能に限定されています。
We first give some concept definitions and then describe how Netlink fits in.
最初にいくつかの概念定義を提供し、次にNetLinkがどのように適合するかを説明します。
A Control Plane (CP) is an execution environment that may have several sub-components, which we refer to as CPCs. Each CPC provides control for a different IP service being executed by a Forwarding Engine (FE) component. This relationship means that there might be several CPCs on a physical CP, if it is controlling several IP services. In essence, the cohesion between a CP component and an FE component is the service abstraction.
コントロールプレーン（CP）は、CPCSと呼ばれるいくつかのサブコンポーネントを持つ可能性のある実行環境です。各CPCは、転送エンジン（FE）コンポーネントによって実行される別のIPサービスの制御を提供します。この関係は、複数のIPサービスを制御している場合、物理CPに複数のCPCがある可能性があることを意味します。本質的に、CPコンポーネントとFEコンポーネントとの間の結束は、サービス抽象化です。
Control Plane Components encompass signalling protocols, with diversity ranging from dynamic routing protocols, such as OSPF [5], to tag distribution protocols, such as CR-LDP [7]. Classical management protocols and activities also fall under this category. These include SNMP [6], COPS [4], and proprietary CLI/GUI configuration mechanisms. The purpose of the control plane is to provide an execution environment for the above-mentioned activities with the ultimate goal being to configure and manage the second Network Element (NE) component: the FE. The result of the configuration defines the way that packets traversing the FE are treated.
コントロールプレーンコンポーネントには、OSPF [5]などの動的なルーティングプロトコルからCR-LDPなどの分布プロトコルのタグ付けに至るまで、多様性を備えたシグナル伝達プロトコルが含まれます。古典的な管理プロトコルとアクティビティもこのカテゴリに分類されます。これらには、SNMP [6]、COPS [4]、および独自のCLI/GUI構成メカニズムが含まれます。制御プレーンの目的は、上記のアクティビティに実行環境を提供することです。最終的な目標は、2番目のネットワーク要素（NE）コンポーネントを構成および管理することです。構成の結果は、FEを通過するパケットが処理される方法を定義します。
The FE is the entity of the NE that incoming packets (from the network into the NE) first encounter.
FEは、（ネットワークからNE）の最初の出会いを着信するパケットがneの実体です。
The FE's service-specific component massages the packet to provide it with a treatment to achieve an IP service, as defined by the Control Plane Components for that IP service. Different services will utilize different FECs. Service modules may be chained to achieve a more complex service (refer to the Linux FE model, described later). When built for providing a specific service, the FE service component will adhere to a forwarding model.
FEのサービス固有のコンポーネントは、そのIPサービスのコントロールプレーンコンポーネントで定義されているように、IPサービスを達成するための処理を提供するためにパケットをマッサージします。さまざまなサービスが異なるFECを利用します。より複雑なサービスを実現するために、サービスモジュールを連鎖させることができます（後述するLinux FEモデルを参照）。特定のサービスを提供するために構築されると、FEサービスコンポーネントは転送モデルに付着します。
____ +---------------+
+->-| FW |---> | TCP, UDP, ... |
| +----+ +---------------+
| |
^ v
| _|_
+----<----+ | FW |
| +----+
^ |
| Y
To host From host
stack stack
^ |
|_____ |
Ingress ^ Y
device ____ +-------+ +|---|--+ ____ +--------+ Egress
->----->| FW |-->|Ingress|-->---->| Forw- |->| FW |->| Egress | device
+----+ | TC | | ard | +----+ | TC |-->
+-------+ +-------+ +--------+
The figure above shows the Linux FE model per device. The only mandatory part of the datapath is the Forwarding module, which is RFC 1812 conformant. The different Firewall (FW), Ingress Traffic Control, and Egress Traffic Control building blocks are not mandatory in the datapath and may even be used to bypass the RFC 1812 module. These modules are shown as simple blocks in the datapath but, in fact, could be multiple cascaded, independent submodules within the indicated blocks. More information can be found at [10] and [11].
上の図は、デバイスごとのLinux Feモデルを示しています。DataPathの唯一の必須部分は、RFC 1812 Conformantである転送モジュールです。さまざまなファイアウォール（FW）、イングレストラフィックコントロール、および出力トラフィックコントロールのビルドブロックは、データパスでは必須ではなく、RFC 1812モジュールのバイパスにも使用できます。これらのモジュールは、データパスの単純なブロックとして表示されますが、実際には、示されたブロック内の複数のカスケード型の独立したサブモジュールである可能性があります。詳細については、[10]および[11]をご覧ください。
Packets arriving at the ingress device first pass through a firewall module. Packets may be dropped, munged, etc., by the firewall module. The incoming packet, depending on set policy, may then be passed via an Ingress Traffic Control module. Metering and policing activities are contained within the Ingress TC module. Packets may be dropped, depending on metering results and policing policies, at this module. Next, the packet is subjected to the only non-optional module, the RFC 1812-conformant Forwarding module. The packet may be dropped if it is nonconformant (to the many RFCs complementing 1812 and 1122). This module is a juncture point at which packets destined to the forwarding NE may be sent up to the host stack.
Ingressデバイスに到着するパケットは、最初にファイアウォールモジュールを通過します。ファイアウォールモジュールによって、パケットをドロップして、マンジングなど。その後、受信パケットは、設定ポリシーに応じて、イングレストラフィックコントロールモジュールを介して渡される場合があります。計量およびポリシングアクティビティは、Ingress TCモジュール内に含まれています。このモジュールでは、計量結果とポリシングポリシーに応じて、パケットが削除される場合があります。次に、パケットは、唯一の非感染モジュールであるRFC 1812-Conformant転送モジュールにさらされます。パケットが不適合である場合（1812および1122を補完する多くのRFCに対して）、パケットが削除される場合があります。このモジュールは、転送neに運命づけられたパケットをホストスタックに送信できる接合点です。
Packets that are not for the NE may further traverse a policy routing submodule (within the forwarding module), if so provisioned. Another firewall module is walked next. The firewall module can drop or munge/transform packets, depending on the configured sub-modules encountered and their policies. If all goes well, the Egress TC module is accessed next.
NE用ではないパケットは、ポリシールーティングサブモジュール（転送モジュール内）をさらに移動する場合があります。別のファイアウォールモジュールが次に歩かれます。ファイアウォールモジュールは、遭遇した構成されたサブモジュールとそのポリシーに応じて、パケットをドロップまたはMunge/変換することができます。すべてがうまくいかない場合、次に出力TCモジュールにアクセスします。
The Egress TC may drop packets for policing, scheduling, congestion control, or rate control reasons. Egress queues exist at this point and any of the drops or delays may happen before or after the packet is queued. All is dependent on configured module algorithms and policies.
出力TCは、ポリシング、スケジューリング、輻輳制御、またはレート制御の理由のためにパケットをドロップする場合があります。この時点で出口キューが存在し、パケットがキューに掲載される前または後にドロップまたは遅延のいずれかが発生する場合があります。すべては、構成されたモジュールアルゴリズムとポリシーに依存します。
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.
IPサービスとは、NE内のIPパケットの処理です。この治療は、CPCとFECの両方の組み合わせによって提供されます。
The time span of the service is from the moment when the packet arrives at the NE to the moment that it departs. In essence, an IP service in this context is a Per-Hop Behavior. CP components running on NEs define the end-to-end path control for a service by running control/signaling protocol/management-applications. These distributed CPCs unify the end-to-end view of the IP service. As noted above, these CP components then define the behavior of the FE (and therefore the NE) for a described packet.
サービスの期間は、パケットがNEに到着した瞬間から出発する瞬間です。本質的に、このコンテキストでのIPサービスは、ホップごとの動作です。NESで実行されるCPコンポーネントは、コントロール/シグナリングプロトコル/管理アプリケーションを実行することにより、サービスのエンドツーエンドパス制御を定義します。これらの分散CPCは、IPサービスのエンドツーエンドビューを統合します。上記のように、これらのCPコンポーネントは、記述されたパケットのFe（したがってNE）の動作を定義します。
A simple example of an IP service is the classical IPv4 Forwarding. In this case, control components, such as routing protocols (OSPF, RIP, etc.) and proprietary CLI/GUI configurations, modify the FE's forwarding tables in order to offer the simple service of forwarding packets to the next hop. Traditionally, NEs offering this simple service are known as routers.
IPサービスの簡単な例は、古典的なIPv4転送です。この場合、ルーティングプロトコル（OSPF、RIPなど）や独自のCLI/GUI構成などの制御コンポーネントは、FEの転送テーブルを変更して、次のホップにパケットを転送する簡単なサービスを提供します。伝統的に、このシンプルなサービスを提供するNESはルーターとして知られています。
In the diagram below, we show a simple FE<->CP setup to provide an example of the classical IPv4 service with an extension to do some basic QoS egress scheduling and illustrate how the setup fits in this described model.
以下の図では、単純なFe <-> CPセットアップを示して、基本的なQoS出力スケジューリングを行い、この記載されたモデルのセットアップがどのように適合するかを示すための拡張機能を備えたクラシックIPv4サービスの例を提供します。
Control Plane (CP)
.------------------------------------
| /^^^^^^\ /^^^^^^\ |
| | | | COPS |-\ |
| | ospfd | | PEP | \ |
| \ / \_____/ | |
/------\_____/ | / |
| | | | / |
| |_________\__________|____|_________|
| | | |
******************************************
Forwarding ************* Netlink layer ************
Engine (FE) *****************************************
.-------------|-----------|----------|---|-------------
| IPv4 forwarding | | |
| FE Service / / |
| Component / / |
| ---------------/---------------/--------- |
| | | / | |
packet | | --------|-- ----|----- | packet
in | | | IPv4 | | Egress | | out
-->--->|------>|---->|Forwarding|----->| QoS |--->| ---->|->
| | | | | Scheduler| | |
| | ----------- ---------- | |
| | | |
| --------------------------------------- |
| |
-------------------------------------------------------
The above diagram illustrates ospfd, an OSPF protocol control daemon, and a COPS Policy Enforcement Point (PEP) as distinct CPCs. The IPv4 FE component includes the IPv4 Forwarding service module as well as the Egress Scheduling service module. Another service might add a policy forwarder between the IPv4 forwarder and the QoS egress scheduler. A simpler classical service would have constituted only the IPv4 forwarder.
上記の図は、OSPFD、OSPFプロトコル制御デーモン、およびCOPSポリシー執行ポイント（PEP）を異なるCPCとして示しています。IPv4 FEコンポーネントには、IPv4転送サービスモジュールと出口スケジューリングサービスモジュールが含まれます。別のサービスは、IPv4フォワーダーとQoS Egressスケジューラの間にポリシーフォワーダーを追加する場合があります。よりシンプルなクラシックサービスは、IPv4フォワーダーのみを構成していました。
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 packet header. However, the name "router", although a misnomer, is still used to describe these NEs. Services (which may look beyond the classical L3 service headers) include firewalling, QoS in Diffserv and RSVP, NAT, policy based routing, etc. Newer control protocols or management activities are introduced with these new services.
長年にわたり、新たな要件を満たすためにルーターに追加のサービスを追加することが重要になっています。古典的な転送を拡張するより複雑なサービスが追加され、標準化されています。これらの新しいサービスは、パケットヘッダーのレイヤー3コンテンツを超えている可能性があります。ただし、「ルーター」という名前は、誤称ですが、これらのNEを説明するためにまだ使用されています。サービス（クラシックL3サービスヘッダーを超えて見る場合があります）には、Firewalling、DiffservとRSVPのQoS、NAT、ポリシーベースのルーティングなどが含まれます。これらの新しいサービスでは、新しい制御プロトコルまたは管理アクティビティが導入されています。
One extreme definition of a IP service is something for which a service provider would be able to charge.
IPサービスの極端な定義の1つは、サービスプロバイダーが請求できるものです。
Control of IP service components is defined by using templates.
IPサービスコンポーネントの制御は、テンプレートを使用して定義されます。
The FEC and CPC participate to deliver the IP service by communicating using these templates. The FEC might continuously get updates from the Control Plane Component on how to operate the service (e.g., for v4 forwarding or for route additions or deletions).
FECとCPCは、これらのテンプレートを使用して通信することにより、IPサービスを提供するために参加します。FECは、サービスの操作方法についてコントロールプレーンコンポーネントから継続的に更新を取得する場合があります（たとえば、V4転送またはルートの追加または削除の場合）。
The interaction between the FEC and the CPC, in the Netlink context, defines a protocol. Netlink provides mechanisms for the CPC (residing in user space) and the FEC (residing in kernel space) to have their own protocol definition -- kernel space and user space just mean different protection domains. Therefore, a wire protocol is needed to communicate. The wire protocol is normally provided by some privileged service that is able to copy between multiple protection domains. We will refer to this service as the Netlink service. The Netlink service can also be encapsulated in a different transport layer, if the CPC executes on a different node than the FEC. The FEC and CPC, using Netlink mechanisms, may choose to define a reliable protocol between each other. By default, however, Netlink provides an unreliable communication.
NetLinkコンテキストでのFECとCPCの間の相互作用は、プロトコルを定義します。Netlinkは、CPC（ユーザースペースに住む）とFEC（カーネルスペースに住む）に独自のプロトコル定義を持つメカニズムを提供します。カーネルスペースとユーザースペースは、保護ドメインが異なることを意味します。したがって、通信するにはワイヤプロトコルが必要です。ワイヤプロトコルは通常、複数の保護ドメイン間でコピーできる特権サービスによって提供されます。このサービスをNetlinkサービスと呼びます。CPCがFECとは異なるノードで実行される場合、NetLinkサービスは異なる輸送層にカプセル化することもできます。NetLinkメカニズムを使用したFECとCPCは、相互に信頼できるプロトコルを定義することを選択できます。ただし、デフォルトでは、NetLinkは信頼できない通信を提供します。
Note that the FEC and CPC can both live in the same memory protection domain and use the connect() system call to create a path to the peer and talk to each other. We will not discuss this mechanism further other than to say that it is available. Throughout this document, we will refer interchangeably to the FEC to mean kernel space and the CPC to mean user space. This denomination is not meant, however, to restrict the two components to these protection domains or to the same compute node.
FECとCPCは両方とも同じメモリ保護ドメインに住み、Connect（）システムコールを使用してピアへのパスを作成し、相互に話し合うことができることに注意してください。このメカニズムは、それが利用可能であると言う以外に、これ以上議論しません。このドキュメント全体を通して、FECを互換性があり、カーネルスペースを意味し、CPCはユーザースペースを意味します。ただし、この宗派は、2つのコンポーネントをこれらの保護ドメインまたは同じ計算ノードに制限することを意味しません。
Note: Netlink allows participation in IP services by both service components.
注：NetLinkは、両方のサービスコンポーネントによるIPサービスへの参加を許可します。
In the diagram below we show a simple FEC<->CPC logical relationship. We use the IPv4 forwarding FEC (NETLINK_ROUTE, which is discussed further below) as an example.
下の図では、単純なFEC <-> CPC論理関係を示しています。例として、IPv4転送FEC（以下でさらに説明します）を使用します。
Control Plane (CP)
.------------------------------------
| /^^^^^\ /^^^^^\ |
| | | / CPC-2 \ |
| | CPC-1 | | COPS | |
| | ospfd | | PEP | |
| | / \____ _/ |
| \____/ | |
| | | |
****************************************|
************* BROADCAST WIRE ************
FE---------- *****************************************.
| IPv4 forwarding | | | |
| FEC | | | |
| --------------/ ----|-----------|-------- |
| | / | | | |
| | .-------. .-------. .------. | |
| | |Ingress| | IPv4 | |Egress| | |
| | |police | |Forward| | QoS | | |
| | |_______| |_______| |Sched | | |
| | ------ | |
| --------------------------------------- |
| |
-----------------------------------------------------
Netlink logically models FECs and CPCs in the form of nodes interconnected to each other via a broadcast wire.
NetLinkは、ブロードキャストワイヤを介して相互に接続されたノードの形でFECとCPCを論理的にモデル化します。
The wire is specific to a service. The example above shows the broadcast wire belonging to the extended IPv4 forwarding service.
ワイヤーはサービスに固有です。上記の例は、拡張IPv4転送サービスに属するブロードキャストワイヤーを示しています。
Nodes (CPCs or FECs as illustrated above) connect to the wire and register to receive specific messages. CPCs may connect to multiple wires if it helps them to control the service better. All nodes (CPCs and FECs) dump packets on the broadcast wire. Packets can be discarded by the wire if they are malformed or not specifically formatted for the wire. Dropped packets are not seen by any of the nodes. The Netlink service may signal an error to the sender if it detects a malformatted Netlink packet.
ノード（上記のCPCまたはFECS）はワイヤーに接続し、特定のメッセージを受信するために登録します。CPCは、サービスをより適切に制御するのに役立つ場合、複数のワイヤーに接続する場合があります。すべてのノード（CPCSおよびFEC）は、ブロードキャストワイヤーにパケットをダンプします。ワイヤーが奇形であるか、ワイヤー用に特別にフォーマットされていない場合、ワイヤーによってパケットを破棄できます。ドロップされたパケットは、ノードのいずれにも見られません。NetLinkサービスは、奇形のNetLinkパケットを検出した場合、送信者にエラーを通知する場合があります。
Packets sent on the wire can be broadcast, multicast, or unicast. FECs or CPCs register for specific messages of interest for processing or just monitoring purposes.
ワイヤーに送信されるパケットは、ブロードキャスト、マルチキャスト、またはユニキャストを使用できます。FECまたはCPCSは、処理または監視目的で関心のある特定のメッセージに登録します。
Appendices 1 and 2 have a high level overview of this interaction.
付録1と2には、この相互作用の高レベルの概要があります。
There are three levels to a Netlink message: The general Netlink message header, the IP service specific template, and the IP service specific data.
NetLinkメッセージには3つのレベルがあります。一般的なNetLinkメッセージヘッダー、IPサービス固有のテンプレート、IPサービス固有のデータです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Netlink message header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Service Template |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Service specific data in TLVs |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Netlink message is used to communicate between the FEC and CPC for parameterization of the FECs, asynchronous event notification of FEC events to the CPCs, and statistics querying/gathering (typically by a CPC).
NetLinkメッセージは、FECとCPCの間でFECのパラメーター化、CPCへのFECイベントの非同期イベント通知、および統計クエリ/収集（通常はCPCによる）の通信に使用されます。
The Netlink message header is generic for all services, whereas the IP Service Template header is specific to a service. Each IP Service then carries parameterization data (CPC->FEC direction) or response (FEC->CPC direction). These parameterizations are in TLV (Type-Length-Value) format and are unique to the service.
NetLinkメッセージヘッダーはすべてのサービスに汎用的ですが、IPサービステンプレートヘッダーはサービスに固有です。各IPサービスは、パラメーター化データ（CPC-> FEC方向）または応答（FEC-> CPC方向）を搭載します。これらのパラメーター化は、TLV（型-length-value）形式であり、サービスに固有のものです。
The different parts of the netlink message are discussed in the following sections.
NetLinkメッセージのさまざまな部分については、次のセクションで説明します。
This section expands on how Netlink provides the mechanism for service-oriented FEC and CPC interaction.
このセクションでは、NetLinkがサービス指向のFECおよびCPC相互作用のメカニズムを提供する方法について拡張します。
Access is provided by first connecting to the service on the FE. The connection is achieved by making a socket() system call to the PF_NETLINK domain. Each FEC is identified by a protocol number. One may open either SOCK_RAW or SOCK_DGRAM type sockets, although Netlink does not distinguish between the two. The socket connection provides the basis for the FE<->CP addressing.
アクセスは、FEのサービスに最初に接続することによって提供されます。接続は、PF_NETLINKドメインにSocket（）システムコールを作成することにより実現されます。各FECは、プロトコル番号で識別されます。NetLinkは2つを区別しませんが、sock_rawまたはsock_dgramタイプのソケットのいずれかを開くことができます。ソケット接続は、Fe <-> CPアドレス指定の基礎を提供します。
Connecting to a service is followed (at any point during the life of the connection) by either issuing a service-specific command (from the CPC to the FEC, mostly for configuration purposes), issuing a statistics-collection command, or subscribing/unsubscribing to service events. Closing the socket terminates the transaction. Refer to Appendices 1 and 2 for examples.
サービスへの接続は（接続の存続期間中の任意の時点で）、CPCからFECへ、主に構成の目的で）、統計収集コマンドの発行、またはサブスクライティング/サブスクライティングの発行イベントにサービスを提供します。ソケットを閉じると、トランザクションが終了します。例については、付録1および2を参照してください。
Netlink messages consist of a byte stream with one or multiple Netlink headers and an associated payload. If the payload is too big to fit into a single message it, can be split over multiple Netlink messages, collectively called a multipart message. For multipart messages, the first and all following headers have the NLM_F_MULTI Netlink header flag set, except for the last header which has the Netlink header type NLMSG_DONE.
NetLinkメッセージは、1つまたは複数のNetLinkヘッダーと関連するペイロードを備えたバイトストリームで構成されています。ペイロードが大きすぎて単一のメッセージに収まることができない場合は、複数のNetLinkメッセージに分割することができます。マルチパートメッセージの場合、NetLinkヘッダータイプNLMSG_DONEを持つ最後のヘッダーを除き、最初とすべての次のヘッダーにはNLM_F_MULTI NetLinkヘッダーフラグセットがあります。
The Netlink message header is shown below.
NetLinkメッセージヘッダーを以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Process ID (PID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the header are:
Length: 32 bits The length of the message in bytes, including the header.
長さ：ヘッダーを含む32ビットメッセージの長さは、バイトの長さです。
Type: 16 bits This field describes the message content. It can be one of the standard message types: NLMSG_NOOP Message is ignored. NLMSG_ERROR The message signals an error and the payload contains a nlmsgerr structure. This can be looked at as a NACK and typically it is from FEC to CPC. NLMSG_DONE Message terminates a multipart message.
タイプ：16ビットこのフィールドはメッセージコンテンツを説明します。標準のメッセージタイプの1つになる可能性があります：nlmsg_noopメッセージは無視されます。NLMSG_ERRORメッセージはエラーを示し、ペイロードにはnlmsgerr構造が含まれています。これはNACKと見なすことができ、通常はFECからCPCまでです。nlmsg_doneメッセージマルチパートメッセージを終了します。
Individual IP services specify more message types, e.g., NETLINK_ROUTE service specifies several types, such as RTM_NEWLINK, RTM_DELLINK, RTM_GETLINK, RTM_NEWADDR, RTM_DELADDR, RTM_NEWROUTE, RTM_DELROUTE, etc.
個々のIPサービスは、より多くのメッセージタイプを指定します。たとえば、netlink_routeサービスは、rtm_newlink、rtm_dellink、rtm_getlink、rtm_newaddr、rtm_deladdr、rtm_newroute、rtm_delrouteなど、いくつかのタイプを指定します。
Flags: 16 bits The standard flag bits used in Netlink are NLM_F_REQUEST Must be set on all request messages (typically from user space to kernel space) NLM_F_MULTI Indicates the message is part of a multipart message terminated by NLMSG_DONE NLM_F_ACK Request for an acknowledgment on success. Typical direction of request is from user space (CPC) to kernel space (FEC). NLM_F_ECHO Echo this request. Typical direction of request is from user space (CPC) to kernel space (FEC).
フラグ：16ビットNetlinkで使用される標準フラグビットは、NLM_F_REQUESTをすべてのリクエストメッセージ（通常はユーザースペースからカーネルスペースまで）で設定する必要があります。NLM_F_MULTIは、メッセージがNLMSG_DONE NLM_F_ACKリクエストによって終了したマルチパートメッセージの一部であることを示します。要求の典型的な方向は、ユーザースペース（CPC）からカーネルスペース（FEC）までです。NLM_F_ECHOこのリクエストをエコーします。要求の典型的な方向は、ユーザースペース（CPC）からカーネルスペース（FEC）までです。
Additional flag bits for GET requests on config information in the FEC. NLM_F_ROOT Return the complete table instead of a single entry. NLM_F_MATCH Return all entries matching criteria passed in message content. NLM_F_ATOMIC Return an atomic snapshot of the table being referenced. This may require special privileges because it has the potential to interrupt service in the FE for a longer time.
FECの構成情報のGETリクエストの追加フラグビット。NLM_F_ROOT単一のエントリではなく、完全なテーブルを返します。nlm_f_matchメッセージコンテンツで渡されたすべてのエントリマッチング基準を返します。NLM_F_ATOMIC参照されているテーブルの原子スナップショットを返します。これには、FEでサービスを長時間中断する可能性があるため、特別な特権が必要になる場合があります。
Convenience macros for flag bits: NLM_F_DUMP This is NLM_F_ROOT or'ed with NLM_F_MATCH
フラグビットの利便性マクロ：nlm_f_dumpこれはnlm_f_rootです。
Additional flag bits for NEW requests NLM_F_REPLACE Replace existing matching config object with this request. NLM_F_EXCL Don't replace the config object if it already exists. NLM_F_CREATE Create config object if it doesn't already exist. NLM_F_APPEND Add to the end of the object list.
新しいリクエスト用の追加フラグビットnlm_f_replaceこのリクエストに既存のマッチング構成オブジェクトを置き換えます。nlm_f_excl既に存在する場合は、構成オブジェクトを置き換えません。NLM_F_CREATEそれがまだ存在しない場合は、構成オブジェクトを作成します。nlm_f_appendオブジェクトリストの最後に追加します。
For those familiar with BSDish use of such operations in route sockets, the equivalent translations are:
ルートソケットでのこのような操作の使用に精通している人のために、同等の翻訳は次のとおりです。
- BSD ADD operation equates to NLM_F_CREATE or-ed with NLM_F_EXCL - BSD CHANGE operation equates to NLM_F_REPLACE - BSD Check operation equates to NLM_F_EXCL - BSD APPEND equivalent is actually mapped to NLM_F_CREATE
- bsd add操作は、nlm_f_f_exclでnlm_f_create or -edに相当します-bsd変更操作はnlm_f_replaceに相当します-bsdチェック操作はnlm_f_exclに相当します-bsd appen
Sequence Number: 32 bits The sequence number of the message.
シーケンス番号：32ビットメッセージのシーケンス番号。
Process ID (PID): 32 bits The PID of the process sending the message. The PID is used by the kernel to multiplex to the correct sockets. A PID of zero is used when sending messages to user space from the kernel.
プロセスID（PID）：32は、メッセージを送信するプロセスのPIDをビットします。PIDは、カーネルによってマルチプレックスに正しいソケットに使用されます。カーネルからユーザースペースにメッセージを送信するときに、ゼロのPIDが使用されます。
One could create a reliable protocol between an FEC and a CPC by using the combination of sequence numbers, ACKs, and retransmit timers. Both sequence numbers and ACKs are provided by Netlink; timers are provided by Linux.
シーケンス番号、ACK、および再送信タイマーの組み合わせを使用して、FECとCPCの間に信頼できるプロトコルを作成できます。シーケンス番号とACKの両方がNetLinkによって提供されます。タイマーはLinuxによって提供されます。
One could create a heartbeat protocol between the FEC and CPC by using the ECHO flags and the NLMSG_NOOP message.
ECHOフラグとNLMSG_NOOPメッセージを使用して、FECとCPCの間にハートビートプロトコルを作成できます。
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 request message). However, the CPC should be able to send ACKs back to FEC when requested. The semantics for this are IP service specific.
このメッセージは、実際にはACKとNACKの両方を示すために使用されます。通常、方向はFECからCPCまでです（ACK要求メッセージに応じて）。ただし、CPCは、要求されたときにACKをFECに戻すことができるはずです。これのセマンティクスはIPサービス固有です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netlink message header |
| type = NLMSG_ERROR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLD Netlink message header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error code: integer (typically 32 bits)
エラーコード：整数（通常32ビット）
An error code of zero indicates that the message is an ACK response. An ACK response message contains the original Netlink message header, which can be used to compare against (sent sequence numbers, etc).
ゼロのエラーコードは、メッセージがACK応答であることを示します。ACK応答メッセージには、元のNetLinkメッセージヘッダーが含まれています。これは、（送信されたシーケンス番号など）と比較するために使用できます。
A non-zero error code message is equivalent to a Negative ACK (NACK). In such a situation, the Netlink data that was sent down to the kernel is returned appended to the original Netlink message header. An error code printable via the perror() is also set (not in the message header, rather in the executing environment state variable).
ゼロ以外のエラーコードメッセージは、ネガティブACK（NACK）と同等です。このような状況では、カーネルに送信されたネットリンクデータは、元のNetLinkメッセージヘッダーに追加された返されます。Perror（）を介して印刷可能なエラーコードも設定されています（メッセージヘッダーではなく、実行環境状態変数ではありません）。
These are services that are offered by the system for general use by other services. They include the ability to configure, gather statistics and listen to changes in shared resources. IP address management, link events, etc. fit here. We create this section for these services for logical separation, despite the fact that they are accessed via the NETLINK_ROUTE FEC. The reason that they exist within NETLINK_ROUTE is due to historical cruft: the BSD 4.4 Route Sockets implemented them as part of the IPv4 forwarding sockets.
これらは、他のサービスが一般的に使用するためにシステムによって提供されるサービスです。これらには、共有リソースの変更を構成し、統計を収集し、聴く機能が含まれます。IPアドレス管理、リンクイベントなどはここに適合します。Netlink_Route FECを介してアクセスされるという事実にもかかわらず、論理的な分離のためにこれらのサービスのこのセクションを作成します。それらがnetlink_route内に存在する理由は、歴史的な運命によるものです。BSD4.4ルートソケットは、IPv4転送ソケットの一部としてそれらを実装しました。
This service provides the ability to create, remove, or get information about a specific network interface. The network interface can be either physical or virtual and is network protocol independent (e.g., an x.25 interface can be defined via this message). The Interface service message template is shown below.
このサービスは、特定のネットワークインターフェイスに関する情報を作成、削除、または取得する機能を提供します。ネットワークインターフェイスは物理的または仮想であり、ネットワークプロトコルに依存しない場合があります（たとえば、このメッセージでX.25インターフェイスを定義できます）。インターフェイスサービスメッセージテンプレートを以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved | Device Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Change Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: 8 bits This is always set to AF_UNSPEC.
家族：8ビットこれは常にAF_UNSPECに設定されます。
Device Type: 16 bits This defines the type of the link. The link could be Ethernet, a tunnel, etc. We are interested only in IPv4, although the link type is L3 protocol-independent.
デバイスタイプ：16ビットこれは、リンクのタイプを定義します。リンクはイーサネット、トンネルなどです。リンクタイプはL3プロトコルに依存しませんが、IPv4のみに興味があります。
Interface Index: 32 bits Uniquely identifies interface.
インターフェイスインデックス：32ビットはインターフェイスを一意に識別します。
Device Flags: 32 bits
デバイスフラグ：32ビット
IFF_UP Interface is administratively up. IFF_BROADCAST Valid broadcast address set. IFF_DEBUG Internal debugging flag. IFF_LOOPBACK Interface is a loopback interface. IFF_POINTOPOINT Interface is a point-to-point link. IFF_RUNNING Interface is operationally up. IFF_NOARP No ARP protocol needed for this interface. IFF_PROMISC Interface is in promiscuous mode. IFF_NOTRAILERS Avoid use of trailers. IFF_ALLMULTI Receive all multicast packets. IFF_MASTER Master of a load balancing bundle. IFF_SLAVE Slave of a load balancing bundle. IFF_MULTICAST Supports multicast.
IFF_UPインターフェイスは管理上アップしています。IFF_BROADCAST有効なブロードキャストアドレスセット。IFF_DEBUG内部デバッグフラグ。IFF_LOOPBACKインターフェイスは、ループバックインターフェイスです。IFF_PointoPointインターフェイスは、ポイントツーポイントリンクです。iff_runningインターフェイスは操作的に上昇しています。iff_noarpこのインターフェイスにはARPプロトコルが必要です。IFF_PROMISCインターフェイスは無差別モードです。iff_notrailersは、トレーラーの使用を避けます。iff_allmultiはすべてのマルチキャストパケットを受信します。iff_masterロードバランシングバンドルのマスター。Load Balancing BundleのIFF_SLAVEスレーブ。IFF_MULTICASTはマルチキャストをサポートしています。
IFF_PORTSEL Is able to select media type via ifmap. IFF_AUTOMEDIA Auto media selection active. IFF_DYNAMIC Interface was dynamically created.
IFF_PORTSELは、IFMAPを介してメディアタイプを選択できます。IFF_AUTOMEDIAオートメディア選択アクティブ。IFF_DYNAMICインターフェイスが動的に作成されました。
Change Mask: 32 bits Reserved for future use. Must be set to 0xFFFFFFFF.
マスクの変更：将来の使用のために予約された32ビット。0xffffffffに設定する必要があります。
Applicable attributes:
Attribute Description
..........................................................
IFLA_UNSPEC Unspecified.
IFLA_ADDRESS Hardware address interface L2 address.
IFLA_BROADCAST Hardware address L2 broadcast
address.
IFLA_IFNAME ASCII string device name.
IFLA_MTU MTU of the device.
IFLA_LINK ifindex of link to which this device
is bound.
IFLA_QDISC ASCII string defining egress root
queuing discipline.
IFLA_STATS Interface statistics.
Netlink message types specific to this service: RTM_NEWLINK, RTM_DELLINK, and RTM_GETLINK
NetLinkメッセージタイプこのサービスに固有のタイプ：rtm_newlink、rtm_dellink、およびrtm_getlink
This service provides the ability to add, remove, or receive information about an IP address associated with an interface. The address provisioning service message template is shown below.
このサービスは、インターフェイスに関連付けられたIPアドレスに関する情報を追加、削除、または受信する機能を提供します。アドレスプロビジョニングサービスメッセージテンプレートを以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Length | Flags | Scope |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: 8 bits Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
家族：8ビットアドレスファミリ：IPv4のAF_INET;IPv6のAF_INET6。
Length: 8 bits The length of the address mask.
長さ：アドレスマスクの長さを8ビットします。
Flags: 8 bits IFA_F_SECONDARY For secondary address (alias interface).
フラグ：8ビットIFA_F_セカンダリーのセカンダリアドレス（エイリアスインターフェイス）。
IFA_F_PERMANENT For a permanent address set by the user. When this is not set, it means the address was dynamically created (e.g., by stateless autoconfiguration). IFA_F_DEPRECATED Defines deprecated (IPV4) address. IFA_F_TENTATIVE Defines tentative (IPV4) address (duplicate address detection is still in progress). Scope: 8 bits The address scope in which the address stays valid. SCOPE_UNIVERSE: Global scope. SCOPE_SITE (IPv6 only): Only valid within this site. SCOPE_LINK: Valid only on this device. SCOPE_HOST: Valid only on this host.
ユーザーが設定した永続的なアドレスのIFA_F_PERMANENT。これが設定されていない場合、アドレスが動的に作成されたことを意味します（例：Stateless Autoconfigurationによって）。IFA_F_DEPRECATEDは、非推奨（IPv4）アドレスを定義します。IFA_F_TENTITIVEは、暫定（IPv4）アドレスを定義します（長期のアドレス検出はまだ進行中です）。範囲：アドレスが有効な状態を維持するアドレス範囲を8ビットします。scope_universe：グローバルスコープ。scope_site（ipv6のみ）：このサイト内でのみ有効です。scope_link：このデバイスでのみ有効です。scope_host：このホストでのみ有効です。
le attributes:
LE属性：
Attribute Description IFA_UNSPEC Unspecified. IFA_ADDRESS Raw protocol address of interface. IFA_LOCAL Raw protocol local address. IFA_LABEL ASCII string name of the interface. IFA_BROADCAST Raw protocol broadcast address. IFA_ANYCAST Raw protocol anycast address. IFA_CACHEINFO Cache address information.
属性説明IFA_UNSPEC不特定。IFA_ADDRESS RAWプロトコルインターフェイスのアドレス。IFA_Local RAWプロトコルローカルアドレス。IFA_LABEL ASCII文字列インターフェイスの名前。IFA_Broadcast RAWプロトコルブロードキャストアドレス。IFA_ANYCAST RAW Protocol AnyCastアドレス。IFA_CACHENFOキャッシュアドレス情報。
Netlink messages specific to this service: RTM_NEWADDR, RTM_DELADDR, and RTM_GETADDR.
このサービスに固有のNetLinkメッセージ：RTM_NEWADDR、RTM_DELADDR、およびRTM_GETADDR。
Although there are many other IP services defined that are using Netlink, as mentioned earlier, we will talk only about a handful of those integrated into kernel version 2.4.6. These are:
前述のように、NetLinkを使用している他の多くのIPサービスが定義されていますが、カーネルバージョン2.4.6に統合されたもののほんの一握りについてのみ説明します。これらは：
NETLINK_ROUTE, NETLINK_FIREWALL, and NETLINK_ARPD.
netlink_route、netlink_firewall、およびnetlink_arpd。
This service allows CPCs to modify the IPv4 routing table in the Forwarding Engine. It can also be used by CPCs to receive routing updates, as well as to collect statistics.
このサービスにより、CPCSは転送エンジンのIPv4ルーティングテーブルを変更できます。また、CPCSによってルーティングの更新を受信したり、統計を収集するために使用することもできます。
This service provides the ability to create, remove or receive information about a network route. The service message template is shown below.
このサービスは、ネットワークルートに関する情報を作成、削除、または受信する機能を提供します。サービスメッセージテンプレートを以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Src length | Dest length | TOS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Table ID | Protocol | Scope | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: 8 bits Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
家族：8ビットアドレスファミリ：IPv4のAF_INET;IPv6のAF_INET6。
Src length: 8 bits Prefix length of source IP address.
SRC長さ：ソースIPアドレスの8ビットプレフィックス長。
Dest length: 8 bits Prefix length of destination IP address.
DESTの長さ：宛先IPアドレスの8ビットプレフィックス長。
TOS: 8 bits The 8-bit TOS (should be deprecated to make room for DSCP). Table ID: 8 bits Table identifier. Up to 255 route tables are supported. RT_TABLE_UNSPEC An unspecified routing table. RT_TABLE_DEFAULT The default table. RT_TABLE_MAIN The main table. RT_TABLE_LOCAL The local table.
TOS：8ビットTOSに8ビット（DSCPのスペースを確保するために非推奨）。テーブルID：8ビットテーブル識別子。最大255のルートテーブルがサポートされています。rt_table_unspecは、不特定のルーティングテーブルです。rt_table_defaultデフォルトのテーブル。rt_table_mainメインテーブル。rt_table_localローカルテーブル。
The user may assign arbitrary values between RT_TABLE_UNSPEC(0) and RT_TABLE_DEFAULT(253).
ユーザーは、rt_table_unspec（0）とrt_table_default（253）の間に任意の値を割り当てることができます。
Protocol: 8 bits
Identifies what/who added the route.
Protocol Route origin.
..............................................
RTPROT_UNSPEC Unknown.
RTPROT_REDIRECT By an ICMP redirect.
RTPROT_KERNEL By the kernel.
RTPROT_BOOT During bootup.
RTPROT_STATIC By the administrator.
Values larger than RTPROT_STATIC(4) are not interpreted by the kernel, they are just for user information. They may be used to tag the source of a routing information or to distinguish between multiple routing daemons. See <linux/rtnetlink.h> for the routing daemon identifiers that are already assigned.
rtprot_static（4）よりも大きい値はカーネルによって解釈されるのではなく、ユーザー情報のためだけです。それらを使用して、ルーティング情報のソースにタグを付けたり、複数のルーティングデーモンを区別したりするために使用できます。すでに割り当てられているルーティングデーモン識別子については、<linux/rtnetlink.h>を参照してください。
Scope: 8 bits Route scope (valid distance to destination). RT_SCOPE_UNIVERSE Global route. RT_SCOPE_SITE Interior route in the local autonomous system. RT_SCOPE_LINK Route on this link. RT_SCOPE_HOST Route on the local host. RT_SCOPE_NOWHERE Destination does not exist.
スコープ：8ビットルートスコープ（宛先までの有効な距離）。rt_scope_universeグローバルルート。ローカル自律システムのRT_SCOPE_SITEインテリアルート。このリンクのrt_scope_linkルート。ローカルホストのRT_SCOPE_HOSTルート。rt_scope_nowhere宛先は存在しません。
The values between RT_SCOPE_UNIVERSE(0) and RT_SCOPE_SITE(200) are available to the user.
rt_scope_universe（0）とrt_scope_site（200）の間の値は、ユーザーが利用できます。
Type: 8 bits The type of route.
タイプ：8つのルートのタイプをビットします。
Route type Description
----------------------------------------------------
RTN_UNSPEC Unknown route.
RTN_UNICAST A gateway or direct route.
RTN_LOCAL A local interface route.
RTN_BROADCAST A local broadcast route
(sent as a broadcast).
RTN_ANYCAST An anycast route.
RTN_MULTICAST A multicast route.
RTN_BLACKHOLE A silent packet dropping route.
RTN_UNREACHABLE An unreachable destination.
Packets dropped and host
unreachable ICMPs are sent to the
originator.
RTN_PROHIBIT A packet rejection route. Packets
are dropped and communication
prohibited ICMPs are sent to the
originator.
RTN_THROW When used with policy routing,
continue routing lookup in another
table. Under normal routing,
packets are dropped and net
unreachable ICMPs are sent to the
originator.
RTN_NAT A network address translation
rule.
RTN_XRESOLVE Refer to an external resolver (not
implemented).
Flags: 32 bits Further qualify the route. RTM_F_NOTIFY If the route changes, notify the user. RTM_F_CLONED Route is cloned from another route. RTM_F_EQUALIZE Allow randomization of next hop path in multi-path routing (currently not implemented).
フラグ：32ビットはさらにルートを修飾します。rtm_f_notifyルートが変更された場合は、ユーザーに通知します。RTM_F_CLONEDルートは、別のルートからクローン化されています。rtm_f_equalizeマルチパスルーティングで次のホップパスのランダム化を許可します（現在実装されていません）。
Attributes applicable to this service:
Attribute Description
---------------------------------------------------
RTA_UNSPEC Ignored.
RTA_DST Protocol address for route
destination address.
RTA_SRC Protocol address for route source
address.
RTA_IIF Input interface index.
RTA_OIF Output interface index.
RTA_GATEWAY Protocol address for the gateway of
the route
RTA_PRIORITY Priority of route.
RTA_PREFSRC Preferred source address in cases
where more than one source address
could be used.
RTA_METRICS Route metrics attributed to route
and associated protocols (e.g.,
RTT, initial TCP window, etc.).
RTA_MULTIPATH Multipath route next hop's
attributes.
RTA_PROTOINFO Firewall based policy routing
attribute.
RTA_FLOW Route realm.
RTA_CACHEINFO Cached route information.
Additional Netlink message types applicable to this service: RTM_NEWROUTE, RTM_DELROUTE, and RTM_GETROUTE
このサービスに適用可能な追加のNetLinkメッセージタイプ：rtm_newroute、rtm_delroute、およびrtm_getroute
This service provides the ability to add, remove, or receive information about a neighbor table entry (e.g., an ARP entry or an IPv4 neighbor solicitation, etc.). The service message template is shown below.
このサービスは、近隣のテーブルエントリに関する情報を追加、削除、または受信する機能（たとえば、ARPエントリまたはIPv4ネイバーの勧誘など）を提供します。サービスメッセージテンプレートを以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | Flags | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: 8 bits Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
家族：8ビットアドレスファミリ：IPv4のAF_INET;IPv6のAF_INET6。
Interface Index: 32 bits The unique interface index.
インターフェイスインデックス：32ビット一意のインターフェイスインデックス。
State: 16 bits A bitmask of the following states: NUD_INCOMPLETE Still attempting to resolve. NUD_REACHABLE A confirmed working cache entry NUD_STALE an expired cache entry. NUD_DELAY Neighbor no longer reachable. Traffic sent, waiting for confirmation. NUD_PROBE A cache entry that is currently being re-solicited. NUD_FAILED An invalid cache entry. NUD_NOARP A device which does not do neighbor discovery (ARP). NUD_PERMANENT A static entry. Flags: 8 bits NTF_PROXY A proxy ARP entry. NTF_ROUTER An IPv6 router.
状態：16ビット次の状態のビットマスク：nud_incompleteはまだ解決しようとしています。nud_reachableは、有効期限が切れたキャッシュエントリNUD_STALEを確認しました。nud_delayの隣人はもはや到達できなくなりました。送信されたトラフィック、確認を待っています。nud_probe現在再検討中のキャッシュエントリ。NUD_は、無効なキャッシュエントリをファイルしました。NUD_NOARP Neighbor Discovery（ARP）を行わないデバイス。nud_permanent静的エントリ。フラグ：8ビットNTF_PROXYプロキシARPエントリ。ntf_router an ipv6ルーター。
Attributes applicable to this service:
Attributes Description
------------------------------------
NDA_UNSPEC Unknown type.
NDA_DST A neighbour cache network.
layer destination address
NDA_LLADDR A neighbor cache link layer
address.
NDA_CACHEINFO Cache statistics.
Additional Netlink message types applicable to this service: RTM_NEWNEIGH, RTM_DELNEIGH, and RTM_GETNEIGH.
このサービスに適用可能な追加のNetLinkメッセージタイプ：rtm_newneigh、rtm_delneigh、およびrtm_getneigh。
This service provides the ability to provision, query or listen to events under the auspices of traffic control. These include queuing disciplines, (schedulers and queue treatment algorithms -- e.g., priority-based scheduler or the RED algorithm) and classifiers. Linux Traffic Control Service is very flexible and allows for hierarchical cascading of the different blocks for traffic resource sharing.
このサービスは、トラフィックコントロールの後援の下でイベントを提供、質問、または聴く機能を提供します。これらには、キューイングの分野、（スケジューラーとキュー治療アルゴリズム - 例えば、優先度ベースのスケジューラまたは赤いアルゴリズム）および分類器が含まれます。Linux Traffic Control Serviceは非常に柔軟であり、トラフィックリソースの共有のためにさまざまなブロックの階層的なカスケードを可能にします。
++ ++ +-----+ +-------+ ++ ++ .++
|| . || +------+ | |-->| Qdisc |-->|| || ||
|| ||---->|Filter|--->|Class| +-------+ ||-+ || ||
|| || | +------+ | +---------------+| | || ||
|| . || | +----------------------+ | || .||
|| . || | +------+ | || ||
|| || +->|Filter|-_ +-----+ +-------+ ++ | || .||
|| -->|| | +------+ ->| |-->| Qdisc |-->|| | ||->||
|| . || | |Class| +-------+ ||-+-->|| .||
->dev->|| || | +------+ _->| +---------------+| || ||
|| || +->|Filter|- +----------------------+ || .||
|| || +------+ || .||
|| . |+----------------------------------------------+| ||
|| | Parent Queuing discipline | .||
|| . +------------------------------------------------+ .||
|| . . .. . . .. . . . .. .. .. . .. ||
|+--------------------------------------------------------+|
| Parent Queuing discipline |
| (attached to egress device) |
+----------------------------------------------------------+
The above diagram shows an example of the Egress TC block. We try to be very brief here. For more information, please refer to [11]. A packet first goes through a filter that is used to identify a class to which the packet may belong. A class is essentially a terminal queuing discipline and has a queue associated with it. The queue may be subject to a simple algorithm, like FIFO, or a more complex one, like RED or a token bucket. The outermost queuing discipline, which is referred to as the parent is typically associated with a scheduler. Within this scheduler hierarchy, however, may be other scheduling algorithms, making the Linux Egress TC very flexible.
上記の図は、出口TCブロックの例を示しています。ここで非常に短いことをしようとしています。詳細については、[11]を参照してください。パケットは、パケットが属するクラスを識別するために使用されるフィルターを最初に通過します。クラスは基本的にターミナルキューイングの規律であり、それに関連するキューがあります。キューは、FIFOのような単純なアルゴリズム、または赤やトークンのバケツのようなより複雑なアルゴリズムの影響を受ける場合があります。親と呼ばれる最も外側のキューイングの規律は、通常、スケジューラに関連付けられています。ただし、このスケジューラ階層内では、他のスケジューリングアルゴリズムである可能性があり、Linux Eutress TCを非常に柔軟にします。
The service message template that makes this possible is shown below. This template is used in both the ingress and the egress queuing disciplines (refer to the egress traffic control model in the FE model section). Each of the specific components of the model has unique attributes that describe it best. The common attributes are described below.
これを可能にするサービスメッセージテンプレートを以下に示します。このテンプレートは、侵入と出口のQueuing分野の両方で使用されます（FEモデルセクションの出力交通制御モデルを参照）。モデルの各コンポーネントには、それを最もよく説明する一意の属性があります。一般的な属性については、以下に説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qdisc handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent Qdisc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCM Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: 8 bits Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
家族：8ビットアドレスファミリ：IPv4のAF_INET;IPv6のAF_INET6。
Interface Index: 32 bits The unique interface index.
インターフェイスインデックス：32ビット一意のインターフェイスインデックス。
Qdisc handle: 32 bits Unique identifier for instance of queuing discipline. Typically, this is split into major:minor of 16 bits each. The major number would also be the major number of the parent of this instance.
QDISCハンドル：32ビットユニークな識別子は、たとえば、キューイングの規律のために。通常、これはメジャーに分割されます：それぞれ16ビットのうちのマイナー。主要な数字は、このインスタンスの親の主要な数にもなります。
Parent Qdisc: 32 bits Used in hierarchical layering of queuing disciplines. If this value and the Qdisc handle are the same and equal to TC_H_ROOT, then the defined qdisc is the top most layer known as the root qdisc.
親QDISC：キューイングの分野の階層階層化で使用される32ビット。この値とQDISCハンドルが同じでTC_H_ROOTと等しい場合、定義されたQDISCはルートQDISCとして知られる最も多くの層です。
TCM Info: 32 bits Set by the FE to 1 typically, except when the Qdisc instance is in use, in which case it is set to imply a reference count. From the CPC towards the direction of the FEC, this is typically set to 0 except when used in the context of filters. In that case, this 32- bit field is split into a 16-bit priority field and 16-bit protocol field. The protocol is defined in kernel source <include/linux/if_ether.h>, however, the most commonly used one is ETH_P_IP (the IP protocol).
TCM情報：QDISCインスタンスが使用されている場合を除き、通常、FOから1で設定された32ビットは、参照カウントを暗示するように設定されています。CPCからFECの方向に向かって、これは通常、フィルターのコンテキストで使用される場合を除き、0に設定されます。その場合、この32ビットフィールドは、16ビットの優先度フィールドと16ビットプロトコルフィールドに分割されます。プロトコルは、カーネルソース<include/linux/if_ether.h>で定義されていますが、最も一般的に使用されるものはETH_P_IP（IPプロトコル）です。
The priority is used for conflict resolution when filters intersect in their expressions.
フィルターが表現で交差する場合、優先度は紛争解決に使用されます。
Generic attributes applicable to this service:
Attribute Description
------------------------------------
TCA_KIND Canonical name of FE component.
TCA_STATS Generic usage statistics of FEC
TCA_RATE rate estimator being attached to
FEC. Takes snapshots of stats to
compute rate.
TCA_XSTATS Specific statistics of FEC.
TCA_OPTIONS Nested FEC-specific attributes.
Appendix 3 has an example of configuring an FE component for a FIFO Qdisc.
付録3には、FIFO QDISC用のFEコンポーネントを構成する例があります。
Additional Netlink message types applicable to this service: RTM_NEWQDISC, RTM_DELQDISC, RTM_GETQDISC, RTM_NEWTCLASS, RTM_DELTCLASS, RTM_GETTCLASS, RTM_NEWTFILTER, RTM_DELTFILTER, and RTM_GETTFILTER.
このサービスに適用可能な追加のNetLinkメッセージタイプ：RTM_NEWQDISC、RTM_DELQDISC、RTM_GETQDISC、RTM_NEWTCLASS、RTM_DELTCLASS、RTM_GETTCLASS、RTM_NEWTFILTER、RTM_DELTFILTER、RTM_GETTFILTER。
This service allows CPCs to receive, manipulate, and re-inject packets via the IPv4 firewall service modules in the FE. A firewall rule is first inserted to activate packet redirection. The CPC informs the FEC whether it would like to receive just the metadata on the packet or the actual data and, if the metadata is desired, what is the maximum data length to be redirected. The redirected packets are still stored in the FEC, waiting a verdict from the CPC. The verdict could constitute a simple accept or drop decision of the packet, in which case the verdict is imposed on the packet still sitting on the FEC. The verdict may also include a modified packet to be sent on as a replacement.
このサービスにより、CPCはFEのIPv4ファイアウォールサービスモジュールを介してパケットを受信、操作、および再注入できます。ファイアウォールルールが最初に挿入され、パケットリダイレクトをアクティブにします。CPCは、Packetのメタデータのみを受信したいのか、実際のデータを受け取るか、メタデータが必要な場合は、リダイレクトされる最大データ長は何ですか？リダイレクトされたパケットはまだFECに保存されており、CPCからの評決を待っています。評決は、パケットの単純な受け入れまたはドロップの決定を構成する可能性があります。その場合、評決はまだFECにあるパケットに課されます。評決には、代替として送信される変更されたパケットが含まれる場合があります。
Two types of messages exist that can be sent from CPC to FEC. These are: Mode messages and Verdict messages. Mode messages are sent immediately to the FEC to describe what the CPC would like to receive. Verdict messages are sent to the FEC after a decision has been made on the fate of a received packet. The formats are described below.
CPCからFECに送信できる2種類のメッセージが存在します。これらは次のとおりです。モードメッセージと評決メッセージ。モードメッセージはすぐにFECに送信され、CPCが受信したいものを説明します。受信したパケットの運命に関する決定が下された後、評決メッセージはFECに送信されます。形式については、以下に説明します。
The mode message is described first.
モードメッセージについて最初に説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mode: 8 bits Control information on the packet to be sent to the CPC. The different types are:
モード：CPCに送信されるパケットの8ビット制御情報。さまざまなタイプは次のとおりです。
IPQ_COPY_META Copy only packet metadata to CPC. IPQ_COPY_PACKET Copy packet metadata and packet payloads to CPC.
IPQ_COPY_META COPY PacketメタデータのみをCPCにコピーします。IPQ_COPY_PACKET PacketメタデータとパケットペイロードをCPCにコピーします。
Range: 32 bits If IPQ_COPY_PACKET, this defines the maximum length to copy.
範囲：32ビットIPQ_COPY_PACKETの場合、これはコピーする最大長を定義します。
A packet and associated metadata received from user space looks as follows.
ユーザースペースから受け取ったパケットと関連するメタデータは、次のように見えます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mark |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp_m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp_u |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hook |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| indev_name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| outdev_name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hw_protocol | hw_type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hw_addrlen | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hw_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data_len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet ID: 32 bits The unique packet identifier as passed to the CPC by the FEC.
パケットID：32ビットFECによってCPCに渡された一意のパケット識別子。
Mark: 32 bits The internal metadata value set to describe the rule in which the packet was picked.
マーク：32ビットパケットが選択されたルールを記述するために設定された内部メタデータ値。
timestamp_m: 32 bits Packet arrival time (seconds)
Timestamp_M：32ビットパケット到着時間（秒）
timestamp_u: 32 bits Packet arrival time (useconds in addition to the seconds in timestamp_m)
Timestamp_u：32ビットパケット到着時間（cemestamp_mの秒に加えて極端に）
hook: 32 bits The firewall module from which the packet was picked.
フック：32ビットパケットが選ばれたファイアウォールモジュール。
indev_name: 128 bits ASCII name of incoming interface.
indev_name：128ビットASCII着信インターフェイスの名前。
outdev_name: 128 bits ASCII name of outgoing interface.
outdev_name：128ビットASCII発信インターフェイスの名前。
hw_protocol: 16 bits Hardware protocol, in network order.
hw_protocol：16ビットハードウェアプロトコル、ネットワーク順序。
hw_type: 16 bits Hardware type.
hw_type：16ビットハードウェアタイプ。
hw_addrlen: 8 bits Hardware address length.
HW_ADDRLEN：8ビットハードウェアアドレスの長さ。
hw_addr: 64 bits Hardware address.
hw_addr：64ビットハードウェアアドレス。
data_len: 32 bits Length of packet data.
data_len：32ビットのパケットデータの長さ。
Payload: size defined by data_len The payload of the packet received.
ペイロード：data_lenで定義されたサイズ受信したパケットのペイロード。
The Verdict message format is as follows
評決メッセージ形式は次のとおりです
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value: 32 bits
値：32ビット
This is the verdict to be imposed on the packet still sitting in the FEC. Verdicts could be:
これは、FECにまだ座っているパケットに課される評決です。評決は次のとおりです。
NF_ACCEPT Accept the packet and let it continue its traversal. NF_DROP Drop the packet.
NF_ACCEPTはパケットを受け入れ、トラバーサルを継続させます。nf_dropパケットをドロップします。
Packet ID: 32 bits The packet identifier as passed to the CPC by the FEC.
パケットID：32 FECによってCPCに渡されたパケット識別子を32ビットします。
Data Length: 32 bits The data length of the modified packet (in bytes). If you don't modify the packet just set it to 0.
データの長さ：32ビット修正パケットのデータ長（バイト単位）。パケットを変更しない場合は、0に設定してください。
Payload: Size as defined by the Data Length field.
ペイロード：データの長さフィールドで定義されているサイズ。
This service is used by CPCs for managing the neighbor table in the FE. The message format used between the FEC and CPC is described in the section on the Neighbor Setup Service Module.
このサービスは、FEの隣接テーブルを管理するためにCPCSによって使用されます。FECとCPCの間で使用されるメッセージ形式は、Neighbor Setup Serviceモジュールのセクションで説明されています。
The CPC service is expected to participate in neighbor solicitation protocol(s).
CPCサービスは、近隣の勧誘プロトコルに参加する予定です。
A neighbor message of type RTM_NEWNEIGH is sent towards the CPC by the FE to inform the CPC of changes that might have happened on that neighbor's entry (e.g., a neighbor being perceived as unreachable).
タイプRTM_Newneighの隣接メッセージは、CPCにFEで送信され、CPCにその隣人のエントリで起こった可能性のある変更を通知します（たとえば、隣人が到達不能であると認識されている）。
RTM_GETNEIGH is used to solicit the CPC for information on a specific neighbor.
RTM_GETNEIGHは、特定の隣人に関する情報についてCPCを求めるために使用されます。
[1] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[1] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[3] Blake, S., Black, D., Carlson, M., Davies, E, Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[3] Blake、S.、Black、D.、Carlson、M.、Davies、E、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[4] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[4] Durham、D.、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R.、A。Sastry、「The Cops（Common Open Policy Service）Protocol」、RFC 2748、2000年1月。
[5] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[5] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[6] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[6] Case、J.、Fedor、M.、Schoffstall、M。and C. Davin、「Simple Network Management Protocol（SNMP）」、STD 15、RFC 1157、1990年5月。
[7] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[7] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[8] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for DiffServ Routers", RFC 3290, May 2002.
[8] Bernet、Y.、Blake、S.、Grossman、D。and A. Smith、「Diffservルーターの非公式管理モデル」、RFC 3290、2002年5月。
[9] G. R. Wright, W. Richard Stevens. "TCP/IP Illustrated Volume 2, Chapter 20", June 1995.
[9] G. R.ライト、W。リチャードスティーブンス。「TCP/IP Illustrated Volume 2、第20章」、1995年6月。
[10] http://www.netfilter.org
[10] http://www.netfilter.org
[11] http://diffserv.sourceforge.net
[11] http://diffserv.sourceforge.net
Netlink lives in a trusted environment of a single host separated by kernel and user space. Linux capabilities ensure that only someone with CAP_NET_ADMIN capability (typically, the root user) is allowed to open sockets.
Netlinkは、カーネルとユーザースペースで区切られた単一のホストの信頼できる環境に住んでいます。Linux機能により、CAP_NET_ADMIN機能（通常、ルートユーザー）がある人のみがソケットを開くことができるようになります。
1) Andi Kleen, for man pages on netlink and rtnetlink.
1) Andi Kleen、netlinkとrtnetlinkのマンページ用。
2) Alexey Kuznetsov is credited for extending Netlink to the IP service delivery model. The original Netlink character device was written by Alan Cox.
2) Alexey Kuznetsovは、NetLinkをIPサービス提供モデルに拡張したと認められています。元のNetlink文字デバイスは、Alan Coxによって作成されました。
3) Jeremy Ethridge for taking the role of someone who did not understand Netlink and reviewing the document to make sure that it made sense.
3) NetLinkを理解していない人の役割を担い、ドキュメントをレビューして、それが理にかなっていることを確認したJeremy Ethridge。
Appendix 1: Sample Service Hierarchy
付録1：サンプルサービス階層
In the diagram below we show a simple IP service, foo, and the interaction it has between CP and FE components for the service (labels 1-3).
下の図では、単純なIPサービス、FOO、およびサービスのCPコンポーネントとFEコンポーネントの間にある相互作用を示しています（ラベル1-3）。
The diagram is also used to demonstrate CP<->FE addressing. In this section, we illustrate only the addressing semantics. In Appendix 2, the diagram is referenced again to define the protocol interaction between service foo's CPC and FEC (labels 4-10).
この図は、Cp <-> FEアドレス指定を示すためにも使用されます。このセクションでは、アドレス指定セマンティクスのみを示します。付録2では、Service FooのCPCとFEC（ラベル4-10）の間のプロトコル相互作用を定義するために、図が再び参照されています。
CP
[--------------------------------------------------------.
| .-----. |
| | . -------. |
| | CLI | / \ |
| | | | CP protocol | |
| /->> -. | component | <-. |
| __ _/ | | For | | |
| | | IP service | ^ |
| Y | foo | | |
| | ___________/ ^ |
| Y 1,4,6,8,9 / ^ 2,5,10 | 3,7 |
--------------- Y------------/---|----------|-----------
| ^ | ^
**|***********|****|**********|**********
************* Netlink layer ************
**|***********|****|**********|**********
FE | | ^ ^
.-------- Y-----------Y----|--------- |----.
| | / |
| Y / |
| . --------^-------. / |
| |FE component/module|/ |
| | for IP Service | |
--->---|------>---| foo |----->-----|------>--
| ------------------- |
| |
| |
------------------------------------------
The control plane protocol for IP service foo does the following to connect to its FE counterpart. The steps below are also numbered above in the diagram.
IPサービスFOOのコントロールプレーンプロトコルは、FEの対応物に接続するために次のことを行います。以下の手順には、上記の図にもあります。
1) Connect to the IP service foo through a socket connect. A typical connection would be via a call to: socket(AF_NETLINK, SOCK_RAW, NETLINK_FOO).
1) ソケット接続を介してIPサービスfooに接続します。典型的な接続は、Socket（af_netlink、sock_raw、netlink_foo）への呼び出しです。
2) Bind to listen to specific asynchronous events for service foo.
2) Service Fooの特定の非同期イベントを聴くために縛ります。
3) Bind to listen to specific asynchronous FE events.
3) 特定の非同期FEイベントを聴くためにバインドします。
Appendix 2: Sample Protocol for the Foo IP Service
付録2：Foo IPサービスのサンプルプロトコル
Our example IP service foo is used again to demonstrate how one can deploy a simple IP service control using Netlink.
私たちの例のIPサービスFOOは、NetLinkを使用して単純なIPサービスコントロールを展開する方法を示すために再び使用されます。
These steps are continued from Appendix 1 (hence the numbering).
これらの手順は、付録1から続きます（したがって、番号付け）。
4) Query for current config of FE component.
4) Feコンポーネントの現在の構成のクエリ。
5) Receive response to (4) via channel on (3).
5) （3）のチャネルを介して（4）への応答を受け取ります。
6) Query for current state of IP service foo.
6) IPサービスの現在の状態FOOのクエリ。
7) Receive response to (6) via channel on (2).
7) （2）のチャネルを介して（6）への応答を受け取ります。
8) Register the protocol-specific packets you would like the FE to forward to you.
8) プロトコル固有のパケットを登録して、FEを転送してください。
9) Send service-specific foo commands and receive responses for them, if needed.
9) 必要に応じて、サービス固有のFOOコマンドを送信し、それらの応答を受け取ります。
Appendix 2a: Interacting with Other IP services
付録2A：他のIPサービスとの対話
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.
付録1の図は、同じサービスを構成する別の制御コンポーネントを示しています。この場合、それは独自のコマンドラインインターフェイスです。CLIは、NetLinkプロトコルを使用してFOOコンポーネントと通信している場合とそうでない場合があります。サービスFOOのFECのポリシーに影響を与えるCLIの問題コマンドの場合、Foo CPCに通知されます。その後、この入力に基づいてアルゴリズムの決定を下す可能性があります。たとえば、FEが別のサービスによってインストールされたポリシーを削除することを許可した場合、FOOがインストールしたポリシーがサービスバーによって削除された場合、これをサービスFOOのすべてのピアに伝播する必要があるかもしれません。
Appendix 3: Examples
付録3：例
In this example, we show a simple configuration Netlink message sent from a TC CPC to an egress TC FIFO queue. This queue algorithm is based on packet counting and drops packets when the limit exceeds 100 packets. We assume that the queue is in a hierarchical setup with a parent 100:0 and a classid of 100:1 and that it is to be installed on a device with an ifindex of 4.
この例では、TC CPCから出力TC FIFOキューに送信された単純な構成NetLinkメッセージを表示します。このキューアルゴリズムは、制限が100パケットを超えるとパケットカウントとドロップパケットに基づいています。キューは、親100：0と100：1のクラスIDを備えた階層セットアップにあり、4のifindexを持つデバイスにインストールされると仮定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (52) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (RTM_NEWQDISC) | Flags (NLM_F_EXCL | |
| |NLM_F_CREATE | NLM_F_REQUEST)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number(arbitrary number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Process ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Family(AF_INET)| Reserved1 | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qdisc handle (0x1000001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent Qdisc (0x1000000) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCM Info (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TCA_KIND) | Length(4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ("pfifo") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TCA_OPTIONS) | Length(4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (limit=100) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authors' Addresses
著者のアドレス
Jamal Hadi Salim Znyx Networks Ottawa, Ontario Canada
Jamal Hadi Salim Znyx Networks Ottawa、オンタリオカナダ
EMail: hadi@znyx.com
Hormuzd M Khosravi Intel 2111 N.E. 25th Avenue JF3-206 Hillsboro OR 97124-5961 USA
Hormuzd M Khosravi Intel 2111 N.E.25th Avenue JF3-206 Hillsboroまたは97124-5961 USA
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com
Andi Kleen SuSE Stahlgruberring 28 81829 Muenchen Germany
Andi Kleen Suse Stahlgruberring 28 81829 Muenchenドイツ
EMail: ak@suse.de
Alexey Kuznetsov INR/Swsoft Moscow Russia
Alexey Kuznetsov Inr/Swsoft Moscow Russia
EMail: kuznet@ms2.inr.ac.ru
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。