RFC3549 日本語訳
3549 Linux Netlink as an IP Services Protocol. J. Salim, H. Khosravi,A. Kleen, A. Kuznetsov. July 2003. (Format: TXT=72161 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループJ.サリムの要求をネットワークでつないでください: 3549Znyxはカテゴリをネットワークでつなぎます: 情報のH.のA.Kleen Suse A.クズネツォーフINR/Swsoft Khosraviインテル2003年7月
Linux Netlink as an IP Services Protocol
IPサービスプロトコルとしてのリナックスNetlink
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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.).
このドキュメントはリナックスNetlinkについて説明します。(Netlinkはイントラカーネルメッセージシステムとカーネルとユーザスペースの間のリナックスに使用されます)。 このドキュメントの焦点はForwarding Engine Component(FEC)とControl Plane Component(CPC)(IPサービスを定義する2つのコンポーネント)の間でNetlinkの機能性をプロトコルとして記述することになっています。 この焦点の結果、このドキュメントはNetlinkの他の用途を無視します、イントラカーネルメッセージシステムとして、または、相互プロセスコミュニケーション体系(IPC)として、または、他の非ネットワークの、または、非IPのネットワーク・サービスのための構成ツール(decnetなどの)として使用を含んでいて。
This document is intended as informational in the context of prior art for the ForCES IETF working group.
このドキュメントは従来技術の文脈のForCES IETFワーキンググループにおける情報として意図します。
Salim, et. al. Informational [Page 1] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[1ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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
1. 序論… 2 1.1. 定義… 3 1.1.1. 飛行機の部品(CPCs)を制御してください… 3 1.1.2. 推進機関部品(FECs)… 3 1.1.3. IPサービス… 5 2. Netlinkアーキテクチャ… 7 2.1. Netlinkの論理的なモデル… 8 2.2. メッセージ形式… 9 2.3. モデルについて議定書の中で述べてください… 9 2.3.1. アドレシングを修理してください… 10 2.3.2. Netlinkメッセージヘッダー… 10 2.3.3. FEシステムサービスのテンプレート… 13 3. 現在、Netlink IPサービスを定義します… 16 3.1. IPサービスNETLINK_ルート… 16 3.1.1. ルート機械船をネットワークでつないでください… 16 3.1.2. 隣人は機械船をセットアップします… 20 3.1.3. トラフィックコントロールサービス… 21 3.2. IPサービスNETLINK_ファイアウォール… 23 3.3. IPサービスNETLINK_ARPD… 27 4. 参照… 27 4.1. 標準の参照… 27 4.2. 有益な参照… 28 5. セキュリティ問題… 28 6. 承認… 28 付録1: サービス階層構造を抽出してください… 29 付録2: Foo IPサービスのためにプロトコルを抽出してください… 30付録2a: Other IPサービスと対話します… 30 付録3: 例… 31人の作者のアドレス… 32 完全な著作権宣言文… 33
1. Introduction
1. 序論
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 Service分離の概念は1990年代前半に最初に、BSD4.4ルーティングソケット[9]によって紹介されました。 その時、焦点はそのIPv4のためにサービスを進めながらテーブルを進めながらサービスとCPCがコマンドライン構成ツールかダイナミックなルートデーモンを通してどう制御されることができたかを進める簡単なIP(v4)でした。
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世界はあれからかなり発展しました。 サービスの食糧を供給するのと管理観点から観測されると、リナックスNetlinkは、より遠くにIPv4推進の周りの焦点のバリアを壊すことによってルーティングソケットにワンステップを取ります。 リナックス以来、2.1カーネル、Netlinkは古典的なRFC1812IPv4推進以外のいくつかのサービスにIPサービス抽象化を提供しています。
Salim, et. al. Informational [Page 2] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[2ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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視点について説明することです。 また、このドキュメントは、多くのForCESの文脈の中で役に立つメカニズムとして従来技術を得るのに役立ちます。 テキストがカーネルで利用可能なことに関する部分集合に制限される、2.4、.6、このドキュメントであるときに、最も新しいカーネルは最初に、書かれました。 また、それはIPv4の機能性に制限されます。
We first give some concept definitions and then describe how Netlink fits in.
私たちは、最初に、いくつかの概念規定を与えて、次に、Netlinkがどう適合するかを説明します。
1.1. Definitions
1.1. 定義
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.
Control Plane(CP)は私たちがCPCsを呼ぶいくつかのサブコンポーネントを持っているかもしれない実行環境です。 各CPCはForwarding Engine(FE)の部品によって実行される異なったIPサービスのためのコントロールを提供します。 いくつかのIPサービスを制御しているなら、この関係は、数個のCPCsが物理的なCPにあるかもしれないことを意味します。 本質では、CPの部品とFEの部品の間の結合はサービス抽象化です。
1.1.1. Control Plane Components (CPCs)
1.1.1. コントロール飛行機の部品(CPCs)
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.
コントロールPlane Componentsは合図プロトコルを包含します、多様性が分配プロトコルにタグ付けをするためにOSPF[5]などのダイナミックルーティングプロトコルから変化していて、CR-自由民主党[7]などのように。 また、古典的経営学プロトコルと活動はこのカテゴリの下で下がります。 これらはSNMP[6]、COPS[4]、および独占CLI/GUI構成メカニズムを含んでいます。制御飛行機の目的は究極の目標がある上記の活動のための実行環境が提供するためには、第2Network Element(NE)の部品を構成して、管理することであるということです: FE。 構成の結果はFEを横断するパケットが扱われる方法を定義します。
1.1.2. Forwarding Engine Components (FECs)
1.1.2. 推進機関部品(FECs)
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
FEのサービス特有のコンポーネントはIPサービスを達成するために処理をそれに提供するためにパケットをマッサージします、そのIPサービスのためにControl Plane Componentsによって定義されるように。 異なったサービスは異なったFECsを利用するでしょう。 機械船は、aを達成するためにチェーニングされるかもしれません。
Salim, et. al. Informational [Page 3] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[3ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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モデルについて言及します)。 特定のサービスを提供するために建てられると、FEサービスの部品は推進モデルを固く守るでしょう。
1.1.2.1. Linux IP Forwarding Engine Model
1.1.2.1. リナックスIP推進エンジンモデル
____ +---------------+
+->-| 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 |-->
+-------+ +-------+ +--------+
____ +---------------+ +->、-| FW|、-、--、>| TCP、UDP… | | +----+ +---------------+ | | ^v| _|_ +----<、-、-、--+ | FW| | +----+ ^ | | ホストFromホストスタックスタック^へのY| |_____ | イングレス^Yデバイス____ +-------+ +|---|--+ ____ +--------+ 出口->。----->| FW| -->、|イングレス| -->、-、-、--、>| Forw|、-、>| FW|、-、>| 出口| デバイス+----+ | Tc| | 急性呼吸器病| +----+ | 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].
リナックスFEがデバイス単位でモデル化するショーを超えた図。 datapathの唯一の義務的な部分がForwardingモジュールです。(そのモジュールはRFC1812conformantです)。 異なったFirewall(FW)、Ingress Traffic Control、およびEgress Traffic Controlブロックは、datapathで義務的でなく、1812年のRFCモジュールを迂回させるのに使用さえされるかもしれません。 これらのモジュールは、簡単なブロックとしてdatapathに示されますが、事実上、示されたブロックの中の複数のどっと落して、独立している「副-モジュール」であるかもしれません。 [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 Traffic Controlモジュールで通過されるかもしれません。 活動を計量して、取り締まるのはIngress TCモジュールの中に含まれています。 このモジュールで結果を計量して、方針を取り締まるのによって、パケットは下げられるかもしれません。 次に、パケットは唯一の非任意のモジュール、RFC 1812-conformant Forwardingモジュールにかけられます。 パケットはそれがnonconformant(1812と1122の補足となる多くのRFCsへの)であるなら下げられるかもしれません。 このモジュールは推進NEに運命づけられたパケットがホストスタックまで送られるかもしれない時点のポイントです。
Salim, et. al. Informational [Page 4] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[4ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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/変換はパケット、遭遇する構成されたサブモジュールによって、およびそれらの方針を落とします。 すべてがうまく行くなら、Egress 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.
Egress TCは取り締まっていて、計画をしている輻輳制御、または速度制御理由でパケットを下げるかもしれません。 出口待ち行列はここに存在します、そして、以前かパケットが列に並ばせられた後に低下か遅れのいずれも起こるかもしれません。 すべてが構成されたモジュールアルゴリズムと方針に依存しています。
1.1.3. IP Services
1.1.3. IPサービス
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サービスはこのような関係においてはPer-ホップBehaviorです。 NEsの上で作業するCPの部品が実行しているコントロール/シグナリング管理プロトコル/アプリケーションでサービスのための終わりからエンドへの経路制御を定義します。 これらの分配されたCPCsは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 Forwardingです。 この場合、ルーティング・プロトコル(OSPF、RIPなど)や独占CLI/GUI構成などのコントロールの部品は、次のホップに対する推進パケットの簡単なサービスを提供するようにFEの推進テーブルを変更します。 伝統的に、この簡単なサービスを提供するNEsがルータとして知られています。
Salim, et. al. Informational [Page 5] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[5ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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サービスの例を拡大に提供するために簡単なFE<->にCPセットアップを示しています。
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| | |
| | ----------- ---------- | |
| | | |
| --------------------------------------- |
| |
-------------------------------------------------------
飛行機(CP)を制御してください。------------------------------------ | /^^^^^^\ /^^^^^^\ | | | | | 巡査|-\ | | | ospfd| | 気力| \ | | \ / \_____/ | | /------\_____/ | / | | | | | / | | |_________\__________|____|_________| | | | | ****************************************** 推進..層にする..エンジン-------------|-----------|----------|---|------------- | IPv4推進| | | | FEサービス//| | コンポーネント//| | ---------------/---------------/--------- | | | | / | | パケット| | --------|-- ----|----- | 中のパケット| | | IPv4| | 出口| | アウト-->。--->|、-、-、-、-、--、>|、-、-、--、>|推進|、-、-、-、--、>| QoS|、-、--、>| ---->|、-、>|、|、|、|、| スケジューラ| | | | | ----------- ---------- | | | | | | | --------------------------------------- | | | -------------------------------------------------------
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.
上のダイヤグラムは異なったCPCsとしてospfd、OSPFプロトコルコントロールデーモン、およびCOPS Policy Enforcement Point(PEP)を例証します。 IPv4 FEの部品はEgress Scheduling機械船と同様にIPv4 Forwarding機械船を含んでいます。 別のサービスは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
数年間、満たす要件として現れるルータに対する追加サービスを加えるのは重要になっています。 古典的な推進を広げるより複雑なサービスが、加えられて、標準化されました。 これらのより新しいサービスはパケットのヘッダーの層3のコンテンツを越えるかもしれません。 しかしながら、誤称ですが、名前「ルータ」は、これらのNEsについて説明するのにまだ使用されています。 サービス、(どれが先を見るかもしれないか。
Salim, et. al. Informational [Page 6] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[6ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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.
古典的な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.
1つの極端なIPサービスの定義がサービスプロバイダーが充電できる何かです。
2. Netlink Architecture
2. Netlinkアーキテクチャ
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推進かルート追加か削除のための)を操作するかにControl Plane Componentからのアップデートを乗せるかもしれません。
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サービスと呼ぶつもりです。 また、異なったトランスポート層の中でNetlinkサービスをカプセル化することができます、CPCがFECよりa異なるところでノードを作成するなら。 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が同じメモリプロテクションドメインと使用にともに住むことができることに注意してください、経路を同輩に作成して、互いに話すために() システムコールを接続してください。 私たちはそれが利用可能であるとさらに言う以外のこのメカニズムについて議論するつもりではありません。 このドキュメント中では、私たちは、カーネルスペースとCPCがユーザスペースを意味することを意味するためにFECについて互換性を持って言及するつもりです。 しかしながら、2つのコンポーネントをこれらの保護ドメインに制限することになっていないか、この宗派は同じくらいにノードを計算することになっていません。
Note: Netlink allows participation in IP services by both service components.
以下に注意してください。 Netlinkは両方のサービスコンポーネントでIPサービスへの参加を許します。
Salim, et. al. Informational [Page 7] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[7ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
2.1. Netlink Logical Model
2.1. Netlinkの論理的なモデル
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論理的関係性を示しています。 私たちは、例として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 | | |
| | ------ | |
| --------------------------------------- |
| |
-----------------------------------------------------
飛行機(CP)を制御してください。------------------------------------ | /^^^^^\ /^^^^^\ | | | | /CPC-2円| | | CPC-1| | 巡査| | | | ospfd| | 気力| | | | / \____ _/ | | \____/ | | | | | | ****************************************| ************* 放送ワイヤ************FE---------- *****************************************. | IPv4推進| | | | | FEC| | | | | --------------/ ----|-----------|-------- | | | / | | | | | | .-------. .-------. .------. | | | | |イングレス| | IPv4| |出口| | | | | |警察| |転送| | QoS| | | | | |_______| |_______| |Schedしました。| | | | | ------ | | | --------------------------------------- | | | -----------------------------------------------------
Netlink logically models FECs and CPCs in the form of nodes interconnected to each other via a broadcast wire.
Netlinkは放送ワイヤを通して互いにインタコネクトされたノードの形でFECsとCPCsを論理的にモデル化します。
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.
ノード(上で例証されるCPCsかFECs)は、ワイヤに接続して、特定のメッセージを受け取るために登録します。 それらがサービスをよりよく制御するのを助けるなら、CPCsは複数のワイヤに接続するかもしれません。 すべてのノード(CPCsとFECs)が放送ワイヤの上にパケットをどさっと落とします。 それらが奇形かワイヤのために明確にフォーマットされていないなら、ワイヤはパケットを捨てることができます。 下げられたパケットはノードのいずれによっても見られません。 malformatted Netlinkパケットを検出するなら、Netlinkサービスは誤りを送付者に示すかもしれません。
Salim, et. al. Informational [Page 8] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[8ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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.
パケットは、ワイヤが放送、マルチキャスト、またはユニキャストであるかもしれないことを転送しました。 FECsかCPCsが処理かちょうどモニターしている目的への興味がある特定のメッセージに登録します。
Appendices 1 and 2 have a high level overview of this interaction.
付録1と2には、この相互作用の高い平らな概要があります。
2.2. Message Format
2.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つのレベルがあります: IPサービスの一般的なNetlinkメッセージヘッダー、特定のテンプレート、および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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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サービステンプレート| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLVsのIPのServiceの特定のデータ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージは、FECsのパラメタリゼーション、CPCsへの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 Service Templateヘッダーはサービスに特定です。 次に、それぞれのIP Serviceがパラメタリゼーションデータを運ぶ、(CPC、-、>FEC方向)、応答、(FEC->、CPC、方向) これらのパラメタリゼーションは、TLV(長さ値をタイプする)形式にはあって、サービスにユニークです。
The different parts of the netlink message are discussed in the following sections.
以下のセクションでnetlinkメッセージの異なった部分について議論します。
2.3. Protocol Model
2.3. プロトコルモデル
This section expands on how Netlink provides the mechanism for service-oriented FEC and CPC interaction.
このセクションはNetlinkがどうサービス志向のFECとCPC相互作用にメカニズムを供給するかを詳述します。
Salim, et. al. Informational [Page 9] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[9ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
2.3.1. Service Addressing
2.3.1. サービスアドレシング
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タイプソケットのどちらかを開くかもしれません。 ソケット接続は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までほとんど構成目的)を発行するか、統計収集命令を発行するか、申し込むか、または外すのが、サービスに接続するということになります(接続の寿命の間の任意な点で)。 ソケットを閉じると、トランザクションは終えられます。 例についてAppendices1と2を参照してください。
2.3.2. Netlink Message Header
2.3.2. Netlinkメッセージヘッダー
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メッセージの上の分裂であるかもしれないというただ一つのメッセージに収まるように大きくて、まとめて呼ばれた複合メッセージであるなら。 複合メッセージに関しては、1番目とすべての次のヘッダーがNLM_F_MULTI Netlinkヘッダー旗を設定させます、NetlinkヘッダーにNLMSG_DONEをタイプさせる最後のヘッダーを除いて。
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salim, et. al. Informational [Page 10] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[10ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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.
以下をタイプしてください。 Thisがさばく16ビットはメッセージ内容について説明します。 それは標準のメッセージタイプのひとりであることができます: NLMSG_NOOP Messageは無視されます。 メッセージが誤りとペイロードを示すNLMSG_ERRORはnlmsgerr構造を含んでいます。 ナックとしてこれを見ることができます、そして、通常、FECからCPCまでそれはあります。 NLMSG_DONE Messageは複合メッセージを終えます。
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).
旗: ___メッセージがNLMSG_DONE NLMによって終えられた複合メッセージの一部であるという要求メッセージ(通常、ユーザスペースからカーネルスペースまでの)NLM_F MULTI Indicatesのセットが成功における承認のためのF_ACK Requestであったなら、Netlinkで標準の中古さフラグビットであることは、16ビット、NLM_F REQUEST Mustです。 ユーザスペース(CPC)からカーネルスペース(FEC)まで要求の典型的な方向があります。 _NLM_F ECHO 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.
GETのための追加フラグビットはコンフィグでFECの情報を要求します。 完全なROOT Returnが単一のエントリーの代わりにテーブルの上に置くNLM_F_。 NLM、_すべてのエントリーマッチング評価基準が中に渡したF_MATCH Returnは内容を通信させます。 _NLM_F ATOMIC Return、参照をつけられるテーブルの原子スナップ。 それには、より長い時間FEでサービスを中断する可能性があるので、これは特権を必要とするかもしれません。
Convenience macros for flag bits:
NLM_F_DUMP This is NLM_F_ROOT or'ed with NLM_F_MATCH
何フラグビットも便利マクロ: _NLM_F DUMP This、_NLM_Fは_NLM_F MATCHとROOT or'edです。
Salim, et. al. Informational [Page 11] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[11ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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.
NEWのための追加フラグビットはREPLACE Replaceの既存のマッチングコンフィグがこの要求で反対させるNLM_F_を要求します。 既に存在するなら、NLM_F_EXCLドンはコンフィグオブジェクトを取り替えません。 NLM_F_CREATE Createコンフィグオブジェクトはそれであるなら既に存在していません。 _オブジェクトリストの終わりまでのNLM_F APPEND Add。
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
- または、BSD ADD操作が_NLM_F CREATEに一致している、-、教育、_BSD CHANGE操作が_NLM_F REPLACEに一致しているというNLM_F EXCLと共に、BSD Check操作は_NLM_F EXCLに一致しています--BSD APPEND同等物は実際に_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は使用されています。
2.3.2.1. Mechanisms for Creating Protocols
2.3.2.1. プロトコルを作成するためのメカニズム
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.
1つは、FECとCPCの間で一連番号、ACKs、および再送信タイマの組み合わせを使用することによって、信頼できるプロトコルを作成するかもしれません。 一連番号とACKsの両方がNetlinkによって提供されます。 リナックスはタイマを提供します。
One could create a heartbeat protocol between the FEC and CPC by using the ECHO flags and the NLMSG_NOOP message.
1つは、FECとCPCの間でECHO旗とNLMSG_NOOPメッセージを使用することによって、鼓動プロトコルを作成するかもしれません。
Salim, et. al. Informational [Page 12] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[12ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
2.3.2.2. The ACK Netlink Message
2.3.2.2. ACK Netlinkメッセージ
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とナックの両方を指示するのに実際に使用されます。 通常、FECからCPC(ACK要求メッセージに対応した)まで方向があります。 しかしながら、要求されると、CPCはACKsを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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
非ゼロエラーコードメッセージはNegative ACK(ナック)に同等です。 そのような状況で、オリジナルのNetlinkメッセージヘッダーに追加していた状態でカーネルまで送られたNetlinkデータを返します。 また、perror()を通して印刷可能なエラーコードは設定されます(メッセージヘッダーと、むしろ実行環境で、変数を述べません)。
2.3.3. FE System Services' Templates
2.3.3. FEシステムサービスのテンプレート
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の中に存在している理由は歴史的な粗末な作りの結果のためです: Route SocketsがIPv4推進ソケットの一部として彼らを実装したBSD4.4。
Salim, et. al. Informational [Page 13] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[13ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
2.3.3.1. Network Interface Service Module
2.3.3.1. ネットワーク・インターフェース機械船
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ビットのThisはいつも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ビットのThisはリンクのタイプを定義します。 リンクはイーサネット、トンネルであるかもしれませんなど。 リンク型はL3プロトコル独立者ですが、私たちはIPv4だけに興味を持っています。
Interface Index: 32 bits Uniquely identifies interface.
インデックスを連結してください: Uniquelyが特定する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 Interfaceは行政上上がっています。 IFF_BROADCAST Valid放送演説はセットしました。 IFF_DEBUG Internalデバッグ旗。 IFF_LOOPBACK Interfaceはループバックインタフェースです。 IFF_POINTOPOINT Interfaceはポイントツーポイント接続です。 IFF_RUNNING Interfaceは操作上上がっています。 このインタフェースに必要であるIFF_NOARPいいえARPプロトコル。 IFF_PROMISC Interfaceが無差別なモードであります。 トレーラのIFF_NOTRAILERS Avoid使用。 IFF_ALLMULTI Receive、すべてのマルチキャストパケット。 ロードバランシングバンドルのIFF_MASTER Master。 ロードバランシングバンドルのIFF_SLAVE Slave。 IFF_MULTICAST Supportsマルチキャスト。
Salim, et. al. Informational [Page 14] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[14ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
IFF_PORTSEL Is able to select media type via ifmap.
IFF_AUTOMEDIA Auto media selection active.
IFF_DYNAMIC Interface was dynamically created.
メディアを選択できるIFF_PORTSEL Isがifmapを通してタイプします。 IFF_AUTOMEDIA Autoメディア選択アクティブです。 IFF_DYNAMIC Interfaceはダイナミックに作成されました。
Change Mask: 32 bits Reserved for future use. Must be set to 0xFFFFFFFF.
マスクを変えてください: 今後の使用のための32ビットのReserved。 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.
適切な属性: 記述を結果と考えてください… IFLA_UNSPEC不特定です。 IFLA_ADDRESS Hardwareは、インタフェースL2がアドレスであると扱います。 IFLA_BROADCAST Hardwareは、L2が放送演説であると扱います。 IFLA_IFNAME ASCIIは装置名を結びます。 デバイスのIFLA_MTU MTU。 このデバイスが制限されているリンクのIFLA_LINK ifindex。 出口根の待ち行列の規律を定義するQDISC ASCIIが結ぶIFLA_。 IFLA_STATS Interface統計。
Netlink message types specific to this service: RTM_NEWLINK, RTM_DELLINK, and RTM_GETLINK
このサービスに特定のNetlinkメッセージタイプ: RTM_NEWLINK、RTM_DELLINK、およびRTM_GETLINK
2.3.3.2. IP Address Service Module
2.3.3.2. IPアドレス機械船
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ビットのAddress Family: 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_のSECONDARY Forのセカンダリアドレス(別名インタフェース)。
Salim, et. al. Informational [Page 15] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[15ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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 For a本籍はユーザでセットしました。 これが設定されないとき、それは、アドレスがダイナミックに作成されたことを(例えば、状態がない自動構成で)意味します。 IFA_F_のDEPRECATED Definesの推奨しない(IPV4)アドレス。 IFA_F_のTENTATIVE Definesの一時的な(IPV4)アドレス(写しアドレス検出はまだ進行しています)。 範囲: 8ビット、アドレスが有効な状態で残っているアドレスは見ます。 範囲_宇宙: グローバルな範囲。 SCOPE_SITE(IPv6専用): このサイトの中で有効であるだけです。 範囲_はリンクします: このデバイスだけでは、有効です。 範囲_は以下を接待します。 このホストだけでは、有効です。
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はanycastアドレスについて議定書の中で述べます。 IFA_CACHEINFO Cacheは情報を扱います。
Netlink messages specific to this service: RTM_NEWADDR, RTM_DELADDR, and RTM_GETADDR.
このサービスに特定のNetlinkメッセージ: RTM_NEWADDR、RTM_DELADDR、およびRTM_GETADDR。
3. Currently Defined Netlink IP Services
3. 現在定義されたNetlink IPサービス
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と統合されたおよそ1つの一握りのものだけについて話すつもりです。 これらは以下の通りです。
NETLINK_ROUTE, NETLINK_FIREWALL, and NETLINK_ARPD.
NETLINK_ルート、NETLINK_ファイアウォール、およびNETLINK_ARPD。
3.1. IP Service NETLINK_ROUTE
3.1. IPサービスNETLINK_ルート
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はForwarding EngineでIPv4経路指定テーブルを変更できます。 また、CPCsは、ルーティングアップデートを受けて、統計を集めるのにそれを使用できます。
3.1.1. Network Route Service Module
3.1.1. ネットワークルート機械船
This service provides the ability to create, remove or receive information about a network route. The service message template is shown below.
このサービスはネットワークルートの情報を作成するか、取り除くか、または受け取る能力を提供します。 サービスメッセージテンプレートは以下で見せられます。
Salim, et. al. Informational [Page 16] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[16ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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ビットのAddress Family: IPv4のためのAF_INET。 そして、IPV6のためのAF_INET6。
Src length: 8 bits Prefix length of source IP address.
Srcの長さ: ソースIPアドレスの8ビットのPrefixの長さ。
Dest length: 8 bits Prefix length of destination IP address.
Destの長さ: 送付先IPアドレスの8ビットのPrefixの長さ。
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ビットのTable識別子。 最大255個のルートテーブルが支えられます。 RT_TABLEの_のUNSPEC Anの不特定の経路指定テーブル。 RT_TABLE_DEFAULT、デフォルトテーブル。 RT_TABLE_MAIN、主卓。 地方のLOCALがテーブルの上に置くRT_TABLE_。
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.
プロトコル: 8ビットのIdentifies、ルートを加えた何という/。 Route発生源について議定書の中で述べてください。 .............................................. RTPROT_UNSPEC未知。 RTPROT_REDIRECT By、ICMPは向け直します。 RTPROT_KERNEL By、カーネル。 RTPROT_BOOT During bootup。 管理者のRTPROT_STATIC By。
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>を見てください。
Salim, et. al. Informational [Page 17] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[17ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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ビットのRoute範囲(目的地への有効な距離)。 RT_SCOPE_宇宙Globalルート。 SITE Interiorが地方の自律システムで発送するRT_SCOPE_。 RT_SCOPE_LINK Routeはこれでリンクします。 地方のHOST Routeが接待するRT_SCOPE_。 RT_SCOPE_NOWHERE Destinationは存在していません。
The values between RT_SCOPE_UNIVERSE(0) and RT_SCOPE_SITE(200) are available to the user.
ユーザにとって、RT_SCOPE_宇宙(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).
ルートタイプ記述---------------------------------------------------- UNSPEC Unknownが発送するRTN_。 RTN_UNICAST Aゲートウェイか直航路。 RTN_LOCAL A局所界面ルート。 RTN_BROADCAST Aローカル放送ルート(放送として、発信します)。 ANYCAST An anycastが発送するRTN_。 RTN_MULTICAST Aマルチキャストルート。 RTN_BLACKHOLEのA静かなパケット低下ルート。 RTN_UNREACHABLE Anの手の届かない目的地。 パケットは低下しました、そして、ホストの手の届かないICMPsを創始者に送ります。 RTN_PROHIBIT Aパケット拒絶ルート。 パケットを下げます、そして、コミュニケーションの禁止されたICMPsを創始者に送ります。 方針ルーティングで使用されるRTN_THROW When、別のテーブルでルックアップを発送し続けてください。 正常なルーティングの下では、パケットを下げます、そして、ネットの手の届かないICMPsを創始者に送ります。 RTN_NAT Aネットワークアドレス変換は統治されます。 外部のレゾルバ(実装されない)へのRTN_XRESOLVE Refer。
Salim, et. al. Informational [Page 18] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[18ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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ビットのFurtherはルートに資格を与えます。 RTM、_ルートが変えるF_NOTIFY If、ユーザに通知してください。 RTM_F_CLONED Routeは別のルートからクローンを作られます。 マルチ経路ルーティング(現在、実装されない)における、次のホップ経路のRTM_F_EQUALIZE Allow無作為化。
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.
このサービスに適切な属性: 属性記述--------------------------------------------------- UNSPECが無視したRTA_。 ルート送付先アドレスのためのRTA_DSTプロトコルアドレス。 ルートソースアドレスのためのRTA_SRCプロトコルアドレス。 RTA_IIF Inputはインデックスを連結します。 RTA_OIF Outputはインデックスを連結します。 ルートのルートRTA_PRIORITY PriorityのゲートウェイへのRTA_ゲートウェイプロトコルアドレス。 1つ以上のソースアドレスを使用できた場合におけるRTA_PREFSRC Preferredソースアドレス。 ルートの結果と考えられたRTA_METRICS Route測定基準と関連プロトコル(例えば、RTT、初期のTCPの窓など)。 RTA_MULTIPATH Multipathは次のホップの属性を発送します。 RTA_PROTOINFO Firewallは方針ルーティング属性を基礎づけました。 RTA_FLOW Route分野。 RTA_CACHEINFO Cachedは情報を発送します。
Additional Netlink message types applicable to this service: RTM_NEWROUTE, RTM_DELROUTE, and RTM_GETROUTE
このサービスに適切な追加Netlinkメッセージタイプ: RTM_NEWROUTE、RTM_DELROUTE、およびRTM_GETROUTE
Salim, et. al. Informational [Page 19] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[19ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
3.1.2. Neighbor Setup Service Module
3.1.2. 隣人セットアップ機械船
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ビットのAddress Family: 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ビットのAビットマスク: 決議するNUD_INCOMPLETE Stillの試み。 NUD_REACHABLE Aは働くキャッシュエントリーNUD_STALEを確認しました。満期のキャッシュエントリー。 もうNUD_DELAY Neighbor、届きます。 確認を待っていて、トラフィックは発信しました。 NUD_PROBE Aは現在再請求されているエントリーをキャッシュします。 NUD_FAILED Anの無効のキャッシュエントリー。 隣人発見(ARP)をしないNUD_NOARP Aデバイス。 NUD_PERMANENTのA静的なエントリー。 旗: 8ビットのNTF_PROXY AプロキシARPエントリー。 NTF_ROUTER An IPv6ルータ。
Salim, et. al. Informational [Page 20] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[20ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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.
このサービスに適切な属性: 属性記述------------------------------------ NDA_UNSPEC Unknownはタイプします。 NDA_DST A隣人キャッシュネットワーク送付先アドレスNDA_LLADDR A隣人キャッシュリンクレイヤアドレスを層にしてください。 NDA_CACHEINFO Cache統計。
Additional Netlink message types applicable to this service: RTM_NEWNEIGH, RTM_DELNEIGH, and RTM_GETNEIGH.
このサービスに適切な追加Netlinkメッセージタイプ: RTM_NEWNEIGH、RTM_DELNEIGH、およびRTM_GETNEIGH。
3.1.3. Traffic Control Service
3.1.3. トラフィックコントロールサービス
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アルゴリズム) そして、クラシファイア。 リナックスTraffic Control Serviceは非常にフレキシブルであり、トラフィックリソース・シェアリングのための異なったブロックの階層的な滝を考慮します。
++ ++ +-----+ +-------+ ++ ++ .++
|| . || +------+ | |-->| Qdisc |-->|| || ||
|| ||---->|Filter|--->|Class| +-------+ ||-+ || ||
|| || | +------+ | +---------------+| | || ||
|| . || | +----------------------+ | || .||
|| . || | +------+ | || ||
|| || +->|Filter|-_ +-----+ +-------+ ++ | || .||
|| -->|| | +------+ ->| |-->| Qdisc |-->|| | ||->||
|| . || | |Class| +-------+ ||-+-->|| .||
->dev->|| || | +------+ _->| +---------------+| || ||
|| || +->|Filter|- +----------------------+ || .||
|| || +------+ || .||
|| . |+----------------------------------------------+| ||
|| | Parent Queuing discipline | .||
|| . +------------------------------------------------+ .||
|| . . .. . . .. . . . .. .. .. . .. ||
|+--------------------------------------------------------+|
| Parent Queuing discipline |
| (attached to egress device) |
+----------------------------------------------------------+
++ ++ +-----+ +-------+ ++ ++ .++ || . || +------+ | | -->、| Qdisc| -->、|、| || || || |、|、-、-、--、>|フィルタ|、-、--、>|クラス| +-------+ ||-+ || || || || | +------+ | +---------------+| | || || || . || | +----------------------+ | || .|| || . || | +------+ | || || || || +->|フィルタ|-_ +-----+ +-------+ ++ | || .|| || -->|、|、| +------+ ->| | -->、| Qdisc| -->、|、|、| |、|、-、>|、| || . || | |クラス| +-------+ ||-+-->|、| .|| ->dev、->|、| || | +------+ _->| +---------------+| || || || || +->|フィルタ|- +----------------------+ || .|| || || +------+ || .|| || . |+----------------------------------------------+| || || | 親Queuing規律| .|| || . +------------------------------------------------+ .|| || . . .. . . .. . . . .. .. .. . .. || |+--------------------------------------------------------+| | 親Queuing規律| | (出口デバイスに取り付けます) | +----------------------------------------------------------+
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
上のダイヤグラムはEgress TCブロックの例を示しています。 私たちはここで非常に簡潔になろうとします。 詳しくは、[11]を参照してください。 パケットは最初に、パケットが属するかもしれないクラスを特定するのに使用されるフィルタを通ります。 クラスは本質的には端末です。
Salim, et. al. Informational [Page 21] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[21ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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.
列を作りは、それに関連している待ち行列を訓練して、持っています。 待ち行列は簡単なアルゴリズムを受けることがあるかもしれません、先入れ先出し法、または、より複雑な人がREDか象徴バケツが好きであるように。 一番はずれの待ち行列の規律であり、どれが親と呼ばれるかは、スケジューラに通常関連しています。 しかしながら、中では、リナックスEgress 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ビットのAddress Family: 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ビットUnique識別子。 通常、これは少佐に分けられます: それぞれ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ビットのUsed。 この値と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
TCMインフォメーション: Qdisc例が使用中である時を除いて、どれがそれをケースに入れるかで1へのFEによる32ビットのSetは参照カウントを含意するように通常用意ができています。 FECの方向に向かったCPCから、これは0に通常設定されます。
Salim, et. al. Informational [Page 22] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[22ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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).
フィルタの文脈で使用される時を除いて。 その場合、この32の噛み付いている分野は16ビットの優先権分野と16ビットのプロトコル分野に分けられます。 プロトコルはしかしながら、カーネルソース<で定義されて、_ether.h>であるなら/linux/を含めてください、最も一般的に使用されたものが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.
このサービスに適切な一般的な属性: 属性記述------------------------------------ KIND Canonicalが命名するFEの部品のTCA_。 FEC TCA_RATEのTCA_STATS Generic用法統計はFECに付けられた見積り人存在を評定します。 レートを計算するために統計のスナップを取ります。 FECのTCA_XSTATS Specific統計。 TCA_OPTIONS Nested FEC特有の属性。
Appendix 3 has an example of configuring an FE component for a FIFO Qdisc.
付録3には、先入れ先出し法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。
3.2. IP Service NETLINK_FIREWALL
3.2. IPサービスNETLINK_ファイアウォール
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.
このサービスで、CPCsはFEのIPv4ファイアウォール機械船でパケットを受けて、操って、再注入します。 ファイアウォール規則は、最初に、パケットリダイレクションを動かすために挿入されます。 CPCは、それが向け直されるためにまさしくパケットか実際のデータとメタデータが望まれているときの最大のデータの長さであることに関するメタデータを受け取りたがっているかどうかをFECに知らせます。 CPCから議決を待っていて、向け直されたパケットはFECにまだ格納されています。 パケットの決定を受け入れるか、または落として、議決がどの場合であるかにまだパケットに課されていて、議決は、FECに座りながら、簡単な状態でaを構成するかもしれません。 また、議決は、交換として転送するために変更されたパケットを含むかもしれません。
Salim, et. al. Informational [Page 23] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[23ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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つのタイプに関するメッセージは存在しています。 これらは以下の通りです。 モードメッセージとVerdictメッセージ。 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:
モード: CPCに送られるパケットの8ビットのControl情報。 異なったタイプは以下の通りです。
IPQ_COPY_META Copy only packet metadata to CPC.
IPQ_COPY_PACKET Copy packet metadata and packet payloads
to CPC.
IPQ_COPY_META Copy、CPCへのパケットメタデータだけ。 CPCへのIPQ_COPY_PACKET Copyパケットメタデータとパケットペイロード。
Range: 32 bits If IPQ_COPY_PACKET, this defines the maximum length to copy.
範囲: 32ビットのIf IPQ_COPY_PACKET、これはコピーするために最大の長さを定義します。
Salim, et. al. Informational [Page 24] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[24ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マーク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ_m| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ_u| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フック| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | indev_名| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | outdev_名| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hw_プロトコル| hw_タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hw_addrlen| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hw_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ_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)
タイムスタンプ_m: 32ビットのPacket到着時間(秒)
timestamp_u: 32 bits Packet arrival time (useconds in addition to the seconds in timestamp_m)
タイムスタンプ_u: 32ビットのPacket到着時間(タイムスタンプ_mの秒に加えたuseconds)
hook: 32 bits The firewall module from which the packet was picked.
以下を掛けてください。 32ビット、パケットが選ばれたファイアウォールモジュール。
Salim, et. al. Informational [Page 25] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[25ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
indev_name: 128 bits ASCII name of incoming interface.
indev_名前: 入って来るインタフェースの128ビットのASCII名。
outdev_name: 128 bits ASCII name of outgoing interface.
outdev_名前: 外向的なインタフェースの128ビットのASCII名。
hw_protocol: 16 bits Hardware protocol, in network order.
hw_プロトコル: 16ビットのHardwareはネットワークオーダーで議定書を作ります。
hw_type: 16 bits Hardware type.
hw_タイプ: 16ビットのHardwareはタイプします。
hw_addrlen: 8 bits Hardware address length.
hw_addrlen: 8ビットのHardwareは長さを記述します。
hw_addr: 64 bits Hardware address.
hw_addr: 64ビットのHardwareアドレス。
data_len: 32 bits Length of packet data.
_データlen: パケットデータの32ビットのLength。
Payload: size defined by data_len The payload of the packet received.
有効搭載量: パケットのペイロードが受けたデータ_lenによって定義されたサイズ。
The Verdict message format is as follows
Verdictメッセージ・フォーマットは以下の通りです。
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.
そして、NF_ACCEPT Accept、パケット、それに縦断を続けさせてください。 NF_DROP Drop、パケット。
Salim, et. al. Informational [Page 26] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[26ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
Packet ID: 32 bits The packet identifier as passed to the CPC by the FEC.
パケットID: 32ビット、FECによってCPCに通過されるパケット識別子。
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.
有効搭載量: Data Length分野によって定義されるサイズ。
3.3. IP Service NETLINK_ARPD
3.3. IPサービスNETLINK_ARPD
This service is used by CPCs for managing the neighbor table in the FE. The message format used between the FEC and CPC is described in the section on the Neighbor Setup Service Module.
このサービスは、FEで隣人テーブルを管理するのにCPCsによって利用されます。 FECとCPCの間で使用されるメッセージ・フォーマットはNeighbor Setup Service Moduleの上のセクションで説明されます。
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に請求するのに使用されます。
4. References
4. 参照
4.1. Normative References
4.1. 引用規格
[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、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年6月。
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[2] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、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.ウィス、「微分されたサービスのための構造」、RFC2475、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.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[5] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[5]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、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)」、STD15、RFC1157)は1990がそうするかもしれません。
Salim, et. al. Informational [Page 27] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[27ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
[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.トーマス、「自由民主党仕様」、RFC3036、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ルータのためにモデル化します」、RFC3290、2002年5月。
4.2. Informative References
4.2. 有益な参照
[9] G. R. Wright, W. Richard Stevens. "TCP/IP Illustrated Volume 2,
Chapter 20", June 1995.
[9] G.R.ライト、W.リチャード・スティーブンス。 「TCP/IPは20インチと、1995年6月に第2巻、章を例証しました。」
[10] http://www.netfilter.org
[10] http://www.netfilter.org
[11] http://diffserv.sourceforge.net
[11] http://diffserv.sourceforge.net
5. Security Considerations
5. セキュリティ問題
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はカーネルとユーザスペースによって切り離された独身のホストの信じられた環境に生きています。 リナックス能力は、CAP_ネット_ADMIN能力(通常根のユーザ)があるだれかだけがソケットを開けることができるのを確実にします。
6. Acknowledgements
6. 承認
1) Andi Kleen, for man pages on netlink and rtnetlink.
1) netlinkとrtnetlinkの上の男性ページアンディKleen。
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クズネツォーフはIPサービス配送モデルにNetlinkを広げるのについて称賛されます。 オリジナルのNetlinkキャラクタ装置はアラン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とドキュメントを再検討するのが、それが理解できるのを確実にするのを理解していなかっただれかの役割を果たすためのジェレミーEthridge。
Salim, et. al. Informational [Page 28] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[28ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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).
以下のダイヤグラムで、私たちは、それがCPとFEの間にサービス(ラベル1-3)のためのコンポーネントを持っているのを簡単なIPサービス、foo、および相互作用に示します。
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アドレシング。 このセクションでは、私たちはアドレシング意味論だけを例証します。 Appendix2では、ダイヤグラムは、サービス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 |----->-----|------>--
| ------------------- |
| |
| |
------------------------------------------
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) ソケットを通したfooが接続するIPサービスに接続してください。 以下には典型的な接続が呼び出しであるでしょう。 ソケット(AF_NETLINK、_生の_NETLINK FOOを強打してください)。
Salim, et. al. Informational [Page 29] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[29ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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).
これらのステップはAppendix1(したがって、付番)から続けられています。
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: Other 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.
Appendix1のダイヤグラムは、別のコントロールの部品が同じサービスを構成するのを示します。 この場合、それは独占Command線Interfaceです。 CLIは、fooの部品に交信するのにNetlinkプロトコルを使用しているかもしれません。 CLIがその時サービスfooのためにFECの方針に影響するコマンドを発行するなら、foo CPCは通知されます。 そして、それはこの入力に基づくアルゴリズムの決定をするかもしれません。 例えば、FEが別のサービスに異なったサービスでインストールされた方針を削除させて、fooがインストールした方針がサービスバーによって削除されるなら、サービスfooのすべての同輩にこれを伝播する必要があるでしょうに。
Salim, et. al. Informational [Page 30] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[30ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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.
この例では、私たちは、簡単な構成NetlinkメッセージがTC CPCから出口TC先入れ先出し法待ち行列まで発信したのを示します。 この待ち行列アルゴリズムは、パケット勘定に基づいていて、限界が100のパケットを超えていると、パケットを落とします。 そして、私たちが、待ち行列が親と共に階層的なセットアップでいると思う、100:0、aがclassidする、100:1 そして、それは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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| | | | F_が作成するNLM_| F_が要求するNLM_)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列Number(特殊活字の数字)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 過程ID(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |家族(AF_INET)| Reserved1| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースインデックス(4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qdiscハンドル(0×1000001)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 親Qdisc(0×1000000)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCMインフォメーション(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (TCA_種類)をタイプしてください。| 長さ(4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値("pfifo")| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (TCA_オプション)をタイプしてください。| 長さ(4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値(限界=100)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salim, et. al. Informational [Page 31] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[31ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
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の東北の第25アベニューのJF3-206ヒルズバロか97124-5961米国
Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
以下に電話をしてください。 +1 0334年の503 264メール: hormuzd.m.khosravi@intel.com
Andi Kleen SuSE Stahlgruberring 28 81829 Muenchen Germany
アンディKleen SuSE Stahlgruberring28 81829Muenchenドイツ
EMail: ak@suse.de
メール: ak@suse.de
Alexey Kuznetsov INR/Swsoft Moscow Russia
Alexeyクズネツォーフ・INR/Swsoftモスクワロシア
EMail: kuznet@ms2.inr.ac.ru
メール: kuznet@ms2.inr.ac.ru
Salim, et. al. Informational [Page 32] RFC 3549 Linux Netlink as an IP Services Protocol July 2003
etサリム、アル。 IPとしての情報[32ページ]のRFC3549リナックスNetlinkは2003年7月にプロトコルを修理します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Salim, et. al. Informational [Page 33]
etサリム、アル。 情報[33ページ]
一覧
スポンサーリンク
