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
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.
著作権（C）インターネット協会（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で使用されているLinuxのするNetlinkを、説明しています。この文書の焦点は、転送エンジン部品（FEC）とコントロールプレーンコンポーネント（CPC）、IPサービスを定義する2つの構成要素間のプロトコルとしてするNetlinkの機能を記述することです。この焦点の結果として、この文書は、プロセス間通信方式（IPC）として、または他の非ネットワークまたは非ための構成ツールとして、イントラカーネルメッセージングシステムとしての使用を含めするNetlinkの他の用途を無視しますIPネットワークサービス（など、DECnetなど）。
This document is intended as informational in the context of prior art for the ForCES IETF working group.
この文書は、IETFワーキンググループのForCESのための先行技術の文脈での情報提供を目的としています。
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サービス制御転送分離の概念は最初BSD 4.4ルーティングソケットによって1990年代初期に導入された[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は、古典的なRFC 1812のIPv4フォワーディング以外のいくつかのサービスにIPサービスの抽象化を提供してきました。
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のチュートリアルであることを意図し、この文書ではありません。アイデアは、チャーターのForCES（すなわち、IPv4およびQoS）の内の必須のビルディングブロックに特別な焦点を当てた全体するNetlinkビューを説明することです。この文書はまた、力のコンテキスト内で有用である多くの機構に従来技術をキャプチャするのに役立ちます。テキストは、この文書が最初に書かれた、最新のカーネルカーネル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）は、我々がクリック単価と呼ぶいくつかのサブコンポーネントを有することができる実行環境です。各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 [7]として配布プロトコルをタグ付けするような動的ルーティングプロトコル、に至るまで多様で、シグナリングプロトコルを包含する。古典的な管理プロトコルおよび活動もこのカテゴリに分類されます。これらは、SNMP [6]、COPS [4]、及びプロプライエタリCLI / GUI構成機構を含みます。 FE：制御プレーンの目的は、究極の目標は、第二のネットワーク要素（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モデルを示しています。データパスの唯一の必須部分はRFC 1812に準拠している転送モジュール、です。異なるファイアウォール（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.
入力装置に到着するパケットは、最初のファイアウォールモジュールを通過します。パケットはファイアウォールモジュールによって、など、ドロップマングドすることができます。着信パケットは、設定されたポリシーに応じて、次に、入力トラフィック制御モジュールを介して渡されてもよいです。メーターとポリシング活動が進入TCモジュール内に含まれています。パケットは、このモジュールでは、計量結果とポリシングポリシーに応じて、ドロップすることができます。次に、パケットは、RFC 1812に準拠転送モジュール、唯一の非オプションのモジュールに供されます。それは不適合である場合、パケットは（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サービスは、ホップ単位の動作です。 NEで実行されている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の転送テーブルを修正します。伝統的に、この単純なサービスを提供するNEは、ルータとして知られています。
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.
< - >いくつかの基本的なQoS出力スケジューリングを行うと、セットアップは、この記述されたモデルにどのように適合するか説明するための拡張子を持つ古典IPv4サービスの一例を提供するために、CPのセットアップ以下の図では、我々は簡単なFEを示しています。
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）を示します。 IPv4のFe成分は、IPv4転送サービスモジュール、ならびに出口スケジューリングサービスモジュールを含みます。別のサービスは、IPv4フォワーダとQoS出力スケジューラ間の政策フォワーダを追加することができます。シンプルな古典サービスは、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サービスヘッダを超える場合があります）サービスがファイアウォールを含めるなどのDiffservとRSVP、NAT、ポリシーベースルーティング、新しい制御プロトコルや管理活動におけるQoSは、これらの新しいサービスを導入しています。
One extreme definition of a IP service is something for which a service provider would be able to charge.
IPサービスの一つの極端な定義は、サービスプロバイダは、充電することができるだろうそのために何かです。
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.
FECとCPCとの間の相互作用は、ネットリンク文脈において、プロトコルを定義します。ちょうど別の保護ドメインを意味するカーネル空間とユーザ空間 - のnetlinkは、独自のプロトコル定義を持っている（ユーザ空間に存在する）CPCとFEC（カーネル空間に存在する）のためのメカニズムを提供しています。したがって、ワイヤプロトコルは、通信に必要とされます。ワイヤプロトコルは、通常、複数の保護ドメイン間でコピーすることができますいくつかの特権サービスで提供されます。私たちはするNetlinkサービスとしてこのサービスを指します。 CPCは、FECとは異なるノードで実行された場合ネットリンクサービスは、異なるトランスポート層中に封入することができます。 FECとCPCは、するNetlinkメカニズムを使用して、互いの間に信頼性の高いプロトコルを定義するために選択することができます。デフォルトでは、しかし、する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（）システムコールを使用できることに注意してください。私たちは、それが利用可能であると言うことよりも、他のこのメカニズムを説明しません。このドキュメントでは、我々は、カーネル空間とユーザ空間を意味するためにCPCを意味するFECに、交換可能に参照します。この金種は、これらの保護ドメインまたは同一の計算ノードへの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.
< - > CPCの論理的関係当社以下の図では、単純なFECを示しました。我々は、例として、FEC（以下でさらに説明されるNETLINK_ROUTEを）転送のIPv4を使用します。
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.
放送線を介して互いに相互接続されたノードの形でネットリンク論理モデルのFECとクリック単価。
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.
（上記示したようにクリック単価またはのFEC）ノードは、ワイヤに接続して特定のメッセージを受信するように登録します。それはより良いサービスを制御するためにそれらを助けている場合のCPCは、複数のワイヤに接続することができます。すべてのノード（のCPCとのFEC）は、ブロードキャストワイヤ上のパケットをダンプします。彼らが不正または特異ワイヤー用にフォーマットされていない場合、パケットは有線で廃棄することができます。ドロップされたパケットは、ノードのいずれかで見られません。それはmalformattedする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またはCPCの処理のための関心の特定のメッセージまたはちょうど監視の目的のために登録します。
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メッセージヘッダ、IPサービスの特定のテンプレート、およびIPサービス固有のデータ：するNetlinkメッセージには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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Netlink message header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Service Template | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Service specific data in TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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のメッセージヘッダ| | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | | IPサービステンプレート| | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | | TLVでIPサービス固有のデータ| | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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).
ネットリンクメッセージは、クリック単価にFECイベントの非同期イベント通知のFECのパラメータのためのFECとCPCとの間の通信に使用され、統計クエリ/（典型的には、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.
IPサービステンプレートのヘッダーはサービスに固有であるのに対しするNetlinkメッセージヘッダーは、すべてのサービスの総称です。各IPサービスは、パラメータデータ（CPC-> FEC方向）または応答（FEC-> CPC方向）に搬送します。これらのパラメータ化は、TLV（Type-Length-Value）フォーマットであり、サービスに固有のものです。
The different parts of the netlink message are discussed in the following sections.
ネットリンクメッセージの異なる部分は、以下のセクションで説明されています。
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ドメインへのソケット（）システムコールを行うことによって達成されます。各FECは、プロトコル番号によって識別されます。するNetlinkは、2つの区別しないもののひとつは、SOCK_RAWまたはSOCK_DGRAMいずれかのタイプのソケットを開くことができます。 < - >アドレシングCPソケット接続はFEのための基礎を提供します。
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メッセージに分割することができ、単一のメッセージに収まるには大きすぎる場合には、総称してマルチパートメッセージと呼ばれます。マルチパートメッセージの場合、最初と次のすべてのヘッダがネットリンクヘッダタイプNLMSG_DONEを有する最後のヘッダを除いて、NLM_F_MULTIするNetlinkヘッダフラグが設定されています。
The Netlink message header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Process ID (PID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|国旗| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |シーケンス番号| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |プロセス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ビットこのフィールドは、メッセージの内容を説明します。これは、標準のメッセージタイプのいずれかになります。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).
フラグ：するNetlinkで使用される16ビットの標準的なフラグビットがNLM_F_REQUESTがNLM_F_MULTIは、メッセージが成功した場合に確認応答をNLMSG_DONE NLM_F_ACK要求によって終了マルチパートメッセージの一部であることを示します（スペースをカーネルに、典型的には、ユーザ空間から）すべての要求メッセージに設定する必要があります。要求の典型的な方向は、空間（FEC）をカーネルにユーザ空間（CPC）からのものです。 NLM_F_ECHOエコーこの要求。要求の典型的な方向は、空間（FEC）をカーネルにユーザ空間（CPC）からのものです。
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 NLM_F_MATCH OR操作されます
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.
新しい要求のための追加のフラグビットは、この要求に既存のマッチングconfigオブジェクトを交換NLM_F_REPLACE。それがすでに存在する場合NLM_F_EXCLは、configオブジェクトを交換しないでください。それはまだ存在しない場合NLM_F_CREATEは、configオブジェクトを作成します。 NLM_F_APPENDオブジェクトリストの末尾に追加します。
For those familiar with BSDish use of such operations in route sockets, the equivalent translations are:
経路ソケットにこのような動作のBSDish使用に精通している人のために、同等の翻訳は、以下のとおりです。
- 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
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の両方を示すために使用されます。典型的には、方向が（ACK要求メッセージに応答して）FECからCPCです。しかし、CPCは、要求されたとき、FECに戻ってACKを送信することができるはずです。このためセマンティクスは、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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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のメッセージヘッダ| |タイプ= NLMSG_ERROR | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |エラーコード| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | OLDするNetlinkメッセージヘッダ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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内に存在することの理由は、過去の嫌なものに起因するものである：BSD 4.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インタフェースは、このメッセージを介して定義することができる）独立したネットワークプロトコルです。 Interfaceサービスメッセージテンプレートは以下の通りです。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 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_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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 8 bits Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
家族：8ビットのアドレスファミリ：AF_INET IPv4用;および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_SECONDARY。
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。これが設定されていない場合は、アドレスが動的に（例えば、ステートレス自動設定によって）作成されたことを意味します。 IFA_F_DEPRECATEDは非推奨（IPV4）アドレスを定義します。 IFA_F_TENTATIVEは仮（IPV4）アドレス（重複アドレス検出がまだ進行中である）を定義します。スコープ：8ビットアドレスが有効なままにアドレス範囲。 SCOPE_UNIVERSE：グローバルスコープ。 SCOPE_SITE（IPv6のみ）：このサイト内のみ有効です。 SCOPE_LINK：のみ、このデバイスに有効です。 SCOPE_HOST：だけこのホストで有効。
le attributes:
属性：
Attribute Description IFA_UNSPEC Unspecified. IFA_ADDRESS Raw protocol address of interface. IFA_LOCAL Raw protocol local address. IFA_LABEL ASCII string name of the interface. IFA_BROADCAST Raw protocol broadcast address. IFA_ANYCAST Raw protocol anycast address. IFA_CACHEINFO Cache address information.
説明IFA_UNSPECが指定されていない属性。インタフェースのIFA_ADDRESS生のプロトコルアドレス。 IFA_LOCAL生プロトコルローカルアドレス。インタフェースのIFA_LABEL ASCII文字列名。 IFA_BROADCAST生プロトコルのブロードキャストアドレス。 IFA_ANYCAST生プロトコルエニーキャストアドレス。 IFA_CACHEINFOキャッシュは、アドレス情報を。
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.
このサービスは、CPCのは、フォワーディングエンジンでのIPv4ルーティングテーブルを変更することができます。また、ルーティングアップデートを受信するだけでなく、統計情報を収集するためのCPCで使用することができます。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ファミリー| Srcの長さ| destの長さ| TOS | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |テーブルID |プロトコル|スコープ|タイプ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |国旗| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Family: 8 bits Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
家族：8ビットのアドレスファミリ：AF_INET IPv4用;および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長さ：8ビットの宛先IPアドレスのプレフィックス長。
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ビット、8ビットのTOS（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).
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.
（4）カーネルによって解釈されないRTPROT_STATICより大きい値は、彼らは、ユーザ情報のためだけです。彼らは、ルーティング情報のソースをタグ付けしたり、複数のルーティングデーモンを区別するために使用することができます。すでに割り当てられているルーティングデーモンの識別子のためには<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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ファミリー| Reserved1 | Reserved2 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |インタフェースインデックス| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |状態|国旗|タイプ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Family: 8 bits Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
家族：8ビットのアドレスファミリ：AF_INET IPv4用;および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 Aは作業キャッシュエントリが期限切れのキャッシュエントリをNUD_STALE確認しました。もはや到達可能NUD_DELAY近隣ません。トラフィックは、確認のために待って、送られました。現在、再勧誘されているキャッシュエントリをNUD_PROBE。無効なキャッシュエントリをNUD_FAILED。近隣探索をしないデバイス（ARP）をNUD_NOARP。スタティックエントリをNUD_PERMANENT。フラグ：8ビットNTF_PROXY AプロキシARPエントリ。 NTF_ROUTERアン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.
このサービスは、提供する機能を提供し、クエリやトラフィック制御の後援のイベントに耳を傾けます。分類 - これらは、キューイング分野、（例えば、優先度ベースのスケジューラまたはREDアルゴリズムスケジューラキュー処理アルゴリズム）が挙げられます。 Linuxのトラフィック制御サービスは非常に柔軟で、トラフィックのリソース共有のための異なるブロックの階層カスケードすることができます。
++ ++ +-----+ +-------+ ++ ++ .++
|| . || +------+ | |-->| 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のような単純なアルゴリズム、またはREDまたはトークンバケツのような、より複雑なもの、を受ける可能性があります。親と呼ばれ、最も外側の待ち行列規律は、典型的には、スケジューラに関連付けられています。このスケジューラ階層内では、しかし、Linuxの出口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.
これを可能にするサービスメッセージテンプレートは以下の通りです。このテンプレートは、入力および出力キューイング分野（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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ファミリー| Reserved1 | Reserved2 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |インタフェースインデックス| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ハンドルなqdisc | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |親のqdisc | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | TCM情報| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Family: 8 bits Address Family: AF_INET for IPv4; and AF_INET6 for IPV6.
家族：8ビットのアドレスファミリ：AF_INET IPv4用;および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インスタンスは、参照カウントを意味するように設定されている場合には、使用されている場合を除き、一般的に1にFEによって設定さ32ビットです。 CPCからのFECの方向に向けて、これは一般的に、フィルタのコンテキストで使用された場合を除き、0に設定されています。その場合には、この32ビットのフィールドは、16ビットの優先度フィールドと、16ビットのプロトコルフィールドに分割されます。プロトコルは、カーネルソース<含む/リナックス/ 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.
このサービスは、受信操作、及びFEにIPv4のファイアウォールサービスモジュールを介してパケットを再注入するクリック単価を可能にします。ファイアウォールルールは、最初のパケットのリダイレクトをアクティブにするために挿入されています。 CPCは、リダイレクトされる最大データ長であるもの、それはメタデータが所望される場合、単にパケットにメタデータまたは実際のデータを受信したいかどうかをFECに通知します。リダイレクトされたパケットは、まだCPCからの評決を待って、FECに格納されています。判決は、判決がまだ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に送信することができますが存在します。これらは次のとおりである：モードメッセージと評決メッセージ。モードメッセージは、CPCを受け取りたいものを記述するためにFECにすぐに送信されます。評決メッセージは、受信したパケットの運命に行われた決定後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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |モード| Reserved1 | Reserved2 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |レンジ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Mode: 8 bits Control information on the packet to be sent to the CPC. The different types are:
モード：8ビットは、CPCに送信するパケットの情報を制御します。さまざまな種類があります：
IPQ_COPY_META Copy only packet metadata to CPC.
IPQ_COPY_PACKET Copy packet metadata and packet payloads
to 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 . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |パケットID | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |マーク| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | timestamp_m | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | timestamp_u | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |フック| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | indev_name | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | outdev_name | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | hw_protocol | HW_TYPE | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | hw_addrlen |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | hw_addr | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | DATA_LEN | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ペイロード。 。 。 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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ビットのパケット到着時間（timestamp_mの秒に加えuseconds）
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 . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |バリュー| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |パケットID | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |データ長| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ペイロード。 。 。 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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.
Packet ID: 32 bits The packet identifier as passed to the CPC by the FEC.
パケットID：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にネイバーテーブルを管理するためのCPCで使用されます。 FECとCPCとの間で使用されるメッセージフォーマットは隣接設定サービスモジュールのセクションに記載されています。
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]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2]ベイカー、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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、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]ダラム、D.、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[5] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[5]モイ、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]ケース、J.、ヒョードル、M.、Schoffstall、M.とC.デーヴィンを、 "簡易ネットワーク管理プロトコル（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]アンダーソン、L.、Doolan、P.、フェルドマン、N.、Fredette、A.及びB.トーマス、 "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.、ブレイク、S.、グロスマン、D.とA.スミス、 "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イラスト2巻、第20章"、1995年6月。
[10] http://www.netfilter.org
「１０」 ｈっｔｐ：／／ｗっｗ。ねｔふぃｌてｒ。おｒｇ
[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能力を持つ唯一の誰かが（通常は、rootユーザ）はソケットを開くことが許可されていることを確認してください。
1) Andi Kleen, for man pages on netlink and rtnetlink.
1）アンディKleenが、ネットリンクとrtnetlinkのmanページのため。
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）アレクセイクズネツォフは、IPサービス配信モデルにするNetlinkを拡張するため入金されます。元する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）ジェレミーEthridgeするNetlinkを理解していなかった誰かの役割を取り、文書が、それは意味を成していることを確認するためにレビューします。
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、およびサービス（ラベル1-3）のためのCPとFEコンポーネント間のそれが持っている相互作用を示しています。
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).
< - > FEアドレッシングの図は、CPを実証するために使用されます。このセクションでは、我々は唯一のアドレッシングセマンティクスを説明します。付録2において、図は、サービス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に接続します。ソケット（AF_NETLINK、SOCK_RAW、NETLINK_FOO）：典型的な接続は、への呼び出しを介してであろう。
2) Bind to listen to specific asynchronous events for service foo.
2）バインドは、サービス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が1にするNetlinkを使用して、簡単なIPサービス制御を展開する方法を示すために再び使用されます。
These steps are continued from Appendix 1 (hence the numbering).
これらの手順は、付録1（したがってナンバリング）から継続されます。
4) Query for current config of FE component.
Fe成分の現在の設定4）クエリ。
5) Receive response to (4) via channel on (3).
5）（3）上のチャネルを介して（4）への応答を受信します。
6) Query for current state of IP service foo.
IPサービスfooの現在の状態のため6）クエリ。
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
付録A：その他の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は、FOOまたはコンポーネントに通信するためにネットリンクプロトコルを使用してもしなくてもよいです。 CLIは、サービスfooのFECの政策に影響を与えるコマンドを発行した場合、その後の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 FIFOキューにTC CPCから送信されたシンプルな構成するNetlinkメッセージが表示されます。このキュー・アルゴリズムは、パケットカウントに基づいており、限界が100個のパケットを超えた場合にパケットを廃棄します。 0と100のCLASSID：1と、それは4のifIndexの持つデバイスにインストールされることを私たちは、キューが親100と階層の設定になっていることを前提としています。
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |長さ（52）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ（RTM_NEWQDISC）|フラグ（NLM_F_EXCL | | | | NLM_F_CREATE | NLM_F_REQUEST）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |シーケンス番号（任意の数）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |プロセスID（0）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ファミリー（AF_INET）| Reserved1 | Reserved1 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |インターフェイスインデックス（4）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |なqdiscハンドル（0x1000001）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |親なqdisc（0x1000000番地）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | TCM情報（0）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ（TCA_KIND）|長さ（4）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |値（ "pfifo"）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ（TCA_OPTIONS）|長さ（4）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |値（限界値= 100）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Authors' Addresses
著者のアドレス
Jamal Hadi Salim Znyx Networks Ottawa, Ontario Canada
ジャマル・ハディサリムZNYXネットワークオタワ、オンタリオ州カナダ
EMail: hadi@znyx.com
メールアドレス：hadi@znyx.com
Hormuzd M Khosravi Intel 2111 N.E. 25th Avenue JF3-206 Hillsboro OR 97124-5961 USA
Hormuzd M Khosraviインテル2111 N.E.第25回アベニューJF3-206ヒルズボロOR 97124から5961 USA
Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
電話：+1 503 264 0334 Eメール：hormuzd.m.khosravi@intel.com
Andi Kleen SuSE Stahlgruberring 28 81829 Muenchen Germany
DクリーンSuSEのsthalagrberaringaのボイド28 81829 muincena
EMail: ak@suse.de
メールアドレス：ak@suse.de
Alexey Kuznetsov INR/Swsoft Moscow Russia
アレクセイ・クズネツォフINR / SWsoftのモスクワロシア
EMail: kuznet@ms2.inr.ac.ru
メールアドレス：kuznet@ms2.inr.ac.ru
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。